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

From: Brian Selzer <brian_at_selzer-software.com>
Date: Sun, 29 Jul 2007 15:51:32 GMT
Message-ID: <8I2ri.24899$RX.20955@newssvr11.news.prodigy.net>

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:2tyqi.11337$rX4.9610_at_pd7urf2no...

> Brian Selzer wrote:

>> "paul c" <toledobythesea_at_oohay.ac> wrote in message
>> news:wo1qi.7977$fJ5.772_at_pd7urf1no...
>>
>>>David Cressey wrote:
>>>
>>>>"Brian Selzer" <brian_at_selzer-software.com> wrote in message
>>>>news:DjPpi.24618$Rw1.11254_at_newssvr25.news.prodigy.net...
>>>>
>>>>
>>>>
>>>>>This illustrates what happens when the only key on a relation schema
>>>>
>>>>permits
>>>>
>>>>
>>>>>updates. It can't be determined if a new individual is being selected,
>>>>>or
>>>>>if the state of the current individual is now different.
>>>>
>>>>
>>>>This is the point I have been trying to make for the past week or so.
>>>>The
>>>>mathematics of the relational data model don't, in this case,
>>>>disambiguate
>>>>two profoundly different scenarios in the real world the data purports
>>>>to
>>>>describe.
>>>>...
>>>
>>>David, what does it matter?
>>>
>>>The user/audience can agree to disambiguate/interpret however it suits
>>>their purpose/application.
>>>
>>>What is the possible usefulness of using this term "rigid" to describe a
>>>key?
>>>
>>
>>
>> It is a simple and precise term that describes a class of identifiers.
>> There are keys whose values identify a specific individual at all
>> database values, and there are keys whose values identify a specific
>> indivdual at some database values. For example, a relation that models
>> an ordered set has two keys, one that represents names for elements and
>> one that represents positions for elements. Both meet all of the
>> criteria for a candidate key (uniqueness and irreducibility), but only
>> the one that represents names permanently identifies each element, since
>> at different database values, a particular element may be in different
>> positions.
>>

>
> I repeat, what does it matter?  If it happens to be a simple and precise 
> term, so what, eg., what is the point?  What is the possible use?  Eg., 
> why would this notion ever matter to a dbms?
>

Given a choice between a key that permanently identifies individuals and a key that contingently identifies individuals, which would you choose to be the primary key, and thus the target of all foreign keys? Don't you see a problem with a relation that represents the histories of a set of individuals where those individuals are denoted only by a set of attributes that contingently identify them?

But requiring that all key values permanently identify individuals significantly limits the expressiveness of the model, cutting in half the expressions that can be used to denote individuals, thereby reducing the number of queries that can be formulated. Referring to my previous example, a query such as "Which part has lot number 203 in location 22?" could not be considered deterministic if the key, {lot_number, location}, were not defined, and thus should be rejected as being formulated incorrectly. Without that key, there can be more than one part with lot number 203 in location 22, and you can't stuff a relation value into a tuple variable.

> If somebody will please answer this question, I'll stop asking it!
>
> p 

Received on Sun Jul 29 2007 - 10:51:32 CDT