DATA BASE MANAGEMENT SYSTEMS

UNIT-IV
 Schema Refinement (Normalization)
• Purpose of Normalization or schema refinement:
Normalization is a process of organizing the data
in database to avoid data redundancy, insertion
anomaly, update anomaly & deletion anomaly.
• Redundancy means having multiple copies of
same data in the database.

• Let’s discuss about anomalies first then we will

discuss normal forms with examples.
 Anomalies in DBMS
• There are three types of anomalies that occur
when the database is not normalized.
• These are
Insertion anomaly.
update anomaly.
deletion anomaly.
Consider a Relation
 Insertion anomaly
• Insertion anomalies occur when inserting the
new record into the database table. In some
cases there is a chance to get null values
during insertion of row in the database table.
The problem in insertion anomaly is data
inconsistency. It is not possible to add a new
data when data value for a particular field is
not known.
• For example, assume Student_Group is
defined so that null values are not allowed. If
a new employee is hired but not immediately
assigned to a Student_Group then this
employee could not be entered into the
database. This results in database
inconsistencies due to omission.
 Update anomaly
• Update anomalies occur when data
redundancy in data values of a particular
attribute. Incorrect data in the table must
have to be changed. Change in single record
value does not make the data consistent.
There may be many records in a database
table which takes more time to modify the
values. If the modification is not done in all
the relevant rows the database will result in
data inconsistency.
• For example, If A. Bruchs’ department is an
error it must be updated at least 2 times or
there will be inconsistent data in the
database. If the user performing the update
does not realize the data is stored redundantly
the update will not be done properly.
 Deletion anomaly
• Deletion anomaly occurs when data is deleted
from database. It leads to loss of data from
rows and it is totally lost from database. It
causes the problem of loss of information and
makes the data inconsistent.
• For example, if the student group Beta Alpha
Psi disbanded and was deleted from the table
above, J. Longfellow and the Accounting
department would cease to exist. This results
in database inconsistencies and is an example
of how combining information that does not
really belong together into one table can
cause problems.
• Update, deletion, and insertion anomalies are
very undesirable in any database. Anomalies
are avoided by the process of normalization.
Concept of functional dependency
We can define functional dependency as:
• In a given relation R, X and Y are attributes.
Attribute Y is functional dependent on
attribute X if each value of X determines
exactly one value of Y. This is represented as :
X->Y
For all pairs of tuples t1 and t2 in the instance
such that t1[x] = t2[x], it is also the case that
t1[y] = t2[y]
 For Example,
• Consider the following relation :
• REPORT(Student#, Course#, CName, IName, Room#, Marks,
Grade)
• Where:
Student# - Student Number
Course# - Course Number
Cname - CourseName
Iname - Name of the instructor who delivered the
course
Room# - Room number which is assigned to respective
instructor
Marks - Scored in Course Course# by student Student#
Grade - Obtained by student Student# in course
Course #
• Student#, Course# together (called composite
attribute) defines EXACTLY ONE value of marks. This
can be symbolically represented as
Student#,Course# Marks
• This type of dependency is called functional
dependency. In above example Marks is functionally
dependent on Student#,Course#.
• Other Functional dependencies in above example:
Course# CName
Course# IName
IName Room#
Marks Grade
 Full functional dependency:
