DBMS-Normalization.ppt

Functional Dependence and
Normalization
Dr. Mrs. KALPANA THAKARE
PROFESSOR
DEPARTMENT OF Computer Engineering
Marathwada Mitra Mandal College of Engineering ,Pune

Objectives
The purpose of normailization
Data redundancy and Update Anomalies
Functional Dependencies
The Process of Normalization
First Normal Form (1NF)
Second Normal Form (2NF)
Third Normal Form (3NF)

Objectives (2)
General Definition of Second and Third
Normal Form
Boyce-Codd Normal Form (BCNF)
Fourth Normal Form (4NF)
Fifth Normal Form (5NF)

GOOD DATABASE DESIGN!!!!!!!
Good Business ------

ISDL Project Design
Understand the organization/ Environment
Convert the functional units into entities
Identify the entities and Attributes and Relations amongst
entities very correctly
Draw an E-R Diagram
Reduce your E-R Diagram into set of tables i.e. database
Put all the integrity constraints of the organization
Bring your databases into normal forms(Normalization)
Then create your back-end
And at last front end

6
Which are our
lowest/highest margin
customers ?
Who are my customers
and what products
are they buying?
Which customers
are most likely to go
to the competition ?
What impact will
new products/services
have on revenue
and margins?
What product prom-
-otions have the biggest
impact on revenue?
What is the most
effective distribution
channel?
A producer wants to know….

7
Data, Data everywhere ...
I can’t find the data I need
 data is scattered over the network
 many versions, subtle differences
• I can’t get the data I need
• need an expert to get the data
• I can’t understand the data I found
• available data poorly documented
• I can’t use the data I found
• results are unexpected
• data needs to be transformed
from one form to other
RDBMS!!!

The Purpose of Normalization
Normalization is a technique for producing a set of
relations with desirable properties, given the data
requirements of an enterprise.
The process of normalization is a formal method that
identifies relations based on their primary or candidate
keys and the functional dependencies among their
attributes.

Pitfalls in Relational Database Design
Relational database design requires that
we find a “good” collection of relation
schemas. A bad design may lead to
• Repetition of Information.
• Inability to represent certain information.

Recipe for a Successful
DATABASE

Good Database Design
 Design Goals:
 Avoid redundant data
 Ensure that relationships among attributes
are represented
 Facilitate the checking of updates for
violation of database integrity constraints
Avoid redundant
data
Ensure that
relationships
among attributes
are represented
Facilitate the
checking of
updates for
violation of
database
integrity
constraints

Example
Consider the relation schema:
Redundancy:
 Data for branch-name, branch-city, assets are repeated for each loan that a branch
makes
 Wastes space
 Complicates updating, introducing possibility of inconsistency of assets value
Null values
 Cannot store information about a branch if no loans exist
 Can use null values, but they are difficult to handle.

Goal — Devise a Theory for the Following
Decide whether a particular relation R is in
“good” form.
In the case that a relation R is not in “good”
form, decompose it into a set of relations {R1,
R2, ..., Rn} such that
 each relation is in good form
 the decomposition is a lossless-join decomposition
Our theory is based on:
 functional dependencies
 multivalued dependencies

Functional Dependencies
Functional dependency describes the relationship between
attributes in a relation.
For example, if A and B are attributes of relation R, and B is
functionally dependent on A ( denoted A B), if each value of
A is associated with exactly one value of B. ( A and B may each
consist of one or more attributes.)
A B
B is functionally
dependent on A
Determinant Refers to the attribute or group of attributes on the
left-hand side of the arrow of a functional dependency

Trival functional dependency means that the right-hand
side is a subset ( not necessarily a proper subset) of the left-
hand side.
Functional Dependencies (2)
For example:
staffNo, sName  sName
staffNo, sName  staffNo
They do not provide any additional information about possible integrity
constraints on the values held by these attributes.
We are normally more interested in nontrivial dependencies because they
represent integrity constraints for the relation.

Main characteristics of functional dependencies in normalization
• Have a one-to-one relationship between attribute(s) on the
left- and right- hand side of a dependency;
• hold for all time;
• are nontrivial.

Identifying the primary key
Functional dependency is a property of the meaning or semantics
of the attributes in a relation. When a functional dependency is
present, the dependency is specified as a constraint between the
attributes.
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 using functional dependency.

