Re: A real world example
Date: Thu, 17 Aug 2006 12:35:19 GMT
Message-ID: <boZEg.10181$kO3.4369_at_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.
>>>> > do so otherwise makes no logical sense.
>> > * Tuples can /only/ correspond if they have a common key attribute. To
>> >
>>
>> 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.
>>>> > different.
>> > * If there is /no/ attribute value that remains the same, then the
>> > items the propositions refer to have no correspondence. They are
>> >
>>
>> 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."
>>>> > that key to identify that lifetime.
>> > * 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
>> >
>>
>> 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.
>>>> > not/ be hidden as it is an external identifer.
>> > * 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
>> >
>>
>> I would have said, "If no natural key is both recordable and immutable
>> then
>> the designer must use an artifical surrogate for it."
>>>> > logic, or am I losing the plot?
>> > That's it. Nothing more to it. Can anyone else see any holes in this
>> >
> Received on Thu Aug 17 2006 - 14:35:19 CEST