• Formal Definition of full functional dependency : In a given
relation R ,X and Y are attributes. Y is fully functionally
dependent on attribute X only if it is not functionally
dependent on sub-set of X. However X may be composite in
nature.
• In above example Marks is fully functional dependent on
{student#, Course#} and not on the sub set of Student#,
Course#. This means marks cannot be determined either by
student # or Course# alone. It can be determined by using
Student# and Course# together. Hence Marks is fully
functional dependent on student#, course#.
• Cname is not fully functionally dependent on {student#,
course#} because one of the subset course# determines the
Cname and Student# does not having role in deciding
Cname. Hence CName is not fully functional dependent on
student#, Course#.
 Partial Dependency:
• In the above relationship CName, IName, Room#
are partially dependent on composite attribute
{Student#, Course#} because Course# alone can
defines the CName, IName, Room#.
• Formal Definition of Partial dependency: In a
given relation R, X and Y are attributes .Attribute
Y is partially dependent on the attribute X only if
it is dependent on subset attribute X .
 Transitive Dependency:
• In above example , Room# depends on IName
and in turn depends on Course# .Here Room#
transitively depends on Course#.
Course# IName
IName Room#
• Similarly Grade depends on Marks, in turn
Marks depends on {Student#, Course#} hence
Grade Fully transitively depends on Student#
Course#.
Trivial and Non-trivial Functional
Dependency
Trivial − If a functional dependency (FD)
X → Y holds, where Y is a subset of X,
then it is called a trivial FD.

Non-trivial − If an FD X → Y holds, where

Y is not a subset of X, then it is called
a non-trivial FD.
 Find Closure
• The set of all those attributes which can be functionally
determined from an attribute set is called as a closure
of that attribute set.
• Closure of attribute set {X} is denoted as {X}+.

• Steps to Find Closure of an Attribute Set-

Step-01:
Add the attributes contained in the attribute set for
which closure is being calculated to the result set.
Step-02:
Recursively add the attributes to the result set which
can be functionally determined from the attributes
already contained in the result set.
• Example-

Consider a relation R ( A , B , C , D , E , F , G ) with

the functional dependencies-
A → BC
BC → DE
D→F
CF → G
Now, let us find the closure of some attributes
and attribute sets-
Closure of attribute A-

A+ = { A }
={A,B,C} ( Using A → BC )
= { A , B , C , D , E} ( Using BC → DE )
= { A , B , C , D , E , F} ( Using D → F )
= { A , B , C , D , E , F , G } ( Using CF → G )
Thus,
A+ = { A , B , C , D , E , F , G}

Closure of attribute D-

D+ = { D }
= { D , F } ( Using D → F )
We can not determine any other attribute using attributes D and F contained in the result set.
Thus,
D+ = { D , F }

Closure of attribute set {B, C}-

{ B , C }+= { B , C }
= {B , C, D , E} ( Using BC → DE )
= { B , C , D , E , F} ( Using D → F )
= { B , C , D , E , F , G } ( Using CF → G )
Thus,
{ B , C }+ = { B , C , D , E , F , G }
Finding the Keys Using Closure:
• Super Key-
If the closure result of an attribute set contains all the attributes of the
relation, then that attribute set is called as a super key of that relation.
Thus, we can say-
“The closure of a super key is the entire relation schema.”
Example-
In the above example, The closure of attribute A is the entire relation
schema. Thus, attribute A is a super key for that relation.

• Candidate Key-
If there exists no subset of an attribute set whose closure contains all the
attributes of the relation, then that attribute set is called as a candidate
key of that relation.
Example-
In the above example, No subset of attribute A contains all the attributes
of the relation. Thus, attribute A is also a candidate key for that relation.
A Candidate Key might be seen as a minimal Super Key, in terms of
attributes.
Problem-

Consider the given functional dependencies-

AB → CD
AF → D
DE → F
C→G
F→E
G→A

Which of the following options is false?

(A) { CF }+ = { A , C , D , E , F , G }
(B) { BG }+ = { A , B , C , D , G }
(C) { AF }+ = { A , C , D , E , F , G }
(D) { AB }+ = { A , C , D , F ,G }
Problem-

A relation R (A, B, C, D, E, F, G, H)and set of

functional dependencies are
CH → G,
A → BC,
B → CFH,
E → A,
F → EG
Then how many candidate keys are
present? What are those?
Relation R has eight attributes ABCDEFGH.
Fields of R contain only atomic values.

F = {CH -> G, A -> BC, B -> CFH, E -> A, F -> EG}

is a set of functional dependencies (FDs) so
that F+ is exactly the set of FDs that hold for
R.

How many candidate keys does the relation R

have?
•Example-1 : Let a Relation R have attributes {a1,a2,a3} and a1 is the
candidate key. Then how many super keys are possible? Here, any
superset of a1 is the super key. Super keys are = {a1, a1 a2, a1 a3, a1 a2
a3}
Thus we see that 4 Super keys are possible in this case.
•In general, if we have ‘N’ attributes with one candidate key then the
number of possible superkeys is 2(N – 1).

•Example-2 : Let a Relation R have attributes {a1, a2, a3,…,an}. Find

Super key of R. Maximum Super keys=2n – 1. If each attribute of
relation is candidate key.

•Example-3: Let a Relation R have attributes {a1, a2, a3,…, an} and the
candidate key is “a1 a2 a3” then the possible number of super
keys? Following the previous formula, we have 3 attributes instead of
one. So, here the number of possible super keys is 2(N-3).
Example-4: Let a Relation R have attributes {a1, a2,
a3,…, an} and the candidate keys are “a1”, “a2” then
the possible number of super keys?
This problem now is slightly different since we now
have two different candidate keys instead of only
one. Tackling problems like these is shown in the
diagram below:

→ |A1 A2| = |A1| + |A2| – |A ∩ A2| = (super keys

possible with candidate key A1) + (super keys
possible with candidate key A2) – (common
superkeys from both A1 and A2)
= 2(n-1) + 2(n-1) – 2(n-2)
Example-5: Let a Relation R have attributes {a1, a2, a3,…, an} and the
candidate keys are “a1”, “a2 a3” then the possible number of super
keys? Super keys of (a1) + Super keys of (a2 a3) – Super keys of (a1 a2
a3)
2(n – 1) + 2(n – 2) – 2(n – 3)

Let a Relation R have attributes {a1, a2, a3,…, an} and the candidate
keys are “a1 a2”, “a3 a4” then the possible number of super
keys? Super keys of(a1 a2) + Super keys of(a3 a4) – Super keys of(a1
a2 a3 a4)
2(n – 2) + 2(n – 2) – 2(n – 4)

Let a Relation R have attributes {a1, a2, a3,…, an} and the candidate
keys are “a1 a2”, “a1 a3” then the possible number of super
keys? Super keys of (a1 a2) + Super keys of (a1 a3) – Super keys of(a1
a2 a3)
2(n – 2) + 2(n – 2) – 2(n – 3)
Armstrong’s Axioms
 Canonical Cover OR Irreducible set
In DBMS,
•A canonical cover is a simplified and reduced version of
the given set of functional dependencies.
•Since it is a reduced version, it is also called
as Irreducible set.

Characteristics-

•Canonical cover is free from all the extraneous functional

dependencies.
•The closure of canonical cover is same as that of the
given set of functional dependencies.
Need-
•Working with the set containing extraneous functional
dependencies increases the computation time.
•Therefore, the given set is reduced by eliminating the
useless functional dependencies.
•This reduces the computation time and working with the
irreducible set becomes easier.
Steps To Find Canonical Cover-
Step-01:
Write the given set of functional dependencies in such a
way that each functional dependency contains exactly one
attribute on its right side.
Example- The functional dependency X → YZ will be
written as,
X→Y
X→Z
Step-02:
•Consider each functional dependency one by one from
the set obtained in Step-01.
•Determine whether it is essential or non-essential.
•Eliminate the non-essential functional dependency from
the set
Step-03:
•Consider the newly obtained set of functional
dependencies after performing Step-02.
•Check if there is any functional dependency that contains
more than one attribute on its left side.
• Find the extraneous attributes on the left hand side and
remove them.
Ex: AB->C {if closure of A contain B then remove B or vice
versa} Then result is A->C or B->C
Problem:

The following functional dependencies hold true

for the relational scheme R ( W , X , Y , Z ) –
X→W
WZ → XY
Y → WXZ
Write the canonical cover or irreducible
equivalent for this set of functional dependencies.
Step-01:
Write all the functional dependencies such that each
contains exactly one attribute on its right side-
X→W
WZ → X
WZ → Y
Y→W
Y→X
Y→Z
Step-02:
Check the essentiality of each functional dependency one by
one.

For X → W:

•Considering X → W, (X)+ = { X , W }
•Ignoring X → W, (X)+ = { X }

Now,
•Clearly, the two results are different.
•Thus, we conclude that X → W is essen al and can not be
eliminated.
For WZ → X:
•Considering WZ → X, (WZ)+ = { W , X , Y , Z }
•Ignoring WZ → X, (WZ)+ = { W , X , Y , Z }
Now,
•Clearly, the two results are same.
•Thus, we conclude that WZ → X is non-essential and can be
eliminated.
•Elimina ng WZ → X, our set of func onal dependencies
reduces to-
X→W
WZ → Y
Y→W
Y→X
Y→Z
Now, we will consider this reduced set in further checks.
For WZ → Y:
•Considering WZ → Y, (WZ)+ = { W , X , Y , Z }
•Ignoring WZ → Y, (WZ)+ = { W , Z }
Now,
•Clearly, the two results are different.
•Thus, we conclude that WZ → Y is essen al and can not be eliminated.

For Y → W:
•Considering Y → W, (Y)+ = { W , X , Y , Z }
•Ignoring Y → W, (Y)+ = { W , X , Y , Z }
Now,
•Clearly, the two results are same.
•Thus, we conclude that Y → W is non-essential and can be eliminated.
•Elimina ng Y → W, our set of func onal dependencies reduces to-
X→W
WZ → Y
Y→X
Y→Z
For Y → X:
•Considering Y → X, (Y)+ = { W , X , Y , Z }
•Ignoring Y → X, (Y)+ = { Y , Z }
Now,
•Clearly, the two results are different.
•Thus, we conclude that Y → X is essen al and can not be
eliminated.

For Y → Z:
•Considering Y → Z, (Y)+ = { W , X , Y , Z }
•Ignoring Y → Z, (Y)+ = { W , X , Y }
Now,
•Clearly, the two results are different.
•Thus, we conclude that Y → Z is essen al and can not be
eliminated.
From here, our essential functional dependencies are-
X→W
WZ → Y
Y→X
Y→Z
Step-03:
•Consider the functional dependencies having more than one attribute
on their left side.
•Check if their left side can be reduced.
In our set,
•Only WZ → Y contains more than one a ribute on its le side.
•Considering WZ → Y, (WZ)+ = { W , X , Y , Z }
Now,
•Consider all the possible subsets of WZ.
•Check if the closure result of any subset matches to the closure result
of WZ.
(W)+ = { W }
(Z)+ = { Z }
Clearly,
•None of the subsets have the same closure result
same as that of the entire left side.
•Thus, we conclude that we can not write
WZ → Y as W → Y or Z → Y.
Finally, the canonical cover is-
X→W
WZ → Y
Y→X
Y→Z
Exercise Problems:

1) Given a relational Schema R( A, B, C, D) and set

of Func on Dependency FD = { B → A, AD → BC,
C → ABD }. Find the canonical cover?
2) Given a relational Schema R( W, X, Y, Z) and set
of Func on Dependency FD = { W → X, Y → X,
Z → WXY, WY → Z }. Find the canonical cover?
3) Given a relational Schema R( V, W, X, Y, Z) and set
of Func on Dependency FD = { V → W, VW → X,
Y → VXZ }. Find the canonical cover?
 Un-Normalized Form (UNF)
• If a table contains non-atomic values at each
row, it is said to be in Un-normalized form.
• An atomic value is an attribute value that
cannot be further decomposed. A non-atomic
value, as the name suggests, can be further
decomposed and simplified.
• Consider the following table:

• In the sample table above, there are multiple

occurrences of rows under each key Emp-Id.

• Although considered to be the primary key, Emp-Id

cannot give us the unique identification facility for any
single row. Further, each primary key points to a
variable length record (3 for E01, 2 for E02 and 4 for
E03).
 Normal Forms based on functional
dependency
First Normal Form (1NF)
A relation is said to be in 1NF if it contains
atomic values and each row can provide a
unique combination of values. The above
table in Un-normalized form can be processed
to create the following table in 1NF. The above
mentioned table normalized to 1NF is given
below.
• The above mentioned table normalized to 1NF is
given below.

• Now, each row contains unique combination of

values. Unlike in UNF, this relation contains only
atomic values, i.e. the rows can not be further
decomposed, so the relation is now in 1NF.
 Second Normal Form (2NF)
A relation is said to be in 2NF, it must be
in first normal form and relation must not
contain any partial dependency. A relation is
in 2NF if it has No Partial Dependency, i.e., no
non-prime attribute (attributes which are not
part of any candidate key) is dependent on
any proper subset of any candidate key of the
table.
• In the above relation {Emp-Id,Month} is the
CANDIDATE key. All attributes depends on
{Emp-Id,Month}. But the attributes Emp-
Name, Bank-Id and Bank-Name depends on
Emp-Id, which is not the CANDIDATE of the
table(we have a partial dependency here). So
the table is in 1NF, but not in 2NF. If we can
remove this partial dependency by creating
another relation, it would come to 2NF.
 Emp-Id Month Sales

E01 JAN 1000

E01 FEB 1200
E01 MAR 850
Sales_Info
E02 JAN 2200
E02 FEB 2500
E03 JAN 1700
E03 FEB 1800 Employee_Info
E03 MAR 1850
E03 APR 1726

Emp-Id Emp-Name Bank-Id Bank-Name

E01 AA B01 SBI
E02 BB B02 UTI
E03 CC B01 SBI
• Let R(A,B,C,D,E,P,G) be a relational schema in which the
following FDs are known to hold:
AB->CD
DE->P
C->E
P->C
B->G

Check is it in 2NF?
• A table has fields F1, F2, F3, F4, and F5, with the
following functional dependencies:
F1->F3
F2->F4
(F1,F2)->F5
Check is it in 2NF?

• A relation R(A,B,C,D) has following FD’s

{AB->CD, C->A, D->B}
is it in 2NF?
 Third Normal Form (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 iff 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).
Transitive dependency – If A->B and B->C are two
FDs then A->C is called transitive dependency.
• For example, in the above example
Employee_Info contains following functional
dependencies.
Emp-Id → Emp-Name, Bank-Id, Bank-Name
Bank-Id → Bank-Name
• In such a case the relation(Employee-Info)
should be broken into two relations
Emp-Id Emp-Name Bank-Id Bank-Id Bank-Name
E01 AA B01 B01 SBI
E02 BB B02
B02 UTI
E03 CC B01

Employee Bank_Info
• Consider relation R(A, B, C, D, E)
A -> BC,
CD -> E,
B -> D,
E -> A

• All possible candidate keys in above relation are

{A, E, CD, BC} All attribute are on right sides of all
functional dependencies are prime.
• So above relation is in 3 NF
 Boyce-Codd Normal Form
• For a table to satisfy the Boyce-Codd Normal
Form, it should satisfy the following two
conditions:
1. It should be in the Third Normal Form.
2. And, for any dependency A → B, A
should be a super key.
 Fourth Normal Form (4NF)
• For a table to satisfy the Fourth Normal Form,
it should satisfy the following two conditions:
1. It should be in the Boyce-Codd Normal
Form.
2. And, the table should not have any Multi-
valued Dependency.
 What is Multi-valued Dependency?
•Multivalued dependency occurs when two attributes
in a table are independent of each other but, both
depend on a third attribute, that's why it always
requires at least three attributes.
•MVD or multivalued dependency means that for a
single value of attribute ‘a’ multiple values of attribute
‘b’ exist. We write it as,
a --> --> b
It is read as: a is multi-valued dependent on b.
Multi Valued Dependency (MVD) :
We can say that multivalued dependency exists if the
following conditions are met.

Conditions for MVD :

Any attribute say a multiple define another attribute b; if
any legal relation r(R), for all pairs of tuples t1 and t2 in r,
such that,

t1[a] = t2[a]
Then there exists t3 and t4 in r such that.

t1[a] = t2[a] = t3[a] = t4[a]

t1[b] = t3[b]; t2[b] = t4[b]
T1[c] = t4[c]; t2[c] = t3[c]
Then multivalued (MVD) dependency exists.
 Sid Course Hobby
1 Science Cricket
1 Maths Hockey
1 Science Hockey
1 Maths Cricket
2 C# Chess
2 Php Hockey
2 C# Hockey
2 Php Chess

In this relation we have 2 multi-valued

dependencies, those are
sid->->course and sid ->-> hobby
Course and hobby are independent of each other.
• So the above relation is split into two sub
relations.

Sid Course Sid Hobby

1 Science 1 Cricket

1 Maths 1 Hockey

2 C# 2 Chess

2 Php 2 Hockey
 Decomposition
The process of breaking up of a relation into smaller
sub-relations is called Decomposition.
Decomposition is required in DBMS to convert a
relation into specific normal form which further
reduces redundancy, anomalies and inconsistency
in the relation.
There are mainly two types of decompositions in
DBMS-
1.Lossless Decomposition
2.Lossy Decomposition
 1. Lossless Decomposition
• The decompositions R1, R2, R2…Rn for a relation
schema R are said to be Lossless if there natural
join results the original relation R.

• Formally, Let R be a relation and R1, R2, R3 … Rn

be it’s decomposition, the decomposition is
lossless if –
R1 R2 R3 .... Rn = R

• The common attribute of the sub relations is a

super key of any one of the relation.
Example-1:
Example to check whether given Decomposition
Lossless Join Decomposition.
Let there be a relational schema R(A, B, C).
R1(A, B) and R2(B, C) be it’s decompositions.
R R1 R2
A B C A B B C

a1 b1 c1 a1 b1 b1 c1

a2 b1 c1 a2 b1 b2 c2

a1 b2 c2 a1 b2
R1 R2 = R then, R1 R2 is
A B C

a1 b1 c1

a2 b1 c1

a1 b2 c2

As, R1 R2 = R,
This decomposition is Lossless.
 Determining Whether Decomposition
Is Lossless Or Lossy-
Consider a relation R is decomposed into two sub
relations R1 and R2.
Then,
•If all the following conditions satisfy, then the
decomposition is lossless.
•If any of these conditions fail, then the
decomposition is lossy.
Condition-01:
Union of both the sub relations must contain
all the attributes that are present in the
original relation R.
Thus, R1 R2 = R

Condition-02:
Intersection of both the sub relations must
not be null.
In other words, there must be some common
attribute which is present in both the sub
relations.
Thus, R1 ∩ R2 ≠
Condition-03:
Intersection of both the sub relations must be
a super key of either R1 or R2 or both.
Thus,R1 ∩ R2 = Super key of R1 or R2
 2. Lossy Decomposition
The decompositions R1, R2, R2…Rn for a relation
schema R are said to be Lossy if there natural join
results into addition of extraneous tuples with the
original relation R.

Formally, Let R be a relation and R1, R2, R3 … Rn

be it’s decomposition, the decomposition is lossy
if –
R R1 R2 R3 .... Rn

The common attribute of the sub relation is not a

super key of any of the sub relation.
Example to check whether given Decomposition
Lossy Join Decomposition.
Let there be a relational schema R(A, B, C).
R1(A, B) and R2(A, C) be it’s decompositions.

Check yourself?

Solution is in next page.

 R R1 R2
A B C A B A C

a1 b1 c1 a1 b1 a1 c1

a2 b1 c1 a2 b1 a2 c1

a1 b2 c2 a1 b2 a1 c2

R1 R2
A B C
a1 b1 c1
Here R R1 R2 so
a1 b1 c2
a2 b1 c1 its lossy.
a1 b2 c1
a1 b2 c2
 Dependency Preservation
A Decomposition D = { R1, R2, R3….Rn } of R is dependency
preserving wrt a set F of Functional dependency if

(F1 F2 … Fm)+ = F+.

Consider a relation R
R ---> F{...with some functional dependency(FD)....}

R is decomposed or divided into R1 with FD { f1 } and R2 with { f2 },

then
there can be three cases:

f1 U f2 = F -----> Decomposition is dependency preserving.

f1 U f2 is a subset of F -----> Not Dependency preserving.
f1 U f2 is a super set of F -----> This case is not possible.
Q1) Consider a schema R(A,B,C,D) and functional dependencies A->B and C->D. Then
the decomposition of R into R1(AB) and R2(CD) is [GATE-CS-2001]
A. dependency preserving and lossless join
B. lossless join but not dependency preserving
C. dependency preserving but not lossless join
D. not dependency preserving and not lossless join

