UCCD 1203

Database Development and

Applications
Topic 7 Normalization

1
Reminder:
Intellectual Property
◼ Copyright must be seriously protected. The University
takes a strong stand against any illegal photocopying and
distributing of all materials provided to students. Students
are forewarned of the consequences and the penalty that
may be meted out if they are “caught in the act”.
◼ All the materials provided to student SHOULD NOT be
posted/distributed at any online platform or any other
ways possible without the permission.
Objectives

◼ How tables that contain redundant data can suffer from update
anomalies, which can introduce inconsistencies into a database.
◼ Identification of various types of update anomalies such as
insertion, deletion, and modification anomalies.

◼ Purpose of normalization.

◼ How to undertake process of normalization.

◼ The rules associated with the most commonly used normal forms,
namely first (1NF), second (2NF), and third (3NF).

3
Purpose

◼ Your goal as a database designer is to "store

information in one place and the best
place“. Following the rules of normalization
helps you achieve this goal.

4
 The Evils of Data redundancy

◼ Major aim of relational database design is to group

columns into tables to minimize data redundancy and
reduce file storage space required by base tables.

◼ Redundancy is the root of several problems associated

with relational schemas.
◼ Redundant storage, insert/delete/modification
anomalies.

5
 Data redundancy

StaffBranch table has redundant data; the details of a branch are repeated
for every member of staff.

6
Data redundancy Resolved

7
Data redundancy and update anomalies
◼ Tables that contain redundant information may
potentially suffer from update anomalies.

◼ 3 types of update anomalies include

◼ Insertion Anomaly – adding new rows forces user to create
duplicate data, violate integrity rules
◼ Deletion Anomaly – deleting rows may cause a loss of data
that would be needed for other future rows
◼ Modification Anomaly – changing data in a row forces
changes to other rows because of duplication

8
Example

9
Insertion anomalies

Insert a record for a new staff located in B001, we

must also enter the correct details for that branch.

To insert a new branch currently has no staff will

cause problem because staffNo is a primary key
which cannot be null.

10
 Deletion anomalies

◼ Delete a record that represents the last member of

staff located at a branch, the details about that
branch are lost from the database.
◼ For example, delete the record of staff named Art
Peters will result in the lost of details of the branch
B003 from the database.

11
 Modification anomalies

◼ To change the value of one attribute (say

telNo of B001), we must remember to change
all the telNo associated to B001. Otherwise
the database will be inconsistent. In this
case, B001 will have two different telNo.

12
EmpNo EmployeFirst Child1 Child2 child3

1 Anna John Joanne Zoe

2 Mark Sue Karen Joe

3 Mary Zoe

4 Susan
Donor Donation 1 Donation 2 Donation 3 Donation 4
Angel Pinelli
421-99-1243

Victor Gomez $200 Solar Scholars

351-12-9867 (Powering schools
with solar panels)
1/4/2015

Victor Gomez $100 Pear Creek $100 DanubeLand $50 Forest Asia
351-12-9867 (Cleaning up litter Trust (Planting trees in
and pollutants from (Purchasing and Asia) 4/1/2016
Pear Creek) preserving land in
11/6/2015 the Danube
watershed)
24/12/2015
Jack Lee $150 Forest Asia $150 Forest Asia $100 Pear Creek
231-49-0802 ( Planting trees in ( Planting trees in (Cleaning up
Asia) 1/7/2015 Asia) 1/2/2016 litter and
pollutants from
Pear Creek)
1/2/2016
Well-Structured Relations and Data
Normalization
◼ A relation that contains minimal data redundancy
and allows users to insert, delete, and update
rows without causing data inconsistencies

◼ Primarily a process to validate and improve a

logical design so that it satisfies certain
constraints that avoid unnecessary duplication of
data

◼ The process of decomposing relations with

anomalies to produce smaller, well-structured
relations
 Normalization
