Chapter 6 Part1 Hands-On Exercies With Answers

Chapter 6 Part1 Hands-on Exercises with Solutions
Problem 1
Given the dependency diagrams in the following figures, identify and discuss each of the
indicated dependencies. Pease notes (C1, C2) is the composite primary key.
Solution and note for student learning:

C1, C3  C2, C4, C5 represents a set of proper functional dependencies, because C2, C4, and
C5 depend on the primary key composed of C1 and C3.
C1  C2 represents a partial dependency, because C2 depends only on C1 (part of the composite
primary key), rather than on the entire primary key composed of C1 and C3.
C4  C5 represents a transitive dependency, because C5 depends on an attribute (C4) that is not
part of a primary key.
*Based on the above analysis of functional dependencies, the figure above should be in 1NF
because it includes both partial and transitive dependency. If we want to go further and transform
the figure into 2NF and 3NF. The following process can be used.
Convert from 1NF to 2NF: remove partial dependencies and create new tables.
1
Convert from 2NF to 3NF: remove transitive dependencies and create new tables.
2
Problem #2
The dependency diagram in following figure indicates that authors are paid royalties for
each book they write for a publisher. The amount of the royalty can vary by author, by book, and
by edition of the book.
Some description:
If a book can only have one author, then you can imply that knowing the ISBN, you also
know the author and the royalty rate. However, it is very common for a book to have multiple
authors, and in that case, the authors may have the same or different royalty rates. In the above
figure, it uses a composite primary key (ISBN, Author_Num), which can determine all
other attributes in the table. The main point of this design is the flexibility of it. Flexibility is
important because it “future-proofs” the data model by allowing the model to support changes in
the business rules in the future.
Q1: Write the relational schema for the 1NF shown in the above figure. Also describe partial
and transitive dependencies if any.
Solution:
Relational Scheme:
1NF (ISBN, Author_Num, BookTitle, LastName, Publisher, Royalty, Edition)
Partial Dependencies
ISBN → BookTitle, Publisher, Edition
Author_Num → LastName
Transitive Dependencies
BookTitle→ Publisher
3
Q2: Convert from 1NF to 2NF
Solution: We need to create new tables to remove partial dependencies. The following figure
showing the 2NF formulations results.
Relational Scheme:
Book (ISBN, BookTitle, Publisher, Edition)
Author (Author_Num, LastName)
Author_Royalty (ISBN, Author_Num, Royalty)
Note for student learning:

At this point (2NF), the tables do NOT include any more partial dependencies; however, in
the table Book, we may note the transitive dependencies: BookTitle functionally determines
Publisher. Here, BookTitle itself is not primary key or part of the composite primary key
(nonprime factor) in the BOOK table. We will create a new table to remove transitive
dependencies when converting from 2NF to 3NF.
4
Q3: Convert from 2NF to 3NF (including indicating FK)
Solution: The following figure showing the 3NF normalization results.
Relational Scheme:
Book (ISBN, BookTitle (FK), Edition)
Publisher (BookTitle, Publisher)
Author (Author_Num, LastName)
Author_Royalty (ISBN(FK), Author_Num(FK), Royalty)

At this point, the tables do NOT include any more partial dependencies or transitive
dependencies, and it is now in 3NF.
5
Problem #3
Given that information, write the relational schema and the normalization process. Make
sure that you label the transitive and/or partial dependencies.
Solution:
First step: write down the relational scheme
The relational schema:
ITEM (ITEM_ID, ITEM_DESCRIPTION, ROOM_NUMBER, BLDG_CODE, BLDG_NAME,
BLDG_MANAGER)
Second step: Analyze functional dependencies

ITEM_ID  ITEM_DESCRIPTION, ROOM_NUMBER, BLDG_CODE, BLDG_NAME,
BLDG_MANAGER)
We can see that ITEM_ID is primary key. In other words, the primary key is a single
attribute. Therefore, there are no partial dependencies – because partial dependency can only
exist when a composite primary key exists. This table is automatically in 2NF.
Accordingly, we need to check whether there are transitive dependencies. If yes, it is 2NF,
and we need to convert it to 3NF. If no, it is already 3NF, and we do not need to do any more
work. Then we check the relational scheme, we found the following transitive dependencies.
Thus, this is in 2NF because of no transitive dependencies. We convert from 2NF to 3NF as
follows.
Transitive dependencies:
ROOM_NUMBER  BLDG_CODE, BLDG_NAME, BLDG_MANAGER
BLDG_CODE  BLDG_NAME, BLDG_MANAGER
BLDG_NAME  BLDG_MANAGER
6
Third step: transfer from 2NF to 3NF
If we make 3NF strictly based on the data provided, the relational schemas are written as
follows:
ITEM (ITEM_ID, ITEM_DESCRIPTION, ROOM_NUMBER (FK))
ROOM (ROOM_NUMBER, BLDG_CODE (FK))
BUILDING (BLDG_CODE, BLDG_NAME (FK))
BILDING_NAME (BLDG_NAME, BLDG_MANAGER)

The above dependencies and tables are determined strictly based on the data provided. In
some cases, we may improve the database design by altering tables to reflect the common
business practices. If we want to take a further step and improve the database design, we
can make 3NF as follows.
The relational schemas for improving database design are written as follows:
ITEM (ITEM_ID, ITEM_DESCRIPTION, ROOM_NUMBER, BLDG_CODE)
BUILDING (BLDG_CODE, BLDG_NAME, EMP_NUM)
EMPLOYEE (EMP_NUM, EMP_LNAME, EMP_FNAME, EMP_INITIAL)
To align with common practice, we now have determined that the location of an item is
determined by the building code and room number. For reporting purposes, this change allows to
easily generate a report of all items in each building. A building can have many rooms, so
knowing the building code will not tell you what the room in that building is. If the room is
numbered to reflect the building it is in—for example, HE105 indicates room 105 in the Heinz
building—one might argue that the ROOM_NUMBER value is the determinant of the
BLDG_CODE and the BLDG_NAME values.
You will learn in Chapter 7, “Introduction to Structured Query Language (SQL),” that you
can create a query to find a building by looking at room prefixes. However, if you define
dependencies in strictly relational algebra terms, you might argue that partitioning the attribute
value to “create” a dependency indicates that the partitioned attribute is not (in that strict sense) a
determinant. In any case, this (arguable) dependency does not create any problems in a
practical sense, so we have not identified it in the solution.
Clearly, BLDG_CODE is a determinant of BLDG_NAME. Therefore, the transitive
dependency is marked properly. The dependency reflects the notion that one employee manages
7
each building. Thus, we have also renamed BLDG_MANAGER as EMP_NUM to reflect the
fact that an employee is the manager of the building and we have added the EMPLOYEE entity.

Chapter 6 Part1 Hands-On Exercies With Answers

Uploaded by

Copyright:

Available Formats

Chapter 6 Part1 Hands-On Exercies With Answers

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 6 Part1 Hands-On Exercies With Answers

Uploaded by

Copyright:

Available Formats

Chapter 6 Part1 Hands-on Exercises with Solutions

Solution and note for student learning:

Note for student learning:

Note for student learning:

Second step: Analyze functional dependencies

Note for student learning:

You might also like