Closure of a Set of Functional Dependencies
Given a set F set of functional dependencies, there are certain
other functional dependencies that are logically implied by F.
 E.g. If A  B and B  C, then we can infer that A  C
The set of all functional dependencies logically implied by F is the
closure of F.
We denote the closure of F by F+.
We can find all of F+ by applying Armstrong’s Axioms:
 if   , then    (reflexivity)
 if   , then      (augmentation)
 if   , and   , then    (transitivity)
These rules are
 sound (generate only functional dependencies that actually
hold) and
 complete (generate all functional dependencies that hold).

Closure of Functional Dependencies (Cont.)
We can further simplify manual computation of
F+ by using the following additional rules.
1. If    holds and    holds, then    
holds (union)
2. If     holds, then    holds and   
holds (decomposition)
3. If    holds and     holds, then    
holds (pseudo transitivity)
The above rules can be inferred from Armstrong’s
axioms.

Example
R = (A, B, C, G, H, I)
F = { A  B
A  C
CG  H
CG  I
B  H}
some members of F+
 A  H
 by transitivity from A  B and B  H
 AG  I
 by augmenting A  C with G, to get AG  CG
and then transitivity with CG  I
 CG  HI
 from CG  H and CG  I : “union rule” can be inferred from
 definition of functional dependencies, or
 Augmentation of CG  I to infer CG  CGI, augmentation of
CG  H to infer CGI  HI, and then transitivity

Closure of Attribute Sets
Given a set of attributes , define the closure of 
under F (denoted by +) as the set of attributes that
are functionally determined by  under F:
   is in F+    +
Algorithm to compute +, the closure of  under F
result := ;
while (changes to result) do
for each    in F do
begin
if   result then result := result  
end

Example of Attribute Set Closure
R = (A, B, C, G, H, I)
F = {A  B
A  C
CG  H
CG  I
B  H}
(AG)+
1. result = AG
2. result = ABCG (A  C and A  B)
3. result = ABCGH (CG  H and CG  AGBC)
4. result = ABCGHI (CG  I and CG  AGBCH)
Is AG a candidate key?
1. Is AG a super key?
1. Does AG  R? == Is (AG)+  R
2. Is any subset of AG a superkey?
1. Does A  R? == Is (A)+  R
2. Does G  R? == Is (G)+  R

Uses of Attribute Closure
There are several uses of the attribute closure
algorithm:
Testing for superkey:
 To test if  is a superkey, we compute +, and check if
+ contains all attributes of R.
Testing functional dependencies
 To check if a functional dependency    holds (or,
in other words, is in F+), just check if   +.
 That is, we compute + by using attribute closure, and
then check if it contains .
 Is a simple and cheap test, and very useful
Computing closure of F

Canonical Cover
Sets of functional dependencies may have redundant
dependencies that can be inferred from the others
 Eg: A  C is redundant in: {A  B, B  C, A  C}
 Parts of a functional dependency may be redundant
 E.g. on RHS: {A  B, B  C, A  CD} can be simplified to
{A  B, B  C, A  D}
 E.g. on LHS: {A  B, B  C, AC  D} can be simplified to
{A  B, B  C, A  D}
Intuitively, a canonical cover of F is a “minimal” set of
functional dependencies equivalent to F, having no
redundant dependencies or redundant parts of
dependencies

Example of Computing a Canonical Cover
R = (A, B, C)
F = {A  BC
B  C
A  B
AB  C}
Combine A  BC and A  B into A  BC
 Set is now {A  BC, B  C, AB  C}
A is extraneous in AB  C
 Check if the result of deleting A from AB  C is implied by the other dependencies
 Yes: in fact, B  C is already present!
 Set is now {A  BC, B  C}
C is extraneous in A  BC
 Check if A  C is logically implied by A  B and the other dependencies
 Yes: using transitivity on A  B and B  C.
 Can use attribute closure of A in more complex cases
The canonical cover is: A  B
B  C

The Process of Normalization
• Normalization is often executed as a series of steps. Each step
corresponds to a specific normal form that has known properties.
• As normalization proceeds, the relations become progressively
more restricted in format, and also less vulnerable to update
anomalies.
• For the relational data model, it is important to recognize that
it is only first normal form (1NF) that is critical in creating
relations. All the subsequent normal forms are optional.

