Functional Dependencies and
Normalization for Relational
Databases
Redundant information in tuples and
update anomalies
• Information is stored redundantly
– Wasted storage
– Causes problems with update anomalies
• Insertion anomalies
• Deletion anomalies
• Modification anomalies
Two relation schemas suffering from
update anomalies
Example of an Update anomalies
• Consider the relation:
• Emp_proj(Emp#, Pro#, Ename, Pname,
No_hours)
• Update anomaly:
• Changing the name of project number P1 from
“Billing” to “Customer-Accounting” may cause
this update to be made for all 100 employees
working on project P1.
Example of an Insert anomaly
• Consider the relation:
– Emp_proj(Emp#, Pro#, Ename, Pname, No_hours)
• Insert anomaly:
– Cannot insert a project unless an employee is
assigned to it.
• Conversely
– Cannot insert an employee unless a he/she is
assigned to a project
Example of an delete anomaly
• Consider the relation:
– Emp_proj(Emp#, Pro#, Ename, Pname, No_hours)
• Delete anomaly:
– When a project is deleted, it will result in deleting
all the employees who work on that project.
– Alternately, if an employee is the sole employee
on a project, deleting that employee would result
in deleting the corresponding project
Normalization of Relations
• 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
Functional Dependencies
• X Y holds if whenever two tuples have the
same value for X, they must have the same value
for Y
– For any two tuples t1 and t2 in any relation instance
r(R): If t1[X]=t2[X], then t1[Y]=t2[Y]
• X Y in R specifies a constraint on all relation
instances r(R)
• Written as X Y; can be displayed graphically on
a relation schema as in Figures. ( denoted by the
arrow: ).
• FDs are derived from the real-world constraints
on the attributes
Examples of FD constraints
• social security number determines employee
name
SSN ENAME
• project number determines project name and
location
PNUMBER {PNAME, PLOCATION}
• employee ssn and project number determines
the hours per week that the employee works
on the project
{SSN, PNUMBER} HOURS
Normal Forms Based on Primary Keys
• First Normal Form
• Second Normal Form
• Third Normal Form
• Boyce Codd Normal Form
• Fourth Normal Form
• Fifth Normal Form
1st NF 2nd NF 3rd NF Higher
NF
Remove Remove Remove
MV partial transitive
attributes dependencies Dependencies
R1
R1 R1
R1 C1 C2 C3
C1 C2 C3 C1 C2 C3
C1 C2 C3
R2
R2
C1 C2 C3
R2 C1 C2 C3
C1 C2 C3 R3
R3
C1 C2 C3
C1 C2 C3
R4
Repeating
groups C1 C2 C3
redundancy
Partial No repeating
transitive Groups, No No partial No transitive
Dependencies MV attributes dependencies dependencies
First Normal Form
• Disallows
– composite attributes,
– multivalued attributes, and
– 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
Definitions of Keys and Attributes
Participating in Keys
• A superkey of a relation schema
R = {A1, A2, ...., An} is a set of attributes S subset-of R
with the property that:
no two tuples t1 and t2 in any legal relation state r
of R will have t1[S] = t2[S]
• A key K is a superkey with the additional
property that removal of any attribute from K
will cause K not to be a superkey any more.
Second Normal Form (2NF)
• Uses the concepts of FDs, primary key
Definitions:
• Prime attribute: 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 (2NF)
• Disallows partial dependency
• 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 (2NF)
Stdno Course_no Mark CourseName StdName
Course Course_no CourseName
Student Stdno StdName
Std_marks Stdno Course_no Mark
Third Normal Form (3NF)
• Disallows transitive dependency
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.
Example (3NF)
A B C D
R1 C D
R2 A B C
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 “even if A is a prime attribute”
• 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)
R in 3rd NF but
not in BCNF
R SID Major Advisor Maj_GPA
SID Advisor Maj_GPA Advisor Major
A B C D E
2NF R1 A B E
2NF R2 B C D
2NF, 3NF R1 A B E
2NF R2 B C D
3NF R3 C D
3NF R4 B C
3NF R1 A B E
3NF R3 C D
3NF R4 B C
3NF R1 A B E
BCNF R5 B E
BCNF R6 A E
BCNF R3 C D
BCNF R4 B C
