An initial dependency diagram depicting only the primary key dependencies is shown in

Figure P6.1a below.

There are no composite keys being used, therefore, by definition, there is not an issue with
partial dependencies and the entities are already in 2NF. Based on the description of the
attributes, it appears that the patient name, phone number, and address can be determined
by the patient id App_PatientID => (App_Name, App_Phone, App_Street, App_City,
App_State, App_Zip)
Zip_Codes can be used to determine a city and state; therefore, we also have the transitive
dependency:
App_Zip -> App_City, App_State

Figure P6.1b Revised dependency diagram for Problem 1.

Since the first transitive dependency completely encloses the second transitive
dependency, it is appropriate to resolve the first transitive dependency before
resolving the second. Figure P6.1c shows the results of resolving the first transitive
dependency.

Figure P6.1c Resolving the first transitive dependency

Finally, the second and final transitive dependency can now be resolved as shown in
the final dependency diagram in Figure P6.1d

Figure P6.1d Final dependency diagram for Problem 1

An initial dependency diagram depicting only the primary key dependencies is shown
in Figure P6.2a below.

Figure P6.2a Initial dependency diagram for Problem 2.

Based on the descriptions of the attributes given, the following partial dependency
can be determined: Pres_SessionNum (Pres_Date, Pres_Room)
Also, the following transitive dependencies can be determined: Pres_AuthorID
(Pres_FName, Pres_LName)

Figure P6.2b shows the revised dependency diagram including the partial and
transitive dependencies.

Figure P6.2b Revised dependency diagram for Problem 2

Resolving the partial dependency to achieve 2NF yields the dependency diagram shown in
Figure

Finally, the transitive dependency is resolved to achieve the 3NF solution shown in
the final dependency diagram in Figure P6.2d.

Figure P6.2d Final dependency diagram for Problem 2

3a Solution
Relational Schema: 1NF(INV_NUM, PROD_NUM, SALE_DATE, PROD_DESCRIPTION,
VEND_CODE, VEND_NAME, NUM_SOLD, PROD_PRICE)

3b Solution

c Solution

d Solution
a
Note 1: The ADV_LASTNAME is not a determinant of ADV_OFFICE or ADV_PHONE,
because there are(potentially) many advisors who have the same last name.

Note 2: If a department has only one phone, DEPT_CODE is a determinant of

DEPT_PHONE. If a departmenthas several phones, the DEPT_CODE is no longer a
determinant of DEPT_PHONE. In any case, if youknow the DEPT_PHONE value, you know
the DEPT_CODE value. Therefore, DEPT_PHONE is a determinant of DEPT_CODE. This
latter dependency, indicated in orange, sets the stage for a BCNFviolation when the initial
structure is normalized.

Note 3: ADV_OFFICE is a determinant of ADV_BUILDING if the ADV_OFFICE is , in

effect, a code. Forexample, if offices such as HE-201 and HE-324 use the prefix HE to
indicate their location in the Heinzbuilding, the office locators determine the building.

The relational schema for the dependency diagram shown in Figure P6.4a is written as:
STUDENT(STU_NUM, STU_LNAME, STU_MAJOR, DEPT_CODE, DEPT_NAME,
DEPT_PHONE, ADVISOR_LNAME, ADVISOR_OFFICE, ADVISOR_BLDG,
ADVISOR_PHONE, STU_GPA, STU_HOURS, STU_CLASS)

b.

The relational schemas are written as:

STUDENT(STU_NUM, STU_LNAME, STU_MAJOR, DEPT_CODE, ADVISOR_NUM,

STU_GPA, STU_HOURS, STU_CLASS)
(Note that we have added the ADVISOR_NUM to serve as an FK to the advisor attributes.)
MAJOR(MAJOR_CODE, DEPT_CODE, MAJOR_DESCRIPTION)
BUILDING(BLDG_CODE, BLDG_NAME, BLDG_MANAGER)

DEPARTMENT(DEPT_CODE, DEPT_NAME, DEPT_PHONE, COLLEGE_CODE)

COLLEGE(COLL_CODE, COLL_NAME)

c
As you examine the ER diagrams in Figure P6.4c, note that we have made several
assumptions that cannot be inferred directly from the dependency diagram in problem 4b.
For example:
- Apparently, some buildings do not house advisors. Some buildings may be used for
storage, others for classrooms, and so on
- When a student is assigned to a department, that department must assign an advisor
to that student. That is, a student must have an advisor. Therefore, ADVISOR
is mandatory to STUDENT.
- Evidently, some advisors do not (yet?) have students assigned to them. From an
operational point of view, this optionality is desirable, because it enables us to
create a new advisor without having to assign a student advisee to that new
advisor. (The new advisor may have to receive some training before having students
assigned to him or her.)
- Some departments do not offer majors. For example, a department may offer service
courses only.
- Some colleges do not have departments. This condition is subject to a business rule
that is not specified, nor can it be inferred from the dependency diagram.
However, this characteristic is not unusual in a college environment. For
example, some professional curricula are certified by special boards. Such boards
may make certification conditional on the professional curriculum’s independence.
(We have created the optionality for discussion purposes. This discussion should
stress the importance of the business rules. You generate the business rules by
asking detailed questions!)
- All departments must be affiliated with a college.
 - STUDENT is optional to MAJOR. This optionality, too, is desirable from an
operational point of view. For example, new majors may not (yet) have attracted
students.

The relational schema may be written as follows: ITEM(ITEM_ID, ITEM_DESCRIPTION,

BLDG_ROOM, BLDG_CODE, BLDG_NAME, BLDG_MANAGER)

FOUNDIT Co. Dependency Diagrams: all tables in 3NF

