DBMS module 2.

Functional Dependency

Database Engineering 4th CSE

 FD
• Functional Dependencies are constraints in the set of legal
relations.
• It plays an important role in database design.
• FDs are constraints that are derived from the meaning
and interrelationships of the data attributes.
• FD is denoted by X  Y, between two sets of attributes X
and Y. we say that “X (functionally) determines Y”
• X may also be called a determinant

Database Engineering 4th CSE

 FD
• A set of attributes X functionally determines a set of
attributes Y if the value of X determines a unique value for
Y
• X Y holds if whenever two tuples have the same value for
X, they must have the same value for Y
If t1[X]=t2[X], then t1[Y]=t2[Y] in any relation instance
r(R)
• X  Y in R specifies a constraint on all relation instances
r(R)
• FDs are derived from the real-world constraints on the
attributes

Database Engineering 4th CSE

 SSN EName PNumber PName PLocation Hour age

0001 Ram A123 Security BBSR 8 29

0002 Ravi A123 Security BBSR 5 30
0003 Shyam B231 DBA RKL 9 28
0001 Ram B231 DBA RKL 4 29
0002 Ravi B231 DBA RKL 5 30
0002 Ravi A123 Security BBSR 6 30

Database Engineering 4th CSE

 Example of FD
• 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

Database Engineering 4th CSE

 Alternate definition of FD
• R satisfies X → Y if whenever two tuples in
any instance of R have the same X-value,
they must also have the same Y-value.
• R satisfies X → Y if each distinct X-value
corresponds to a unique Y-value in any r(R).

Database Engineering 4th CSE

 Which FD is satisfied?
• Which FD does R(A, B, C, D) satisfy, if the
following instance is the only instance of R?
D → B,
R
A B C D A → C,
A1 B1 C1 D1 AB → D
A1 B2 C1 D2
A2 B2 C2 D2
A2 B3 C2 D3
A3 B3 C2 D4

Database Engineering 4th CSE

 Full Functional Dependency
• A full functional dependency occurs when you already
meet the requirements for a functional dependency and
the set of attributes on the left side of the functional
dependency statement cannot be reduced any farther.
• Given a relation R and Functional Dependency X→Y
Y is fully functionally dependent on X and there should
not be any Z→Y, Where Z is a proper subset of X.
• For example, “{SSN, age} -> name” is a functional
dependency, but it is not a full functional dependency
because you can remove age from the left side of the
statement without impacting the dependency
relationship.

Database Engineering 4th CSE

 Trivial FD
• A functional dependency FD: X → Y is
called trivial if Y is a subset of X.
• i.e Y ⊆ X.
• Example:
• A → A, AB → A

Database Engineering 4th CSE

 Inference Rules for FDs
• Given a set of FDs F, we can infer additional FDs
that hold whenever the FDs in F hold
• Armstrong's inference rules also called
Armstrong’s axioms
A1. (Reflexive) If Y ⊆ X, then X  Y
A2. (Augmentation) If X  Y, then XZ  YZ
(Notation: XZ stands for X U Z)
A3. (Transitive) If X  Y and Y  Z, then X  Z
• A1, A2, A3 form a sound and complete set of
inference rules

Database Engineering 4th CSE

 Armstrong's Axioms
1. Reflexivity Rule
– If X is a set of attributes and Y is a subset of X, then
X → Y holds.
– Each subset of X is functionally dependent on X.
2. Augmentation Rule
– If X → Y holds and W is a set of attributes, then
WX → WY holds
– If Y is determined by X then a set of attributes W and Y
together will be determined by W and X together
3. Transitivity Rule
– If X → Y and Y → Z hold, then X → Z holds
– If X functionally determines Y and Y functionally
determines Z then X functionally determines Z.

Database Engineering 4th CSE

 Additional Useful Inference Rules
1. Decomposition
– If X  YZ is FD, then X  Y and X  Z are
FD
2. Union
– If X  Y and X  Z, then X  YZ is FD
3. Psuedotransitivity
– If X  Y is FD and WY  Z is FD, then WX 
Z is FD

Database Engineering 4th CSE

 Closure of a set of FD