Normalization
A relation r is said to be normalized if it do
not create any problem for three basic
operations: insert, delete and update
A relation r is said to be in a particular
normal form if it satisfies a certain prescribed
set of conditions.
Ex : 2NF

Goals of Normalization
Decide whether a particular relation R is in
“good” form.
In the case that a relation R is not in
“good” form, decompose it into a set of
relations {R1, R2, ..., Rn} such that
 each relation is in good form
 the decomposition is a lossless-join
decomposition
Our theory is based on:
 functional dependencies
 multivalued dependencies

Normalization Using Functional Dependencies
When we decompose a relation schema R with a set of functional
dependencies F into R1, R2,.., Rn we want
 Lossless-join decomposition(Nonloss decomposition) :
Otherwise decomposition would result in information loss.
 No redundancy: The relations Ri preferably should be in
either Boyce-Codd Normal Form or Third Normal Form.
 Dependency preservation: Let Fi be the set of dependencies
F+ that include only attributes in Ri.
 Preferably the decomposition should be dependency preserving, that
is, (F1  F2  …  Fn)+ = F+
 Otherwise, checking updates for violation of functional dependencies
may require computing joins, which is expensive.

Example
R = (A, B, C)
F = {A  B, B  C)
 Can be decomposed in two different ways
R1 = (A, B), R2 = (B, C)
 Lossless-join decomposition:
R1  R2 = {B} and B  BC
 Dependency preserving
R1 = (A, B), R2 = (A, C)
 Lossless-join decomposition:
R1  R2 = {A} and AB AC
 Not dependency preserving
(cannot check B  C without computing R1 R2)

Example
S# STATUS CITY
S3 30 PARIS
S5 50 ATHENS
S# STATUS
S3 30
S5 50
S# CITY
S3 PARIS
S5 ATHENS
S# STATUS
S3 30
S5 50
STATUS CITY
30 PARIS
50 ATHENS
S#STATUS
CITY  STATUS

Normalization
1NF
2NF
3NF
4NF
5NF

1NF
1NF: A relation r is in 1NF if and only if
every tuple contains exactly one value
for each attribute.
Criteria:
 Value of each attribute is atomic
 No composite attribute
 All entries in any column must be of same
kind
 Each column must have a unique name
 No two rows are identical

1NF: A relation r is in 1NF if and only if every tuple contains exactly
one value for each attribute.
FIRST
S# STATUS CITY P# QTY
S1 20 LONDON P1 300
S1 20 LONDON P2 200
S1 20 LONDON P3 400
S1 20 LONDON P4 200
S1 20 LONDON P5 100
S1 20 LONDON P6 100
S2 10 PARIS P1 300
S2 10 PARIS P2 400
S3 10 PARIS P2 300
S4 20 ATHENS P2 200
S4 20 ATHENS P4 300
S4 20 ATHENS P5 400
Repeating group

1NF
FD’S
S#STATUS
S#CITY
CITYSTATUS
P#QTY
S#P#  QTY
Anomalies
INSERT
DELETE
UPDATE

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 partially dependent if there
is some attributes that can be removed from A and the
dependency still holds.

Nonloss decomposition
S# STATUS CITY
S1 20 LONDON
S2 10 PARIS
S3 10 PARIS
S4 20 ATHENS
SECOND
S# P# QTY
S1 P1 300
S1 P2 200
S1 P3 400
S1 P4 200
S1 P5 100
S1 P6 100
S2 P1 300
S2 P2 400
S3 P2 300
S4 P2 200
S4 P4 300
S4 P5 400
SP 
Discuss Anomalies !!!!!!!!!!!
S#STATUS
S#CITY
CITYSTATUS
S#P#  QTY

2NF
Definition: A relation is in 2NF if and only if
it is in 1NF and every nonkey attribute is
dependent on the primary key
Criteria:
 R must be in 1NF
 All the nonprime attribute are fully functional
dependent on any key of R( each candidate
key)

2NF
Anomalies with SECOND
S#STATUS
S#CITY
CITYSTATUS
S#P#  QTY
SECOND

