Data Normalization

Program Name

Acronym Name

ID

0001

BS Computer Science

BSCS

970169 F

0002

BS Management Information
System

0004

Associate in Computer
Networking

ACoN

Richel

970171 F

0001

BS Computer Science

BSCS

Jeffrey

970172 M

0002

BS Management Information
System

BSMIS

Bunny

970173 F

0003

BS Information Technology

BSIT

Luisa

970174 F

80

0003

BS Information Technology

BSIT

Evans

970175 M

81

0001

BS Computer Science

BSCS

Vicky

970176 F

94

0002

BS Management Information
System

0002

BS Management Information
System

0004

Associate in Computer
Networking

ACoN

John

970179 M

0005

BS Computer Engineering

BSCoE

Ryan

970180 M

Noreen

Sex

FG

Code

85
78

BSMIS

Sheryl

970170 F
88
97
79

98
BSMIS

Milbert

970177 M
88

BSMIS

AJ

970178 F
76
89

Data Normalization
The

process of decomposing relations

with anomalies to produce smaller,
well-structured relations

Improve

a logical design so that it

satisfies certain constraints that avoid

unnecessary duplication of data

Well-Structured Relations

A relation that contains minimal data redundancy and

allows users to insert, delete, and update rows without
causing data inconsistencies
Goal is to avoid anomalies

Insertion Anomaly adding new rows forces user to create

duplicate data
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

General rule of thumb: a table should not pertain to

more than one entity type

Anomalies in this Table

Insertion

cant enter a new employee without

having the employee take a class
Deletion if we remove employee 140, we lose
information about the existence of a Tax Acc class
Modification giving a salary increase to employee
100 forces us to update multiple records
Why do these anomalies exist?
Because there are two themes (entity types) into one
relation. This results in duplication, and an
unnecessary dependency between the entities

Steps in
normalization

First Normal Form

No

multivalued attributes
Every attribute value is atomic
All relations are in 1st Normal
Form

Note: this is NOT a relation

Table with no multivalued attributes and unique rows

Note: this is relation, but not a well-structured one

Anomalies in this Table

Insertion

if new product is ordered for order 1007

of existing customer, customer data must be reentered, causing duplication
Deletion if we delete the Dining Table from Order
1006, we lose information concerning this item's
finish and price
Update changing the price of product ID 4
requires update in several records
Why do these anomalies exist?
Because there are multiple themes (entity types) into
one relation. This results in duplication, and an
unnecessary dependency between the entities

Second Normal Form

1NF

PLUS 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

Functional Dependencies and Keys

Functional

Dependency: The value of

one attribute (the determinant)
determines the value of another
attribute

Order_ID Order_Date, Customer_ID, Customer_Name, Customer_Address

Product_ID Product_Description, Product_Finish, Unit_Price
Order_ID, Product_ID Order_Quantity

Therefore, NOT in 2nd Normal Form

Getting it into Second Normal Form

Partial Dependencies are removed, but there

are still transitive dependencies

Third Normal Form

PLUS no transitive dependencies
(functional dependencies on non-primary-key
attributes)
Note: this is called transitive, because the
primary key is a determinant for another
attribute, which in turn is a determinant for a third
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
2NF

Getting it into Third Normal Form

Transitive dependencies are removed

Another Example
Assignment(EventID,

Location, EventDate,
EmpID, Name, AssignedRole, StartTime,
EndTime)
Already in the 1st Normal Form
Full Functional Dependency

EventID, EmpID AssignedRole, StartTime, EndTime

Partial

Functional Dependencies

EventID Location, EventDate

EmpID Name

Exercises

Reservation( Reservation Code, Flight Number,

Flight Date, Origin, ETD, ETA, Passenger Name,
Seat Number, Reservation Agent No.,
Reservation Agent Name )
Rental_History(MemberID, MemberName,
VideoID, VideoFormat, StorageType, MovieID,
MovieTitle, ActorName, date_rented,
date_returned, amt_paid)
Instructor(EmployeeID, Employee Name,
CourseCode, Duration, DayOfWeek)

Boyce-Codd Normal Form (BCNF)

3NF

relations are generally in BCNF

Results to relations in which every
determinant is a candidate key.

3NF Relation but not BCNF

StudentID Course_Major Adviser

StudentID

Course_Major

Adviser

Major_Grade

Major_Grade

123

Programming

Dulaca

90

123

Databases

Opina

86

456

Multimedia

Elumba

88

789

Databases

Opina

82

678

Programming

Dulaca

89

Getting it into BCNF

1.

The determinant in the relation that is not a

candidate key becomes a component of the
primary of the revised relation. The attribute that
is functionally dependent on that determinant
becomes a nonkey attribute.

StudentID

Adviser

Course_Major

Major_Grade

Getting it into BCNF

Decompose the relation to eliminate the partial functional
dependency

StudentID

Adviser

Adviser

Major Grade

Course_Major

Fourth Normal Form

A relation

in BCNF that contains no

multivalued dependencies
Multivalued Dependency the type of
dependency that exists where there are
atleast 3 attributes in a relation (A,B and
C), with a well-defined set of B and C
values for each A value, but those B
and C are independent of each other

Relation in BCNF
Offering
Course

Course

Instructor

Instructor

Textbook

Textbook

Management

White

Drucker

Management

White

Peters

Management

Green

Drucker

Management

Green

Peters

Management

Black

Drucker

Management

Black

Peters

Finance

Gray

Jones

Finance

Gray

Change

Contains
redundant
data that
can lead to
update
anomalies

Getting it into 4NF

To remove

the multivalued dependency,

divide the relation into two new
relations. Each of these relations
contain two attributes that have a
multivalued relationship in the original
relation

Relation in 4NF

Course_Teacher

Course
Course

Course_Text

Instructor
Instructor

Course

Textbook

Course

Textbook

Management

White

Management

Drucker

Management

Green

Management

Peters

Management

Black

Finance

Jones

Finance

Gray

Finance

Change

Fifth Normal
Deals

with the property called lossless

joins
Occurs very rarely and difficult to detect;
not practical

Quiz: Determine the relations present normal

form. If the relation is not in the 3rd Normal Form,
normalize it. Show the dependencies.

Inventory (ItemID, ItemName, Quantity,

VendorID, VendorName, VendorAddress,
InventoryNumber)
Park (ParkID, ParkAddres, AreaID,
AreaType, AreaCapacity)
PriceList (ItemID, ItemName, Price,
EffectiveDate, VendorID, VendorName,
VendorAddres)