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

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:9AAni.22576$RX.8592_at_newssvr11.news.prodigy.net...
>
> "David Cressey" <cressey73_at_verizon.net> wrote in message
> news:nvsni.7235$fP4.2538_at_trndny07...
> >
> > "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> > news:7bqni.22449$RX.18708_at_newssvr11.news.prodigy.net...
> >>
> >> "David Cressey" <cressey73_at_verizon.net> wrote in message
> >> news:Cmhni.6545$Gx5.2883_at_trndny02...
> >> >
> >> > "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> >> > news:oXdni.23174$Rw1.4623_at_newssvr25.news.prodigy.net...
> >
> >> >
> >> > widgets do not have identity in this scheme.
> >>
> >> Ah, but they do. {lot_number, location} is a key. You could also have
a
> >> relation widgit_part_numbers {lot_number, location, customer,
> >> customer_part_number} that references widgits. What widgits don't have
> >> is
> >> rigid designation. That's the problem: it cannot be determined if a
> >> referent at one possible database value is the same as a referent at
> >> another.
> >
> > I think you and I mean something different by "identity".
> >
> > lot_number is not an attribute of a widget, if I understand your
subject
> > matter correctly. It's an attribute of a lot, and a widget is a member
> > of
> > a lot.
> >
> > location is not an attribute of a widget either. It's an attribute of
a
> > location (sorry about overloading the word "location"), and a widget
can
> > be stored at a location.
> >
> > You can't identify an entity solely by listing attributes of other
> > entities
> > to which the entity in question has (possibly temporal) relationships.
> >
> > Hence {lot_number, location} can't be the identity of a widget. The
> > relation isn't really about widgets. It's about widget placements.
And,
> > if you can store more than one widget from a lot in a location, it
isn't
> > even a relation; it's a bag.
> >
>
> I think another example is in order. The focus has changed from the
> theoretical problem with definite descriptions to a discussion of widgits.
> Consider this:
>
> Appointments {UserId, Start, Duration, Description} where {UserId, Start}
is
> the key. (Ignore for the moment that Appointments cannot overlap.} In
this
> case the key is again a definite description that is not rigid. Suppose
> that you had scheduled a thirty-minute appointment tomorrow at 2:00pm at
the
> barber.

The comment I made that started this exchange between you and me was with regard to a situation where the key is the entire header. This is a different situation. Updates to a relation whose key is the entire header are peculiar... not mathematically, but in terms of the semantics of the data. Received on Thu Jul 19 2007 - 13:23:51 CEST