Table Relationships - Database Design for Mere Mortals - page 303

the appropriate stages of the database design process until you return to this point. You
shouldn't encounter any problems with the tables if you've been following proper proced-
ures thus far.
Refining All Foreign Keys
You now know that a primary key becomes a foreign key when you use it to establish a
relationship between a pair of tables in a one-to-one or one-to-many relationship. As with
any other key that you've worked with so far, a foreign key must comply with a specific
set of elements. These elements are collectively known as the Elements of a Foreign Key.
Elements of a Foreign Key
• It has the same name as the primary key from which it was copied. You should ad-
here to this rule unless there is an absolutely compelling reason not to do so.
(Review the discussion of the Alias field specification element in Chapter 9 , “ Field
Specifications . ” It provides an example of an occasion when you might decide to
break this rule.) Consider the relationship diagram in Figure 10.51 , and note that
the foreign keys have different names than the primary keys to which they refer.
Figure 10.51. Primary keys and foreign keys with mismatched names
The fact that the names are different poses a problem because you can't be sure
that the foreign keys are truly valid and actually refer to the primary keys. Is E MP #
truly equivalent to E MPLOYEE N UMBER ? Is “Emp” really a shortened version of