What Is Normalization?

Normalization is the branch of relational theory that provides design insights. It is the process of
determining how much redundancy exists in a table. The goals of normalization are to:

 Be able to characterize the level of redundancy in a relational schema

 Provide mechanisms for transforming schemas in order to remove redundancy

Normalization theory draws heavily on the theory of functional dependencies. Normalization

theory defines six normal forms (NF). Each normal form involves a set of dependency properties
that a schema must satisfy and each normal form gives guarantees about the presence and/or
absence of update anomalies. This means that higher normal forms have less redundancy, and as
a result, fewer update problems.

If a database design is not perfect, it may contain anomalies, which are like a bad dream for any
database administrator. Managing a database with anomalies is next to impossible.

 Update anomalies − If data items are scattered and are not linked to each other properly,
then it could lead to strange situations. For example, when we try to update one data item
having its copies scattered over several places, a few instances get updated properly while
a few others are left with old values. Such instances leave the database in an inconsistent
state.
 Deletion anomalies − We tried to delete a record, but parts of it was left undeleted
because of unawareness, the data is also saved somewhere else.
 Insert anomalies − We tried to insert data in a record that does not exist at all.

Normalization is a method to remove all these anomalies and bring the database to a consistent
state.

Normal Forms
All the tables in any database can be in one of the normal forms we will discuss next. Ideally we
only want minimal redundancy for PK to FK. Everything else should be derived from other
tables. There are six normal forms, but we will only look at the first four, which are:

 First normal form (1NF)

 Second normal form (2NF)
 Third normal form (3NF)
 Boyce-Codd normal form (BCNF)

BCNF is rarely used.

First Normal Form (1NF)
In the first normal form, only single values are permitted at the intersection of each row and
column; hence, there are no repeating groups.

To normalize a relation that contains a repeating group, remove the repeating group and form
two new relations.

The PK of the new relation is a combination of the PK of the original relation plus an attribute
from the newly created relation for unique identification.

Process for 1NF

We will use the Student_Grade_Report table below, from a School database, as our example to
explain the process for 1NF.

Student_Grade_Report (StudentNo, StudentName, Major, CourseNo, CourseName, InstructorNo,

InstructorName, InstructorLocation, Grade)

 In the Student Grade Report table, the repeating group is the course information. A student can
take many courses.
 Remove the repeating group. In this case, it’s the course information for each student.
 Identify the PK for your new table.
 The PK must uniquely identify the attribute value (StudentNo and CourseNo).
 After removing all the attributes related to the course and student, you are left with the student
course table (StudentCourse).
 The Student table (Student) is now in first normal form with the repeating group removed.
 The two new tables are shown below.

Student (StudentNo, StudentName, Major)

StudentCourse (StudentNo, CourseNo, CourseName, InstructorNo, InstructorName, InstructorLocation,
Grade)

It defines that all the attributes in a relation must have atomic domains. The values in an atomic domain
are indivisible units.
Second Normal Form (2NF)
For the second normal form, the relation must first be in 1NF. The relation is automatically in
2NF if, and only if, the PK comprises a single attribute.

If the relation has a composite PK, then each non-key attribute must be fully dependent on the
entire PK and not on a subset of the PK (i.e., there must be no partial dependency or
augmentation).

Process for 2NF

To move to 2NF, a table must first be in 1NF.

 The Student table is already in 2NF because it has a single-column PK.

 When examining the Student Course table, we see that not all the attributes are fully dependent
on the PK; specifically, all course information. The only attribute that is fully dependent is grade.
 Identify the new table that contains the course information.
 Identify the PK for the new table.
 The three new tables are shown below.

Student (StudentNo, StudentName, Major)

CourseGrade (StudentNo, CourseNo, Grade)

CourseInstructor (CourseNo, CourseName, InstructorNo, InstructorName, InstructorLocation)

 Remove partial dependency

Third Normal Form (3NF)

To be in third normal form, the relation must be in second normal form. Also all transitive
dependencies must be removed; a non-key attribute may not be functionally dependent on
another non-key attribute.

Process for 3NF

 Eliminate all dependent attributes in transitive relationship(s) from each of the tables that have
a transitive relationship.
 Create new table(s) with removed dependency.
 Check new table(s) as well as table(s) modified to make sure that each table has a determinant
and that no table contains inappropriate dependencies.
 See the four new tables below.

Student (StudentNo, StudentName, Major)

CourseGrade (StudentNo, CourseNo, Grade)

Course (CourseNo, CourseName, InstructorNo)

Instructor (InstructorNo, InstructorName, InstructorLocation)

For a relation to be in Third Normal Form, it must be in Second Normal form and the following
must satisfy −

 No non-prime attribute is transitively dependent on prime key attribute.

 For any non-trivial functional dependency, X → A, then either −
o X is a superkey or,
o A is prime attribute.

At this stage, there should be no anomalies in third normal form. Let’s look at the dependency
diagram (Figure 12.1) for this example. The first step is to remove repeating groups, as discussed
above.

Student (StudentNo, StudentName, Major)

StudentCourse (StudentNo, CourseNo, CourseName, InstructorNo, InstructorName,

InstructorLocation, Grade)

To recap the normalization process for the School database, review the dependencies shown in
Figure 12.1.

Figure 12.1 Dependency diagram, by A. Watt.

The abbreviations used in Figure 12.1 are as follows:

 PD: partial dependency

 TD: transitive dependency
 FD: full dependency (Note: FD typically stands for functional dependency. Using FD as an
abbreviation for full dependency is only used in Figure 12.1.)
Boyce-Codd Normal Form (BCNF)
When a table has more than one candidate key, anomalies may result even though the relation is
in 3NF. Boyce-Codd normal form is a special case of 3NF. A relation is in BCNF if, and only if,
every determinant is a candidate key.

Boyce-Codd Normal Form

Boyce-Codd Normal Form (BCNF) is an extension of Third Normal Form on strict terms. BCNF
states that −

 For any non-trivial functional dependency, X → A, X must be a super-key.

In the above image, Stu_ID is the super-key in the relation Student_Detail and Zip is the super-
key in the relation ZipCodes. So,

Stu_ID → Stu_Name, Zip

and

Zip → City

BCNF Example 1

Consider the following table (St_Maj_Adv).

Student_id Major Advisor

111 Physics Smith

111 Music Chan

320 Math Dobbs

671 Physics White

803 Physics Smith

The semantic rules (business rules applied to the database) for this table are:

1. Each Student may major in several subjects.

2. For each Major, a given Student has only one Advisor.
 3. Each Major has several Advisors.
4. Each Advisor advises only one Major.
5. Each Advisor advises several Students in one Major.

The functional dependencies for this table are listed below. The first one is a candidate key; the
second is not.

1. Student_id, Major ——> Advisor

2. Advisor ——> Major

Anomalies for this table include:

1. Delete – student deletes advisor info

2. Insert – a new advisor needs a student
3. Update – inconsistencies

Note: No single attribute is a candidate key.

PK can be Student_id, Major or Student_id, Advisor.

To reduce the St_Maj_Adv relation to BCNF, you create two new tables:

1. St_Adv (Student_id, Advisor)

2. Adv_Maj (Advisor, Major)

St_Adv table

Student_id Advisor

111 Smith

111 Chan

320 Dobbs

671 White

803 Smith

Adv_Maj table

Advisor Major

Smith Physics

Chan Music
Dobbs Math

White Physics