Re: A pk is *both* a physical and a logical object.

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:oXdni.23174$Rw1.4623_at_newssvr25.news.prodigy.net...
>
> "David Cressey" <cressey73_at_verizon.net> wrote in message
> news:hbcni.9923$yx4.9381_at_trndny08...
> >
> > "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> > news:_jani.39744$Um6.23567_at_newssvr12.news.prodigy.net...
> >>
> >> "Roy Hann" <specially_at_processed.almost.meat> wrote in message
> >> news:7e2dncCYhYD45wHbRVnytAA_at_pipex.net...
> >> > "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> >> > news:1Pwmi.39574$Um6.32783_at_newssvr12.news.prodigy.net...
> >> > [snip]
> >> >> In addition, the definition of a candidate key does not demand that
> >> >> its
> >> >> values rigidly designate individuals in the universe of discourse.
> >> >
> >> > I've been waiting for someone else to pick up on this comment, but
> >> > since
> >> > they haven't I'm going to bite. When you talk about "individuals"
> >> > here,
> >> > do you intend that to be understood as "individual propositions"?
> >> >
> >> No.
> >> > My layman's understanding is that the value of a candidate key most
> >> > definitely *is* a unique identifier (and is irreducible).
> >> >
> >>
> >> Indeed. But does the same key value identify the same individual in
all
> >> possible relation values? Clearly this is not the case. Consider a
> >> relation schema in which the entire heading is the key. Now suppose
that
> > a
> >> user issues a update. The tuple that identified an individual in the
> >> universe prior to the update is now different from the tuple that
> > identifies
> >> the same individual after the update. Because the entire heading is
the
> >> key, it is clear that although the key uniquely identifies an
individual
> > and
> >> is irreducible, it does not rigidly designate that individual. A rigid
> >> designator identifies the same individual in all possible relation
> >> values,
> >> not just the one that happens to be actual at any given point in time.
> >>
> >
> > You can call what the user issued an update, if you care to, but what
> > really happened is that an individual, identified by the before value
of
> > the key, was deleted, and a new individual, identified by the after
> > value
> > of the key was inserted. The fact that the old value and the new value
> > used
> > the same storage ("row", if you like) is irrelevant. They are
different
> > values, and they designate different individuals.
> >
>
> Not so. Consider the following statement:
>
> I moved the widgit with lot number 203 at location 22 to location 44.
>
> Now assuming that there can only be one widgit from the same lot at a
> particular location, then the definite description before the update,
>

widgets do not have identity in this scheme. If you only have a table describing
widgets (lot_number, location), then you don't have a table designed to store the fact

"I moved the widget with lot number 203 at location 22 to location 44".

You can only express the following:

"The widget with lot number 203 at location 22 no longer exists,   and there is now a widget with lot number 203 at location 44."

The table deosn't tell you whether a widget was moved, or whether a widget was removed, and another one inserted somewhere else.

And if you modify the table(s) so that you CAN store the above fact, you will no longer have a case where the key is the entire header. Received on Wed Jul 18 2007 - 07:16:18 CEST