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