◼ Normalization is a relational database concept.
However, if you have created a correct entity model,
then the tables created during design will conform to
the rules of normalization.
◼ Anomalies can be removed by splitting the relation
into two or more relations; each with a different,
single theme.
◼ However, breaking up a relation may create
referential integrity constraints
◼ Works through a series of stages called normal forms:
◼ Normal form (1NF)
◼ Second normal form (2NF)
◼ Third normal form (3NF)
◼ …
 Normalization Rules
Normal Form Rule Description
First Normal Form All attributes are simple/single
valued. No repeating group.
Second Normal Form (2NF) An attribute must be dependent upon
entity’s entire unique identifier.
Third Normal Form (3NF) No non-UID attribute can be
dependent on another non-UID
attribute.

A normalized entity-relationship data model automatically translates into

a normalized relational database design.

Third normal form is the generally accepted goal for a database

design that eliminated redundancy.
Steps in
normalization
Functional Dependency

◼ Diagrammatic representation:

Determinant of a functional dependency

refers to attribute or group of attributes on
left-hand side of the arrow.

19
 Unnormalized Form (UNF)
◼ A table that contains one or more repeating
groups
◼ A repeating group is an attribute or group of
attributes, within a table that occurs with
multiple values for a single occurrence of the
nominated key attribute(s) of that table.
◼ To create an unnormalized table:
◼ transform data from information source (e.g.
form) into table format with columns and
rows.

20
Branch table is not in 1NF

21
Relation which is in unnormalized Form
B001 8, Jefferson … 503-555-3618
503-555-2727
503-555-6534
B002 City center plaza, … 206-555-6756
206-555-8836
B003 14-8th Avenue….
 First Normal Form
◼ The intersection of every column and record
contains only one value.
◼ There are no repeating groups in the table
◼ All attributes are dependent on primary key
◼ All relational tables satisfy 1NF requirements
◼ Some tables contain partial dependencies
◼ Dependencies based on only part of the primary key
◼ Sometimes used for performance reasons, but should
be used with caution
◼ Still subject to data redundancies

23
 UNF to 1NF

◼ Conversion to First Normal Form

◼ Step 1: Eliminate the repeating groups,
multivalued attributes
◼ Step 2: Identify the Primary Key
◼ Step 3: Identify all Dependencies

24
Branch table is not in 1NF

25
 UNF
B001 8, Jefferson … 503-555-3618
503-555-2727
503-555-6534
B002 City center plaza, … 206-555-6756
206-555-8836
B003 14-8th Avenue….

Step 1: Eliminate the repeating

groups, multivalued attributes
 UNF to 1NF (‘flattening’ the table)
B001 8, Jefferson … 503-555-3618
B001 8, Jefferson … 503-555-2727
B001 8, Jefferson … 503-555-6534
B002 City center plaza, … 206-555-6756
B002 City center plaza, … 206-555-8836
B003 14-8th Avenue….

the repeating groups, multivalued attributes

eliminated.
Step 2: Identify the Primary Key
Step 3: Identify all Dependencies
◼ Primary Key – BranchNo+telNo

BranchNo telNo branchAddress

◼

Step 2: Identify the Primary Key

Step 3: Identify all Dependencies
Converting Branch table to 1NF

29
Is the table in 1NF?

Step 1: Eliminate the repeating

groups, multivalued attributes
Step 2: Identify the Primary Key
Step 3: Identify all Dependencies

30
Second Normal Form
◼ a table that is 1NF and every non-key attribute is fully
functionally dependent on the ENTIRE primary key
◼ Every non-key attribute must be defined by the
entire key, not by only part of the key
◼ No partial functional dependencies

◼ 2NF only applies to tables with composite primary

keys.
1NF to 2NF

◼ Identify all key components.

◼ Identify dependent attributes in the relation.

32
Is the table in 2NF?

a table that is 1NF and partial dependency

33
34
 Third normal form (3NF)

◼ A table that is in 2NF and in which all non-primary-key

