Theory of Database
Systems
Lecture 10. The process of normalization
I.
Normalization
• Normalization is a technique for producing a set of
suitable relations that support the data
requirements of an enterprise.
Suitable set of relations
• Characteristics of a suitable set of relations include:
– the minimal number of attributes necessary to
support the data requirements of the enterprise;
– attributes with a close logical relationship are found in
the same relation;
– minimal redundancy with each attribute represented
only once with the important exception of attributes
that form all or part of foreign keys.
Benefits of suitable set of relations
• The benefits of using a database that has a
suitable set of relations is that the database will
be:
– easier for the user to access and maintain the data;
– take up minimal storage space on the computer.
How Normalization Supports
Database Design
• Normalization is a bottom-up approach to DB design that begins by
examining the relationships between attributes.
• However a top-down approach can also be used that begins by
identifying the main entities and relationships and uses normalization
as a validation technique.
The Process of Normalization
• Normalization is a formal technique for analyzing
a relation based on its primary key and the
functional dependencies between the attributes of
that relation.
• Often executed as a series of steps. Each step
corresponds to a specific normal form, which has
known properties.
Normalization
• Four most commonly used normal forms are first
(1NF), second (2NF) and third (3NF) normal
forms, and Boyce–Codd normal form (BCNF).
• Normalization is based on functional
dependencies among the attributes of a relation.
• A relation can be normalized to a specific form to
prevent possible occurrence of update anomalies.
The Process of Normalization
The relationship between the normal forms.
It shows that some 1NF relations are also in
2NF and some 2NF relations are also in 3NF,
an so on.
The Process of Normalization
Unnormalized Form (UNF)
• Before discussing first normal form, we initially
give a definition of the state prior to first normal
form.
• Unnormalized form is a table that contains one or
more repeating groups.
• To create an unnormalized table
– Transform the data from the information source
(e.g. form) into table format with columns and rows.
• In this format, the table is in unnormalized form
(UNF).
Repeating group
• 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.
• Nominated key: refers to the attribute(s) that
uniquely identify each row within the
unnormalized table.
Example: Form
Collection of DreamHome leases.
In the example it is assumed that a client rents a given
property only once and cannot rent more than one
property at any one time.
UNF example
• Sample data is taken from two leases for two different
clients and is transferred into table format with rows and
columns.
• This is an unnormalized table.
ClientRental unnormalized table.
UNF example
• We identify the key attribute for the Clientrental
unnormalized table as clientNo.
• Next we identify the repeating group in the
unnormalized table:
Repeating Group = (propertyNo, pAddress, rentstart,
rentFinish, rent, ownerNo, ownerName)
• As a consequence, there are multiple values at
the intersection of certain rows and columns.
First Normal Form (1NF)
• A relation in which the intersection of each row
and column contains one and only one value.
UNF to 1NF
• To transform the unnormalized table to first
normal form we identify and remove repeating
groups within the table.
– Nominate an attribute or group of attributes to act
as the key for the unnormalized table.
– Identify the repeating group(s) in the unnormalized
table which repeats for the key attribute(s).
• There are two common approaches to removing
repeating groups from unnormalized tables.
Method 1
• We remove the repeating group by entering
appropriate data into the empty columns of rows
containing the repeating data (‘flattening’ the
table). We fill in the blanks by duplicating the
nonrepeating data.
• The resulting relation contains atomic values at
the intersection of each row and column, and is
therefore in 1NF.
• With this approach redundancy is introduced
into the resulting relation.
Method 1 example
• Remove the repeating group by entering the
appropriate client data into each row.
• The resulting relation ClientRental is in 1NF as there is
a single value at the intersection of each row and
column.
Method 1 example
• We identify the candidate keys for the
ClientRental relation as being composite keys:
– (clientNo, propertyNo)
– (clientNo, rentStart)
– (propertyNo, rentStart)
• We select (clientNo, propertyNo) as the primary
key.
• The relation contains data describing clients,
property rented, and property owners, which is
repeated several times. As a result, the relation
contains significant data redundancy.
Method 2
• We remove the repeating group by placing the
repeating data along with a copy of the original
key attribute(s) into a separate relation.
• A primary key is identified for the new relation.
• This approach produces relations in at least 1NF
with less redundancy.
Method 2 example
• Using the second approach, we remove the repeating group by
placing the repeating data along with a copy of the original key
attribute (clientNo) into a separate table, called
PropertyRentalOwner.
Method 2 example
• Then we identify a primary key for the new table
(clientNo, propertyNo).
• The format of the resulting 1NF relations are as follows:
Client (clientNo, CName)
PropertyRentalOwner (clientNo, propertyNo, pAddress,
rentStart, rentFinish, rent, ownerNo, oName)
• Both the Client and PropertyRentalOwner tables are in
1NF, but the PropertyRentalOwner table contains
significant redundancy.
Second Normal Form (2NF)
• Second normal form is based on the concept of
full functional dependency.
• Full functional dependency indicates that if
– A and B are attributes of a relation,
– B is fully functionally dependent on A if B is
functionally dependent on A but not on any proper
subset of A.
• A functional dependency A B is a full functional
dependency if removal of any attribute from A
results in the dependency not being sustained any
more.
Second Normal Form (2NF)
• A relation that is in 1NF and every non-primary-
key attribute is fully functionally dependent on the
primary key.
– Second normal form applies to relations with
composite keys (the primary key composed of two
or more attributes).
– A relation with a single attribute primary key is
automatically in at least 2NF.
1NF to 2NF
• Identify the primary key for the 1NF relation.
• Identify the functional dependencies in the
relation.
• If partial dependencies exist on the primary key
remove them by placing them in a new relation
along with a copy of their determinant.
Partial dependency
• A functional dependency A B is partially
dependent if there is some attribute that can be
removed from A and the dependency still holds.
2NF example
Consider the ClientRental relation.
• This ClientRental table is in 1NF. The primary key of the
table is (clientNo, propertyNo).
• In order to move this table to a 2NF solution, we must
identify and remove the partial dependencies from the
table.
Functional dependencies in
ClientRental relation
• The functional dependencies (fd) for the
ClientRental relation are as follows:
• The presence of partial dependencies show that
the table is not in 2NF.
– cName is partially dependent on the primary key, in
other words, on only the clientNo attribute.
– Property attributes are also partially dependent on
the primary key.
Transform the ClientRental relation
into 2NF
• To remove the partial dependencies, we create new
tables so that the non-primary-key columns are
removed, along with a copy of the part of the
primary key on which they are fully functionally
dependent.
• This results in the creation of three new relations
called Clioent, Rental, and PropertyOwner.
2NF relations derived from
ClientRental relation
• The three tables, Client, Rental and PropertyOwner are
in 2NF because every non-primary-key column is fully
functionally dependent on the primary key of the table.
Remarks
• Although 2NF relations have less redundancy than those
in 1NF, they may still suffer from update anomalies.
• E.g. if we want to update the name of on owner e.g.
Tony Diamond we have to update two tuples in the
PropertyOwner relation.
• If we update only one tuple and not the other the
database would be in an inconsistent state.
• This update anomaly is caused by a transitive
dependency.
• We need to remove such dependencies by progressing
to third normal form.
