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.