DBMS

Unit-3
Functional Dependencies
Dr. D. SUDHEER
Assistant Professor
Department of CSE
VNR VJIET (NAAC: A++, NIRF: 113)
Hyderabad, Telangana.
The Problems of Redundancy
⚫ Redundancy: root of several problems
with relational schemas:
◦ redundant storage, insert/delete/update
anomalies
EID Name DeptID DeptName
A01 Ali 12 Wing
EmpDept A12 Eric 10 Tail
A13 Eric 12 Wing
A03 Tyler 12 Wing
What anomalies are associated with EmpDept?
⚫Update Anomalies: If one copy of such repeated data
is updated, an inconsistency is created unless all
copies are similarly updated.
⚫Can we change DeptName of DeptID 12 in the first
tuple? We should repeat the same for all tuples.
⚫ Insertion Anomalies: Cannot insert a department
unless an employee is assigned to it. It may not be
possible to store certain information unless some
other, unrelated, information is stored as well.
⚫Deletion Anomalies: If we delete record of A12 then
the Department 10 no longer exists.
 Functional Dependencies: Introduction

Formal Definition:
• Functional dependency in DBMS, as the name suggests
is a relationship between attributes of a table
dependent on each other.

• A Functional Dependency (FD) is basically a many to

one relationship from one set of attribute to another
within a given relation variable.
(Ref: An Introduction to database systems, C.J. Date, 8 th edition pg.
333)

• Introduced by E. F. Codd, it helps in preventing data

redundancy and gets to know about bad designs.
• Functional Dependency is represented by -> (arrow
sign)
• To understand the concept thoroughly, let us consider
P is a relation with attributes A and B.
• The following represents the FD between attributes:

FD: A->B (B - Functionally Dependent on A)

A – Determinant set
B – Dependent Attribute.
 Basic Definitions

• Let r be a relation, and let X and Y be a arbitrary subset of the set of

