I turn now to the second of the two issues mentioned in the introduction to this appendix: viz., that entities of a given type are supposed to be identified in exactly the same way everywhere in the database. What this means, loosely speaking, is that there’ll typically be:
A single “anchor” relvar for the pertinent entity type, having some particular primary key, together with
Zero or more subsidiary relvars giving further information about entities of that type, each having a foreign key that refers back to the primary key of that anchor relvar.
(Does this state of affairs remind you of the RM/T discipline discussed in Chapter 15?) But several obvious questions arise:
Might there not be good reasons to have more than one anchor relvar for a given entity type—perhaps corresponding to different “roles” (see the section immediately following) for that entity type?
If there are several such anchor relvars, might there not be good reasons to have different primary keys in different anchor relvars—thus implying that the same entity might be identified in different ways in different contexts?
Hence, might there not be good reasons to have different foreign keys in different relvars that, again, identify the same entity in different ways in different contexts?
Finally, might there not even be good reasons to have several distinct identifiers, all of equal weight, for the same entity in the same relvar?
We’ve already seen several examples in this appendix (in the section RELVARS WITH MORE THAN ONE KEY) in which the answer to the last of these questions is clearly yes. In order to examine the other questions, let’s consider another example.