Chapter 7

Normalization

Chapter 14 & 15 in Textbook

 Database Design

:Steps in building a database for an application

Create
Real-world Conceptual DBMS data Modify
Schema
domain model model data (DML)
(DDL)

2
Normalizatio
 ?How to produce a good relation schema

1. Start with a set of relation.

2. Define the functional dependencies for the relation to specify the PK.

3. Transform relations to normal form.

3
Normalizatio
Data Redundancy and Update Anomalies

(branchNo) is repeated in
the Staff relation, to
represent where each
member of staff is located

Redundant
data

4
Pearson Education © 2009
Data Redundancy and Update Anomalies
 Relations that contain redundant information may
potentially suffer from update anomalies.

 Types of update anomalies include

– Insertion
– Deletion
– Modification

5
Pearson Education © 2009
Relation Decomposition
 Normalization process involve decomposing a relation.
 Decomposition require to be reversible.
 Functional dependencies guarantee decomposition to be
reversible.
 While normalization, two important properties associated
with decomposition:
– Lossless-join property: enables us to find any instance of the
original relation from corresponding instances in the smaller
relations.
– Dependency preservation property: enables us to enforce a
constraint on the original relation by enforcing some constraint on
each of the smaller relations.
6
Pearson Education © 2009
Functional Dependencies
 Describes the relationship between attributes in a relation.
 If A and B are attributes of relation R,
 B is functionally dependent on A, denoted A  B, if each
value of A is associated with exactly one value of B. B may
have several values of A.
B is functionally
A dependent on A B
Determinant Dependent
 An alternative way to describe the relation ship between
attribute A an B is to say that “ A functionally determines B”

7
Pearson Education © 2009
 An Example Functional Dependency

1:1 or M:1
relationship
between
attributes in a
relation

1:M
relationship
between
attributes in a
relation

8
Pearson Education © 2009
Example Functional Dependency that holds for all Time
 Consider the values shown in staffNo and sName
attributes of the Staff relation.
 Based on sample data, the following functional
dependencies appear to hold.

staffNo → sName
sName → staffNo

 However, the only functional dependency that remains

true for all possible values for the staffNo and sName
attributes of the Staff relation is:
staffNo → sName
9
Pearson Education © 2009
Characteristics of Functional Dependencies

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  B is a full functional dependency if
removal of any attribute from A results in the
dependency no longer existing.
10
Pearson Education © 2009
Example Full Functional Dependency
 In the Staff relation
staffNo, sName → branchNo Partial dependency

staffNo→ branchNo Fully dependency

 True - each value of (staffNo, sName) is associated
with a single value of branchNo.
 However, branchNo is also functionally dependent
on a subset of (staffNo, sName), namely staffNo.
Example above is a partial dependency.

11
Pearson Education © 2009
Transitive Dependencies
 Important to recognize a transitive dependency because its
existence in a relation can potentially cause update anomalies.

 Transitive dependency describes a condition where A, B, and

C are attributes of a relation such that if
A→B
B→C
 Then C is transitively dependent on A via B
A→C
 Provided that A is not functionally dependent on B or C.
B → A, and C → A doesn't exist

12
Pearson Education © 2009
 Example Transitive Dependency
 Consider functional dependencies in the StaffBranch relation.
staffNo → sName, position, salary, branchNo, bAddress
branchNo → bAddress

 Transitive dependency, staffNo → bAddress exists via branchNo

(staffNo functionally determines the bAddress via branchNo ).

 And, neither branchNo nor bAddress functionally determines

staffNo.
branchNo → staffNo , and bAddress → staffNo doesn't exist
13
Pearson Education © 2009
 Summary Characteristics of Functional
Dependencies
 Main characteristics of functional dependencies used
in normalization:
1. There is a one-to-one relationship between the
determinant and dependent.
2. Holds for all time.
3. There must be a full functional dependency between
determinant and dependent.

14
Pearson Education © 2009
 Identifying Functional Dependencies
There are two approach to Identifying all functional dependencies :
1. Identifying all functional dependencies between a set of attributes is
quite simple if the meaning of each attribute and the relationships
between the attributes are well understood.
 This information should be provided by the enterprise (discussions
with users and/or documentation)
 The missing information Ex: documentation is incomplete
 (database designer use their common sense and/or experience).

2. It may possible to identify functional dependencies if sample data is

available that is true representation of all possible data.

15
Pearson Education © 2009
 Example - Identifying a set of functional