3NF
Definition: A relation is in 3NF if and only
if it is in 2NF and every nonkey attribute
is nontransitively dependant on the
primary key.
Criteria:
 R should be in 2NF
 Nontransitive dependence or
 There should not be the case that a
nonprime attribute is dependent on
nonprime attribute

3NF
Definition: A relation is in 3NF if and only if it
is in 2NF and every nonkey attribute is
nontransitively dependant on the primary
key.
S# CITY
S1 LONDON
S2 PARIS
S3 PARIS
S4 ATHENS
CITY STATUS
LONDON 20
PARIS 10
PARIS 10
ATHENS 20
SC
CS
S#CITY CITYSTATUS

BCNF(Boyce/Codd Normal Form)
Definition: A relation is in BCNF if and only if
the only determinants are candidate keys.
Determinants: are the attribute on which
some other attributes are dependent on
BCNF is strictly stronger than 3NF
EX. TABLE FIRST S#STATUS
S#CITY
CITYSTATUS
P#QTY
S#P#  QTY THREE DETERMINENTS(S#,CITY,S#P#)
only S#P# is candidate key HENCE
FIRST IS NOT IN BCNF

TABLE SP
S#P#  QTY
Determinant S#P#, IS THE ONLY CANDIDATE KEY HENCE
SECOND IS IN BCNF
TABLE SECOND:
S#STATUS
S#CITY
CITYSTATUS
TWO DETERMINENTS S#,CITY
CITY IS NOT A CANDIDATE KEY,HENCE SECOND IS NOT IN
BCNF

TABLE SC:
S#CITY
DETERMINENTS S# IS THE ONLY
CANDIDATE KEY HENCE IN BCNF
TABLE CS
CITYSTATUS
DETERMINENTS CITY IS THE ONLY
CANDIDATE KEY HENCE IN BCNF

4NF
COURSE TEACHERS TEXTS
PHYSICS PROF GREEN
PROF BROWN
BASIC MECHAINICS
PRINCIPALS OF OPTICS
MATH PROF GREEN BASIC MECHAINICS
VECTOR ANALYSIS
TRIGNOMETRY
HCTX

4NF
COURSE TEACHERS COURSE
PHYSICS PROF GREEN BASIC MECHAINICS
PHYSICS PROF GREEN PRINCIPALS OF
OPTICS
PHYSICS PROF BROWN BASIC MECHAINICS
PHYSICS PROF BROWN PRINCIPALS OF
OPTICS
MATH PROF GREEN BASIC MECHAINICS
MATH PROF GREEN VECTOR ANALYSIS
MATH PROF GREEN TRIGNOMETRY

4NF
Redundancy, update anomalies
Decompose CTX into two projections
COURSE TEACHERS
PHYSICS PROF GREEN
PHYSICS PROF BROWN
MATH PROF GREEN
COURSE TEXTS
PHYSICS BASIC MECHAINICS
PHYSICS PRINCIPALS OF
OPTICS
MATH BASIC MECHAINICS
MATH VECTOR ANALYSIS
MATH TRIGNOMETRY
CT
CX
COURSETEACHER|TEXT

4NF
Fagin’s Theorem: Let R(A,B,C) be a relation
where A,B,C are sets of attributes then R is
equal to the join of its projections on {A,B}and
{A,C} if and only if r satisfies the MVDs
AB|C
4NF Definition: Relation R is in 4NF if and
only if whenever there exists subsets A and B
of the attributes of R such that the MVD
AB is satisfied then all attributes of R are
also functionally dependent on A .

Fifth Normal Form (5NF)
Lossless-join dependency
A property of decomposition, which ensures that no spurious
tuples are generated when relations are reunited through a
natural join operation.
Join dependency
Describes a type of dependency. For example, for a relation
R with subsets of the attributes of R denoted as A, B, …, Z, a
relation R satisfies a join dependency if, and only if, every
legal value of R is equal to the join of its projections on A, B,
…, Z.
Fifth normal form (5NF)
A relation that has join dependency.

PJNF
S# P# J#
S1 P1 J2
S1 P2 J1
S2 P1 J1
S1 P1 J1
S# P#
S1 P1
S1 P2
S2 P1
P# J#
P1 J2
P2 J1
P1 J1
J# S#
J2 S1
J1 S1
J1 S2
S# P# J#
S1 P1 J2
S1 P2 J1
S2 P1 J1
S2 P1 J2
S1 P1 J1
JOIN
OVER
P#
JOIN
OVER J#S#
Original
SPJ