• Let F be a set of functional dependencies.
The closure of F is the set of all functional
dependency logically implied by F.
+
• We denote the closure of F by F .
+
• We can find the F given F by using the
Inference rules.

Database Engineering 4th CSE

 • R=(A, B, C, D, E) and FDs are:
A → BC
CD → E
B→D
E→A
Sol:
E → A, A → BC ,so E → BC using transitivity rule.
CD→ E, E → A ,so CD → A using transitivity rule.
A→ BC, A → B ,so A → C using decomposition rule.
B → D, CD → E ,so BC → E using pseudotransitivity.

Database Engineering 4th CSE

 Compute the closure of given set
• Closure of Attribute Sets:
• Let R is a relation schema with set of FDs F.
• Let X is a set of attributes
• The closure of attribute set X under a set of
+
F and it denoted by X

Database Engineering 4th CSE

 Compute the closure of given set
Algorithm of X + based on F
Input: A set of FDs and set of attribute X.
Output: The closure of X i.e. X + under F
set Result = X
Repeat until Result doest not change.
For each FD A → B in F
If A ⊆ Result then
Result = Result ∪ B
end

Database Engineering 4th CSE

 Compute the closure of given set
• R=(A, B, C, D, E) and FDs are:
A → BC
CD → E
B→D
E→A
find Closure of A, B, C, D, CD
+
Sol: A = {A, B, C, D, E}
+
B = {B, D}
+
C = {C}
+
D = {D}
+
CD = {C, D, E, A, B}

Database Engineering 4th CSE

 Compute the closure of given set
• R=(A, B, C, G, H, I) and FDs are:
A→B
A→C
CG → H
CG → I
B→H
find Closure of A, B, CG
+
Sol: A = {A, B, C, H}
+
B = {B, H}
+
CG = {C, G, H, I}

Database Engineering 4th CSE

 Compute Candidate Key
• Determine each set of attribute X for which
the left hand side of any FD in F must be a
subset of X.
+
• Compute X under the given set of FD in F.
+
• If X = {R} then X is a candidate key of R .

Database Engineering 4th CSE

 Example
• R=(A, B, C, D, E, F, G, H, I, J) and FDs are:
A B→ C
A → DE
B→ F
F → GH
D→IJ
find the candidate key of R
Sol: A + = {A, D, E, I, J}
B + = {B, F, G, H}
D + = {D, I, J}
F + = {F, G, H}
AB + = {A, B,C, D, E, F, G, H, I, J} //AB is the candidate key

Database Engineering 4th CSE

 Prime and Non Prime Attribute
• An attribute A in a relation schema R is a
prime attribute if A is part of any candidate
key of the relation .
• If A is not part of any candidate key of R,
then A is called non prime attribute or non
prime.

Database Engineering 4th CSE

 Partial Dependency
• If any proper subsets of the key determine any of
the non-key attributes then there exist a partial
dependency.
• Example: Given A relation R(A,B,C,D,E) , Functional
Dependency : AB→CDE , Primary key(key) is AB.
• Then A→C : is a Partial Dependency
A→D : is a Partial Dependency
A→E : is a Partial Dependency
B→C : is a Partial Dependency
B→D : is a Partial Dependency
B→E : is a Partial Dependency

Database Engineering 4th CSE

 Nonredundant Covers