dependencies for the StaffBranch relation
 Identifing the functional dependencies for the StaffBranch
relation as:

staffNo → sName, position, salary, branchNo, bAddress

branchNo → bAddress
bAddress → branchNo
branchNo, position → salary
bAddress, position → salary

Hint : Assume that position held and branch determine a member of staff’s
salary.
16
Pearson Education © 2009
 Identifying the Primary Key for a Relation
using Functional Dependencies
 Main purpose of identifying a set of functional dependencies for a
relation is to specify the set of integrity constraints that must
hold on a relation.

 An important integrity constraint to consider first is the

identification of candidate keys, one of which is selected to be the
primary key for the relation.

 All attributes that are not part of a candidate key should be

functionally dependent on the key.

17
Pearson Education © 2009
 Example - Identify Primary Key for
StaffBranch Relation
 StaffBranch relation has five functional dependencies.
staffNo → sName, position, salary, branchNo, bAddress
branchNo → bAddress
bAddress → branchNo
branchNo, position → salary
bAddress, position → salary

 The determinants are staffNo, branchNo, bAddress, (branchNo,

position), and (bAddress, position).
 To identify all candidate key(s), identify the attribute (or group of
attributes) that uniquely identifies each tuple in this relation.
 The only candidate key and therefore primary key for StaffBranch
relation, is staffNo, as all other attributes of the relation are
functionally dependent on staffNo.
18
Pearson Education © 2009
 Closure
Closure (inferred from) X+: The set of all functional dependencies that are
implied by a given set of functional dependencies X is called the closure of X,
written X+ .
If t & u agree here Then they must agree here

CB B
A C
X A B
t
X+ A C
u

So surely they will agree here

 Inference Rules for Functional Dependencies

Armstrong’s axioms (inference rules): The set of inference rules specifies how
functional dependencies can be inferred from given one.

Inference rules:

Reflexivity If B  A, then A B
Augmentation If A B, then A,C B,C
Transitivity If A B and B C, then A C
Self-Determination A A
Decomposition If A B,C, then A B and A C
Union If A B and A C, then A B,C

20
Normalizatio
 Minimal Sets of Functional Dependencies

• Complete set of functional dependencies for a relation can be very large.

• We need to reduce the set to a manageable size, by applying the inference rules
repeatedly until they stop producing new FDs.

Assume S1 & S2 are set of dependencies:

S1  S2, then (S2 is a cover for S1) OR (S1 is covered by S2)

if S2 is a cover for S1
S1 equivalent to S2
& S1 is a cover for S2

21
Normalizatio
 Minimal Sets of Functional Dependencies

A set of functional dependencies X is minimal if it satisfies the following:

1. Every dependency in X has a single attribute for its right-hand side.

2. Can’t replace any dependency A B in X with C B , where C  A, & still have

a set of dependencies equivalent to X.

3. Can’t remove any dependency from X and still have a set of dependencies that is
equivalent to X.

22
Normalizatio
 Minimal Sets of Functional Dependencies

1. For each X {A1, A2, .. An}, create X A1, X A2, …., X An.

2. A, B C is equivalent to B C, then replace A, B C with B C.

3. X - {A B} equivalent to X, then remove A B.

23
Normalizatio
Exercise

Q5: Given the relation R ( W, X, Y,Z) and the following

functional dependencies:
FD1: X →W
FD2: W, Z → X, Y
FD3: Y → W, X
FD4: X, Z → W

Compute the minimal set of functional dependencies.

Exercise ( cont.)
FD1: X →W
FD2: W, Z → X, Y
FD3: Y → W, X
FD4: X, Z → W
Step1 (single attribute on RH side):

FD1: X →W
FD2.1: W, Z → X
FD2.2: W, Z → Y
FD3.1: Y → W
FD3.2 :Y→ X
FD4: X, Z → W
Exercise ( cont.)
 FD1: X →W
 FD2.1: W, Z → X
 FD2.2: W, Z → Y
 FD3.1: Y→W
 FD3.2 :Y→ X
 FD4: X, Z → W

Step2 (determine if fd2.1 , fd 2.2 or fd4 fd can be simplified):

Replace FD4: X, Z → W with FD1: X →W

FD1: X →W
FD2.1: W, Z → X
FD2.2: W, Z → Y
FD3.1:Y → W
FD3.2 :Y→ X
FD4: X, Z → W
Exercise ( cont.)
 FD1: X →W
 FD2.1: W, Z → X
 FD2.2: W, Z → Y
 FD3.1: Y→W
 FD3.2 :Y→ X

