Logical Database Design

Normalisation

Part – 2
 The Process of Normalization
• Formal technique for analyzing a relation based on its
primary key and functional dependencies between its
attributes.
• Often executed as a series of steps. Each step
corresponds to a specific normal form, which has
known properties.
• As normalization proceeds, relations become
progressively more restricted (stronger) in format and
also less vulnerable to update anomalies.
Relationship between the normal forms
 Purchase Order - Attribute Analysis
ATTRIBUTE TYPE LEN- DESCRIPTION
GTH
PO-NO N 3 Unique purchase order (PO) number.
Many parts can be ordered in one PO
PO-DATE D 8 DDMMYYYY date when PO written
EMP-CODE C 2 Unique code of employee who wrote
the PO
SUPP-NO N 3 Unique number assigned to supplier
SUPP-NAME C 20 Supplier name
PART-NO N 2 Unique number assigned to each part
PART-DESC C 10 Part description
PART-QTY N 2 Quantity of parts ordered in given PO
Key PO-NO
 Purchase Order Relation in 0NF

PO- PO-DATE EMP- SUP SUPP- PART PART- PART

NO CODE P-NO NAME -N O DESC -QTY
111 01012001 M2 222 AC Stores P1 Nut 10
P2 Bolt 5
P3 Nail 3
P5 Screw 6
112 01012001 S3 105 I Hardware P2 Bolt 2
P5 Screw 1
113 02012001 S1 111 BC Trading P1 Nut 3
P3 Nail 4
114 02012001 M2 150 DO Service P6 Plug 5
115 03012001 S1 222 AC Stores P7 Pin 8
116 04012001 S1 100 LM Centre P8 Fuse 2
 First Normal Form - 1NF

A relation is in First Normal Form (1NF) if

ALL its attributes are ATOMIC. i.e.
If there are no repeating groups.
If each attribute is a primitive.
e.g. integer, real number, character string,
but not lists or sets
non-decomposable data item
single-value
 Purchase Order Relation in 0NF

PO( PO-NO, PO-DATE, EMP-CODE, SUPP-NO,

SUPP-NAME, PARTS-ORDERED{PART-NO,
PART-DESC, PART-QTY})

Within a single purchase order we could find

several part numbers, part descriptions and
part quantities. Hence, parts ordered can be
decomposed.
 Purchase Order Relation in 0NF
PO- PO-DATE EMP- SUP SUPP- PART PART- PART
NO CODE P-NO NAME -N O DESC -QTY
111 01012001 M2 222 AC Stores P1 Nut 10
P2 Bolt 5
P3 Nail 3
P5 Screw 6
112 01012001 S3 105 I Hardware P2 Bolt 2
P5 Screw 1
113 02012001 S1 111 BC Trading P1 Nut 3
P3 Nail 4
114 02012001 M2 150 DO Service P6 Plug 5
115 03012001 S1 222 AC Stores P7 Pin 8
116 04012001 S1 100 LM Centre P8 Fuse 2
 1NF - Actions Required

1) Examine for repeat groups of data

2) Remove repeat groups from relation
3) Create new relation(s) to include repeated data
4) Include key of the 0NF to the new relation(s)
5) Determine key of the new relation(s)
 Purchase Order Relations in 1NF

PO PO-PART
PO- PO- EMP- SUP SUPP- PO- PAR PART- PART
NO DATE CODE P-NO NAME NO T-NO DESC -QTY
111 01012001 M2 222 AC Stores 111 P1 Nut 10
112 01012001 S3 105 I Hardware 111 P2 Bolt 5
113 02012001 S1 111 BC Trading 111 P3 Nail 3
114 02012001 M2 150 DO Service 111 P5 Screw 6
115 03012001 S1 222 AC Stores 112 P2 Bolt 2
116 04012001 S1 100 LM Centre 112 P5 Screw 1
113 P1 Nut 3
113 P3 Nail 4
114 P6 Plug 5
115 P7 Pin 8
116 P8 Fuse 2
 Problems - 1NF

