DATABASE MANAGEMENT

SYSTEM

Dr. Mageshwari V
Assistant Professor
Department of Mathematics
Amrita Vishwa Vidyapeetham
 F U N C T I O NA L
D E P E N DA N C Y &
DECOMPOSITION

1
F U N C T I O N A L D E P E N DA N C Y &
DECOMPOSITION

1. Basics of Functional Dependency

2. Functional dependency diagram and examples
3. Full function dependency (FFD)
4. Armstrong’s Axioms for functional dependencies
5. Redundant functional dependencies
6. Closures of a set of functional dependencies
7. Lossy Decomposition
2 8. Lossless join decomposition
9. Dependency-Preserving Decomposition
BASICS O F FU N C TI ONAL D E P E N D E N C Y

 Functional dependency is a relationship that exists when one

attribute uniquely determines another attribute.
 A functional dependency is an association between two

attributes of the same relational database table.

 One of the attributes is called the determinant and the

other
attribute is called the determined.
 For each value of the determinant there is associated one

and
only one value of the determined.
 If A is the determinant and B is the determined then we say that A
4
functionally determines B and graphically represent this as
A -> B. can also be expressed as B is functionally determined by A.
 Since for each value of A there
is associated one and only one
value of B.

5
 Since for A = 3 there is associated
more than one value of B.
 Functional dependency can also

be defined as follows:
 An attribute in a relational model

is said to be functionally
dependent on another attribute
in the table if it can take only one
value for a given value of the
attribute upon which it is
functionally dependent.
6
FU N C TI O NA L D E P E N D E N C Y DIAGRAM AND
EXAMPLES

7
 Here in Supplier table

Sno - Supplier number of supplier that is

unique
Sname - Supplier name
City - City of the supplier
Status - Status of the city
e.g. A grade cities
may have status
10,
B grad cities may 8

have status 20 and

 Here, Sname is F D on Sno. Because, Sname can take only one
value for the given value of Sno.
 F D is represented as:

Sno -> Sname

 F D is shown by “->” which means that Sname is functionally

dependent on Sno.
 Similarly, city and status are also F D on Sno, because for each

value of Sno there will be only one city and status.

 F D is represented as:

Sno - > City

Sno - > Status 8
 D E P E N D E N C Y DIAGRAMS

 A dependency diagram consists of The dependency diagram of Supplier

the attribute names and all table is.
functional dependencies in a
given table.
 Here, following functional
dependencies exist in supplier
table
Sno -> Sname
Sname -> Sno
Sno -> City
Sno -> Status
Sname -> City
Sname -> Status
City -> Status
 The F D diagram of relation P
is shown in diagram.
 Here following functional

dependencies exist in Part

table:

 Pno -> Pname

 Pno -> Color

 Pno -> Wt

11
 The F D diagram of relation
Shipment is shown in diagram.
 Here following functional

dependencies exist in parts

table

S P (Sno, Pno) -> SP.QT Y

12
F U L LY F U N C T I O N D E P E N D E N C Y (FDD)
 The term full functional dependency (FFD) is used to indicate the
minimum set of attributes in of a functional dependency (FD).
 In other words, the set of attributes X will be full functionally
dependent on the set of attributes Y if the following conditions
are satisfied:
 X is functionally dependent on Y and
 X is not functionally dependent on any subset of Y.

Example:
 Let R be
Student(stuId, Name, branch)
 FDs in R include

{stuId}→{Name}, but not the reverse 12

PARTIAL F U N C T I O N D E P E N D E N CY
 Let us assume a relation R with attributes A, B, C , and D. Also,
assume that the set of functional dependencies F that hold on R as
follows;
F = {A → B, D → C}
 From set of attributes F, we can derive the primary key.

 For R, the key can be (A,D), a composite primary key.

 That means, A D → B C , A D can uniquely identify B and C .

 To identify B, attribute A is enough.

 Likewise, to identify C , attribute D is enough.

 The functional dependencies A D → B or A D → C are called as

Partial functional dependencies. 13

 Full Functional Dependency : In a relation , there exists Full
Functional Dependency between any two attributes X and Y, when X
is functionally dependent on Y and is not functionally dependent on any
proper subset of Y.
 Partial Functional Dependency : In a relation, there exists Partial
Dependency, when a non prime attribute (the attributes which are not a
part of any candidate key ) is functionally dependent on a proper subset
of Candidate Key.
 example : Let there be a relation R ( Course, Sid , Sname , schedule
, room , marks )
 Full Functional Dependencies : (Course , Sid) -> Sname ,
(Course , Sid) -> Marks, etc.
 Partial Functional Dependencies : Course -> Schedule ,
14
Course -> Room
TRIVIAL DEPENDENCY
 Consider a table with two columns Student_id and Student_Name.
 {Student_Id, Student_Name} -> Student_Id is a trivial

functional dependency as Student_Id is a subset of

{Student_Id, Student_Name}.
 That makes sense because if we know the values of Student_Id and

Student_Name then the value of Student_Id can be uniquely

determined.
 Student_Id -> Student_Id & Student_Name -> Student_Name are

trivial dependencies too.

16
NON-TRIVIAL DE P E NDE NCY
 An employee table with three attributes: emp_id, emp_name,
emp_address.
The following functional dependencies are non-trivial:
emp_id -> emp_name (emp_name is not a subset of emp_id)
emp_id -> emp_address (emp_address is not a subset of
emp_id)
 On the other hand, the following dependencies are trivial:

{emp_id, emp_name} -> emp_name

 Here, emp_name is a subset of {emp_id, emp_name}

17
ARMSTRONG’S AXIOMS(RULES) FOR
FUNCTIONAL D E P E N D E N C I E S
 Armstrong's Axioms is a set of rules.
 It provides a simple technique for reasoning about functional

