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

From: Brian Selzer <>
Date: Sun, 29 Jul 2007 06:22:27 GMT
Message-ID: <DmWqi.24865$>

"David Cressey" <> wrote in message news:YZEqi.151$Kk4.114_at_trndny09...
> "Brian Selzer" <> wrote in message
> news:1Uuqi.29231$
>> "paul c" <> wrote in message
>> news:wo1qi.7977$fJ5.772_at_pd7urf1no...
>> > David Cressey wrote:
>> >> "Brian Selzer" <> wrote in message
>> >> news:DjPpi.24618$
>> >>
>> >>
>> >>>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.
> The term "rigid" in this usage is new to me, with this discussion. Maybe
> its time to ask for a formal definition.
> What is the distinction betweeb "rigid" and "immutable"?

The property of being rigid fixes the meaning of an expression. Immutability has nothing to do with meaning.

> Does rigid imply immutable and vice versa?

No. A rigid key can be the target of an update. An immutable key cannot. An update that targets a rigid key selects a different individual.

> What is the benefit of a non rigid identifier?

It provides another means to denote an individual.

Consider a relation that has two attributes that represent different sets of individuals. For example, men and women paired in a dance. Both attributes are candidate keys because one man cannot be paired with more than one woman at the same time, nor can one woman be paired with more than one man at the same time. It is easy to see that two dance pairs can swap partners; therefore, it should be obvious that none of the candidate key values permanently identifies a dance pair.

> Do you call that a "limp" identifier?

I think I read somewhere that the correct term is "flaccid."

> Isn't immutability one of the criteria for a candidate key of a relation?

No. It isn't.

Received on Sun Jul 29 2007 - 08:22:27 CEST

Original text of this message