1.INSERT PROBLEM
do not know available parts until an order is placed
(e.g. P4 is bush)
2. DELETE PROBLEM
loose information of part P7 if we cancel purchase
order 115 (i.e. Delete PO-PART for Part No P7)
3. UPDATE PROBLEM:
to change description of Part P3 we need to change
every tuple in PO-PART containing Part No P3
 Second Normal Form - 2NF

• 2NF is based on the concept of full functional

dependency.

• A functional dependency XÆ Y is a full functional

dependency if removal of any attribute A from X
means that the dependency does not hold any more.

• A functional dependency XÆ Y is a partial

dependency if some attribute A Є X can be removed
from X and the dependency still holds.
 Second Normal Form - 2NF

• {Empid, Pnumber} Æ Hours

is a full dependency (neither Empid Æ Hours
nor Pnumber Æ Hours holds).

However, the dependency

{Empid, Pnumber} Æ Ename is partial as
Empid Æ Ename holds.
 Second Normal Form - 2NF

A relation is in 2NF if it is in 1NF and every

non-key attribute is dependent on the whole
key

i.e. Is not dependent on part of the key only.

 PO-PART Relation (Parts Ordered)
in 1NF
PO-PART( PO-NO, PART-NO, PART-DESC,
PART-QTY)

Part Description is depended only on Part No,

which is part of the key of PO-PART.
Parts Ordered Relation in 1NF

PO- PART PART- PART

N O -N O DESC -QTY
111 P1 Nut 10
111 P2 Bolt 5
111 P3 Nail 3
111 P5 Screw 6
112 P2 Bolt 2
112 P5 Screw 1
113 P1 Nut 3
113 P3 Nail 4
114 P6 Plug 5
115 P7 Pin 8
116 P8 Fuse 2
 Second Normal Form - 2NF

Deals with the relationship between non-key

and key fields

It is relevant when the key is composite, i.e.

consists of several fields
 2NF - Actions Required

If entity has a concatenated key

1)Check each attribute against the whole key

2)Remove attribute and partial key to new
relation
3)Optimise relations
 Parts Ordered Relations in 2NF
PO-PART
PO- PART PART PART
NO -NO -QTY
111 P1 10 PART PART-
111 P2 5 -N O DESC
111 P3 3 P1 Nut
111 P5 6 P2 Bolt
112 P2 2 P3 Nail
112 P5 1 P5 Screw
113 P1 3 P6 Plug
113 P3 4 P7 Pin
114 P6 5 P8 Fuse
115 P7 8
116 P8 2
 Purchase Order Relations in 2NF
PART PAR PART-
T-NO DESC
P1 Nut PO-PART
P2 Bolt PO- PAR PART
P3 Nail NO T-NO -QTY
P5 Screw 111 P1 10
P6 Plug 111 P2 5
P7 Pin 111 P3 3
PO P8 Fuse 111 P5 6
112 P2 2
PO- PO- EMP- SUP SUPP-
112 P5 1
NO DATE CODE P-NO NAME
113 P1 3
111 01012001 M2 222 AC Stores
113 P3 4
112 01012001 S3 105 I Hardware
114 P6 5
113 02012001 S1 111 BC Trading
115 P7 8
114 02012001 M2 150 DO Service
116 P8 2
115 03012001 S1 222 AC Stores
116 04012001 S1 100 LM Centre
 Second Normal Form - 2NF

• Emp_Proj

Empid Pnumber Hours Ename Pname Plocation

 Problems - 2NF
1. INSERT PROBLEM
cannot know available suppliers until an order is
placed (e.g. 200 is hardware stores)
2. DELETE PROBLEM
loose information of supplier 100 if we cancel
purchase order 116 (i.e. Delete PO for Supplier No
100)
3. UPDATE PROBLEM
to change name of Supplier 222 we need to change
every tuple in PO containing Supplier No 222
 Third Normal Form - 3NF

