Functional Dependencies

UNIT III
 Normal Forms Based on Primary Keys

 Normalization of Relations
 Practical Use of Normal Forms
 Definitions of Keys and Attributes
Participating in Keys
 First Normal Form
 Second Normal Form
 Third Normal Form
 Normalization of Relations
 Proposed by Codd(1972) – three NFs
 Boyce and Codd proposed BCNF
 Normalization:
◼ The process of decomposing unsatisfactory
"bad" relations by breaking up their
attributes into smaller relations

 Normal form:
◼ Condition using keys and FDs of a relation to
certify whether a relation schema is in a
particular normal form
 Normalization of Relations
 2NF, 3NF, BCNF
◼ based on keys and FDs of a relation schema
 4NF
◼ based on keys, multi-valued dependencies :
MVDs;
 5NF
◼ based on keys, join dependencies : JDs
 Additional properties may be needed to
ensure a good relational design
◼ lossless join
◼ dependency preservation
 Practical Use of Normal Forms
 Normalization is carried out in practice so
that the resulting designs are of high quality
and meet the desirable properties
 The practical utility of these normal forms
becomes questionable when the constraints on
which they are based are hard to understand or
to detect
 The database designers need not normalize to
the highest possible normal form
◼ usually up to 3NF, BCNF or 4NF
 Denormalization:
◼ The process of storing the join of higher normal form
relations as a base relation—which is in a lower
normal form
 First Normal Form
 Disallows
◼ composite attributes
◼ multivalued attributes
◼ nested relations; attributes whose values
for an individual tuple are non-atomic

 Considered to be part of the definition of

relation
Normalization into 1NF
Normalization of nested relations into 1NF
1 NF
1 NF
 Second Normal Form
 Uses the concepts of FDs, primary key
 Definitions
◼ Prime attribute: An attribute that is member of the
primary key K
◼ Full functional dependency: a FD Y -> Z where
removal of any attribute from Y means the FD does
not hold any more
 Examples:
◼ {SSN, PNUMBER} -> HOURS is a full FD since
neither SSN -> HOURS nor PNUMBER -> HOURS
hold
◼ {SSN, PNUMBER} -> ENAME is not a full FD (it is
called a partial dependency ) since SSN -> ENAME
also holds
 Second Normal Form
 A relation schema R is in second
normal form (2NF) if every non-prime
attribute A in R is fully functionally
dependent on the primary key

 R can be decomposed into 2NF relations

via the process of 2NF normalization
Example: 1NF to 2NF
Normalizing into 2NF
2 NF
2 NF
 Third Normal Form
 Definition:
◼ Transitive functional dependency: a FD
X -> Z that can be derived from two FDs X
-> Y and Y -> Z

 Examples:
◼ SSN -> DMGRSSN is a transitive FD
 Since SSN -> DNUMBER and DNUMBER ->
DMGRSSN hold
◼ SSN -> ENAME is non-transitive
 Since there is no set of attributes X where SSN
-> X and X -> ENAME
 Third Normal Form
 A relation schema R is in third normal form
(3NF) if it is in 2NF and no non-prime attribute
A in R is transitively dependent on the primary
key
 R can be decomposed into 3NF relations via the
process of 3NF normalization
 NOTE:
