1

07 Normalization
CII1J3 Database Modelling
 2

Learning Outcomes
Students can create database modeling using E-R model,
relational model, and normalization correctly
 3

Topics
Steps in Normalization
1st Normalization
2nd Normalization
3rd Normalization
 Intro
4

• Now that we have examined functional dependencies and keys, we are

ready to describe and illustrate the steps of normalization.
• If an EER data model has been transformed into a comprehensive set of
relations for the database, then each of these relations needs to be
normalized.
• In other cases in which the logical data model is being derived from user
interfaces, such as screens, forms, and reports, you will want to create
relations for each user interface and normalize those relations.
Steps in Normalization
5
 Steps in Normalization (cont.)
6

1. First normal form Any multivalued attributes (also called repeating groups) have been
removed, so there is a single value (possibly null) at the intersection of each row and column
of the table.
2. Second normal form Any partial functional dependencies have been removed (i.e., nonkey
attributes are identified by the whole primary key).
3. Third normal form Any transitive dependencies have been removed (i.e., nonkey attributes
are identified by only the primary key).
4. Boyce-Codd normal form Any remaining anomalies that result from functional
dependencies have been removed (because there was more than one possible primary key
for the same nonkeys).
5. Fourth normal form Any multivalued dependencies have been removed.
6. Fifth normal form Any remaining anomalies have been removed.
 Example
7

• For a simple illustration, we use a customer invoice from Pine Valley Furniture Company
 8

Represent the View in Tabular Form

Invoice data (Pine Valley Furniture Company)
9

*Plus data for second order (Order ID 1007)

 10

Convert to First Normal Form

 1NF Constraints
11

A relation is in first normal form (1nF) if the following two constraints both
apply:

1. There are no repeating groups in the relation (thus, there is a single fact at
the intersection of each row and column of the table).

2. A primary key has been defined, which uniquely identifies each row in the
relation.
Remove Repeating Group
12

Repeating Group
Relation with no repeating group
13
 Determine FD & Select the Candidate Key
14

There are four determinants in INVOICE, and their functional dependencies are the following:
• OrderID → OrderDate, CustomerID, CustomerName, CustomerAddress
• CustomerID → CustomerName, CustomerAddress
• ProductID → ProductDescription, ProductFinish, ProductStandardPrice
• OrderID, ProductID → OrderedQuantity
From the four determinants we can infer that:
• OrderID, ProductID → OrderDate, CustomerID, CustomerName, CustomerAddress,
ProductDescription, ProductFinish, ProductStandardPrice, OrderedQuantity
As you can see, the only candidate key for INVOICE is the composite key consisting of the
attributes OrderID and ProductID (because there is only one row in the table for any
combination of values for these attributes).
 Relation in 1NF with CK
15

Candidate Key
 16

Anomalies still occur in 1NF

INSERTION DELETION UPDATE

ANOMALY ANOMALY ANOMALY
 17

Convert to Second Normal Form

 2NF Constraints
18

A relation is in second normal form (2NF) if it is :

1. In first normal form

2. Contains no partial functional dependencies.

A partial functional dependency exists when a nonkey attribute is

functionally dependent on part (but not all) of the primary key.
Functional Dependency Diagram for Invoice
19

As you can see, the following partial dependencies exist in

the diagram:
▪ OrderID → OrderDate, CustomerID, CustomerName, CustomerAddress
▪ ProductID → ProductDescription, ProductFinish, ProductStandardPrice
 Removing partial dependencies
20

To convert a relation with partial dependencies to second normal form, the

following steps are required:

1. Create a new relation for each primary key attribute (or combination of
attributes) that is a determinant in a partial dependency. That attribute is the
primary key in the new relation.

2. Move the nonkey attributes that are only dependent on this primary key
attribute (or attributes) from the old relation to the new relation.
Relation in 2NF (no partial dependencies)
21
 22

Convert to Third Normal Form

 Constraints
23

A relation is in third normal form (3NF) if it is:

1. in second normal form

2. no transitive dependencies exist.

Transitive dependency in a relation is a functional dependency between the

primary key and one or more nonkey attributes that are dependent on the
primary key via another nonkey attribute.
 24

There are two transitive dependencies in the CUSTOMER ORDER relation

shown in the diagram:

1. OrderID → CustomerID → CustomerName

2. OrderID → CustomerID → CustomerAddress
 Removing transitive dependencies
25

You can easily remove transitive dependencies from a relation by means of a three-step
procedure:

1. For each nonkey attribute (or set of attributes) that is a determinant in a relation, create a
new relation. That attribute (or set of attributes) becomes the primary key of the new
relation.

2. Move all of the attributes that are functionally dependent only on the primary key of the
new relation from the old to the new relation.

3. Leave the attribute that serves as a primary key in the new relation in the old relation to
serve as a foreign key that allows you to associate the two relations.
Removing transitive dependencies
26

into
Relation in 3NF (no transitive dependencies)
27
Relational schema for invoice data
28

Customer Order

PK CustomerID PK OrderID

CustomerName OrderDate

CustomerAddress FK CustomerID

Product OrderLine

PK ProductID PK FK OrderID

ProductDescription PK FK ProductID

ProductFinish OrderedQuantity

ProductStandardPrice
 29

Advanced Normalization:
Boyce-Codd Normal Form
 Definition & Constraint
30

• A relation is in Boyce-Codd normal form (BCNF) if and only if

every determinant in the relation is a candidate key
 Invoice Relation
31

There are four determinants in INVOICE from functional dependencies

• OrderID → OrderDate, CustomerID, CustomerName, CustomerAddress

• CustomerID → CustomerName, CustomerAddress

• ProductID → ProductDescription, ProductFinish, ProductStandardPrice

• OrderID, ProductID → OrderedQuantity

3NF relation:

Based on 3NF result, INVOICE relations already in BCNF, because every determinant is a candidate key.
Relation in 3NF but not in BCNF
32

Relation with sample data

Functional dependencies in
STUDENT ADVISOR
 2-step process
33

1. The relation is modified so that the determinant in the

relation that is not a candidate key becomes a
component of the primary key of the revised relation.
 2-step process
34

2. Decompose the relation to eliminate the partial

functional dependency
 Note for Decomposition
35

• The decomposition is a lossless decomposition

Let R be a relation schema and let R1 and R2 form a decomposition of R . That
is R = R1 U R2
We say that the decomposition is a lossless decomposition if there is no
loss of information by replacing R with the two relation schemas R1 U R2
Example of Lossy Decomposition
36

FAILURE DECOMPOSITION
 37

Reference

Hoffer, Jeffrey A., et.al., "Modern Database Management", Twelfth Edition,

Pearson, 2016. Chapter 4
Questions
38