Step3 determine if there is redundancy:

FD1: X →W
FD2.1: W, Z → X ( beacuse of FD2.2 W,ZY FD3.2 YX )
FD2.2: W, Z → Y
FD3.1:Y → W ( beacuse of FD3.2 YX FD1 XW )
FD3.2 :Y→ X

Minimal set is :
FD1: X →W
FD2.2: W, Z → Y
FD3.2 :Y→ X
 The Process of Normalization

Normalization is a technique for analyzing relations based on their CK & Functional

dependencies.

1NF
2NF s
lie
a
m
3NF at no
orm e a
f at
BCNF n
i pd
r
e u
g
n to
4NF o
r le
St rab
5NF lne
vu
Higher Normal ess
L
Form

Normalization
28
 The Purpose of Normalization

Normalization is a bottom-up approach to database design that begins by examining

the relationships between attributes. It is performed as a series of tests on a relation to
determine whether it satisfies or violates the requirements of a given normal form.
Purpose:
Guarantees no redundancy due to FDs
Guarantees no update anomalies
Normal Forms:
First Normal Form (1NF)
Second Normal Form (2NF)
Third Normal Form (3NF)
Boyce-Codd Normal Form (BCNF)
Fourth Normal Form (4NF)
Fifth Normal Form (5NF)

29
 First Normal Form (1NF)
Unnormalized form (UNF): A relation that contains one or more repeating groups.

First normal form (1NF): A relation in which the intersection of each row and
column contains one & only one value.

CLIENT_PROPERTY
ClientNo Name PropertyNo
CR76 John Key PG4
PG16
CR56 Aline Stewart PG4
PG36
PG16

Unnormalized relation

30
Normalizatio
 UNF 1NF
Approach 1
Expand the key so that there will be a separate tuple in the original relation for each
repeated attribute(s). Primary key becomes the combination of primary key and
redundant value.

CLIENT_PROPERTY
ClientNo Name PropertyNo
CR76 John Key PG4
CR76 John Key PG16
CR56 Aline Stewart PG4
CR56 Aline Stewart PG36
CR56 Aline Stewart PG16

1NF relation

Disadvantage: introduce redundancy in the relation.

31
Normalizatio
 UNF 1NF
Approach 2
If the maximum number of values is known for the attribute, replace repeated
attribute (PropertyNo) with a number of atomic attributes (PropertyNo1,
PropertyNo2, PropertyNo3).

CLIENT_PROPERTY
ClientNo Name PropertyNo1 PropertyNo2 PropertyNo3
CR76 John Key PG4 PG16 NULL
CR56 Aline Stewart PG4 PG36 PG16

1NF relation

Disadvantage: introduce NULL values in the relation.

32
Normalizatio
 UNF 1NF
Approach 3

Remove the attribute that violates the 1NF and place it in a separate relation along
with a copy of the primary key.

CLIENT PROPERTY
ClientNo Name ClientNo PropertyNo

CR76 John Key CR76 PG4

CR76 PG16
CR56 Aline Stewart
CR56 PG4
1NF relation CR56 PG36
CR56 PG16

1NF relation

33
Normalizatio
 Full Functional Dependency

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.
B is partial functional dependent on A if some attributes can be removed from A
& the dependency still holds.

StaffNo, Sname BranchNo Partial dependency

ClientNo, PropertyNo RentDate Full dependency

34
Normalizatio
 Second Normal Form (2NF)

Second normal form (2NF): A 1NF relation in which every attribute is fully
nontrivial functionally dependent on the PK. (non-prime attributes fully dependent
on PK.)

Applies to relations with composite primary keys & partial dependencies.

CLIENT_RENTAL
ClientNo PropertyNo cName pAddress RentStart RentFinish Rent OwnerNo OName

1NF relation

35
Normalizatio
 1NF 2NF

1. Start with 1NF relation.

2. Find the FDs of a relation.

3. Test the FDs whose determinant attribute is part of the PK.

36
Normalizatio
 1NF 2NF
CLIENT_RENTAL
ClientNo PropertyNo cName pAddress RentStart RentFinish Rent OwnerNo OName

(ClientNo, PropertyNo) PK

ClientNo, PropertyNo RentStart, RentFinish Full Dependency

ClientNo CName Partial Dependency
PropertyNo Paddress, Rent, OwnerNo, Oname Partial Dependency
OwnerNo OName