◼ In X -> Y and Y -> Z, with X as the primary key, we
consider this a problem only if Y is not a candidate
key.
◼ When Y is a candidate key, there is no problem with
the transitive dependency .
◼ E.g., Consider EMP (SSN, Emp#, Salary ).
 Here, SSN -> Emp# -> Salary and Emp# is a
candidate key.
 Normal Forms Defined Informally
 1st normal form
◼ All attributes depend on the key
 2nd normal form
◼ All attributes depend on the whole key
 3rd normal form
◼ All attributes depend on nothing but the
key
3 NF
3 NF
Successive Normalization of LOTS into 2NF and
3NF
SUMMARY OF NORMAL FORMS
based on Primary Keys
 BCNF (Boyce-Codd Normal Form)
 A relation schema R is in Boyce-Codd Normal
Form (BCNF) if whenever an FD X -> A holds
in R, then X is a superkey of R
 Each normal form is strictly stronger than the
previous one
◼ Every 2NF relation is in 1NF
◼ Every 3NF relation is in 2NF
◼ Every BCNF relation is in 3NF
 There exist relations that are in 3NF but not in
BCNF
 The goal is to have each relation in BCNF (or
3NF)
BCNF
BCNF
Boyce-Codd Normal Form
A relation TEACH that is in 3NF but not in
BCNF
 Achieving the BCNF by Decomposition

 Two FDs exist in the relation TEACH:

◼ fd1: { student, course} -> instructor
◼ fd2: instructor -> course
 {student, course} is a candidate key for
this relation
◼ So this relation is in 3NF but not in BCNF
 A relation NOT in BCNF should be
decomposed so as to meet this property,
while possibly forgoing the preservation
of all functional dependencies in the
decomposed relations.
 Achieving the BCNF by Decomposition
 Three possible decompositions for relation TEACH
◼ {student, instructor} and {student, course}
◼ {course, instructor } and {course, student}
◼ {instructor, course } and {instructor, student}
 All three decompositions will lose fd1.
◼ We have to settle for sacrificing the functional dependency
preservation. But we cannot sacrifice the non-additivity
property after decomposition.
 Out of the above three, only the 3rd decomposition will not
generate spurious tuples after join.(and hence has the
non-additivity property).
Example -
Class_Test(Student_id, Professor_id,
Class_code, Student_grade)
Functional Dependecy
(Student_id, Professor_id) → (Class_code,
Student_grade)
Class_code → Professor_id>
 student_id subject Professor Name
101 Java Alex
101 C++ Amit
102 Java Alex
This table satisfies the 1st Normal form because all the values are
atomic, column names are unique and all the values stored in a
particular column are of same domain.
Candidate Key Student_id –>Subject, Professor name
Professor name –> Subject
This table also satisfies the 2nd Normal Form as their is no Partial
Dependency.
And, there is no Transitive Dependency, hence the table also
satisfies the 3rd Normal Form.

But this table is not in Boyce-Codd Normal Form.

Why this table is not in BCNF?

In the table above, student_id, subject form primary

key, which means subject column is a prime attribute.
But, there is one more dependency, professor →
subject.
And while subject is a prime attribute, professor is a
non-prime attribute, which is not allowed by BCNF.
How to satisfy BCNF?

To make this relation(table) satisfy BCNF,

we will decompose this table into two
tables, student table and professor table.
Below we have the structure for both the
tables.
Student Table

student_id Professor Name

101 Alex
Professor Table

Professor Name Subject

Alex Java

Amit C++
 Example 1: Determine NF
 ISBN → Title
 ISBN → Publisher
 Publisher → Address All attributes are directly
or indirectly determined
by the primary key;
therefore, the relation is
at least in 1 NF

BOOK

ISBN Title Publisher Address

 Example 1: Determine NF
 ISBN → Title
 ISBN → Publisher
 Publisher → Address The relation is at least in 1NF.
There is no COMPOSITE
primary key, therefore there
can’t be partial dependencies.
Therefore, the relation is at
least in 2NF
BOOK

ISBN Title Publisher Address

 Example 1: Determine NF
 ISBN → Title
 ISBN → Publisher
 Publisher → Address Publisher is a non-key attribute,
and it determines Address,
another non-key attribute.
Therefore, there is a transitive
dependency, which means that
the relation is NOT in 3 NF.
BOOK

ISBN Title Publisher Address

 Example 1: Determine NF
 ISBN → Title
 ISBN → Publisher
 Publisher → Address We know that the relation is at
least in 2NF, and it is not in 3
NF. Therefore, we conclude
that the relation is in 2NF.

BOOK

ISBN Title Publisher Address

 Example 1: Determine NF

 ISBN → Title In your solution you will write the

following justification:
 ISBN → Publisher No M/V attributes, therefore at least
 Publisher → 1NF
Address No partial dependencies, therefore at
least 2NF
There is a transitive dependency
(Publisher → Address), therefore, not
3NF
Conclusion: The relation is in 2NF

BOOK

ISBN Title Publisher Address

 Example 2: Determine NF
 Product_ID → Description

All attributes are directly or

indirectly determined by the primary
key; therefore, the relation is at
least in 1 NF
ORDER

Order_No Product_ID Description

 Example 2: Determine NF
 Product_ID → Description

The relation is at least in 1NF.

There is a COMPOSITE Primary Key (PK) (Order_No,
Product_ID), therefore there can be partial
dependencies. Product_ID, which is a part of PK,
determines Description; hence, there is a partial
dependency. Therefore, the relation is not 2NF. No
sense to check for transitive dependencies!

ORDER

Order_No Product_ID Description

 Example 2: Determine NF
 Product_ID → Description

We know that the relation is at least

in 1NF, and it is not in 2 NF.
Therefore, we conclude that the
relation is in 1 NF.

ORDER

Order_No Product_ID Description

 Example 2: Determine NF

 Product_ID →
Description
In your solution you will write the
following justification:
1) No M/V attributes, therefore at least 1NF
2) There is a partial dependency
(Product_ID → Description), therefore not
in 2NF
Conclusion: The relation is in 1NF
ORDER

