WEEK III

DATABASE NORMALIZATION
Database normalization is a series of steps to obtain a database design that allows
efficient organization access and storage of data in a relational database.
Normalization can also be referred to as the process of organizing the fields and tables
of a relational database to minimize redundancy and dependency.

The main objective of database normalization is to restructure the logical data model
of a database to:

 Eliminate redundancy
 Organize data efficiency
 Reduce the potential for data anomalies.

Normalization usually involves dividing a database into two or more tables and
defining relationships between the tables.

Normal forms
There are guidelines (or steps) for ensuring that database table is normalized. These
guidelines are referred to as normal forms. We have First normal form (1NF), Second
normal form (2NF), Third normal form (3NF), Fourth normal form (4NF) and Fifth
normal form (5NF).

Non-Normal form (ONF): a table in a relational database is not in normal form if it

contains multiple values in a single cell, a repeating group of similar data or does not
contain unique identifier for each row.

Un-normalized employee table

Employee ID Employee F_Name Employee L_Name Qualification
P112 Paul Dada OND, BSC
P113 Lawal Usman NECO, BA
P114 Uche Chukwudu WAEC, NCE, BED
P115 Oladele Adebayo NECO
P116 John Stone NECO

This table is not in normal form because of the following reason: the qualification
column contains multiple values in a single cell.

1
Un-normalized product table
Product I Colour Price
1 Red, green 15.99
2 Yellow 23.99
3 Green 17.50
4 Yellow, blue 9.99
5 Red 29.99

This table is not in normal form because the (colour) column contains multiple values.
To bring this table to 1st normal form, we split the table into two tables.

Normalized product table

Table_Product_Price

Product ID Price
1 15.99

2 23.99

3 17.50

4 9.99

5 29.99

Table_Product_Colour

Product ID colour
1 red
1 Green
2 Yellow
3 Green
4 Yellow
4 Blue
5 Red

First normal form (1NF): it eliminates repeating groups by putting each value of a
multi-valued attribute into a new row. A table is said to be in 1NF if:

2
  Each row contains a unique identifier (Primary key)
 Each column contains only atomic values (i.e. no multiple values in a single
cell)
 No repeating groups of similar data.

A unique identifier (primary key) is a value that uniquely identifies a row. When the
value is made up of two or more values it becomes a composite key. An atomic value
is a value that cannot be divided or separated.

To create a 1NF table:

Step 1: identify the primary key in the table

Step 2: identify the columns with multiple values or repeating group of data.

Step 3: eliminate multiple values by putting each value into a new one.

Examples of 1NF tables are:

Customer ID First name Surname Phone No

CUS-201 Ade Babatunde 08044665555
CUS-235 Jenifer Wright 08044335566
CUS-339 Usman Hammed 08054545454
CUS-339 Usman Hammed 08045456677
CUS-345 Oghor Abednego 08036336344
Primary key (Unique identifier) = Customer ID

Student table
Reg No Student_Sname Student_Fname Course
001 Babatunde Peters ICT 302
001 Babatunde Peters MAT 300
002 Oni Titilayo ICT 302
002 Oni Titilayo ICT 301
003 Matthew Emeka ICT 302
003 Matthew Emeka ICT 314
004 Amaka Michael MAT 305

Problems of table in 1NF

(i) Data duplication: there is duplication of data items within the same
database.
(ii) Cascade update: if a data item is replaced then all the records that has the
data item need to be updated.

3
 (iii) Consume time: as a result of cascade update processing time is consumed
for checking and performing updates.

Functional dependency and determinant of normal form

A functional dependency is the relationship between fields in which the value in one
field determines the value in another field. Consider the table below:

Stadium Town
National Abuja
Liberty Ibadan
Lekan Salami Ibadan
Teslim Balogun Lagos
Nnamdi Azikwe Enugu
Ahmadu Bello Kaduna
Onikan Lagos

Each stadium name is unique and can only be one town. This means town is
functionally dependent on stadium. That is, the value in the stadium field determines
the value in the town field (i.e. stadium is a determinant field)

This is written as: Stadium Town and it is read as: stadium is a determinant
of town. On the other hand, a town can have more than one stadium, e.g. Ibadan town,
Lagos town, therefore, stadium is not functionally dependent on town; the value in
town does not determine what the value in stadium will be.