Databases Reference
In-Depth Information
seem a pity to have to deal with a constraint that's so similar to a “true” foreign key constraint in such a
roundabout manner; indeed, it could be argued that the effect is again to introduce an undesirable asymmetry,
foreign keys that reference primary keys being treated in one manner and “foreign keys” that reference
alternate keys being treated in quite another.
We could introduce a surrogate primary key ({ISNO}, say) for INV_SHIP, and use that as the foreign key in
the CONTAINER table─which would still involve a level of indirection, as in paragraph 2 above, but would
at least reintroduce the symmetry that was lost when we arbitrarily chose {INVNO} as the primary key for
To summarize: None of these four “workaround” approaches seems totally satisfactory. The example thus
seems to show that─if we wish to avoid redundancy and arbitrariness and artificiality and asymmetry and
indirectness─then we need to be able to treat primary and alternate keys as equals, and we need to be able to have
foreign keys that reference alternate keys. In other words, we need to ignore the differences between primary and
alternate keys, and simply consider them all as just keys. Please note carefully, however, that I'm not saying the
apparent need in this example to violate certain precepts of the original relational model can't be avoided; what I'm
saying is I don't see a good way to avoid it, nor a good reason for adopting a bad way. I would therefore like to
suggest that the precepts in question be treated as strong (?) guidelines but not as inviolable rules.
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
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?
Search WWH ::

Custom Search