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

"David Cressey" <cressey73_at_verizon.net> wrote in message news:bRHni.5488$4J4.2660_at_trndny05...
>
> "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.
>

Can you please elaborate? I can't see any difference between the situations. It shouldn't matter whether there are dependent attributes in the header: a relation may have no dependent attributes but may be referenced in a foreign key constraint. Consider the relations,

R{A,B,C} and S{A,B,C,D} where S[ABC] in R[ABC].

Here R is a relation in which the entire heading is the key, but the inclusion dependency makes the values for D dependent (albeit indirectly) upon the referenced key values in R. What makes the updates peculiar must therefore be something other than having the entire header as the key. Received on Thu Jul 19 2007 - 19:23:26 CEST