CSC271 DATABASE SYSTEMS
NORMALIZATION
COMSATS UNIVERSITY ISLAMABAD, WAH CAMPUS
PREVIOUS LECTURE
OUTLINE
In this lesson, you will learn about:
• Well Structured Relations
• Functional Dependencies
• Normalization Steps
• Example
DATA NORMALIZATION
• Primarily a tool 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
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
EXAMPLE
Question–Is this a relation? Answer–Yes: Unique rows and no
multivalued attributes
Question–What’s the primary key? Answer–Composite: Emp_ID, Course_Title
ANOMALIES IN THIS TABLE
• Insertion–can’t 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) in this one relation. This results in
data duplication and an unnecessary dependency between the entities
FUNCTIONAL DEPENDENCIES AND KEYS
• Functional Dependency: The value of one
attribute (the determinant) determines the value
of another attribute
• Candidate Key:
• A unique identifier.
• One of the candidate keys will become the primary key
• E.g. perhaps there is both credit card number and SS# in a
table…in this case both are candidate keys
• Each non-key field is functionally dependent on every candidate
key
FUNCTIONAL DEPENDENCIES AND KEYS (CONT…)
a) EmpID → Name, DeptName, Salary
Determinant: The attribute on the left side of the
b) EmpID, CourseTitle → DateCompleted arrow in a functional dependency.
Steps in normalization
PRELIMINARY TO NORMALIZATION
Table with multivalued attributes, not in 1st normal form
Note: this is NOT a relation
FIRST NORMAL FORM
• A relation that has a primary key and in which
there are no repeating groups.
• No multivalued attributes
• Every attribute value is atomic
• All relations are in 1st Normal Form
Table with no multivalued attributes and unique rows, in 1st
normal form
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 re-entered, 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) in one relation. This results in
duplication and an unnecessary dependency between the entities
SECOND NORMAL FORM
• A relation in first normal form in which every non-key attribute is fully
functionally dependent on the primary key.
1. 1NF
+
2. No partial functional dependencies
• Every non-key attribute must be defined by the entire key, not by only part of the key
Partial Functional Dependencies: A functional dependency in which one or more
non-key attributes are functionally dependent on part (but not all) of the primary
key.
Functional dependency diagram for INVOICE
Order_ID ➔ Order_Date, Customer_ID, Customer_Name, Customer_Address
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
REMOVING PARTIAL DEPENDENCIES
• 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 non-key attributes that are dependent on this primary key
attribute (or attributes) from the old relation to the new relation.
Removing partial dependencies
Getting it into
Second Normal
Form
Partial dependencies are removed, but there
are still transitive dependencies
THIRD NORMAL FORM
• A relation that is in second normal form and has no transitive
dependencies.
1. 2NF +
2. No transitive dependencies
• No functional dependencies on non-primary-key attributes
• Transitive dependency: A functional dependency between the
primary key and one or more non-key attributes that are
dependent on the primary key via another non-key attribute.
REMOVING TRANSITIVE DEPENDENCIES
• Remove transitive dependencies from a relation via a three-step procedure:
1) For each non-key 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 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
Getting it into
Third Normal
Form
Transitive dependencies are removed
RELATIONAL SCHEMA FOR INVOICE DATA