Sol:
a) First check whether given relation R is lossless or lossy:
Condition 1: R1 U R2 = {A,B,C,D} = R, success
Condition 2: R1 ∩ R2 = {} is it an empty set? Yes. If its empty set no need to check
third condition, directly we say it is lossy decomposition.

b) Now check whether it is dependency preserving or not.

Divide the FD’s among sub-relations
R1(A,B) R2(C,D)
{ {
AB CD
} }
If we perform F1 U F2 should equal to F. (Where F1 and F2 are functional
dependencies in R1 and R2 respectively.
So F1 U F2 = {AB, CD} = F. Hence relation R is dependency
preserving. So option C is correct.
Q2) Let suppose, a relation R (P, Q, R, S) with a set of Functional Dependency F =
(PQ→R, R→S, S→P) is given. Into R1 (P, Q, R) and R2(R, S), relation R (P, Q, R, S) is
decomposed. Find out whether the decomposition is dependency preserving or not.

Sol: Divide the FD’s among sub-relations

R1(P,Q,R) R2(R,S)
{ {
PQR RS
RP }
}
But SP does not belongs to any relation.
If we perform F1 U F2 should equal to F. (Where F1 and F2 are functional
dependencies in R1 and R2 respectively.
So F1 U F2 = {PQR, RP, RS}.
Now check is it equivalent with F or not, by using Closure of attributes gives
the same result or not. Observe the below table, all values are not equal, so
its not dependency preserving.
F1 U F2 F
PQ+ {P,Q,R,S} {P,Q,R,S}
R+ {R,S,P} {R,S,P}
S+ {S} {S,P}
Q3) Consider a Rela on R {A,B,C,D,E,F} with FDs {A→B,AB→C,D→AC,D→E} . R is
decomposed into R1 {ABC}, R2{DE} and R3{ACD}. What can be said about
decomposition.