37
Normalizatio
 1NF 2NF

4. Remove partial dependencies by placing the functionally dependent attributes in

a new relation along with a copy of their determinants.

CLIENT RENTAL
ClientNo cName ClientNo PropertyNo RentStart RentFinish

2NF relation 2NF relation

PROPERTY_OWNER
PropertyNo pAddress Rent OwnerNo OName

2NF relation

38
Normalizatio
 Transitive Dependency

A, B, C are attributes of a relation, such that:

If A B and B C, then C is transitively dependent on A via B.
Provided A is NOT functionally dependent on B or C (nontrivial FD).

Example:
StaffNo BranchNo , BranchNo Address
StaffNo Address

39
Normalizatio
 Third Normal Form (3NF)

Third normal form (3NF): A 2NF relation in which NO non-prime attribute is

transitively dependent on the PK.

CLIENT RENTAL
ClientNo cName ClientNo PropertyNo RentStart RentFinish

3NF relation 3NF relation

PROPERTY_OWNER
PropertyNo pAddress Rent OwnerNo OName

2NF relation

40
Normalizatio
 2NF 3NF

1. Identify the PK in the 2NF relation.

2. Identify FDs in this relation.
3. If transitive dependencies exist, place transitively dependent attributes in a new
relation along with a copy of their determinants.

OWNER PROPERTY_FOR_RENT
OwnerNo OName PropertyNo pAddress rent OwnerNo

3NF relation 3NF relation

41
Normalizatio
 Review of Decompositions

1NF CLIENT_RENTAL

2NF CLIENT RENTAL PROPERTY_OWNER

3NF CLIENT RENTAL OWNER PROPERTY_FOR_RENT

42
Normalizatio
 General Definition of 2NF & 3NF

Second normal form (2NF): A 1NF relation in which every non-primary-key attribute
is fully functionally dependent on the CK.

Third normal form (3NF): A 2NF relation in which NO non-primary-key attribute in a

nontrivial FD is transitively dependent on the CK.

43
Normalizatio
 Review Example
STAFF_PROPERTY_INSPECTION
Pno pAddress iDate iTime comments StaffNo sName CarReg

PG4 Lawrence St, 18-Oct-00 10:00 Replace crockery SG37 Ann M23JGR
Glasgow 22-Apr-01 09:00 Good order SG14 David M53HDR
1-Oct-01 12:00 Damp rot SG14 David N72HFR
PG16 5 Novar Dr., 22-Apr-01 13:00 Replace carpet SG14 David M53HDR
Glasgow 24-Oct-01 14:00 Good condition SG37 Ann N72HFR

Unnormalized relation

44
Normalizatio
 UNF 1NF
STAFF_PROPERTY_INSPECTION
Pno pAddress iDate iTime comments StaffNo sName CarReg

PG4 Lawrence St, Glasgow 18-Oct-00 10:00 Replace crockery SG37 Ann M23JGR
PG4 Lawrence St,Glasgow 22-Apr-01 09:00 Good order SG14 David M53HDR
PG4 Lawrence St,Glasgow 1-Oct-01 12:00 Damp rot SG14 David N72HFR
PG16 5 Novar Dr., Glasgow 22-Apr-01 13:00 Replace carpet SG14 David M53HDR
PG16 5 Novar Dr., Glasgow 24-Oct-01 14:00 Good condition SG37 Ann N72HFR

1NF

45
Normalizatio
 1NF 2NF
STAFF_PROPERTY_INSPECTION
Pno iDate pAddress iTime comments StaffNo sName CarReg

Pno, iDate iTime, comments, StaffNo, sName, carReg

Pno pAddress Partial Dependency
StaffNo Sname

46
 1NF 2NF
PROPERTY
Pno pAddress Pno pAddress
2NF

PROPERTY_INSPECTION
Pno iDate iTime comments StaffNo sName CarReg

2NF

Pno, iDate iTime, comments, StaffNo, Sname, CarReg

StaffNo Sname Transitive Dependency

47
Normalizatio
 2NF 3NF
PROPERTY
Pno pAddress
3NF

STAFF
StaffNo sName

3NF

PROPERTY_INSPECTION
Pno iDate iTime comments StaffNo CarReg

3NF

PROPERTY(Pno, pAddres)
STAFF(StaffNo, sName)
PROPERTY_INSPECT(Pno, iDate, iTime, comments, staffNo, CarReg)

48
Normalizatio