attributes of r then we say Y is functionally dependent on X.
X -> Y
Ex: {S#} -> {city}, {QTY} -> {S#}
• The constraint is that for any two tuples t1 and t2 that
have t1[X]=t2[X], they must also have t1[Y]=t2[Y].
• We say that there is a functional dependency from X
to Y or Y is functionally dependent on X

Types: 1. Trivial Functional Dependency

2. Non-Trivial Functional Dependency
3.Completely Non-Trivial Functional Dependency
 Trivial Functional Dependency

• An FD is trivial if and only if the right side is subset of left side arrow.
Ex1: {S#, P#} -> {S#}
Ex2: {DeptId, DeptName} -> {DeptId}

Non Trivial Functional Dependency

It occurs when B is not a subset of A in −

A -> B
Ex: DeptId -> DeptName

Completely Non - Trivial Functional Dependency

It occurs when A intersection B is null in −
A -> B
 Armstrong’s Axioms Property of F D
Armstrong’s Axioms property was developed by
William Armstrong in 1974 to reason about functional
dependencies.

• Transitivity: If A->B and B->C, then A->C i.e. a

transitive relation.
• Reflexivity: A-> B, if B is a subset of A.
• Augmentation: The last rule suggests: AC->BC, if A->B
Several other rules can be derived from the above
three:
Self – determination: A -> A,
Decomposition: if A-> BC, then A->B, and A-> C.
Union: if A->B, A->C, then A->BC.
 Closure set of dependencies:
• The set of all FDs that implied by a given set of S is
called as closure of S denoted by S+ .
• Let R be the relation variable with attributes as
R(A,B,C,D,E)
FD{A->B,B->C,C->D,D->E}
Closure set of dependencies:
A->A self – determintion.
A->C Transitivity
A->BC Union
AC->BD Composition
AC->BC Augmentation
A->B, A->C Decomposition
 Closure set of attributes:
• We can compute the closure set of attributes S+ of a
given set of S of FDs (repeatedly apply the rules until
they stop producing new FDs)
 Transitive dependency:
• When an indirect relationship causes functional
dependency it is called Transitive Dependency.
 Schema Refinement

• The Schema Refinement refers to refine the schema by

using some technique.
• The best technique of schema refinement is
decomposition.
• Normalization or Schema Refinement is a technique
of organizing the data in the database.
• It is a systematic approach of decomposing tables to
eliminate data redundancy.
• It is also used to eleminate undesirable characteristics
like Insertion, Update and Deletion Anomalies.
 Decomposition: A good solution
• The standard solution to the redundancy problem is to
decompose redundant schemas, e.g., EmpDept becomes

EID Name DeptID Dept

A01 Ali 12
Emp A12 Eric 10 DeptID DeptName
A13 Eric 12 12 Wing
A03 Tyler 12 10 Tail
⚫ The first problem students usually identify with the
EmpDept schema is that it combines two different
ideas: employee information and department
information. But what is wrong with this?
1. If we separated the two concepts we could save
space.
2. Combining the two ideas leads to some bad
anomalies.
⚫ These two problems occur because DeptID
determines DeptName, but DeptID is not a key.
Problems related to decomposition
What problem(if any) does the given decomposition
cause?
2 properties are important

Lossless-join property
It enables us to recover any instance of decomposed
relation from the corresponding instance of the
smaller relations.

Dependency preservation property

It enables us to enforce any constraint on the original
relation by simply enforcing some constraints on each
 1NF

• each attribute should contain atomic values.

• each column should contain same domain values.
• each column should have unique name.
• no ordering to rows and columns.
• remove composite or multi-valued attribute.
 2NF

• It should be in 1 NF.
• To be in second normal form, a relation must be in first normal form
and relation must not contain any partial dependency.

Partial Dependency – If the proper subset of candidate key

determines non-prime attribute, it is called partial dependency.
 3NF

• A relation is in third normal form, if there is no

transitive dependency for non-prime attributes as well
as it is in second normal form.
• A relation is in 3NF if at least one of the following
condition holds in every non-trivial function
dependency X –> Y :

* X is a super key.
* Y is a prime attribute (each element of Y is
part of some candidate key).
• (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE,
STUD_COUNTRY_STUD_AGE) as:

• STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE,

STUD_AGE)

• STATE_COUNTRY (STATE, COUNTRY)

 BCNF

• 3NF failed to handle if composite candidate key attributes are

overlapped.
• It is defined by Boyce and Codd, so named as Boyes Codd Normal
Form (BCNF).
• It is more strict version of 3NF.
• The determinant of FD should be a superkey.
• For BCNF, the table should be in 3NF, and for every FD, LHS is super
key.

• X->Y (in BCNF iff X is super key).

 4NF

• It should be in BCNF.
• Table should not contain multi valued dependency.

Multi valued dependency (mvd):

• For multi valued dependency A->-> B, there will be multiple values
for single determinant value of A.
• mvd exists with a relation of at least 3 columns.
• For relation R (A,B,C) exists mvd A->->B, iff B and C are
independent each other.
• There can be functional dependencies along with mvd.
Then need to decompose the functional dependencies into a
separate relation.
 S.Id Course Hobby Address
1 DBMS Cricket Hyd
1 DBMS Tennis Hyd
1 JAVA Cricket Hyd
1 JAVA Tennis Hyd
2 DBMS Cricket Warangal
2 DBMS Tennis Warangal
2 JAVA Cricket Warangal
2 JAVA Tennis Warangal
4NF decomposition
S.ID Course S.ID Hobby S.Id Address
1 DBMS 1 Cricket 1 Hyd
1 JAVA 1 Tennis 2 Warangal
2 DBMS 2 Cricket
2 JAVA 2 Tennis
 Summary

• The purpose of normalization is to group attributes into

relations to minimize data redundancy.
• Codd (1970, 1971) proposed the concept of
normalization by introducing 1NF (first normal form),
followed by 2NF (second normal form), and 3NF (third
normal form).
• Together with Raymond F. Boyce, Codd (1974) defined
BCNF ( Boyce-Codd normal form).
• Fagin (1977) introduced 4NF (fourth normal form)
followed by 5NF (fifth normal form) in 1979.
• In practice, the normalization process to 3NF is good
enough to reduce data redundancy.
• Higher normal forms usually increase join-operations, which reduces
performance without any added value in reducing data redundancy.