• Let R is a relation schema with a set of FDs
F. Assume X → Y is a FD.
+ +
• Find out X under {F-(X → Y) FD, If X = {R }
then X → Y is redundant and remove the
redundant FD from F we got nonredundant
cover .

Database Engineering 4th CSE

 Example
• R=(A, B, C, D, E, H) and FDs are:
A → BC
CD → E
E→ C
D → AEH
ABH → BD
DH →BC
find out non redundant cover
Sol: for CD → E
+
CD under {F-(CD → E)} = {A, B,C, D, E, H} = {R} so CD → E is redundant
for DH →BC
DH + under {F-(DH →BC)} = {A, B,C, D, E, H} = {R} so DH →BC
is redundant

Database Engineering 4th CSE

 Canonical Cover
• Sets of functional dependencies may have
redundant dependencies that can be inferred from
the others
– For example: A → C is redundant in: {A → B, B → 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

Database Engineering 4th CSE

 Extraneous Attributes
• Consider a set F of functional dependencies
and the functional dependency α → β in F.
– Attribute A is extraneous in α if A ∈ α
and F logically implies (F – {α → β}) ∪ {(α – A)
→ β}.
– Attribute A is extraneous in β if A ∈ β
and the set of functional dependencies
(F – {α → β}) ∪ {α →(β – A)} logically implies F.
• Note: implication in the opposite direction is
trivial in each of the cases above, since a
“stronger” functional dependency always
implies a weaker one
Database Engineering 4th CSE
 Extraneous Attributes
• Example: Given F = {A → C, AB → C }
– B is extraneous in AB → C because {A → C,
AB → C} logically implies A → C (I.e. the
result of dropping B from AB → C).
• Example: Given F = {A → C, AB → CD}
– C is extraneous in AB → CD since AB → C
can be inferred even after deleting C

Database Engineering 4th CSE

 Testing if an Attribute is Extraneous
• Consider a set F of functional dependencies and the
functional dependency α → β in F.
• To test if attribute A ∈ α is extraneous in α
1. compute ({α} – A)+ using the rest of dependencies in F
2. check that ({α} – A)+ contains β; if it does, A is
extraneous in α
• To test if attribute A ∈ β is extraneous in β
1. compute α+ using only the dependencies in
F’ = (F – {α → β}) ∪ {α →(β – A)},
2. check that α+ contains A; if it does, A is extraneous in β

Database Engineering 4th CSE

 Canonical Cover
• A canonical cover for F is a set of dependencies Fc such that
– F logically implies all dependencies in Fc, and
– Fc logically implies all dependencies in F, and
– No functional dependency in Fc contains an extraneous attribute,
and
– Each left side of functional dependency in Fc is unique.
• To compute a canonical cover for F:
repeat
Use the union rule to replace any dependencies in F
α1 → β1 and α1 → β2 with α1 → β1 β2
Find a functional dependency α → β with an
extraneous attribute either in α or in β
If an extraneous attribute is found, delete it from α → β
until F does not change
• Note: Union rule may become applicable after some extraneous
attributes have been deleted, so it has to be re-applied

Database Engineering 4th CSE

 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

Database Engineering 4th CSE

 Canonical Cover or minimal cover
• R=(A, B, C, D, E, H) and FDs are:
A → BC
CD → E
E→ C
D → AEH
ABH → BD
DH →BC
find out canonical cover
Sol: 1. remove redundant
2. Decomposition
3. Remove extraneous attribute

Database Engineering 4th CSE

 • R = (A, B, C, D)
F = {A → BC
B→C
A→B
AB → C
AC → D}

Sol: B→C
A→B
AC → D

Database Engineering 4th CSE

 Definition of Decomposition
Let R be a relation schema
A set of relation schemas { R1, R2,…, Rn } is a
decomposition of R if
 R = R1 U R2 U …..U Rn
 each Ri is a subset of R ( for i = 1,2…,n)

Database Engineering 4th CSE

 Example of Decomposition
• For relation R(x,y,z) there can be 2 subsets:
• R1(x,z) and R2(y,z)
• If we union R1 and R2, we get R
• R = R1 U R2

Database Engineering 4th CSE

 Goal of Decomposition
• Eliminate redundancy by decomposing a
relation into several relations in a higher
normal form.
• It is important to check that a
decomposition does not lead to bad design

Database Engineering 4th CSE

 Problem with Decomposition
• Given instances of the decomposed
relations, we may not be able to reconstruct
the corresponding instance of the original
relation – information loss

Database Engineering 4th CSE

 Example : Problem with Decomposition
R
Model Name Price Category
a11 100 Canon
s20 200 Nikon
a70 150 Canon

R1 R2
Model Name Category Price Category

a11 Canon 100 Canon

s20 Nikon 200 Nikon

a70 Canon 150 Canon

Database Engineering 4th CSE

 Example : Problem with Decomposition
R1 R2 Model Name Price Category
a11 100 Canon
a11 150 Canon
s20 200 Nikon
a70 100 Canon
a70 150 Canon

R Model Name Price Category

a11 100 Canon
s20 200 Nikon
a70 150 Canon

Database Engineering 4th CSE

 Lossy decomposition
• In previous example, additional tuples are
obtained along with original tuples
• Although there are more tuples, this leads to
less information
• Due to the loss of information,
decomposition for previous example is
called lossy decomposition or lossy-join
decomposition

Database Engineering 4th CSE

 Lossy decomposition (more example)
T Employee Project Branch
Brown Mars L.A.
Green Jupiter San Jose
Green Venus San Jose
Hoskins Saturn San Jose
Hoskins Venus San Jose

Functional dependencies:

Employee Branch, Project Branch

Database Engineering 4th CSE

 Lossy decomposition
Decomposition of the previous relation
T1 T2

Employee Branch Project Branch

Mars L.A.
Brown L.A
Jupiter San Jose
Green San Jose
Saturn San Jose
Hoskins San Jose Venus San Jose

Database Engineering 4th CSE

 Lossy decomposition
After Natural Join Original Relation

Employee Project Branch Employee Project Branch

Brown Mars L.A. Brown Mars L.A.
Green Jupiter San Jose Green Jupiter San Jose
Green Venus San Jose Green Venus San Jose
Hoskins Saturn San Jose Hoskins Saturn San Jose
Hoskins Venus San Jose Hoskins Venus San Jose
Green Saturn San Jose
Hoskins Jupiter San Jose

After Natural Join, we get two extra tuples. Thus, there is loss of information.

Database Engineering 4th CSE

 Lossless Decomposition
A decomposition {R1, R2,…, Rn} of a
relation R is called a lossless decomposition
for R if the natural join of R1, R2,…, Rn
produces exactly the relation R.

Database Engineering 4th CSE

 Lossless Decomposition
A decomposition is lossless if we can recover:

R(A, B, C)
Decompose
R1(A, B) R2(A, C)
Recover
R’(A, B, C)

Thus, R’ = R

Database Engineering 4th CSE

 Lossless Decomposition Property
R : relation
F : set of functional dependencies on R
X,Y : decomposition of R
Decomposition is lossless if :
– X ∩ Y  X, that is: all attributes common to both X and Y
functionally determine ALL the attributes in X OR
– X ∩ Y  Y, that is: all attributes common to both X and Y
functionally determine ALL the attributes in Y

Database Engineering 4th CSE

 Lossless Decomposition Property
• In other words, if X ∩ Y forms a superkey of
either X or Y, the decomposition of R is a lossless
decomposition

Database Engineering 4th CSE

 Armstrong’s Axioms
X, Y, Z are sets of attributes

1. Reflexivity: If X ⊇ Y, then X → Y
2. Augmentation: If X → Y, then XZ → YZ for any Z
3. Transitivity: If X → Y and Y → Z, then
X→Z
4. Union: If X → Y and X → Z, then X → YZ
5. Decomposition: If X → YZ, then X → Y and
X→Z

Database Engineering 4th CSE

 Example : Lossless Decomposition
Given:
Lending-schema = (branch-name, branch-city, assets,
customer-name, loan-number, amount)
Required FD’s:
branch-name branch-city, assets
loan-number amount, branch-name
Decompose Lending-schema into two schemas:
Branch-schema = (branch-name, branch-city, assets)
Loan-info-schema = (branch-name, customer-name, loan-
number, amount)

Database Engineering 4th CSE

 Example : Lossless Decomposition
Show that decomposition is Lossless Decomposition

 Since branch-name branch-city assets, the

augmentation rule for FD implies that:
branch-name branch-name branch-city assets

 Since Branch-schema ∩ Loan-info-schema = {branch-name}

Thus, this decomposition is Lossless decomposition

Database Engineering 4th CSE

 Conclusions
• Decompositions should always be lossless
Lossless decomposition ensure that the
information in the original relation can be
accurately reconstructed based on the
information represented in the decomposed
relations.

Database Engineering 4th CSE

 Dependency Preservation

Database Engineering 4th CSE

 Why Do We Preserve The Dependency?

• We would like to check easily that updates to

the database do not result in illegal relations
being created.

• It would be nice if our design allowed us to

check updates without having to compute
natural joins.
Database Engineering 4th CSE
 Definition

• A decomposition D = {R1, R2, ..., Rn} of R is

dependency - preserving with respect to F if
the union of the projections of F on each Ri
in D is equivalent to F; that is
if (F1 ∪ F2 ∪ … ∪ Fn )+ = F +

Database Engineering 4th CSE

 In Layman’s Term

• Each Functional Dependency specified in F either

appears directly in one of the relations in the
decomposition.

DBMS 5th SEM ETC & EEE

 Continue…
• It is not necessary that all dependencies
from the relation R appear in some relation
Ri. It is sufficient that the union of the
dependencies on all the relations Ri be
equivalent to the dependencies on R.

DBMS 5th SEM ETC & EEE

 Property of Dependency-Preservation
• If a decomposition is not dependency-preserving,
therefore, that dependency is lost in the
decomposition.

FD3

FD3
FD1

FD2

DBMS 5th SEM ETC & EEE

 Example of Dependency Preservation

• R(A B C D)

• FD1: A  B
• FD2: B  C
• FD3: C  D

• Decomposition:
R1(A B C) R2(C D)

DBMS 5th SEM ETC & EEE

  FD1: A  B
 FD2: B  C
 FD3: C  D

R1( A B C )
FD1

FD2

DBMS 5th SEM ETC & EEE

  FD1: A  B
 FD2: B  C
 FD3: C  D

R2( C D )
FD3

DBMS 5th SEM ETC & EEE

 • FD1: A  B
• FD2: B  C
• FD3: C  D

FD1 FD3

R1 ( A B C ) R2 ( C D )
FD2

Has all 3 functional dependencies!

Therefore, it’s preserving the dependencies

DBMS 5th SEM ETC & EEE

 Example of Non-Dependency Preservation

• R(A B C D)

• FD1: A  B
• FD2: B  C
• FD3: C  D

• Decomposition:
R1(A C D) R2(B C)

DBMS 5th SEM ETC & EEE

  FD1: A  B
 FD2: B  C
 FD3: C  D

R1( A C D )
FD3

DBMS 5th SEM ETC & EEE

  FD1: A  B
 FD2: B  C
 FD3: C  D

R2( B C )
FD2

DBMS 5th SEM ETC & EEE

 • FD1: A  B
• FD2: B  C
• FD3: C  D

FD3 FD2

R1 ( A C D ) R2 ( B C )

Does not support FD1: A => B

Therefore, it does not preserve the dependencies

DBMS 5th SEM ETC & EEE

 More Example

• R(A B C D E)

• FD1: A  B
• FD2: BC  D

• Decomposition:
R1(A C E) R2(B C D) R3(A B)

DBMS 5th SEM ETC & EEE

  FD1: A  B
 FD2: BC  D

R1( A C E )
No Dependencies

DBMS 5th SEM ETC & EEE

  FD1: A  B
 FD2: BC  D

R2( B C D )
FD2

DBMS 5th SEM ETC & EEE

  FD1: A  B
 FD2: BC  D

R3( A B )
FD1

DBMS 5th SEM ETC & EEE

 • FD1: A  B
• FD2: BC  D

FD2

R1( A C E ) R2( B C D )

R3 ( A B )
FD1

Has all 2 functional dependencies!

Therefore, it’s preserving the dependencies

DBMS 5th SEM ETC & EEE

 Exercise Problem

DBMS 5th SEM ETC & EEE

 • R(A, B, C, D, E, F )

• FD1: D  A, B
• FD2: C  E, F

• Decomposition:
R1( A, C, D )
R2( A, D, B )
R3( D, E, F )
R4( C, E, F )

DBMS 5th SEM ETC & EEE

 R1 ( A C D) FD1: D  A, B
FD2: C  E, F

R2 ( A D B)
FD1

R3 ( D E F)
FD2

R4 ( C E F)
DBMS 5th SEM ETC & EEE