M Relationships Between Strong Entities

N:M Relationships Between Strong Entities

Again, we must first create the database design tables from the data model entities, and then create the relationship. However, the situation for N:M relationships is more complicated.

Figure 6-9

COMPANY

DEPARTMENT

Representing a 1:N DepartmentName Relationship Between

Strong Entities

Country

MailStop

Volume (a) 1:N Relationship Between Strong Entities

CompanyName (FK) (b) Placing the Primary Key of the Parent in the Child as a Foreign Key

Volume

Chapter 6 Transforming Data Models into Database Designs

QuantityOnHand (a) The Foreign Key Has No Place in Either Table

ReOrderQuantity QuantityOnHand

COMPANY_PART_INT CompanyName (FK)

Figure 6-10

PartNumber (FK)

Representing an N:M Relationship Between Strong Entities

(b) Foreign Keys Placed in ID-Dependent Intersection Table

The problem is that there is no place in either table in an N:M relationship in which to place the foreign key. Consider the example in Figure 6-10(a), which shows a relationship between COMPANY and PART that specifies which companies can supply which parts. A COMPANY may supply many PARTs, and a PART may be supplied by many different COMPANY(ies).

Suppose we try to represent this relationship by placing the primary key of one table as a foreign key in the second table, as we did for 1:N relationships. Say we place the primary key of PART in COMPANY as follows:

COMPANY (CompanyName, City, Country, Volume, PartNumber) PART (PartNumber, PartName, SalesPrice, ReOrderQuantity, QuantityOnHand)

With this design, a given PartNumber may appear in many rows of COMPANY so that many companies can supply the part. But, how do we show that a company can supply many parts? There is only space to show one part. We do not want to duplicate the entire row for a company just to show a second part; such a strategy would result in unacceptable data duplication and data integrity problems. Therefore, this is not an acceptable solution, and a similar problem will occur if we try to place the primary key of COMPANY, CompanyName, into PART as a foreign key.

The solution is to create a third table, called an intersection table. Such a table shows the correspondences of a given company and a given part. It holds only the primary keys of the two tables as foreign keys, and this combination of keys serves as the composite primary key of the intersection table itself. The intersection holds only the key data; it contains no other user data. For the example in Figure 6-10(a) we create the following intersection table:

COMPANY_PART_INT (CompanyName, PartNumber)

The COMPANY_PART_INT table has one row for each company–part combination. Notice that both columns are part of the primary key, and that each column is a foreign key to

Part 2 Database Design

a different table. Because both columns are keys of other tables, intersection tables are always ID-dependent on both of their parent tables and the relationships with the parent tables are identifying relationships.

Thus, while the database design in Figure 6-10(a) is drawn with a nonidentifying N:M relationship between two strong entities, in Figure 6-10(b) COMPANY_PART_INT is shown as ID-dependent with identifying relationship lines. Like all ID-dependent tables, the parent tables are required; COMPANY_PART_INT requires both a COMPANY and PART. The parents may or may not require an intersection table row, depending on application requirements. In Figure 6-10 (b), a COMPANY need not supply a PART, but a PART must be supplied by at least one COMPANY.

The problem for the data models of N:M relationships between strong entities is that they have no direct representation. An N:M relationship must

always be decomposed into two 1:N relationships using an intersection table in the database design. This is why products like MySQL Workbench are unable to represent N:M relationships in a data model. These products force you to make the transformation to two 1:N relationships ahead of time, during modeling. As stated in Chapter 5, however, most data modelers consider this requirement to be a nuisance because it adds complexity to data modeling when the whole purpose of data modeling is to reduce complexity to the logical essentials.