Representing Ternary and Higher-Order Relationships
Representing Ternary and Higher-Order Relationships
As we discussed in Chapter 5, ternary and higher-order relationships can be represented by multiple binary relationships, and such a representation usually works without any problems. However, in some cases, there are constraints that add complexity to the situation. For example, consider the ternary relationship among the entities ORDER, CUSTOMER, and SALESPERSON. Assume that the relationship from CUSTOMER to ORDER is 1:N and that the relationship from SALESPERSON to ORDER also is 1:N. We can represent the three-part relationship among ORDER:CUSTOMER:SALESPERSON as two separate binary relationships: one between ORDER and CUSTOMER and a second between SALESPERSON and CUSTOMER. The design of the tables will be:
CUSTOMER (CustomerNumber, {nonkey data attributes}) SALESPERSON (SalespersonNumber, {nonkey data attributes}) ORDER (OrderNumber, {nonkey data attributes}, CustomerNumber,
SalespersonNumber)
Part 2 Database Design
Suppose, however, that the business has a rule that each CUSTOMER can place orders only with a particular SALESPERSON. In this case, the ternary relationship ORDER: CUSTOMER:SALESPERSON is constrained by an additional binary 1:N relationship between SALESPERSON and CUSTOMER. To represent the constraint, we need to add the key of SALESPERSON to CUSTOMER. The three tables will now be:
CUSTOMER (CustomerNumber, {nonkey data attributes}, SalespersonNumber) SALESPERSON (SalespersonNumber, {nonkey data attributes}) ORDER (OrderNumber, {nonkey data attributes}, CustomerNumber,
SalespersonNumber)
The constraint that a particular CUSTOMER is sold to by a particular SALESPERSON means that only certain combinations of CustomerNumber and SalespersonNumber can exist together in ORDER. Unfortunately, this constraint cannot be expressed in a relational model. It must be documented in the design, however, and enforced by program code, as shown in Figure 6-23.
A constraint that requires one entity to be combined with another entity is called a MUST constraint. Other similar constraints are the MUST NOT constraint and the MUST COVER constraint. In a MUST NOT constraint, the binary relationship indicates combina- tions that are not allowed to occur in the ternary relationship. For example, the ternary relationship PRESCRIPTION:DRUG:CUSTOMER shown in Figure 6-24 can be constrained by a binary relationship in the ALLERGY table that lists the drugs that a customer is not allowed to take.
In a MUST COVER constraint, the binary relationship indicates all combinations that must appear in the ternary relationship. For example, consider the relationship AUTO_REPAIR: REPAIR:TASK in Figure 6-25. Suppose that a given REPAIR consists of a number of TASKs, all of which must be performed for the REPAIR to be successful. In this case, in the table AUTO_REPAIR, when a given AUTO_REPAIR has a given REPAIR, then all of the TASKs for that REPAIR must appear as rows in that table.
None of the three types of binary constraints discussed here can be represented in the rela- tional design. Instead, they are documented in the design and implemented in application code.
Figure 6-23
SALESPERSON Table
Ternary Relationship with SalespersonNumber
Other nonkey data
a MUST Constraint
CUSTOMER Table
CustomerNumber
Other nonkey data
Binary MUST Constraint ORDER Table
OrderNumber
Other nonkey data
Only 20 is allowed here
Chapter 6 Transforming Data Models into Database Designs
DRUG Table DrugNumber
Other nonkey data
ALLERGY Table CustomerNumber
DrugNumber
Other nonkey data
Binary MUST NOT Constraint PRESCRIPTION Table PrescriptionNumber
Other nonkey data
Figure 6-24
2000 Ternary Relationship with
a MUST NOT Constraint
Neither 20 nor 45 can appear here
REPAIR Table
RepairNumber
Other nonkey data
TASK Table TaskNumber
Other nonkey data
Binary MUST COVER Constraint AUTO_REPAIR Table
Other nonkey data
Figure 6-25
Ternary Relationship with a MUST COVER Constraint
2002 must appear here
Part 2 Database Design
ProfessorFirstName ProfessorLastName
DeanFirstName
Phone
Chairs / Chairs By
Room APPOINTMENT
Major Title Terms
STUDENT StudentNumber
Title StudentFirstName StudentLastName HomeStreet
Advises / Advised By
HomeCity
Figure 6-26
HomeState HomeZip
Data Model for Highline
Phone
University in Figure 5-52