Normalization of Database Tables
Database Tables and
Normalization
Normalization is a process for assigning attributes to
entities. It reduces data redundancies and helps eliminate
the data anomalies.
Normalization works through a series of stages called
normal forms:
– First normal form (1NF)
– Second normal form (2NF)
– Third normal form (3NF)
– Fourth normal form (4NF)
The highest level of normalization is not always desirable.
Database Tables and Normalization
The Need for Normalization
– Case of a Construction Company
Building project -- Project number, Name, Employees
assigned to the project.
Employee -- Employee number, Name, Job classification
The company charges its clients by billing the hours spent
on each project. The hourly billing rate is dependent on
the employee’s position.
Periodically, a report is generated.
The table whose contents correspond to the reporting
requirements is shown in Table 5.1.
Scenario
A few employees works for Project Num : 15
one project.
Project Name :
Evergreen
Employee Num :
101, 102, 103,
105
Sample Form
Project Num : 15
Project Name : Evergreen
Emp Num Emp Name Job Class Chr Hours Hrs Billed Total
101
102
103
105
Table Structure Matches
the Report Format
Database Tables and Normalization
Problems with the Figure 5.1
– The project number is intended to be a primary key, but it
contains nulls.
– The table displays data redundancies.
– The table entries invite data inconsistencies.
– The data redundancies yield the following anomalies:
Update anomalies.
Addition anomalies.
Deletion anomalies.
Database Tables and Normalization
Conversion to First Normal Form
– A relational table must not contain repeating groups.
– Repeating groups can be eliminated by adding the
appropriate entry in at least the primary key
column(s).
Data Organization: First Normal Form
After
Before
First Normal Form (1 NF)
1NF Definition
– The term first normal form (1NF) describes the
tabular format in which:
All the key attributes are defined.
There are no repeating groups in the table.
All attributes are dependent on the primary key.
Dependency Diagram
Dependency Diagram
– The primary key components are bold, underlined, and shaded in
a different color.
– The arrows above entities indicate all desirable dependencies,
i.e., dependencies that are based on PK.
– The arrows below the dependency diagram indicate less
desirable dependencies -- partial dependencies and transitive
dependencies.
Second Normal Form (2 NF)
Conversion to Second Normal Form
– Starting with the 1NF format, the database can be converted
into the 2NF format by
It should be 1NF
All the non-primary key attributes should be functionally
dependent on the primary key.
PROJECT (PROJ_NUM, PROJ_NAME)
EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS, CHG_HOUR)
ASSIGN (PROJ_NUM, EMP_NUM, HOURS)
Dependency Diagram
Second Normal Form (2 NF)
A table is in 2NF if:
It is in 1NF and
It includes no partial dependencies; that is, no
attribute is dependent on only a portion of the
primary key.
(It is still possible for a table in 2NF to exhibit
transitive dependency; that is, one or more
attributes may be functionally dependent on
nonkey attributes.)
Third Normal Form (3 NF)
Conversion to Third Normal Form
– Create a separate table with attributes in a transitive
functional dependence relationship.
PROJECT (PROJ_NUM, PROJ_NAME)
ASSIGN (PROJ_NUM, EMP_NUM, HOURS)
EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS)
JOB (JOB_CLASS, CHG_HOUR)
Third Normal Form (3 NF)
3NF Definition
– A table is in 3NF if:
It is in 2NF and
It contains no transitive dependencies.
The Completed
Database
Boyce-Codd Normal Form (BCNF)
– A table is in Boyce-Codd normal form (BCNF) if every
determinant in the table is a candidate key.
(A determinant is any attribute whose value
determines other values with a row.)
– If a table contains only one candidate key, the 3NF and
the BCNF are equivalent.
– BCNF is a special case of 3NF.
– Figure 5.7 illustrates a table that is in 3NF but not in
BCNF.
– Figure 5.8 shows how the table can be decomposed to
conform to the BCNF form.
A Table That Is In 3NF
But Not In BCNF
The Decomposition of a Table Structure
to Meet BCNF Requirements
Sample Data for a BCNF Conversion
Decomposition into BCNF
BCNF Definition
BCNF Definition
– A table is in BCNF if every determinant in that table
is a candidate key. If a table contains only one
candidate key, 3NF and BCNF are equivalent.
Normalization
– Normalization will help us identify correct and
appropriate TABLES.
– Until Now we have 4 tables
PROJECT (PROJ_NUM, PROJ_NAME)
ASSIGN (PROJ_NUM, EMP_NUM, HOURS)
EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS)
JOB (JOB_CLASS, CHG_HOUR)
NEXT ........
– We are going to identify the relationships
between entities (tables) including their
cardinality, connectivity.
– We have to list out the Business Rules.
PROJECT (PROJ_NUM, PROJ_NAME)
ASSIGN (PROJ_NUM, EMP_NUM, HOURS)
EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS)
JOB (JOB_CLASS, CHG_HOUR)
Fourth Normal form
4NF is the next level of normalization after Boyce–
Codd normal form (BCNF). A table is in 4NF if and
only if, for every one of its non-trivial multivalued
dependencies X {\displaystyle \twoheadrightarrow
} Y, X is a superkey—that is, X is either a candidate
key or a superset thereof.
Table SHOULD BE in BCNF
No Multivalued dependencies
The problem is that the table features two non-
trivial multivalued dependencies on the
{Restaurant} attribute (which is not a superkey).
The dependencies are:
•{Restaurant} {Pizza Variety}
•{Restaurant} {Delivery Area}
To eliminate the possibility of
these anomalies, we must
place the facts about varieties
offered into a different table
from the facts about delivery
areas, yielding two tables that
are both in 4NF:
Fifth Normal form
Fifth normal form (5NF), also known as project-join normal
form (PJ/NF) is a level of database normalization designed to
reduce redundancy in relational databases recording multi-
valued facts by isolating semantically related multiple
relationships. A table is said to be in the 5NF if and only
if every non-trivial join dependency in that table is implied by
the candidate keys.
Table should be in 4 NF.
No Join Depedency.
The primary key is the composite of all three
columns. Also note that the table is in 4NF, since
there are no multivalued dependencies (2-part join
dependencies) in the table: no column (which by
itself is not a candidate key or a superkey) is a
determinant for the other two columns.
Suppose, however, that the following rule
applies: A Traveling Salesman has certain Brands
and certain Product Types in their repertoire. If
Brand B1 and Brand B2 are in their repertoire,
and Product Type P is in their repertoire, then
(assuming Brand B1 and Brand B2 both make
Product Type P), the Traveling Salesman must
offer products of Product Type P those made by
Brand B1 and those made by Brand B2.
In that case, it is possible to split the table into
three:
Business Rules
The company manages many projects.
Each project requires the services of many employees.
An employee may be assigned to several different
projects.
Some employees are not assigned to a project and
perform duties not specifically related to a project.
Some employees are part of a labor pool, to be shared
by all project teams.
Each employee has a (single) primary job
classification. This job classification determines the
hourly billing rate.
Many employees can have the same job classification.
Normalization and Database Design
Two Initial Entities:
PROJECT (PROJ_NUM, PROJ_NAME)
EMPLOYEE (EMP_NUM, EMP_LNAME, EMP_FNAME,
EMP_INITIAL, JOB_DESCRIPTION, JOB_CHG_HOUR)
Normalization and Database Design
Three Entities After Transitive Dependency Removed
PROJECT (PROJ_NUM, PROJ_NAME)
EMPLOYEE (EMP_NUM, EMP_LNAME, EMP_FNAME, EMP_INITIAL,
JOB_CODE)
JOB (JOB_CODE, JOB_DESCRIPTION, JOB_CHG_HOUR)
The Modified ERD
Creation of Composite Entity ASSIGN
Normalization and Database Design
Attribute ASSIGN_HOUR is assigned to the composite entity
ASSIGN.
“Manages” relationship is created between EMPLOYEE and
PROJECT.
PROJECT (PROJ_NUM, PROJ_NAME, EMP_NUM)
EMPLOYEE (EMP_NUM, EMP_LNAME, EMP_FNAME, EMP_INITIAL,
EMP_HIREDATE, JOB_CODE)
JOB (JOB_CODE, JOB_DESCRIPTION, JOB_CHG_HOUR)
ASSIGN (ASSIGN_NUM, ASSIGN_DATE, PROJ_NUM, EMP_NUM,
ASSIGN_HOURS)
Relational Schema
Higher-Level Normal Forms
4NF Definition
– A table is in 4NF if it is in 3NF and has no multiple sets
of multivalued dependencies.
A Set of Tables in 4NF
Denormalization
Normalization is only one of many database design
goals.
Normalized (decomposed) tables require additional
processing, reducing system speed.
Normalization purity is often difficult to sustain in
the modern database environment. The conflict
between design efficiency, information
requirements, and processing speed are often
resolved through compromises that include
denormalization.
SUMMARY
The Initial 1NF Structure
Identifying the Possible PK Attributes
Table Structures Based On
The Selected PKs