First Normal Form (1NF)
Unnormalized form (UNF)
A table that contains one or more repeating groups.
ClientNo cName propertyNo pAddress rentStart rentFinish rent ownerNo oName
CR76
John
kay
PG4
PG16
6 lawrence
St,Glasgow
5 Novar Dr,
Glasgow
1-Jul-00
1-Sep-02
31-Aug-01
1-Sep-02
350
450
CO40
CO93
Tina
Murphy
Tony
Shaw
CR56
Aline
Stewart
PG4
PG36
PG16
6 lawrence
St,Glasgow
2 Manor Rd,
Glasgow
5 Novar Dr,
Glasgow
1-Sep-99
10-Oct-00
1-Nov-02
10-Jun-00
1-Dec-01
1-Aug-03
350
370
450
CO40
CO93
CO93
Tina
Murphy
Tony
Shaw
Tony
Shaw
Figure 3 ClientRental unnormalized table
Repeating group = (propertyNo, pAddress,
rentStart, rentFinish, rent, ownerNo, oName)

1NF ClientRental relation with the first
approach
ClientNo propertyNo cName pAddress rentStart rentFinish rent ownerNo oName
CR76 PG4
John
Kay
6 lawrence
St,Glasgow
1-Jul-00 31-Aug-01 350 CO40
Tina
Murphy
CR76 PG16
John
Kay
5 Novar Dr,
Glasgow
1-Sep-02 1-Sep-02 450 CO93
Tony
Shaw
CR56 PG4
Aline
Stewart
6 lawrence
St,Glasgow
1-Sep-99 10-Jun-00 350 CO40
Tina
Murphy
CR56 PG36
Aline
Stewart
2 Manor Rd,
Glasgow
10-Oct-00 1-Dec-01 370 CO93
Tony
Shaw
CR56 PG16
Aline
Stewart
5 Novar Dr,
Glasgow
1-Nov-02 1-Aug-03 450 CO93
Tony
Shaw
Figure 4 1NF ClientRental relation with the first approach
The ClientRental relation is defined as follows,
ClientRental ( clientNo, propertyNo, cName, pAddress, rentStart, rentFinish, rent,
ownerNo, oName)
With the first approach, we remove the repeating group (property rented
details) by entering the appropriate client data into each row.

1NF ClientRental relation with the second approach
With the second approach, we remove the repeating group
(property rented details) by placing the repeating data along with
a copy of the original key attribute (clientNo) in a separte relation.
Client (clientNo, cName)
PropertyRentalOwner (clientNo, propertyNo, pAddress, rentStart,rentFinish,
rent, ownerNo, oName)
ClientNo cName
CR76 John Kay
CR56 Aline Stewart
ClientNo propertyNo pAddress rentStart rentFinish rent ownerNo oName
CR76 PG4
6 lawrence
St,Glasgow
1-Jul-00 31-Aug-01 350 CO40
Tina
Murphy
CR76 PG16
5 Novar Dr,
Glasgow
1-Sep-02 1-Sep-02 450 CO93
Tony
Shaw
CR56 PG4
6 lawrence
St,Glasgow
1-Sep-99 10-Jun-00 350 CO40
Tina
Murphy
CR56 PG36
2 Manor Rd,
Glasgow
10-Oct-00 1-Dec-01 370 CO93
Tony
Shaw
CR56 PG16
5 Novar Dr,
Glasgow
1-Nov-02 1-Aug-03 450 CO93
Tony
Shaw
Figure 5 1NF ClientRental relation with the second approach

Second Normal Form (2NF)
Second normal form (2NF) is a relation that is in first
normal form and every non-primary-key attribute is fully
functionally dependent on the primary key.
The normalization of 1NF relations to 2NF involves the
removal of partial dependencies. If a partial dependency
exists, we remove the function dependent attributes from
the relation by placing them in a new relation along with
a copy of their determinant.

