Re: A real world example

"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:1155809294.447326.279260_at_m73g2000cwd.googlegroups.com...
> 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:
>

I understand why it doesn't make sense. That's my entire argument. If something can have its appearance altered and still be the same thing, and if the only way to compare things is by their appearance, then you can't tell if two sets contain the same things unless you know how each of their appearances has changed or unless you know that the appearance of only one of them has changed.

> * Tuples can /only/ correspond if they have a common key attribute. To
> do so otherwise makes no logical sense.
>

If you know that the tuples in the proposed instance correspond to those in the current instance, and you know that only one tuple has a different key value, then the one that doesn't correspond by the key values is the one that is different.

If you know how to identify tuples in one instance and you know how to identify tuples in another and if you know how they're supposed to correspond, then instead of issuing a single assignment containing all of the changes, you can issue a series of individual assignments where only one tuple is different in each. (e.g., FOR EACH ROW)

Of course, issuing a series of assignments introduces its own problems. For example, consider a self-referencing relation. If any of the assignments changes the only key in a tuple that is referenced by another, then the database will be inconsistent until the new value for the referencing tuple is assigned.

> * If there is /no/ attribute value that remains the same, then the
> items the propositions refer to have no correspondence. They are
> different.
>

This is true only if by "attributes" you mean the properties of something, including those that are not included in the propositions about it. If you are referring to "attributes" as the set of attributes included in a proposition, then "They are different." must become "You can't tell whether or not they're the same."

> * 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.
>

Then the model should take this into account in its definition. That may embody changing the definition of a key, or changing its treatment of attributes in the definition of a relation schema, or both. You can define multiplicity constraints, and that is defined in the model. Maybe you could define mutability constraints, and include that in the model. Maybe the entity integrity rule could be changed to include restrictions against mutable attributes as well as nullable attributes. I don't know. All I know is that I can break it, and that should be addressed somehow.

> * 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.
>

I would have said, "If no natural key is both recordable and immutable then the designer must use an artifical surrogate for it."

> 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 - 13:50:01 CEST