The relational schemas are written as follows:
EMPLOYEE(EMP_CODE, EMP_LNAME, EMP_FNAME, EMP_INITIAL)
BUILDING(BLDG_CODE, BLDG_NAME, EMP_CODE) ITEM(ITEM_ID,
ITEM_DESCRIPTION, ITEM_ROOM, BLDG_CODE)

As you discuss the dependency diagrams in Figure P6.5b, remind the students that
BLDG_CODE is not a determinant of BLDG_ROOM. A building can have many rooms, so
knowing the building code will not tell you what the room in that building is.

c
a

The relational schema is written as:

EMPLOYEE(EMP_CODE, EMP_LNAME, EMP_EDUCATION, JOB_CLASS,
EMP_DEPENDENTS,DEPT_CODE, DEPT_NAME, DEPT_MANAGER, EMP_TITLE,
EMP_DOB, EMP_HIRE_DATE, EMP_TRAINING, EMP_BASE_SALARY,
EMP_COMMISSION_RATE)

b
The relational schemas are written as:

EMPLOYEE(EMP_CODE, EMP_LNAME, DEPT_CODE, JOB_CLASS, EMP_DOB,

EMP_HIREDATE)
DEPENDENT(EMP_CODE, DEP_NUM, DEP_FNAME, DEP_TYPE)
DEPARTMENT(DEPT_CODE, DEPT_NAME, EMP_CODE)
JOB(JOB_CLASS, JOB_TITLE, JOB_BASE_SALARY)
EDUCATION(EDUC_CODE, EDUC_DESCRIPTION)
QUALIFICATION(EMP_CODE, EDUC_CODE, QUAL_DATE_EARNED)

c
d
a

The relational schema may be written as follows: MEMBER(MEMBER_NUM,

MEMBER_NAME, MEMBER_ADDRESS, MEMBER_CITY, MEMBER_ZIP_CODE,
INVITE_NUM, INVITE_DATE, ACCEPT_DATE, DINNER_DATE, DINNER_ATTENDED,
DINNER_CODE, ENTRÉE_CODE, ENTRÉE_DESCRIPTION, DESSERT_CODE,
DESSERT_DESCRIPTION)

b
The relational schemas follow:
MEMBER(MEM_NUM, MEM_NAME, MEM_ADDRESS, MEM_CITY, MEM_STATE,
MEM_ZIP)
INVITATION(INVITE_NUM, INVITE_DATE, DIN_CODE, MEM_NUM, INVITE_ACCEPT,
INVITE_ATTEND)
ENTRÉE(ENT_CODE, ENT_DESCRIPTION)
DINNER(DIN_CODE, DIN_DATE, DIN_DESCRIPTION, ENT_CODE, DES_CODE)
DESSERT(DES_CODE, DES_DESCRIPTION)
c
a

c
9

a
b
Table P6.9 shows several professor attributes – ADVISEE, COMMITTEE_CODE, and
JOURNAL_CODE -- that represent multivalued dependencies
c

d Eliminate the multivalued dependencies by converting the affected table structures to 4NF.
e
a
The relational schema is written as follows: CONTRACT(CLIENT_NUM, CLIENT_NAME,
DATE, CONTRACT, CLASS_1, CLASS_2, CLASS_3, CLASS_4, REGION, CONS_NUM_1,
CONS_NAME_1, CONS_NUM_2, CONS_NAME_2, CONS_NUM_3, CONS_NAME_3,
CONS_NUM_4, CONS_NAME_4)

The relational schemas are written as follows:

CLIENT(CLIENT_NUM, CLIENT_NAME, REGION_CODE) CLASS(CLASS_CODE,

CLASS_DESCRIPTION)

CONTRACT(CONTR_NUM, CLIENT_CODE, CONTR_DATE, REGION_CODE)

CONSULTANT(CONS_NUM, CONS_NAME, REGION_CODE)

REGION(REGION_CODE, REGION_NAME)
c
a

The relational schema is written as follows:

CHARTER(CHAR_TRIP, CHAR_DATE, CHAR_CITY, CHAR_MILES, CUST_NUM,

CUST_LNAME, CHAR_PAX, CHAR_CARGO, PILOT, COPILOT, FLT_ENGINEER,
LOAD_MASTER, AC_NUMBER, MODEL_CODE, MODEL_SEATS, MODEL_CHG_MILE)
b

While the ERD shown in Figure P6.11c faithfully reflects the results generated by the
normalization process, it has a major design flaw. This flaw has the following consequences:

- If additional crewmembers such as copilots, loadmasters, and flight engineers

are not assigned to the flight, the CHARTER table will include many nulls. (Many of the
smaller aircraft that used in charter flying require only that a pilot and a functioning
autopilot be used. In fact, the Federal Air Regulations (FARs) that govern charter aviation
permit single pilot operations for aircraft that have less than a 12,500-lbs. gross take-off
weight and that are not turbine-powered.)
 - The inclusion of COPILOT, FLT_ENGINEER, and LOAD_MASTER also produce
synonyms in the CHARTER table.
- As the aircraft used in the charter flights become larger and more complex, crews
become larger, thus producing more synonyms and more potential nulls. (Not
to mention that the CHARTER table will have to be modified to accept additional
crew members such as flight attendants.)

The problems associated with the ERD shown in Figure P6.11c are eliminated
through the composite entity named CREW in Figure P6.11d. Note that this modification
makes it possible to assign any number of crewmembers. To ensure that the crewmembers
are properly qualified, a job attribute can be added to the EMPLOYEE entity and the
applications software can then assign crewmembers based on job classifications such
a pilot, loadmaster, flight attendant, etc. Because only some employees are qualified as
crewmembers, CREW is optional to EMPLOYEE. But each crewmember must be an
employee, so EMPLOYEE is mandatory to CREW.