Chapter 4
Chapter 4
Normalization
A relational database is merely a collection of data, organized in a
particular manner.
As the father of the relational database approach, Codd created a
series of rules called normal forms that help define that organization
Database normalization is a series of steps followed to obtain a
database design that allows for consistent storage and efficient access
of data in a relational database.
These steps reduce data redundancy and the risk of data becoming
inconsistent.
NORMALIZATION is the process of identifying the logical
associations between data items and designing a database that will
represent such associations but without suffering the update anomalies
which are;
Insertion Anomalies
Prepared by: Elisaye B.@ WSU-DTC 1
Deletion Anomalies
Normalization may reduce system performance since
data will be cross referenced from many tables.
Thus denormalization is sometimes used to improve
performance, at the cost of reduced consistency
guarantees.
Normalization normally is considered as good if it is
lossless decomposition.
All the normalization rules will eventually remove the
update anomalies that may exist during data
manipulation after the implementation. The update
anomalies are;
Insertion anomalies
Deletion anomalies
Modification anomalies
Prepared by: Elisaye B.@ WSU-DTC 2
1. Insertion anomalies
In a properly normalized database, information about a new
entry needs to be inserted into only one place in the database
An "insertion anomaly" is a failure to place information
about a new database entry into all the places in the database
where information about that new entry needs to be stored.
2. Deletion anomalies
A "deletion anomaly" is a failure to remove information
about an existing database entry when it is time to remove
that entry.
3. Modification anomalies
A modification of a database involves changing some value
of the attribute of a table.
The purpose of normalization is to reduce the chances for
Prepared by: Elisaye B.@ WSU-DTC 3
anomalies to occur in a database.
Functional Dependency (FD)
Before moving to the definition and application of normalization,
it is important to have an understanding of "functional
dependency.“
Data Dependency
The logical association between data items that point the
database designer in the direction of a good database design are
refered to as determinant or dependent relationships.
X Y holds if whenever two tuples have the same value for X,
they must have the same value for Y
The notation is: AB which is read as; B is functionally
dependent on A
In general, a functional dependency is a relationship among
attributes.
FDs are derived from the real-world
Prepared constraints on the attributes
by: Elisaye B.@ WSU-DTC 4
Prepared by: Elisaye B.@ WSU-DTC 5
FDs basically categorized as Partial Dependency,
Full Dependency, Transitive Dependency.
Partial Dependency
If an attribute which is not a member of the
primary key is dependent on some part of the
primary key (if we have composite primary key)
then that attribute is partially functionally
dependent on the primary key.
Let {A,B} is the Primary Key and C is no key
attribute.
Then if {A,B}C and B C
Then C is partially functionally dependent on
Prepared by: Elisaye B.@ WSU-DTC 6
Full Dependency
If an attribute which is not a member of the
primary key is not dependent on some part of the
primary key but the whole key (if we have
composite primary key) then that attribute is fully
functionally dependent on the primary key.
Let {A,B} is the Primary Key and C is no key
attribute
{A,B} C and B C
Then if
1NF