2NF ClientRental relation
The ClientRental relation has the following functional
dependencies:
fd1 clientNo, propertyNo  rentStart, rentFinish (Primary Key)
fd2 clientNo  cName (Partial dependency)
fd3 propertyNo  pAddress, rent, ownerNo, oName (Partial dependency)
fd4 ownerNo  oName (Transitive Dependency)
fd5 clientNo, rentStart  propertyNo, pAddress,
rentFinish, rent, ownerNo, oName (Candidate key)
fd6 propertyNo, rentStart  clientNo, cName, rentFinish (Candidate key)

After removing the partial dependencies, the creation of the three
new relations called Client, Rental, and PropertyOwner
ClientNo cName
CR76 John Kay
CR56 Aline Stewart
Client
ClientNo propertyNo rentStart rentFinish
CR76 PG4 1-Jul-00 31-Aug-01
CR76 PG16 1-Sep-02 1-Sep-02
CR56 PG4 1-Sep-99 10-Jun-00
CR56 PG36 10-Oct-00 1-Dec-01
CR56 PG16 1-Nov-02 1-Aug-03
Rental
propertyNo pAddress rent ownerNo oName
PG4 6 lawrence St,Glasgow 350 CO40 Tina Murphy
PG16 5 Novar Dr, Glasgow 450 CO93 Tony Shaw
PG36 2 Manor Rd, Glasgow 370 CO93 Tony Shaw
PropertyOwner
Rental (clientNo, propertyNo, rentStart, rentFinish)
PropertyOwner (propertyNo, pAddress, rent, ownerNo, oName)
Figure 6 2NF ClientRental relation

Third Normal Form (3NF)
Transitive dependency
A condition where A, B, and C are attributes of a relation such that
if A  B and B  C, then C is transitively dependent on A via B
(provided that A is not functionally dependent on B or C).
Third normal form (3NF)
A relation that is in first and second normal form, and in which
no non-primary-key attribute is transitively dependent on the
primary key.
The normalization of 2NF relations to 3NF involves the removal
of transitive dependencies by placing the attribute(s) in a new
relation along with a copy of the determinant.

The functional dependencies for the Client, Rental and
PropertyOwner relations are as follows:
Client
fd2 clientNo  cName (Primary Key)
Rental
fd1 clientNo, propertyNo  rentStart, rentFinish (Primary Key)
fd5 clientNo, rentStart  propertyNo, rentFinish (Candidate key)
fd6 propertyNo, rentStart  clientNo, rentFinish (Candidate key)
PropertyOwner
fd3 propertyNo  pAddress, rent, ownerNo, oName (Primary Key)
fd4 ownerNo  oName (Transitive Dependency)

The resulting 3NF relations have the forms:
Rental (clientNo, propertyNo, rentStart, rentFinish)
PropertyOwner (propertyNo, pAddress, rent, ownerNo)
Owner (ownerNo, oName)

ClientNo cName
CR76 John Kay
CR56 Aline Stewart
Client
ClientNo propertyNo rentStart rentFinish
CR76 PG4 1-Jul-00 31-Aug-01
CR76 PG16 1-Sep-02 1-Sep-02
CR56 PG4 1-Sep-99 10-Jun-00
CR56 PG36 10-Oct-00 1-Dec-01
CR56 PG16 1-Nov-02 1-Aug-03
Rental
propertyNo pAddress rent ownerNo
PG4 6 lawrence St,Glasgow 350 CO40
PG16 5 Novar Dr, Glasgow 450 CO93
PG36 2 Manor Rd, Glasgow 370 CO93
PropertyOwner
ownerNo oName
CO40 Tina Murphy
CO93 Tony Shaw
Owner
Figure 7 2NF ClientRental relation

EXAMPLE
SPJX (S#,SNAME,STATUS,CITY, P#, PNAME,
COLOR,WEIGHT,CITY,J#,JNAME,CITY,QTY)
SUPPLIER-PARTS-PROJECTS DATABASE
SOLUTION
S(S#,SNAME,STATUS,CITY)
P(P#,PNAME,COLOR,WEIGHT,CITY)
J (J#,JNAME,CITY)
SPJ (S#,P#,J#,QTY)

DBMS-Normalization.ppt

Recommended

More Related Content

Similar to DBMS-Normalization.ppt (20)

Recently uploaded (20)

DBMS-Normalization.ppt