Normalization Examples

For each of the following, state whether the relation is unnormalized, in 1NF, 2NF or
3NF. If it is not in 3NF, convert it to a set of relations in 3NF.

1. TimeSheet (Date, Employee#, HoursWorked, EmpName)

2. City-Rainfall (Month, Day, Year, Amount)

3. BankAccount (Account#, OwnerSSN, OwnerName, Balance)

4. School (ClassCode, ClassName, Credits, (StudentID, Grade, StudentName,

MajorCode, MajorName))

Answers (but try them first!)

1. This one is in 1NF.

There is no repeating group, so it isnt unnormalized, it is at least 1NF. To be in 2NF,

all non-key attributes must depend on the WHOLE key. That is, HoursWorked and
EmpName (the non-key attributes) must be dependent on BOTH Date and Employee#
(the key). Since Employee# alone identifies EmpName
the relation is not in 2NF. HoursWorked does require both parts of the key.

To fix it, we need to make an Employee relation with just Employee# as key, and include
EmpName there. So the new set of relations is:

Employees (Employee#, EmpName)

TimeSheet (Date, Employee#, HoursWorked)

2. This one is in 3NF, so no need to fix it. To know how much rain fell in the city on a
particular date, we need all of Month, Day and Year.

3. This one is in 2NF.

There is no repeating group, so it is at least 1NF. To be in 2NF, all non-key attributes

have to be dependent on the WHOLE key. Since the primary key only has one attribute
(Account#), that is it is not composite, the relation is automatically in 2NF. To be in
3NF, all non-key attributes have to depend on the key and not some other non-key
attribute (that is, must depend on NOTHING BUT the key). Here is the problem.
OwnerName is really dependent on OwnerSSN, not Account#. The other two attributes
(OwnerSSN and Balance) depend on the primary key. So to fix the relation, pull out the
OwnerName into a new relation, use what it depends on as the primary key. That is, we
have TWO entitiesBankAccounts and Customers.
 Customers (OwnerSSN, OwnerName)
BankAccount (Account#, OwnerSSN, Balance)

4. This one is obviously unnormalized, given the repeating group (between the
parentheses). Fixing it is not trivial!

First, remove the repeating group. That comes about because one class can have many
students. We say there is a one-to-many (1:M) relationship between them. Sometimes
we use the symbol <->> where a single arrowhead is pointing toward the one side and
a double arrowhead toward the many. So, class <->> student. But in the real world,
we know that one class has many student AND one student takes many classes. So, this
is really a many-to-many relationship (M:N or M:M or class <<->> student, note the
double arrowhead in both directions).

Looking at the attributes, we may note that there are several entitiesClasses,
Students, Majors. And there is a relationshipStudents take classes. Normally we
have a table for each entity and for most relationships. Identify the key for each
relationship.

Class (ClassCode,
Students (StudentID,
Majors (MajorCode,
Enrollment (ClassCode, Student,

Then decide for the non-key attributes, which relation do they fit in? What is needed to
identify the attribute.
ClassCode -> ClassName // given ClassCode, know ClassName
ClassCode -> Credits
StudentID -> StudentName
MajorCode -> MajorName
ClassCode, StudentID -> Grade // need BOTH ClassCode and StudentID to
// determine grade

Final relations:

Class (ClassCode, ClassName, Credits)

Students (StudentID, StudentName, MajorCode)
Majors (MajorCode, MajorName)
Enrollment (ClassCode, StudentID, Grade)

Note that MajorCode in the Students relation is a foreign key into the Major table.
Similarly, both ClassCode and StudentID in the Enrollment table are foreign keys into the
Class and Students relations, respectively.

The other way to work on this problem is to fix the unnormalized portion first.
That is go from the original:

School (ClassCode, ClassName, Credits, (StudentID, Grade, StudentName,

MajorCode, MajorName))

to the set of relations below by removing the repeating portion and concatenating the key
from the whole with the primary key of the repeating portion.

School (ClassCode, ClassName, Credits)

CourseStudent (ClassCode, StudentID, Grade, StudentName,
MajorCode, MajorName)

Now, looking at the first relation, it has ClassCode as key and ClassName and Credits as
attributes. The non-key depend on the primary key. The only problem is the name. The
relation really refers to Courses or Classes, so probably should be renamed. If so, we get
the Class relation as above.

Now consider the second relation. It has a composite key. Check each non-key attribute
to see if they depend on the WHOLE key. Grade does depend on both ClassCode and
StudentID. StudentName depends only on StudentID, MajorCode and MajorName
similarly depend only on the Student and not a particular class the student took. So we
need to make a new relation for Student, and remove the non-key attributes that depend
only the Student from the CourseStudent relation. We now have:

Class (ClassCode, ClassName, Credits)

CourseStudent (ClassCode, StudentID, Grade)
Student(StudentID, StudentName, MajorCode, MajorName)

CourseStudent and Class are now fine. But look at Student. It is in 2NF (no repeating
group and no way to have attributes dependent on only part of the key). But it is not in
3NF. That is MajorName really depends on MajorCode and not on StudentID. We can
fix it by (again), making a new relation for Majors and pull out MajorName. This yields
the same final set of relations as above.