dependencies.
 It was developed by William W. Armstrong in 1974.

 There are two types of rules

1) Primary Rules and

2) Secondary Rules

18
PRIMARY RULES
Rule 1----------Reflexivity
 If A is a set of attributes and B is a subset of A, then A holds B.

{A → B }
Rule 2-------Augmentation
If A->B, then AC->B and A C → B C
 It means that attribute in dependencies does not change the basic

dependencies.
Rule 3--------Transitivity
 If A holds B and B holds C , then A holds C .

 If {A → B} and {B → C}, then {A → C}

18
 A holds B {A → B} means that A functionally determines B.
S E CO N DA RY RULES
 Rule 1 -----Union
If A holds B and A holds C , then A holds BC.
If{A → B} and {A → C}, then {A → BC}

 Rule 2 ------ Decomposition

If A holds B C and A holds B, then A holds C .
If{A → BC} and {A → B}, then {A → C}

 Rule 3 ------ Pseudo Transitivity

If A holds B and B C holds D, then A C holds
D. 20
If{A → B} and {BC → D}, then {AC → D}
REDUNDANT FUNCTIONAL D E P E ND E N CI E S

 A F D in the set is redundant, if it can be derived from the other

FDs in the set.
 Redundant F D can be detected by using Membership

algorithm.

 Example

 Suppose a relation R is given with attributes A, B, C , D, E .

Also, a set of functional dependencies F is given with following
FDs.
21

F = {A → B , C → D, B D → E , A C → E}
1. Find out whether a F D f: A C → E is redundant or not.

Step-1: F'= { A → B, C → D, B D → E} # F' = F – f

Step-2: T = AC # set T = determinant of A C → E

Step-3: T = A C + B = AC B # A → B is in F’ and A ⊆T

T = ACB+D=ACB D # C → D is in F’ and C ⊆
T

T = AC B + E = AC B D E # A C → E is in F’ and A C
⊆T 21

Step-4: f: A C → E is redundant. #E ⊆T
2. Find out whether a F D f: B D → E is redundant or not.

Step-1: F'= { A → B, C → D, AC → E} # F' = F – f

Step-2: T = B D # set T = determinant of BD→ E

Step-3: Nothing can be added to T, As there is no other FD:X → Y

such that X ⊆ T

Step-4: f: B D → E is not redundant. # E is not contained in T

 C L O S U R E S O F A SET O F FUNCTIONAL
D E P E ND E N C I E S

 A closure of a set of FDs is a set of all possible FDs that can be derived
from a given set of FDs. It is also referred as a complete set of FDs.
 If F is used to denote the set of FDs for relation R , then a closure of a set
of FDs implied by F is denoted by F + .

 Example

Consider the following relation schema

Depositer_Account(cid, ano, acess_date, balance, bname).
For this relation, a set of functional dependencies F can be given
as
F = { {cid, ano } → access_date , ano → { balance, bname } 22

}
 Determine each set of attributes X that appears as a left-hand side of F D
in F. { cid, ano } and ano.
Find out { cid, ano }+
Step-1 : { cid, ano }+ = { cid, ano }
Step-2 : { cid, ano }+ = { cid, ano, acess_date } # {cid, ano} ⊆ X +
{ cid, ano }+ = { cid, ano, acess_date, balance, bname } # ano ⊆ X +
Step-3: { cid, ano }+ = { cid, ano, acess_date, balance, bname }

 Find out ano +

Step-1: ano+ = ano
Step-2: ano + = { ano, balance, bname } # ano ⊆ X +
Step-3: ano+ = { ano, balance, bname } 23
 Combine all such sets of X + to form a closure of F .

{ cid, ano }+ = { cid, ano, acess_date, balance, bname }

ano + = { ano, balance, bname }

26
DECOMPOSITION
 A decomposition of a relation can be either lossy decomposition or
lossless join decomposition.

 There are two types of decomposition

⚫ Lossy Decomposition
⚫ Lossless J o i n Decomposition

27
L O S SY DECOMPOSITION

 The decomposition of relation R into R1 and R2 is lossy when the

join of R1 and R2 does not yield the same relation as in R .

 This is also referred as lossy-join decomposition.

 The disadvantage of such kind of decomposition is that some

information is lost during retrieval of original relation. And so,
such kind of decomposition is referred as lossy decomposition.

 From Practical Point of view, decomposition should not be lossy

decomposition. 26
29
L O S S L E S S J O I N DECOMPOSITION
 The decomposition of relation R into R1 and R2 is lossless when
the join of R1 and R2 produces the same relation as in R .

 This is also referred as non-additive decomposition. All

decompositions must be lossless.

30
31
DEPENDENCY- P R E SE RVI N G
DECOMPOSITION
 When any relation is decomposed, illegal relations should not be
created. A relation is an illegal relation, if it does not preserve
given functional dependencies.

 A relation R is decomposed into the relation schema R1, R2, ... ,

R n with the functional dependencies F1,F2, .. ,Fn. Let F' = F1 U
F2 U... U Fn.

 This decomposition is dependency preserving decomposition, if

closure of F' is identical to F + , i.e F' + = F + .

 Here, closure is considered rather than simple set of FDs. Because

even if F' ≠ F . It may be that, F' + = F + . 30
EXAMPLE

 Let a relation R (A,B,C,D)and a set of FDs F = { A->B,A->C,C->D}

are given.
 A relation is decomposed into -

R1 = (A, B, C) with FDs F1 = {A->B, A->C}.

R2 = (C, D) with FDs F2 = {C->D}.

F' = F1 U F2 = {A->B, A->C, C->D}

So, F'= F .
And so, F' + = F + .

31
 Thus, the decomposition is dependency preserving decomposition.
32