1:1 Relationships Between Strong Entities

1:1 Relationships Between Strong Entities

After the tables corresponding to the strong entities have been designed, a 1:1 relationship between these entities can be represented in one of two ways. You can place the primary key of the first table in the second as a foreign key, or you can place the primary key of the second table in the first as a foreign key. Figure 6-8 shows the representation of the 1:1 nonidentifying relationship between CLUB_MEMBER and LOCKER. In Figure 6-8(a), MemberNumber is placed in LOCKER as a foreign key. In Figure 6-8(b), LockerNumber is placed in CLUB_MEMBER as a foreign key.

Either of these designs will work. If you have a club member’s number and want his or her locker, then using the design in Figure 6-8(a) you can query the LOCKER table for the given value of MemberNumber. But, if you have the LockerNumber and want the club member’s data, then, using the design in Figure 6-8(a), you can query the LOCKER table for the Locker- Number, obtain the MemberNumber, and use that value to query the CLUB_MEMBER table for the rest of the club member’s data.

Follow a similar procedure to verify that the design in Figure 6-8(b) works as well. However, one data constraint applies to both designs. Because the relationship is 1:1, a given value of a foreign key can appear only once in the table. For example, in the design in Figure 6-8(a), a given

Figure 6-8

CLUB_MEMBER

LOCKER

The Two Alternatives for LockerNumber Representing a 1:1

Relationship Between

Phone

LockerSize

Strong Entities

Email

MemberNumber (FK) (AK1.1)

(a) With Foreign Key in LOCKER

CLUB_MEMBER

Email LockerNumber (FK) (AK1.1)

(b) With Foreign Key in CLUB_MEMBER

Part 2 Database Design

value of MemberNumber can appear just once; each value must be unique in the LOCKER table. If a value of MemberNumber were to appear in two rows, then a member would be assigned to two lockers, and the relationship would not be 1:1.

To cause the DBMS to enforce the required uniqueness of the foreign key value, we define the foreign key column as unique. This can be done either directly in the column definition of the foreign key (in which case there is no designation in the table diagram) or by defining the foreign key as an alternate key. This latter technique, though common, is a bit confusing because, logically, MemberNumber is not an alternate key for LOCKER. We are just using the fact that alternate keys are unique to document the uniqueness of the foreign key in a 1:1 relationship. Depending on the database design software being used, the alternate key designa- tion may appear in the database design of the tables and the relationship, and this is illustrated in Figure 6-8(a). A similar technique is used on the foreign key LockerNumber in Figure 6-8(b).

Figure 6-8 shows the minimum cardinalities of the relationship as optional-optional (O-O), and in this case either of the designs in Figure 6-8 will work, although the design team may prefer one over the other. However, if the minimum cardinalities of the relationship are either mandatory-optional (M-O) or optional-mandatory (O-M), then one design will be greatly preferred, as you will learn in the section on minimum cardinality design later in this chapter. Also, application requirements may mean that one design is faster than the other.

To summarize, to represent a 1:1 strong entity relationship, place the key of one table in the other table. Enforce the maximum cardinality by defining the foreign key as unique (or as an alternate key).