Re: A real world example

Brian Selzer wrote:
> [snip]
> If you've read the rest of my argument, then I ask you: how can you possibly
> use a temporal attribute to make the tuples in the database instance
> preceding a change correspond to tuples in the database instance succeeding
> a change?

I'm running out of ways to explain why this doesn't make sense Brian, so let me summarize:

• Tuples can /only/ correspond if they have a common key attribute. To do so otherwise makes no logical sense.
• If there is /no/ attribute value that remains the same, then the items the propositions refer to have no correspondence. They are different.
• This isn't a problem because there is /always/ an attribute that will identify something. If your aim is to model the entity that consists of an 'item over its lifetime', then it is up to the designer to determine that key to identify that lifetime.
• If no natural key is recordable then the designer must use an artificial surrogate for it (remember the underlying natural attribute it represents does exist somewhere). That artificial surrogate /must not/ be hidden as it is an external identifer.

That's it. Nothing more to it. Can anyone else see any holes in this logic, or am I losing the plot? Received on Thu Aug 17 2006 - 05:08:14 CDT