column can be worked out from only the primary key
column(s) and no other columns.
◼ no transitive dependencies
◼ Transitive dependency is a dependency of one non-key
attribute on another non-key attributes.

◼ Solution: non-key determinant with transitive

dependencies go into a new table; non-key determinant
becomes primary key in the new table and stays as
foreign key in the old table

36
 2NF to 3NF

◼ Identify the primary key in the 2NF relation.

◼ Identify functional dependencies and partial
dependencies in the relation.

◼ If transitive dependencies exist on the primary key

remove them by placing them in a new relation
along with copy of their determinant.

37
38
Converting the StaffBranch table to 3NF
More examples

40
 The Need for Normalization

◼ Example: company that manages building

projects
◼ Charges its clients by billing hours spent on
each contract
◼ Hourly billing rate is dependent on employee’s
position
◼ Periodically, a report is generated that
contains information displayed in Table 5.1

41
42
43
 Dependency Diagram

Projno Empno ProjName empName JobClass ChgHr HrWorked Pmgr

 Dependency Diagram

Projno Empno ProjName empName JobClass ChgHr HrWorked Pmgr

 Dependency Diagram

Projno Empno ProjName empName JobClass ChgHr HrWorked Pmgr

FD

Projno Empno ProjName empName JobClass ChgHr HrWorked Pmgr

FD : Full Dependency
 Dependency Diagram

Projno Empno ProjName empName JobClass ChgHr HrWorked Pmgr

FD

PD

PD

FD : Full Dependency
PD: Partial Dependency
 FD : Full Dependency
Dependency Diagram PD: Partial Dependency

Projno Empno ProjName empName JobClass ChgHr HrWorked Pmgr

FD

PD
PD

PROJECT: PROJECT_EMP:
Projno ProjName Pmgr
Projno Empno HrWorked

EMPLOYEE:
Empno empName JobClass ChgHr
 Dependency Diagram

Projno Empno ProjName empName JobClass ChgHr HrWorked Pmgr

FD

PD

PD

TD

FD : Full Dependency
PD: Partial Dependency
TD: Transitive Dependency
 FD : Full Dependency
Dependency Diagram PD: Partial Dependency
TD: Transitive Dependency

Projno Empno ProjName empName JobClass ChgHr HrWorked Pmgr

FD
PD
PD
TD
PROJECT:
PROJECT_EMP:
Projno ProjName Pmgr
Projno Empno HrWorked

EMPLOYEE: JOB:
Empno empName JobClass ChgHr JobClass ChgHr
 Dependency Diagram

Projno Empno ProjName empName JobClass ChgHr HrWorked Pmgr

FD

PD

PD

TD

FD : Full Dependency
PD: Partial Dependency
TD: Transitive Dependency
Identify and discuss each of the
indicated dependencies.

C1 C2 C3 C4 C5

52
Specify the primary key, foreign key and normal
form

Table

Prima
C1 C2 Forei
Norm

Table

C1 C3 C4 C5 Prima
Foreig
Norma
tab
de

54
 Table 1

Primary key: C1
C1 C2 Foreign key: None
Normal form: 3NF

Table 2

C1 C3 C4 C5 Primary key: C1 + C3
Foreign key: C1 (in Table 1)
Normal form: 2NF, because the
table exhibits the transitive
dependencies C4 C5
Specify the primary key, foreign key and
normal form

Table
Prima
C1 C2 Foreig
Norm

Table
Prima
C1 C3 C4 Foreig

Norm

Table
Prima
C4 C5 Foreig
Norm

56
 Table 1
Primary key: C1
C1 C2 Foreign key: None
Normal form: 3NF

Table 2
Primary key: C1 + C3
C1 C3 C4 Foreign key: C1 (in Table 1)
C4 (in Table 3)
Normal form: 3NF

Table 3
Primary key: C4
C4 C5 Foreign key: None
Normal form: 3NF