Re: A real world example

From: Brian Selzer <brian_at_selzer-software.com>
Date: Thu, 17 Aug 2006 12:35:19 GMT
Message-ID: <boZEg.10181$kO3.4369@newssvr12.news.prodigy.com>

"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:1155816327.644741.10320_at_p79g2000cwp.googlegroups.com...

> Brian Selzer wrote:

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

>
> I was referring to why tuples between relation-values cannot correspond
> if they do not have a common key.
>

And I agree entirely.

>> 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,

>
> You can /only/ know that by comparing a key value that maintains
> identity over the lifetime of the item, as specified by your design
> choice.
>

The database can /only/ know that. The originator of the change can know, however. But again, that pushes the responsibility to enforce constraints onto the user.

>> 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,

>
> wuh? Now you are referring to a schema change? If not, tuples are
> identified the same way across relation values.
>

No. Not if "you" is the originator of the change.

> Perhaps bob was right, I give up. I think your notion of how we record
> identity is flawed. Maybe oid's are what you are looking for if that is
> the case.
>

>> 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 - 07:35:19 CDT