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

<joelle.alcock_at_gmail.com> wrote in message news:1185149625.763136.122460_at_n60g2000hse.googlegroups.com...

> On Jul 18, 4:08 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:

>
> This has been analyzed before on cdt, and as I recall Brian misses the
> point that an 'individual' is only characterized by its identifying
> attributes, and that there is nothing more to its nature whatsoever.
> What we deem as identifying attributes may vary from one application
> to another, and as they do so varies the definition itself of what
> actually makes up the 'individual' too This can sounds unintuitive  to
> many (even though they naturally resolve such variations in their
> everyday conversations all the time), so I can easily see where the
> confusion comes from.
>
> I actually prefer the term 'construct' to thing, entity or individual
> within database design (even in spite of its semantic overloading)
> because it highlights that when we define an item's identifiers,
> attributes and boundaries,  we do so in our heads, that these
> definitions are not god-made, and that they can change quite happily
> from one situation to another.
>
> In this case, if you use the schema {lot_number, location} then you
> are saying that the widget construct being discussed is identified by
> the lot_number/location pair, and as far as your universe of discourse
> is concerned /that is it/. If that was not the case (and serial_number
> is the identifying attribute for the individual being constructed)
> then that should have been used. However if the attribute you defined
> as the identifying property changes, well then, it is now a different
> item according to your description of the world.
>
> I believe this very subtle issue (and it is one which I grappled with
> for a long time), but that it is the cause of many serious database
> design errors. How you identify your constructs in the real world
> should correspond to how you identify them in the database's
> propositions, otherwise your setting yourself up for a serious fall in
> the future.
>

I don't miss the point: I dismiss it not only because it is a gross oversimplification based upon faulty assumptions but also because it is incorrect. Although a key value identifies (or is a surrogate for) an individual in the Universe of Discourse, it is not correct to assume that the same key value identifies the same individual at every database value in which it appears. Here's proof: given a relation schema with two keys, one whose values rigidly designate individuals and one whose values represent non-rigid definite descriptions for individuals, there can be a tuple in each of two possible relation values that has the same value for the rigid key, but different values for the non-rigid key. Here each individual has two sets of identifying properties: one that identifies the individual at all possible states of affairs and one that identifies the individual at a particular state of affairs.

Again, the definition of a candidate key does not demand that its values designate rigidly. All that is required is that within the bounds of each possible database value, (1) each key value uniquely identifies a tuple in a relation value (and thus indirectly an individual in the Universe of Discourse) and (2) no proper subset of the key value also uniquely identifies a tuple in a relation value. Because the tuples above have the same value for the rigid key, the tuples refer to the same individual--even though they have different values for the non-rigid key. So, since it is clearly possible for different key values to identify the same individual at different database values, it is also possible for the same key value to identify different individuals at different database values.

The point is incorrect because it states "that there is nothing more to its nature whatsoever." This is another gross oversimplification, and is quite frankly, nonsense. An essential property may apply to all individuals, for example, the property that an individual can be combined with others to form atomic facts. Essential properties are part of an individual's nature, yet here's one that cannot be used to identify an individual because every individual has it. In addition, as has been shown above, there can be sets of identifying properties that are not also essential properties. Proper names are not essential properties, they are extrinsic properties that have been assigned by another individual. So, part numbers, supplier numbers, customer numbers, employee numbers--all would be considered proper names in the sense that they are rigid designators that are not also rigid definite descriptions. As such, they are not even part of the nature of the individuals they designate.

What I was trying to say when I brought this up is that there can be theoretical justifications for distinguishing one candidate key as the primary key. In fact, the only times that the choice becomes arbitrary are when more than one key rigidly designates individuals and when no key rigidly designates individuals.

--Brian Received on Mon Jul 23 2007 - 16:57:13 CEST