a) lossless and dependency preserving.

b) lossless but not dependency preserving.
c) lossy and dependency preserving.

Sol:
a) In this case take any two sub relations, first conclude those two sub relations
are lossy or lossless. If its lossless, join these two sub relations and check this
with 3rd sub relation.
First check whether given relation R is lossless or lossy:
Condition 1: R1 U R2 U R3 = {ABCD} = R, success
Condition 2 & 3:
In this case take any two sub relations(take any 2 relations which should have
common attribute), first conclude those two sub relations are lossy or lossless. If
its lossless, join these two sub relations and check this with 3rd sub relation.
R2 ∩ R3 = {D} is it an empty set? No. So check is it a super key or not in R2 or R3.
Yes. Which is the candidate key in R2. So its lossless. Join these two sub relations
R2 and R3, we get R23{ACDE}.
Now check R1 and R23 is lossy or lossless
R1 ∩ R23 = {AC} is it an empty set? No. So check is it a super key or not in R1 or
R23. Yes, which is a candidate key of R1. So given relation R is lossless.
b) Now check whether it is dependency preserving or not.
Divide the FD’s among sub-relations
R1(A,B,C) R2(D,E) R3(A,C,D)
{ { {
AB DE DAC
ABC } }
}
If we perform F1 U F2 U F3 should equal to F. (Where F1, F2 and F3 are
functional dependencies in R1, R2 and R3 respectively.
So F1 U F2 U F3= {AB, ABC, DAC, DE}
Now check is it equivalent with F or not, by using Closure of left side
attributes in F gives the same result or not. Observe the below table, all
values are equal, so its dependency preserving.

F1 U F2 U F3 F
A+ {A,B,C} {A,B,C}
AB+ {A,B,C} {A,B,C}
D+ {A,C,D,E} {A,C,D,E}
Q4) Consider a relation schema R ( A , B , C , D ) with the following functional
dependencies-
A→B
B→C
C→D
D→B
Determine whether the decomposition of R into R1 ( A , B ) , R2 ( B , C ) and R3 ( B , D ) is
lossless or lossy and also check it is dependency preserving or not?

