Relational Representation of the Highline University Data Model

Relational Representation of the Highline University Data Model

Let’s consider the data model we created for Highline University in Chapter 5. Our final data model for Highline University is shown in Figure 6-26.

Using the principles we have discussed in this chapter, we can turn this into a relational

Figure 6-27

database design, and the resulting database design is a straightforward application of the principles

Database Design for

described in this chapter. The database design for Highline University is shown in Figure 6-27.

Highline University COLLEGE

DEPARTMENT

PROFESSOR

Chairs / Chaired By

CollegeName

DepartmentName

ProfessorFirstName ProfessorLastName

Building Phone

TotalMajors

OfficeNumber Building

Room

Phone Room

CollegeName (FK)

ProfessorFirstName (FK) (AK1.1) ProfessorLastName (FK) (AK1.2)

Major

APPOINTMENT

DepartmentName (FK)

STUDENT

ProfessorFirstName (FK) ProfessorLastName (FK)

DepartmentName (FK) StudentFirstName StudentLastName HomeStreet HomeCity HomeState

Adviser

HomeZip Phone ProfessorDepartment (FK) ProfessorFirstName (FK) ProfessorLastName (FK)

Chapter 6 Transforming Data Models into Database Designs

You should review Figure 6-27 to ensure that you understand the representation of every relationship. Note that there are actually two foreign key references to a DepartmentName primary key column in STUDENT. The first is DepartmentName (FK), which is the foreign key linking to the DepartmentName primary key in DEPARTMENT. This relationship has the referential integrity constraint:

DepartmentName in STUDENT must exist in DepartmentName in DEPARTMENT The second is ProfessorDepartment (FK), which is part of the composite foreign key

(ProfessorDepartment, ProfessorFirstName, ProfessorLastName). This foreign key links to the primary key (DepartmentName, ProfessorFirstName, ProfessorLastName) in APPOINTMENT and has the referential integrity constraint:

(ProfessorDepartment, ProfessorFirstName, ProfessorLastName) in STUDENT must exist in (DepartmentName, ProfessorFirstName, ProfessorLastName) in APPOINTMENT

Note that we had to change DepartmentName in APPOINTMENT to ProfessorDepartment in STUDENT because we cannot have two columns named DepartmentName in STUDENT and we had already used DepartmentName as the foreign key linking to DEPARTMENT.

This illustrates that a foreign key does not have to have the same name as the primary key it links to. As long as the referential integrity constraints are correctly specified, the foreign key name can be whatever we want it to be.

In addition to the two referential integrity constraints above our database design, we will also have the following:

CollegeName in DEPARTMENT must exist in CollegeName in COLLEGE (ProfessorFirstName, ProfessorLastName) in DEPARTMENT

must exist in (ProfessorFirstName, ProfessorLastName) in PROFESSOR DepartmentName in APPOINTMENT must exist in DepartmentName in DEPARTMENT (ProfessorFirstName, ProfessorLastName) in APPOINTMENT

must exist in (ProfessorFirstName, ProfessorLastName) in PROFESSOR

Design for Minimum Cardinality

The third and last step of transforming data models into database designs is to create a plan for enforcing minimum cardinality. Unfortunately, this step can be considerably more complicated than the first two design steps. Relationships that have required children entities are particularly problematic because we cannot enforce such constraints with database structures. Instead, as you will see, we must design procedures for execution by the DBMS or by applications.

Relationships can have one of four minimum cardinalities: parent optional and child optional (O-O), parent mandatory and child optional (M-O), parent optional and child mandatory (O-M), or parent mandatory and child mandatory (M-M). As far as enforcing minimum cardinality is concerned, no action needs to be taken for O-O relationships, and we need not consider them further. The remaining three relationships pose restrictions on insert, update, and delete activities.

Figure 6-28 summarizes the actions needed to enforce minimum cardinality. Figure 6-28(a) shows needed actions when the parent row is required (M-O and M-M relationships), and Figure 6-28(b) shows needed actions when the child row is required (O-M and M-M relationships). In these figures and the accompanying discussion, the term action means minimum cardinality enforcement action. We use the shorter term action for ease of discussion.

To discuss these rules, we will use the database design for storing data on several companies shown in Figure 6-29. In this diagram, we have a 1:N, M-O relationship between COMPANY and DEPARTMENT and between DEPARTMENT and EMPLOYEE, and a 1:N, M-M relationship between COMPANY and PHONE_CONTACT. In the COMPANY-to-DEPARTMENT relationship,

Part 2 Database Design

Parent Required Action on Parent

Action on Child

Insert

None.

Get a parent. Prohibit.

Modify key or

Change children’s foreign

OK, if new foreign

foreign key

key values to match new

key value matches

value (cascade update).

existing parent.

Delete children

None.

(cascade delete). Prohibit.

(a) Actions When the Parent Is Required

Child Required

Action on Parent

Action on Child

Insert

Get a child.

None.

Prohibit.

Modify key or

Update the foreign key of

If not last child, OK.

foreign key

(at least one) child.

If last child, prohibit

Prohibit.

or find a replacement.

Delete

None.

If not last child, OK. If last child, prohibit

Figure 6-28

or find a replacement. Summary of Actions to

Enforce Minimum Cardinality (b) Actions When the Child Is Required

COMPANY (on the 1 side of the relationship) is the parent entity and DEPARTMENT (on the N side of the relationship) is the child entity. In the DEPARMENT-to-EMPLOYEE relationship, DEPARTMENT (on the 1 side of the relationship) is the parent entity and EMPLOYEE (on the N side of the relationship) is the child entity. In the COMPANY-to-PHONE_CONTACT relationship, COMPANY (on the 1 side of the relationship) is the parent entity and PHONE_CONTACT (on the N side of the relationship) is the child entity.

Figure 6-29

DEPARTMENT Database Design for Data

COMPANY

DepartmentName on Several Companies

CompanyName (FK)

PHONE_CONTACT

CompanyName (FK)

EmployeeName

PhoneNumber

Phone Email (AK1.1) HireDate ReviewDate EmpCode DepartmentName (FK)

Chapter 6 Transforming Data Models into Database Designs