In this appendix I’ve presented a number of pragmatic arguments for:
Relaxing the commonly accepted rule that every base relvar have a distinguished key called the primary key
Relaxing the (perhaps less commonly accepted) rule that every foreign key refer specifically to a primary key instead of to an alternate key[179]
Relaxing the commonly accepted rule that there be exactly one anchor relvar for each entity type
Of course, I’m well aware that if we do relax these rules, then we open the door to the possibility of bad designs. That’s why I recommend retaining recommendations such as “one primary key per entity type” as rules of thumb, or good design guidelines. In other words, the rules in question should be violated only if there’s some really good reason for doing so. But I’ve tried to show in this appendix that sometimes such good reasons do exist.
[179] I say less commonly accepted because—to its credit—the SQL standard, at least, does allow foreign keys to reference any candidate key.