A relation is in 3NF if it is in 2NF and each

non-key attribute is only dependent on the
whole key, and not dependent on any non-key
attribute.

i.e. no transitive dependencies

 Third Normal Form - 3NF

PO( PO-NO, PO-DATE, EMP-CODE, SUPP-

NO, SUPP-NAME)

Supplier name is a non-key field depended on

another non-key field (i.e. the supplier no) in
addition to be depended on the key purchase
order no.
 Third Normal Form - 3NF

Deals with the relationship between non-key

fields

A non-key field cannot be a fact about another

non-key field
 3NF - Actions Required

1)Check each non-key attribute for dependency

against other non-key fields
2)Remove attribute depended on another non-
key attribute from relation
3)Create a new relation comprising the attribute
and non-key attribute which it depends on
4)Determine key of the new relation
 PO and SUPPLIER Relations in 3NF

PO
SUPPLIER
PO- PO-DATE EMP- SUP
NO CODE P-NO SUP SUPP-
P-NO NAME
111 01012001 M2 222
112 01012001 S3 105 100 LM Centre
113 02012001 S1 111 105 I Hardware
114 02012001 M2 150 111 BC Trading
115 03012001 S1 222 150 DO Service
116 04012001 S1 100 222 AC Stores
 Purchase Order Relations in 3NF
SUPPLIER SUP SUPP-
P-NO NAME
PART PO-PART
222 AC Stores
105 I Hardware PAR PART- PO- PAR PART
111 BC Trading T-NO DESC NO T-NO -QTY
150 DO Service P1 Nut 111 P1 10
222 AC Stores P2 Bolt 111 P2 5
100 LM Centre P3 Nail 111 P3 3
PO P5 Screw 111 P5 6
PO- PO- EMP- SUP P6 Plug 112 P2 2
NO DATE CODE P-NO P7 Pin 112 P5 1
111 01012001 M2 222 P8 Fuse 113 P1 3
112 01012001 S3 105 113 P3 4
113 02012001 S1 111 114 P6 5
114 02012001 M2 150 115 P7 8
115 03012001 S1 222 116 P8 2
116 04012001 S1 100
 Further Normalization
• BCNF or Boyce–Codd Normal form
• 4th Normal form
• 5th Normal form
In a normal situation normalization up-to 3NF is quite
sufficient. Certain relations may even be de-
normalized on account of efficiency. The
Normalizations which are discussed next are not
practically enforced most of the time.
• But a relation in 3NF does not guarantee that all
anomalies have been removed, hence the additional
normalizations.
 Boyce Codd Normal Form

• Consider the below relation

Student Course Instructor

• It also has the following dependencies

{student,course} Instructor
Instructor course
 Boyce Codd Normal Form

• This relation has more than one candidate

key.(student,course) or (student,instructor)
• We have arbitrarily chosen the previous. Choosing
the latter would also be fine
• The above relation is in 3NF, but not in BCNF
• But this has anomalies
– If we need to add an instructor ‘silva’ for ‘database’ we
have to wait till an appropriate student is present.
– Deleting a record may also delete other data, specially if an
instructor is in one students record (deleting the student
will also erase the instructors data)
 solution

• We divide the relation into 2 .

• The attribute that is a determinant but not a
key (instructor) must be placed in a separate
relation and becomes its key.
Instructor Course

Instructor Student
 Definition of Third and Boyce-Codd
Normal Form
3NF
• A relation schema R is in third normal form
(3NF) if, whenever a nontrivial functional
dependency XÆ A holds in R, either
(a) X is a superkey of R or
(b) A is a prime attribute of R
BCNF
• A relation schema R is in BCNF if whenever a
nontrivial functional dependency XÆ A holds
in R, then X is superkey of R