Re: A real world example

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.

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

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

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 - 14:05:27 CEST