Order_No Product_ID Description

Example 3: Determine NF

 Part_ID → Description Comp_ID and No are not

 Part_ID → Price determined by the primary
key; therefore, the relation
 Part_ID, Comp_ID → No
is NOT in 1 NF. No sense
in looking at partial or
transitive dependencies.

PART

Part_ID Descr Price Comp_ID No

 Example 3: Determine NF
 Part_ID → Description
 Part_ID → Price
 Part_ID, Comp_ID → No In your solution you will write
the following justification:
There are M/V attributes;
therefore, not 1NF
Conclusion: The relation is not
normalized.

PART

Part_ID Descr Price Comp_ID No

Bringing a Relation to 1NF

STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Bringing a Relation to 1NF

 Option 1: Make a determinant of the

repeating group (or the multi-valued
attribute) a part of the primary key.
Composite
Primary Key

STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Bringing a Relation to 1NF

 Option 2: Remove the entire repeating group from

the relation. Create another relation which would
contain all the attributes of the repeating group,
plus the primary key from the first relation. In this
new relation, the primary key from the original
relation and the determinant of the repeating group
will comprise a primary key.

STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Bringing a Relation to 1NF

STUDENT

Stud_ID Name
101 Lennon
125 Jonson

STUDENT_COURSE

Stud_ID Course Units

101 M S I 250 3
101 M S I 415 3
125 M S I 331 3
Bringing a Relation to 2NF

Composite
Primary Key

STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Bringing a Relation to 2NF

 Goal: Remove Partial Dependencies

Partial
Composite Dependencies
Primary Key

STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00

101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Bringing a Relation to 2NF

 Remove attributes that are dependent from the part

but not the whole of the primary key from the
original relation. For each partial dependency,
create a new relation, with the corresponding part
of the primary key from the original as the primary
key.
STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Bringing a Relation to 2NF
CUSTOMER
STUDENT_COURSE
Stud_I Name Course_I Units
D D
101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
Stud_ID Course_ID
125 Johnson MSI 331 3.00
101 MSI 250
101 MSI 415
125 MSI 331

STUDENT COURSE

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
 Bringing a Relation to 3NF
 Goal: Get rid of transitive dependencies.

Transitive
Dependency
EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name

111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
Bringing a Relation to 3NF

 Remove the attributes, which are dependent on a

non-key attribute, from the original relation. For
each transitive dependency, create a new relation
with the non-key attribute which is a determinant in
the transitive dependency as a primary key, and
the dependent non-key attribute as a dependent.

EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name

111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
Bringing a Relation to 3NF
EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name

111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg

EMPLOYEE

Emp_ID F_Name L_Name Dept_ID

111 Mary Jones 1
122 Sarah Smith 2

DEPARTMENT

Dept_ID Dept_Name
1 Acct
2 Mktg