Chapter 2 Problem Solutions
Peter Rob and Elie Semaan
Databases: Design, Development,
and Deployment
Using Microsoft Access
Second Edition
A
B
C
D
partial dependency
E
F
G
H
I
transitive dependency
transitive dependency
J
A
B
Step1: Identify each of the primary key attributes.
(In this case, the PK attributes are A, B, C.)
No dependencies
D
Step 2: Place each of the primary key attributes on
a separate line.
Table 1 3NF
Step 3: Write the composite PK on a separate line.
C
A
Step 4: Break out all partial dependencies to create
a new table. (See Table 1, B
D.)
No dependencies
B
C
E
F
G
H
I
Transitive dependencies
Foreign key to table 1
Transitive dependency
J
Table 2 2NF
B
D
Table 1 3NF
E
J
Table 2 3NF
F
H
I
A
B
C
Table 3 3NF
E
F
G
Table 4 3NF
Foreign key to table 1
Foreign key to table 3
Foreign key to table 2
STU_NUM
STU_LNAME
STU_FNAME
COLL_NAME
DEPT_NUM
DEPT_NAME STU_CREDITS
Transitive dependency
STU_CLASS
Transitive dependency
Note: Although the STU_CREDITS determine the STU_CLASS,
there is no unique student credit hour value that determines each
student classification. For example, whether a student has earned 42,
45, or 51 credit hours, that student is still classified as a sophomore.
Therefore, it is not appropriate to create a linked CLASS table to the
STUDENT entity. Instead, you may create a CLASS look-up table, or
you may let the application code determine the student classification.
In short, the transitive dependency STU_CREDITS
is not as clear-cut as it appears to be at first glance.
STU_CLASS
STU_GPA
STU_NUM
STU_LNAME
STU_FNAME
STU_CREDITS
STU_CLASS
STU_GPA
DEPT_NUM
STUDENT table, 2NF Note: Although the STU_CREDITS determine the STU_CLASS,
there is no unique student credit hour value that determines each
student classification. For example, whether a student has earned 42,
45, or 51 credit hours, that student is still classified as a sophomore.
Therefore, it is not appropriate to create a linked CLASS table to the
STUDENT entity. Instead, you may create a CLASS look-up table, or
you may let the application code determine the student classification.
DEPT_NUM
DEPT_NAME COLL_CODE
DEPARTMENT table, 3NF
COLL_CODE
COLL_NAME
COLLEGE table, 3NF
Note: The normalization process usually requires the creation of additional attributes to generate appropriate
entities. In this case, we used the COLL_NAME attribute to help define the COLLEGE entity’s characteristics.
Additional COLLEGE attributes might include a FK to an EMPLOYEE entity, recognizing that a college has a
dean. Other appropriate COLLEGE entities might be the mail stop, phone extension, etc.
Note: The optionalities shown in this ERD are based on assumed
business rules. In this example, DEPARTMENT is mandatory to
STUDENT, thus requiring each student to select an existing
department. (The referential integrity rules require that each
DEPT_NUM foreign key value in the STUDENT table must point
to an existing DEPARTMENT table primary key value. Therefore,
a DEPARTMENT must exist before students can be assigned to it.)
COLLEGE
1
(0,N)
includes
M
(1,1)
Some colleges do not have departments. Therefore, DEPARTMENT
Is optional to COLLEGE. However, each department “belongs” to
a college. Therefore, COLLEGE is mandatory to DEPARTMENT.
1
M
has
DEPARTMENT
(0,N)
STUDENT
(1,1)
A
B
C
D
E
Partial dependency
F
G
H
I
J
K
Transitive dependencies
Transitive dependency
Partial dependency
This dependency diagram shows a 1NF condition, because it contains both
partial and transitive dependencies. (Removal of the partial dependency
would yield a 2NF condition.)
A
J
K
E
G
Table 3 3NF
A
Table 1 3NF
B
C
E
F
G
B
D
F
H
Table 2 3NF
I
Table 5 3NF
Foreign key to table 1
Foreign key to table 4
Foreign key to table 2
Foreign key to table 3
Table 4 3NF
RENT_NUM
CUS_NUM
CUS_LNAME AC_NUM
Transitive dependency
AC_TTAF
MOD_CODE
MOD_CHG_HR
RENT_HOURS
RENT_CHARGE
Transitive dependencies
Transitive dependency
The AIRCRAFT table’s dependency diagram indicates a 2NF condition, based on the existence of
transitive dependencies. Note that two transitive dependencies overlap: the AC_TTAF clearly
determines the MOD_CODE attribute’s value and, therefore, the MOD_CHG_HOUR. However,
the MOD_CODE attribute also determines the MOD_CHG_HR. Given the proper use of naming
conventions, it is clear that the MOD_CODE is likely to be the PK of a MODEL table in which
the MOD_CHG_HR attribute values would be stored. (Naturally, the MODEL table should store
all attributes that are properly descriptive of an aircraft model!)
RENT_NUM
CUS_NUM
AC_NUM RENT_HOURS RENT_CHARGE
RENT table, 3NF
CUS_NUM
CUS_LNAME
CUSTOMER table, 3NF
MOD_CODE
MOD_CHG_HR
MODEL table, 3NF
AC_NUM
AC_TTAF
MOD_CODE
AIRCRAFT table, 3NF
Note: Optionalities are often used for operational reasons. In
this case, AVIARS maintains a list of basic aircraft models, but
some of these models are not (yet) found in the AVIARS aircraft
fleet. Therefore, AIRCRAFT is kept optional to MODEL.
When AVIARS puts a new aircraft on line, it has not (yet) been
rented. Therefore, RENTAL is made optional to AIRCRAFT.
(If the relationship were mandatory, you would have to create a
dummy rental record just to place the aircraft in your database.)
MODEL
(0,N)
Some customers have not (yet) rented an aircraft, so RENTAL is
made optional to CUSTOMER.
1
M
CUSTOMER
M
references
1
(1,1)
(1,1)
M
AIRCRAFT
RENTAL
(0,N)
1
(1,1)
(0,N)
LOG_NUM
LOG_DATE
LINE_NUM CUS_NUM CUS_LNAME AC_NUM AC_TTAF MOD_CODE
Transitive dependency
Dependency diagram,
continued. (LOG_NUM
and LINE_NUM repeated.)
Transitive dependencies
LOG_NUM
PART_CODE
PART_PRICE
Transitive dependency
LINE_NUM UNITS_USED LINE_HOURS EMP_NUM
Note: By itself, the log’s line number (LINE_NUM) does not determine any attribute value. Therefore, there
is no partial dependency. However, there are several transitive dependencies, so the dependency diagram indicates a 2NF condition.
LOG table
LOG_NUM
CUS_NUM
AC_NUM
LOG_DATE_IN
EMP_NUM_IN LOG_PROBLEM LOG_DATE_OUT
EMP_NUM_OUT
(Note that the normalization process usually yields additional attributes to make sure that the entities are
described more completely and precisely. Each new attribute must be checked to ensure its compliance
with the normalization requirements.)
LOG_NUM
PART_CODE
LINE_NUM
PART_PRICE
PART_CODE
UNITS_USED LINE_HOURS EMP_NUM
PART_QOH
PART table
AC_NUM
AC_TTAF
AIRCRAFT table
CUS_NUM
CUS_LNAME
LINE table
CUS_E_MAIL
CUSTOMER table
MOD_CODE
CUS_NUM
MOD_CODE
MOD_NAME
MODEL table
MOD_PRICE
MODEL
1
(0,N)
references
1
M
CUSTOMER
M
(1,1)
1
(1,1)
(0,N)
owns
M
ACTION
is a
EMPLOYEE
(0,1)
(1,1)
1
(0,N)
M
LOG
(1,1)
M
(1,1)
1
M
1
enters
(0,N)
(0,N)
1
1
AIRCRAFT
RENTAL
(0,N)
(1,1)
M
1
(1,N)
1
(1,N)
PART
contains
(1,1)
M
(1,1)
1
(0,1)
(1,1)
signs
1
(0,N)
M
(1,1)
(0,N)
uses
LINE
MECHANIC
M
A
B
C
D
E
F
G
H
I
J
A
B
C
D
Partial dependencies
E
F
G
H
Transitive dependencies
Partial dependencies
I
J
A
F
G
B
C
D
Table 2 3NF
A
B
E
H
Table 1 3NF
I
J
Transitive dependency
Table 3 2NF
A
F
G
Table 1 3NF
E
H
I
Table 3 3NF
B
A
C
B
D
E
Table 2 3NF
J
Table 4 3NF
Foreign key to table 1
Foreign key to table 2
Foreign key to table 3
EMP_NUM DRIVER_LIC_1
DRIVER_LIC_1TYPE DRIVER_LIC_1DATE SCHOOL_CODE1 SCHOOL_NAME1
Transitive dependency
Dependency diagram, continued. (PK repeated.)
EMP_NUM DRIVER_LIC_2
DRIVER_LIC_2TYPE DRIVER_LIC_2DATE SCHOOL_CODE2 SCHOOL_NAME2
Transitive dependency
Dependency diagram, continued. (PK repeated.)
EMP_NUM ENDORSE_CODE1 ENDORSE-CODE1_DESC ENDORSE_CODE1_DATE
Transitive dependencies
Dependency diagram, continued. (PK repeated.)
EMP_NUM ENDORSE_CODE1 ENDORSE-CODE1_DESC ENDORSE_CODE1_DATE
Transitive dependencies
EMP_NUM
EMP_LNAME
EMP_E_MAIL
EMPLOYEE table
EMP_NUM LICENSE_CODE LICENSE_DATE SCHOOL_CODE
SCHOOL_CODE
SCHOOL_NAME
SCHOOL table
ENDORSE_CODE ENDORSE_DESCRIPTION
ENDORSEMENT table
EMP_NUM
DRIV_LICENSE table
ENDORSE_CODE ENDORSE_DATE
LICENSE_CODE
LICENSE_DESCRIPTION
LICENSE table
SCHOOL_CODE
DRIV_ENDORSEMENT table
1
1
is a
EMPLOYEE
(0,1)
DRIVER
(1,1)
Assumptions: Drivers are employees who have unique
characteristics, such as a license, a medical status, and
so on. Each driver has a single license. Higher-level
licenses supersede lower-level licenses.
1
(0,N)
M
(1,1)
M
1
SCHOOL
ENDORSE_DRIV
(1,1) (0,N)
A license can have more than one endorsement for such
items as hazardous materials handling, dual trailers, etc.
M
(1,1)
An endorsement may or may not have been earned from
a school. Not all approved schools are represented in the
endorsement listing. Some endorsements have not (yet)
been earned by any drivers.
1
(0,N)
ENDORSEMENT
1
1
1
is a
EMPLOYEE
(0,1)
M
DRIVER
(1,1)
Assumptions:
Not all employees are drivers.
1
(0,N)
M
(1,1)
DRIV_LICENSE
(1,N) (1,1)
M
(0,N)
1
(1,1)
M
Drivers can have multiple licenses and endorsements.
LICENSE
DRIV_ENDORSE
(0,1)
A driver must have at least one license, but may not
(yet) have earned one or more endorsements.
M
(1,1)
A license must have been earned from an approved
school, but an endorsement is not necessarily earned
from a school.
1
(0,N)
The company has not (yet) hired drivers from some
of the approved schools.
(1,1)
M
1
ENDORSEMENT
1
SCHOOL
(0,N)
(0,N)
1
1
1
is a
EMPLOYEE
(0,1)
M
DRIVER
(1,1)
1
(0,N)
M
(1,1)
DRIV_LICENSE
(1,N) (1,1)
(1,1)
M
(0,N)
1
M
(1,1)
M
LICENSE
DRIV_ENDORSE
(0,1)
If you want to keep track of which
schools offer what licenses, create
a composite entity to link the two.
The optionalities depend on what
assumptions are expressed in the
business rules.
M
(1,1)
(0,N)
1
(1,1)
M
LIC_SCHOOL
1
(0,N)
1
ENDORSEMENT
(1,1)
(0,N)
M
1
1
SCHOOL
(0,N)
(0,N)
CLIENT_NUM CLIENT_NAME CLIENT_REGION CONTRACT_NUM
Partial dependency
CONS_NUM1
CONS1_REGION CONS_NUM2
Transitive dependencies
CONS_NAME3
CONS_NUM2
Transitive dependencies
CONS_NAME2
CONS2_REGION
Transitive dependencies
CONS3_REGION
Transitive dependencies
CONS_NUM1
CONTRACT_AMT
Partial dependencies
CONS_NAME1
CONS_NUM3
CONTRACT_DATE
CONS_NUM3
CONS_NUM4
CONS_NAME4
CONS4_REGION
Transitive dependencies
CONS_NUM4
CERT_1 CERT_2 CERT_3 CERT_4
CLIENT_NUM
CLIENT_NAME CLIENT_EMAIL CLIENT_PHONE
REGION_CODE Table name: CLIENT
Note: The normalization process often causes the designer to add attributes to describe the
entities more completely and precisely. Information requirements also tend to require the
designer to decompose the attributes into their atomic components. Keep these points in
mind as you examine the entity structures shown here.
REGION_CODE
REGION_NAME
Table name: REGION
Table name: CONSULTANT
CERT_CODE
CONTRACT_NUM
CERT_DESCRIPTION
CONSULTANT_NUM
CERT_CHG_HOUR
CONTRACT_AMOUNT
CONSULTANT_NAME
REGION_CODE
Table name: CERTIFICATION
CONTRACT_DATE
CLIENT_NUM
Table name: CONTRACT
Normalization focuses on the attributes within an entity, rather than on the relationship between the entities.
Therefore, the ERD is an indispensable production database design tool. For example, we know that there must
be a relationship between the consultant and the contract and one between the consultant and his or her specialty,
probably through certification. Without the ERD, the specialty, assignment, and certification structures shown
here are not readily apparent. (The attribute names have been abbreviated to fit the screen.)
CLNT_NUM
CLNT_NAME CLNT_EMAI
L
CLNT_PHON
E
REG_CODE
Table name: CLIENT
CONS_NUM
CONS_NAME
Table name: REGION
REG_CODE
Table name: CONSULTANT
CONTR_NUM
CONS_NUM
SPEC_CODE
SPEC_DESCR
SPEC_CHG_H
R
Table name: SPECIALTY
ASSGN_HRS
ASSGN_CHG
Table name: ASSIGNMENT
CONTR_NUM CONTR_DATE
REG_CODE REG_NAME
CONS_NUM
SPEC-CODE
CERT_DATE
Table name: CERTIFICATION
CONTR_AM
T
CLNT_NUM
Table name: CONTRACT
1
houses
REGION
1
(0,N)
M
(0,N)
CONSULTANT
(1,1)
contains
M
(1,1)
1 M
(0,N)
1
(1,1)
M
ASSIGNMENT
1
M
generates
CLIENT
(0,N)
(1,1)
M
(0,N)
1
CONTRACT
(1,1)
CERTIFICATION
(0,N) (1,1)
M
(1,1)
1
(0,N)
SPECIALTY
CERTIFICATION
M
CONSULTANT
SPEC_CODE
1
CONS_NUM
1
REG_CODE
M
ASSGN_HRS
CLIENT
ASSGN_CHG_HR
CLNT_NUM
……….
CLNT_NAME
CLNT_E_MAIL
……….
M
CONS_NUM
1
SPEC_CODE
SPEC_DESCR
SPEC_CHG_HR
CTRCT_NUM
REG_CODE
REG_NAME
1
ASSIGNMENT
CONS_E_MAIL
……….
M
M
CERT_DATE
1
CONS_NAME
REGION
SPECIALTY
CONS_NUM
M
CONTRACT
1
ASSGN_CHARGE
CTRCT_NUM
CTRCT _DATE
M
CTRCT_AMT
CLNT_NUM
REG_CODE
Note: Designers often create “artificial” single-attribute keys for performance reasons. For example, the
ASSIGNMENT table shown here uses a composite key CTRCT_NUM + CONS_NUM. You could create
a new PK named ASSGN_NUM and continue to use the original PK attributes as foreign keys.
A B
C
D
E
F G
A B
C D
E
The original dependencies. Note that the dependency
defined by C
B is not transitive, because it shows
a PK attribute to be dependent on a non-key attribute.
(In a transitive dependency, one non-key attribute determines another non-key attribute!)
F G
Transitive dependency
partial dependency
A
D
A
B
3 NF
C
E
F G
2 NF
Transitive dependency
A
D
3 NF
E G
3 NF
A
B
C E
F
3 NF, but not BCNF. (The dependency defined by C
B
involves a non-key attribute that determines a key attribute.)
A
D
Table 1, 3 NF
E G
C
B
Table 3, 3 NF
A C
Table 2, 3 NF
E
F
Table 4, 3 NF and BCNF
Foreign key to table 2
Foreign key to table 3
Foreign key to table 1
The End