Functional Dependency

Consider a relation R that has two attributes A and B. The attribute B of

the relation is functionally dependent on the attribute A if and only if
for each value of A no more than one value of B is associated. In other
words, the value of attribute A uniquely determines the value of B and
if there were several tuples that had the same value of A then all these
tuples will have an identical value of attribute B. That is, if t1 and t2
are two tuples in the relation R and
t1(A) = t2(A) then we must have t1(B) = t2(B).
A and B need not be single attributes. They could be any subsets of the
attributes of a relation R (possibly single attributes). We may then write
R.A -> R.B
if B is functionally dependent on A (or A functionally determines B).
unctional dependency does not imply a one!to!one relationship
between A and B although a one!to!one relationship may e"ist
between A and B.
# simple e"ample of the above functional dependency is when A is a
primary $ey of an entity (e.g. student number) and A is some single!
valued property or attribute of the entity (e.g. date of birth). A -> B
then must always hold. unctional dependencies also arise in
relationships. %et C be the primary $ey of an entity and D be the
primary $ey of another entity. %et the two entities have a relationship.
If the relationship is one!to!one, we must have C -> D and D -> C. If
the relationship is many!to!one, we would have C -> D but not D -> C.
or many!to!many relationships, no functional dependencies hold. or
e"ample, if C is student number and D is sub&ect number, there is no
functional dependency between them. If however, we were storing
mar$s and grades in the database as well, we would have
(student_number, subject_number) -> marks
and we might have
marks -> grades
The second functional dependency above assumes that the grades are
dependent only on the mar$s. This may sometime not be true since
the instructor may decide to ta$e other considerations into account in
assigning grades, for e"ample, the class average mar$.
or e"ample, in the student database that we have discussed earlier,
we have the following functional dependencies'
sno -> sname
sno -> address
cno -> cname
cno -> nstructor
nstructor -> o!ce
These functional dependencies imply that there can be only one name
for each sno, only one address for each student and only one sub&ect
name for each cno. It is of course possible that several students may
have the same name and several students may live at the same
address. If we consider cno -> nstructor, the dependency implies
that no sub&ect can have more than one instructor (perhaps this is not
a very realistic assumption). unctional dependencies therefore place
constraints on what information the database may store. In the above
e"ample, one may be wondering if the following (s hold
sname -> sno
cname -> cno
Certainly there is nothing in the instance of the e"ample database
presented above that contradicts the above functional dependencies.
)owever, whether above (s hold or not would depend on whether the
university or college whose database we are considering allows
duplicate student names and sub&ect names. If it was the enterprise
policy to have unique sub&ect names than cname -> cno holds. If
duplicate student names are possible, and one would thin$ there
always is the possibility of two students having e"actly the same
name, then sname -> sno does not hold.
unctional dependencies arise from the nature of the real world that
the database models. *ften A and B are facts about an entity where A
might be some identi+er for the entity and B some characteristic.
unctional dependencies cannot be automatically determined by
studying one or more instances of a database. FDs can be
determined only by a careful study of the real world and a
clear understanding of what each attribute means.
We have noted above that the de+nition of functional dependency does
not require that A and B be single attributes. In fact, A and B may be
collections of attributes. or e"ample
(sno, cno) -> (mark, date)
When dealing with a collection of attributes, the concept of full
functional dependence is an important one. %et A and B be distinct
collections of attributes from a relation R end let R.A -> R.B. B is then
fully functionally dependent on A if B is not functionally dependent on
any subset of A. The above e"ample of students and sub&ects would
show full functional dependence if mark and date are not functionally
dependent on either student number ( sno) or sub&ect number ( cno)
alone. The implies that we are assuming that a student may have more
than one sub&ects and a sub&ect would be ta$en by many di,erent
students. urthermore, it has been assumed that there is at most one
enrolment of each student in the same sub&ect.
The above e"ample illustrates full functional dependence. )owever the
following dependence
(sno, cno) -> nstructor
is not full functional dependence because cno -> nstructor holds.
#s noted earlier, the concept of functional dependency is related to the
concept of candidate $ey of a relation since a candidate $ey of a
relation is an identi+er which uniquely identi+es a tuple and therefore
determines the values of all other attributes in the relation. Therefore
any subset X of the attributes of a relation R that satis+es the property
that all remaining attributes of the relation are functionally dependent
on it (that is, on X), then X is candidate $ey as long as no attribute can
be removed from X and still satisfy the property of functional
dependence. In the e"ample above, the attributes (sno, cno) form a
candidate $ey (and the only one) since they functionally determine all
the remaining attributes.
unctional dependence is an important concept and a large body of
formal theory has been developed about it. We discuss the concept of
closure that helps us derive all functional dependencies that are
implied by a given set of dependencies. *nce a complete set of
functional dependencies has been obtained, we will study how these
may be used to build normalised relations.
Closure
%et a relation R have some functional dependencies F speci+ed. The
closure of F (usually written as "#) is the set of all functional
dependencies that may be logically derived from F. *ften F is the set of
most obvious and important functional dependencies and "#, the
closure, is the set of all the functional dependencies including F and
those that can be deduced from F. The closure is important and may,
for e"ample, be needed in +nding one or more candidate $eys of the
relation.
or e"ample, the student relation has the following functional
dependencies
sno -> sname cno -> cname sno -> address cno -> nstructor
nstructor -> o!ce
%et these dependencies be denoted by F. The closure of F, denoted by
"#, includes F and all functional dependencies that are implied by F.
To determine "#, we need rules for deriving all functional
dependencies that are implied by F. # set of rules that may be used to
infer additional dependencies was proposed by #rmstrong in -./0.
These rules (or a"ioms) are a complete set of rules in that all possible
functional dependencies may be derived from them. The rules are'
1. Reflexivity Rule --- If X is a set of attributes and Y is a subset of X, then X -> Y
holds.
The re1e"ivity rule is the most simple (almost trivial) rule. It
states that 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.
The augmentation rule is also quite simple. It states that if Y is
determined by X then a set of attributes W and Y together will be
determined by W and X together. 2ote that we use the notation
WX to mean the collection of all attributes in W and X and write
WX rather than the more conventional (W, X) for convenience.
3. Transitivity Rule --- If X -> Y and Y -> Z hold, then X -> Z holds.
The transitivity rule is perhaps the most important one. It states
that if X functionally determines Y and Y functionally determines
Z then X functionally determines Z.
These rules are called Armstron!s A"ioms.
urther a"ioms may be derived from the above although the above
three a"ioms are sound and complete in that they do not generate any
incorrect functional dependencies (soundness) and they do generate
all possible functional dependencies that can be inferred from F
(completeness). 3ome of the most important additional a"ioms are'
1. Union Rule --- If X -> Y and X -> Z hold, then X -> YZ holds.
2. Decomposition Rule --- If X -> YZ holds, then so do X -> Y and X -> Z.
3. Pseudotransitivity Rule --- If X -> Y and WY -> Z hold then so does WX -> Z.
4ased on the above a"ioms and the functional dependencies speci+ed
for relation student, we may write a large number of functional
dependencies. 3ome of these are'
(sno, cno) -> sno (5ule -)
(sno, cno) -> cno (5ule -)
(sno, cno) -> (sname, cname) (5ule 6)
cno -> o!ce (5ule 7)
sno -> (sname, address) (8nion 5ule) etc.
*ften a very large list of dependencies can be derived from a given set
F since 5ule - itself will lead to a large number of dependencies. 3ince
we have seven attributes (sno, sname, address, cno, cname,
instructor, o#ce), there are -69 (that is, 6:/) subsets of these
attributes. These -69 subsets could form -69 values of X in functional
dependencies of the type $ -> %. *f course, each value of X will then
be associated with a number of values for Y ( Y being a subset of X)
leading to several thousand dependencies. These large number of
dependencies are not particularly helpful in achieving our aim of
normali;ing relations.
#lthough we could follow the present procedure and compute the
closure of to +nd all the functional dependencies, the computation
requires e"ponential time and the list of dependencies is often very
large and therefore not very useful. There are two possible approaches
that can be ta$en to avoid dealing with the large number of
dependencies in the closure. *ne is to deal with one attribute or a set
of attributes at a time and +nd its closure (i.e. all functional
dependencies relating to them). The aim of this e"ercise is to +nd what
attributes depend on a given set of attributes and therefore ought to
be together. The other approach is to +nd the minimal co$ers. We will
discuss both approaches brie1y.
#s noted earlier, we need not deal with the large number of
dependencies that might arise in a closure since often one is only
interested in determining closure of a set of attributes given a set of
functional dependencies. Closure of a set of attributes X is all the
attributes that are functionally dependent on X given some functional
dependencies F while the closure of F was all functional dependencies
that are implied by F. Computing the closure of a set of attributes is a
much simpler tas$ if we are dealing with a small number of attributes.
We will denote the closure of a set of attributes X given F by $#.
#n algorithm to determine the closure'
3tep - %et $# &- $
3tep 6 %et the ne"t dependency be A -> B. If A is in $# and B is not,
$# &- $#' B.
3tep 7 Continue step 6 until no new attributes can be added to $#
The result of the algorithm is equal to $#.
The above algorithm may also be used to remove redundant
dependencies. or e"ample, to chec$ if $ -> A is redundant, we +nd
closure of X without using $ -> A. If A is in $#, we can eliminate $ ->
A as redundant.
Consider the following relation
student(sno, sname, cno, cname).
We wish to determine the closure of (sno, cno). We have the following
functional dependencies.
sno -> sname
cno -> cname
We apply the above algorithm using $(c as the place holder for all the
attributes that have been found to be dependent on X so far.
%tep & !!! $# &- $, that is, $# &- (sno, cno)
%tep ' !!! Consider sno -> sname, since sno is in $# and sname is
not, we have
$# &- (sno, cno) # sname
%tep ( !!! Consider cno -> cname, since cno is in $# and cname is
not, we have
$# &- (sno, cno, sname) # cname
%tep ) !!! #gain, consider sno -> sname but this does not change $#
%tep * !!! #gain, consider cno -> cname but this does not change $#
Therefore $# = (sno, cno, sname, cname).
This shows that all the attributes in the relation student (sno, cno,
sname, cname) are dependent on (sno, cno) and therefore (sno, cno) is
a candidate $ey of the present relation. In this case, it is the only
candidate $ey.
3imilarly we may wish to investigate the closure of (sname, cname).
We will +nd that the closure of (sname, cname) is only (sname,
cname). Therefore these two attributes together cannot form the $ey
of the above relation.
We de+ne some further concepts about functional dependencies'
%et F1 and F2 be two sets of (s. The two (s are called equivalent if
- < 6. *f course, it is not always easy to test that the two sets are
equivalent since each of them may consist of hundreds of (s. *ne
way to carry out the chec$ing would be to ta$e each dependency $ ->
% in turn from - and c+eck if it is in 6,
3ometime the term F1 covers F2 and F2 covers F1 is used to denote
equivalence.
Minimal Functional
Dependencies
In discussing the concept of equivalent (s, it is useful to de+ne the
concept of minimal functional dependencies or minimal co$er which is
useful in eliminating unnecessary functional dependencies so that only
the minimal number of dependencies need to be enforced by the
system. The concept of minimal cover of F is sometimes called
-rreduci.e %et of F. To +nd the minimal cover of a set of functional
dependencies F, we transform F such that each ( in it that has more
than one attribute in the right hand side is reduced to a set of (s that
have only one attribute on the right hand side. This can be done easily
using the decomposition rule that we have already discussed. The
minimal cover of F is then a set of (s such that'
(a) every right hand side of each dependency is a single attribute=
(b) for no $ -> A in F is the set " - )$ -> A* equivalent to F=
(c) for no $ -> A in F and proper subset Z of X is " - )$ -> A* ' )+
-> A* equivalent to F.
5equirements (a), as already noted, can be met easily given any set of
dependencies F. 5equirement (b) guarantees that we cannot remove
any dependencies from F and still have a set of dependencies
equivalent to F or no attribute on the left hand side of a dependency is
redundant. 5equirement (c) ma$es sure that no dependencies may be
replaced by a dependency that involves a subset of the left hand side.
The concept of minimal set of dependencies is useful in normali;ation
as we shall discuss later. The minimal set may be considered a
standard or canonical form of (s with no redundancies that is
equivalent to F. 8nfortunately however the minimal cover is not
unique.
Compiled by 3.5.5oy
The script is only a supplement to the class room discussions.