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

"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.
Appointments:

{{UserId="DAVIDC", Start="2007-07-19 14:00:00",

    Duration=1800, Description="Barber"}}

but you got a ticket and have to go to Traffic Court at the same time, so you need to reschedule the visit to the barber to Friday, and insert a new appointment for Traffic Court. So you issue the following transaction:

BEGIN TRAN
UPDATE Appointments SET Start="2007-07-20 14:00:00"

    WHERE UserId="DAVIDC" AND Start="2007-07-19 14:00:00" INSERT Appointments (UserId, Start, Duration, Description)   VALUES ("DAVIDC", "2007-07-19 14:00:00", 7200,"Traffic Court"} COMMIT This results in the following relation:

Appointments:

{{UserId="DAVIDC", Start="2007-07-20 14:00:00",
    Duration=1800, Description="Barber"},
 {UserId="DAVIDC", Start="2007-07-19 14:00:00",
    Duration=7200, Description="Traffic Court"}}

Now it is clear that the intent behind the transaction is to push the barber shop visit to Friday and to schedule the visit to Traffic Court. So what we have is a situation where

{UserId="DAVIDC", Start="2007-07-19 14:00:00"}

identifies a different individual at different possible database values, one a barber shop visit and one a traffic court visit, and that

{UserId="DAVIDC", Start="2007-07-19 14:00:00"}

at the database value prior to the transaction identifies the same individual as

{UserId="DAVIDC", Start="2007-07-20 14:00:00"}

at the database value after the transaction, which is the barber shop visit. Received on Thu Jul 19 2007 - 05:07:49 CEST