Relationships in Mixed Entity Designs
Relationships in Mixed Entity Designs
As you might guess, the design of mixed entity patterns is a combination of strong entity and ID-dependent entity designs. Consider the example of employees and skills in Figure 6-17. Figure 6-17(a) is a copy of Figure 5-35. Here, the entity EMPLOYEE_SKILL is ID dependent on EMPLOYEE, but it has a nonidentifying relationship to SKILL.
SKILL Transformation of the
Figure 6-17
EmployeeNumber Name Mixed Entity Pattern
EMPLOYEE_SKILL
EMPLOYEE_SKILL
EmployeeNumber
EmployeeNumber (FK)
CourseTaken Name (FK)
(a) Data Model with Mixed Entity
(b) Database Design for
Pattern from Figure 5-35
Mixed Entity Pattern
Part 2 Database Design
The database design of the E-R model for the data model in Figure 6-17(a) is shown in Figure 6-17(b). Notice that EmployeeNumber is both a part of the primary key of EMPLOYEE_SKILL and also a foreign key to EMPLOYEE. The 1:N nonidentifying relationship between SKILL and EMPLOYEE_SKILL is represented by placing the key of SKILL, which is Name, in EMPLOYEE_SKILL. Note that EMPLOYEE_SKILL.Name is a foreign key but not part of the primary key of EMPLOYEE_SKILL.
A similar strategy is used to transform the SALES_ORDER data model in Figure 6-18. Figure 6-18(a) is a copy of the SALES_ORDER data model originally shown in Figure 5-33. In Figure 6-18(b), the ID-dependent table, ORDER_LINE_ITEM, has SalesOrderNumber as part of its primary key and as a foreign key. It has ItemNumber as a foreign key only.
The design transformation process for all HAS-A relationships can be summarized by the phrase, “Place the primary key of the parent in the child
as a foreign key.” For strong entities, a 1:1 relationship can have either entity as the parent, and therefore the foreign key can go in either table. For 1:N relationships, the primary key of the parent goes in the child as the foreign key. For N:M relationships, decompose the model into two 1:N relationships by defining an intersection table and place the parent key of the parent in the child as a foreign key for each.
For identifying relationships, the primary key of the parent is already in the child, so there is nothing more to do. For mixed relationships, on the identifying side, the primary key of the parent is already in the child. On the nonidentifying side, place the primary key of the parent in the child. In short, if you’re going to memorize just a few rules for creating relationships, the first one is “HAS-A: Place the primary key of the parent in the child as the foreign key.”
Figure 6-18
Transformation of the SALES_ORDER Pattern
CUSTOMER
CUSTOMER
SALESPERSON CustomerID
CustomerID
SalespersonID LastName
SalespersonLastName Address
Address
SalespersonFirstName City
SalespersonLastName
City
SalespersonCode State
SALES_ORDER
SALES_ORDER Phone
SalesOrderNumber SalesOrderNumber
CustomerID (FK)
ItemNumber
SalespersonID (FK) ITEM ItemNumber
UnitPrice Description
UnitPrice ORDER_LINE_ITEM
Description SalesOrderNumber
ORDER_LINE_ITEM
LineNumber SalesOrderNumber (FK) LineNumber
Quantity UnitPrice
Quantity
ExtendedPrice
UnitPrice ExtendedPrice ItemNumber (FK)
(a) Data Model of SALES_ORDER (b) Database Design for the Pattern from Figure 5-33
SALES_ORDER Pattern
Chapter 6 Transforming Data Models into Database Designs
isGradStudent isGradStudent
isGradStudent
UNDERGRADUATE
GRADUATE StudentID
GRADUATE
UNDERGRADUATE
StudentID (FK) HighSchoolGPA
StudentID
StudentID (FK)
UndergraduateGPA ScoreOnSAT
(a) Data Model of the Supertype/Subtype (b) Database Design for the Relationship from Figure 5-13(a)
Supertype/Subtype Relationship
Figure 6-19
Transformation of the
Relationships Between Supertype and Subtype Entities
Supertype/Subtype Entities
Representing relationships between supertype entities and their subtypes is easy. Recall that these relationships are also called IS-A relationships because a subtype and its super- type are representations of the same underlying entity. A MANAGER (subtype) is an EMPLOYEE (supertype), and a SALESCLERK (subtype) is also an EMPLOYEE (supertype). Because of this equivalence, the keys of all subtype tables are identical to the key of the supertype table.
Figure 6-19(a) shows the data model in Figure 5-13(a), an example for two subtypes of STUDENT. Notice that the key of STUDENT is StudentID and that the key of each of the subtypes also is StudentID. UNDERGRADUATE.StudentID and GRADUATE.StudentID are both primary keys and foreign keys to their supertype.
Discriminator attributes cannot be represented in relational designs. In Figure 6-19(b), we can do nothing with isGradStudent except note in the design documentation that isGradStudent determines subtype. Application programs will need to be written to use isGradStudent to determine which subtype pertains to a given STUDENT.