Sol:
a)
First check whether given relation R is lossless or lossy:
Condition 1: R1 U R2 U R3 = {ABCD} = R, success
Condition 2 & 3:
In this case take any two sub relations(take any 2 relations which should have
common attribute), first conclude those two sub relations are lossy or lossless. If its
lossless, join these two sub relations and check this with 3rd sub relation.
R1 ∩ R2 = {B} is it an empty set? No. So check is it a super key or not in R1 or R2.
Yes. Which is the candidate key in R2. So its lossless. Join these two sub relations R1
and R2, we get R12{ABC}
Now check is R12 and R3 is lossy or lossless.
R12 ∩ R3 = {B} is it an empty set? No. So check is it a super key or not in R12 or R3.
Yes, which is a candidate key of R3. So given relation R is lossless.
 b) Now check whether it is dependency preserving or not.
Divide the FD’s among sub-relations, we need to identify closure for the
attributes present in that sub relation using given FD’s, we need to add it as
functional dependency in that relation. Here closure of C is C+={C,D,B} So we add
CB in R2 relation. Similarly B+={B,C,D} So we add BD in R3 sub relation.
R1(A,B) R2(B,C) R3(B,D)
{ { {
AB BC BD
} CB DB
} }
If we perform F1 U F2 U F3 should equal to F. (Where F1, F2 and F3 are
functional dependencies in R1, R2 and R3 respectively.
So F1 U F2 U F3= {AB, BC, CB, BD, DB}.
Now check is it equivalent with F or not, by using Closure of attributes
gives the same result or not. Observe the below table, so its dependency preserving.

F1 U F2 U F3 F
A+ {A,B,C,D} {A,B,C,D}
B+ {B,C,D} {B,C,D}
C+ {C,B,D} {C,B,D}
D+ {D,B,C} {D,B,C}