Chapter 5

Data Normalisation
1. Introduction
CDM  Tasks frequencies
 External models

OIS
ODM
Conceptual/organisational OMP

Transformation
Formalism
CIS
Logical/physical
Raw
LDM

Transformation Transformation
Formalism Formalism

Valued
LDM

Optimisation

Optimised
LDM

Technical
constraints

PDM
Database schema

Figure 1: Transition from the conceptual data model to the logical data model

1
 One of the main challenges of database design is to avoid redundancies and
incoherencies. a first approach to constitute a set of good tables limiting the risk of potential
inconsistencies (avoid redundancies and null values) is to start from a universal table whose
diagram consists of all the attributes, to which we apply a normalization algorithm, or
normalization theory.
Normalization requires having more semantics on data. This complementary
semantics will be expressed through functional dependencies(FD) between attributes.
Normalization then presents itself as a decomposition process of this starting table into several
tables by projections judiciously defined according to these functional dependencies between
attributes. This normalization process, or standardization theory, can be illustrated as follows
(see Figure 2):

• attribute 1
• attribute 2
• attribute 3
Semantics
• attribute 4
on data
• attribute i

Decomposition
• attribute n algorithm
(normalisation) Reconstruction
with joints

Reconstruction Structuration
with joins of relations
R1 ••
Ri • •
Final relations
••
Rn •••

Figure 2: Normalisation process

Note that this process is absolutely reversible and allows, from standard tables, to find
the starting tables, by means of joins. Codd proposed three normal forms, to which were later
added other normal forms like the 4th, 5th normal forms or the Boyce-Codd form. These other
normal forms can be considered as refinements of the relational model when faced with very
particular cases (optimization).
In the set of tables that can be generated by decomposition, a subset of tables is in 1st
normal form; in this subset, some tables are in 2nd normal form, finally, among these latter
tables, some are in 3rd normal form (see Figure 3).

2
 Set of relations (tables)
Relations in first normal form (1NF)
Relations in second normal form (2NF)
Relations in third normal form (3NF)

Figure 3: the three normal forms

2. Notion of functional dependencies

An attribute (or group of attributes) B of a table R is functionally dependent on another
attribute (or group of attributes) A of R, if at any time each value of A has only one associated
value of B: we denote A -> B.
considering the ORDER_LINE table (order_num, item_num, designation, qty) in which it is
the designation of the article and the quantity of items ordered in the order. We have functional
dependencies following:
 item_num -> designation (an item number value corresponds only to one designation
value);
 (order_num, item_num) -> qty (a couple of values order_num and item_num,
corresponds only to a value of qty).
We can represent these functional dependencies as follows:

ORDER_LINE table
order_num Compound
item_num primary key

designation
qty

a. Properties of functional dependencies

The functional dependencies are:

 reflexivity (A -> A);

 transitivity (A -> B and B -> C then A -> C).

b. Primary key of a table

The primary key of a table is an attribute (or a set of attributes) such that all the other attributes
(non-key) of the table are in functional dependence with the primary key.
Examples:

3
Consider the CUSTOMER table (customer_number, name, address); we have the following
functional dependencies:

 customer number -> name;

 customer number -> address.
Customer_number is the primary key of the customer table.
Consider the ORDER_LINE table (order_num., item_num, designation, qty); we then have the
following functional dependencies:

 order_num, item_num -> designation;

 order_num., item_num -> order qty.
(order_num, item_num) is a primary key composed of the ORDER_LINE table. It is also
necessary to verify that no subset of the attributes making up the primary key could also not be
a primary key to the table.

3. First normal Form (1NF)

This normalization applies to any table. The 1st form normal is used to eliminate repetitive
groups in a table. The approach is as follows:

 Remove the repeating group from the initial table.

 Transform the repetitive group into a table, add to the key of this new table the primary
key of the initial table.
This first normal form formatting process is recursive in case the initial table includes several
levels of repetition.
We note that this 1st normal form is similar to the verification rule (or non-repetitivity) used in
entity-relationship formalism.
Consider the ORDER table (order_num, date, customer_num, name, item_num, designation,
qty). The name attribute is the name of the customer and designation is the item designation.
This table also presents a repetitive group:
ORDER table

ORDER table order_num (PK)

date
order_num (PK) customer_num
Tables in first normal
date name
form obtained after
customer_num
elimination of
name ITEM_ORDER table
Repetitive repetitive groups
item_num
designation group order_num
CPK
qty item_num
designation
qty

4
 4. Second Normal Form (2NF)
This standardization requires that the table is already in 1st normal form. it concerns
only tables with a compound primary key (composed of several attributes).
The rule imposes that the non-primary key attributes depend on the entire primary key. Any
attribute that would depend only on part of the primary key must be excluded from the table.
The process is as follows:

 Group the attributes depending on the entire key in a table, and keep this key for this
table;
 Group in another table the attributes depending on a part of the key, and make this part
of the key the primary key of the new table.
We notice that this second normal form is similar to the normalization rule of relations used in
entity-relationship formalism.
In our example, the ITEM_ORDER table is not in second form normal because the non-key
attribute “designation” does not fully depend on the compound primary key:

ORDER_LIGNE table
order_num
Compound PK
item_num
ITEM_ORDER table
qty
order_num Compound
item_num primary
designation ITEM table
key
qty item_num
qty

The transition to the second normal form lead us to replace this table ITEM_ORDER by the
tables ORDER_LIGNE and ITEM in second normal as shown here above.

5. Third Normal Form (3NF)

The third normal form process only applies to tables already in second normal form.
The purpose of the rule is to eliminate transitive dependencies within a table. The process is as
follows:

 Keep in the initial table the attributes that directly depend on the key.
 Group in a table the attributes depending transitively; the transitive attribute remains
duplicated in the initial table, and becomes the primary key of the new table.
Note that Codd and many specialists have rigorously demonstrated that a third normal
form data model was a "canonical form” on a dataset, and that it minimized the redundancy
of the future database.

5
In our example, the previous COMMAND table is not in the third normal form because the
non-key attribute name depends on the key by transitivity:

ORDER table
order_num (PK)
date
ORDER table customer_num
order_num (PK)
date
customer_num
name CUSTOMER table
customer_num (PK)
name

The transition to third normal form lead us to replace the table ORDER by the tables ORDER
and CUSTOMER as illustrated here above.

6. Boyce-Codd Normal Form (BCNF)

The Boyce-Codd normal form process avoids redundancies due to the existence of
functional dependencies other than those of the key to non-key attributes.
Consider an example in which an employee is assigned (a certain number hours) to a
number of projects in a number manufacturing units (a manufacturing unit only deals with a
given project). Here is the associated ASSIGN table allowing to take into account this
assignment:

ASSIGN table
employee_number
Primary key
project_number
nb_hours
unit_fab

The transition to the Boyce-Codd normal form will lead us to replace this table by the
following tables:

ASSIGN table
employee_number
Primary key
project_number
nb_hours

6
 UNIT_FAB table
unit_fab (PK)
project_number

The Boyce-Codd decomposition is lossless. Note that the functional dependency

employee_number -> unit_fab has disappeared but can be recomposed by joining the two new
tables on the unit_fab attribute.