Databases Reference
In-Depth Information
Appendix A
P r i m a r y K e y s A r e N i c e
b u t N o t E s s e n t i a l
Life is rather like a tin of sardines─
we're all of us looking for the key
─Alan Bennett:
Beyond the Fringe
Note:
Portions of this appendix originally appeared in somewhat different form in my topic
Relational Database
Writings 1991-1994
(Addison-Wesley, 1995).
Recall this text from Chapter 1:
I said it's
usual
to choose a primary key. Indeed it is usual─but it's not 100 percent necessary. If there's just one
candidate key, then there's no choice and no problem; but if there are two or more, then having to choose one and make it
primary smacks a little bit of arbitrariness, at least to me. (Certainly there are situations where there don't seem to be any
good reasons for making such a choice. There might even be good reasons for not doing so. Appendix A [
i.e., the
present appendix
] elaborates on such matters.)
Now, the position articulated in this extract clearly flies in the face of conventional wisdom, somewhat; it
might even be said to contravene certain widely accepted precepts of the relational model, or of relational theory in
general. To be specific:
Out of the (necessarily nonempty) set of keys possessed by a given relvar, the relational model as originally
defined ascribes a primal role to an arbitrarily chosen member of that set called the
primary
key.
Relational design methodologies (though not the relational model per se) tend to suggest, again a trifle
arbitrarily, that a given “entity” should be identified and referenced throughout the database by the same
(primary) key value everywhere it's represented.
As indicated, however, these recommendations─some might even call them
prescriptions
─both involve a
certain degree of arbitrariness. The first in particular has always been the source of some slight embarrassment to
relational advocates (myself included). One of the strongest arguments in favor of the relational model is and
always has been its claim to a solid logical foundation. However, whereas this claim is clearly justified for the most
part, the distinction between primary and alternate keys
1
─i.e., the idea of having to choose one member from a set of
equals and make it somehow “more equal than the others”─has always seemed to rest on grounds that don't enjoy
the same degree of theoretical respectability. Certainly there doesn't seem to be any
formal
justification for the
distinction; it seems to smack more of dogma than logic, which is why (as I said) I find the situation embarrassing.
1
The term
alternate key
was defined in Chapter 1, but I repeat the definition here for convenience: Let relvar
R
have two or more keys and let
one be chosen as primary; then the others are
alternate
keys. The term isn't used much in practice, but I do need to use it in this appendix.
