Functional Dependency

A functional dependency is a constraint between two sets of attributes in a relation from a

database.
Given a relation R, a set of attributes X in R is said to functionally determine another attribute
Y, also in R, (written X → Y) if, and only if, each X value is associated with precisely one Y
value. Customarily we call X the determinant set and Y the dependent attribute. Thus, given a
tuple and the values of the attributes in X, one can determine the corresponding value of the Y
attribute. In simple words, if X value is known, Y value is certainly known. For the purposes of
simplicity, given that X and Y are sets of attributes in R, X → Y denotes that X functionally
determines each of the members of Y—in this case Y is known as the dependent set. Thus, a
candidate key is a minimal set of attributes that functionally determine all of the attributes in a
relation. The concept of functional dependency arises when one attribute is dependent on another
attribute and it also uniquely determines the other attribute.
(Note: the "function" being discussed in "functional dependency" is the function of
identification.)
A functional dependency FD: X → Y is called trivial if Y is a subset of X.
The determination of functional dependencies is an important part of designing databases in the
relational model, and in database normalization and denormalization. The functional
dependencies, along with the attribute domains, are selected so as to generate constraints that
would exclude as much data inappropriate to the user domain from the system as possible.
For example, suppose one is designing a system to track vehicles and the capacity of their
engines. Each vehicle has a unique vehicle identification number (VIN). One would write VIN
→ EngineCapacity because it would be inappropriate for a vehicle's engine to have more than
one capacity. (Assuming, in this case, that vehicles only have one engine.) However,
EngineCapacity → VIN is incorrect because there could be many vehicles with the same engine
capacity.
 This functional dependency may suggest that the attribute EngineCapacity be placed in
a relation with candidate key VIN. However, that may not always be appropriate. For
example, if that functional dependency occurs as a result of the transitive functional
dependencies VIN → VehicleModel and VehicleModel → EngineCapacity then that
would not result in a normalized relation.
Irreducible function depending set
A functional depending set S is irreducible if the set has the following three properties:
1. Each right set of a functional dependency of S contains only one attribute.
2. Each left set of a functional dependency of S is irreducible. It means that reducing any
one attribute from left set will change the content of S (S will lose some information).
3. Reducing any functional dependency will change the content of S.
Sets of Functional Dependencies (FD) with these properties are also called canonical or minimal.
Properties of functional dependencies
Given that X, Y, and Z are sets of attributes in a relation R, one can derive several properties of
functional dependencies. Among the most important are Armstrong's axioms, which are used in
database normalization:
 Subset Property (Axiom of Reflexivity): If Y is a subset of X, then X → Y
  Augmentation (Axiom of Augmentation): If X → Y, then XZ → YZ
 Transitivity (Axiom of Transitivity): If X → Y and Y → Z, then X → Z
From these rules, we can derive these secondary rules:
 Union: If X → Y and X → Z, then X → YZ
 Decomposition: If X → YZ, then X → Y and X → Z
 Pseudo-transitivity: If X → Y and WY → Z, then WX → Z
Equivalent sets of functional dependencies are called covers of each other. Every set of
functional dependencies has a canonical cover.
Example
This example illustrates the concept of functional dependency. The situation modeled is that of
college students visiting one or more lectures in each of which they are assigned a teaching
assistant (TA). Let's further assume that every student is in some semester and is identified by a
unique integer ID.
Student_ID Semester Lecture TA
1234 6 Numerical Methods John
2380 4 Numerical Methods Peter
1234 6 Visual Computing Amina
1201 4 Numerical Methods Peter
1201 4 Physics II Simone
We notice that whenever two rows in this table feature the same StudentID, they also necessarily
have the same Semester values. This basic fact can be expressed by a functional dependency:
 StudentID → Semester.
Other nontrivial functional dependencies can be identified, for example:
 {StudentID, Lecture} → TA
 {StudentID, Lecture} → {TA, Semester}
The latter expresses the fact that the set {StudentID, Lecture} is a superkey of the relation.
Database Dependencies/Functional Dependencies
A dependency occurs in a database when information stored in the same database table uniquely
determines other information stored in the same table. You can also describe this as a
relationship where knowing the values of one attribute (or a set of attributes) is enough to tell
you the value of another attribute (or set of attributes) in the same table.
Saying that there is a dependency between attributes in a table is the same as saying that there is
a functional dependency between those attributes. If there is a dependency in a database such that
an attribute B is dependent upon another attribute A, you would write this as “A -> B”.
For example, in a table listing employee characteristic including Social Security Number (SSN)
and name, it can be said that name is dependent upon SSN (or SSN -> name) because an
employee's name can be uniquely determined from their SSN. However, the reverse statement
(name -> SSN) is not true because more than one employee can have the same name but
different SSNs.
Trivial Functional Dependencies
A trivial functional dependency occurs when you describe a functional dependency of an
attribute on a collection of attributes that includes the original attribute. For example, “{A, B} ->
B” is a trivial functional dependency, as is “{name, SSN} -> SSN”. This type of functional
dependency is called trivial because it can be derived from common sense. It is obvious that if
you already know the value of B, then the value of B can be uniquely determined by that
knowledge.
Cyclic functional dependencies
Attributes on right side of one FD may appear on left side of another!
Simplest example: A -> B & B -> A
Real Example:
street, city -> value & city, value -> tax
studentID -> Email & Email -> studentID
Full Functional Dependencies
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. 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.
Transitive Dependencies
Transitive dependencies occur when there is an indirect relationship that causes a functional
dependency. For example,”A -> C” is a transitive dependency when it is true only because both
“A -> B” and “B -> C” are true.
Multi-valued Dependencies
Multi-valued dependencies occur when the presence of one or more rows in a table implies the
presence of one or more other rows in that same table. For example, imagine a car company that
manufactures many models of car, but always makes both red and blue colours of each model. If
you have a table that contains the model name, colour and year of each car the company
manufactures, there is a multi-valued dependency in that table. If there is a row for a certain
model name and year in blue, there must also be a similar row corresponding to the red version
of that same car.
Importance of Dependencies
Database dependencies are important to understand because they provide the basic building
blocks used in database normalization. For example:
 For a table to be in second normal form (2NF), there must be no case of a non-prime
attribute in the table that is functionally dependent upon a subset of a candidate key.
 For a table to be in third normal form (3NF), every non-prime attribute must have a non-
transitive functional dependency on every candidate key.
 For a table to be in Boyce-Codd Normal Form (BCNF), every functional dependency
(other than trivial dependencies) must be on a Super-key.
  For a table to be in fourth normal form (4NF), it must have no Multi-valued
dependencies.
More Examples:
Student-courses
Sid Sname Phone Courses-taken
100 John 487 2454 St-100-courses-taken
200 Smith 671 8120 St-200-courses-taken
300 Russell 871 2356 St-300-courses-taken

St-100-Course-taken
Course-id Course-description Credit-hours Grade
IS380 Database Concepts 3 A
IS416 Unix Operating System 3 B

St-200-Course-taken
Course-id Course-description Credit-hours Grade
IS380 Database Concepts 3 B
IS416 Unix Operating System 3 B
IS420 Data Net Work 3 C

St-300-Course-taken
Course-id Course-description Credit-hours Grade
IS417 System Analysis 3 A

Student-courses Integrated:
Sid SName Phone Course Course-Description Credit Grade
Id Hours
100 John 487 2454 IS380 Database Concepts 3 A
100 John 487 2454 IS416 Unix OS 4 B
200 Smith 671 8120 IS380 Database Concepts 3 B
200 Smith 671 8120 IS416 Unix OS 4 B
200 Smith 671 8120 IS420 Data Network 2 C
300 Russell 871 2356 IS417 System Analysis 5 A
 Functional Dependency 1

Functional Dependency 2

Closure of a Set of Functional Dependencies

1. We need to consider all functional dependencies that hold. Given a set F of functional
dependencies, we can prove that certain other ones also hold. We say these ones are
logically implied by F.
2. Suppose we are given a relation scheme R = (A,B,C,G,H,I), and the set of functional
dependencies:
A B
A C
 CG H
CG I
B H

Then the functional dependency is logically implied.

3. To see why, let and be tuples such that

As we are given A B, it follows that we must also have

Further, since we also have B H, we must also have

Thus, whenever two tuples have the same value on A, they must also have the same value
on H, and we can say that A H.
4. The closure of a set F of functional dependencies is the set of all functional dependencies
logically implied by F.
5. We denote the closure of F by .
6. To compute , we can use some rules of inference called Armstrong's Axioms:
o Reflexivity rule: if is a set of attributes and , then holds.
o Augmentation rule: if holds, and is a set of attributes, then
holds.
o Transitivity rule: if holds, and holds, then holds.
7. These rules are sound because they do not generate any incorrect functional
dependencies. They are also complete as they generate all of .
8. To make life easier we can use some additional rules, derivable from Armstrong's
Axioms:
o Union rule: if and , then holds.
o Decomposition rule: if holds, then and both hold.
o Pseudo-transitivity rule: if holds, and holds, then holds.
9. Applying these rules to the scheme and set F mentioned above, we can derive the
following:
o A H, as we saw by the transitivity rule.
o CG HI by the union rule.
o AG I by several steps:
 Note that A C holds.
 Then AG CG, by the augmentation rule.
 Now by transitivity, AG I.
(You might notice that this is actually pseudo-transitivity if done in one step.)
Normalization
Normalization is a process in which we systematically examine relations for
anomalies and, when detected, remove those anomalies by splitting up the
relation into two new, related, relations.

Normalization is an important part of the database development process.

Often during normalization, the database designers get their first real look
into how the data are going to interact in the database.

Finding problems with the database structure at this stage is strongly

preferred to finding problems further along in the development process
because at this point it is fairly easy to cycle back to the conceptual model
(Entity Relationship model) and make changes.

Normalization can also be thought of as a trade-off between data

redundancy and performance. Normalizing a relation reduces data
redundancy but introduces the need for joins when all of the data is
required by an application such as a report query.

If a database design is not perfect, it may contain anomalies, which are like
a bad dream for any database administrator. Managing a database with
anomalies is next to impossible.

 Update anomalies − If data items are scattered and are not linked to each
other properly, then it could lead to strange situations. For example, when
we try to update one data item having its copies scattered over several
places, a few instances get updated properly while a few others are left with
old values. Such instances leave the database in an inconsistent state.

 Deletion anomalies − We tried to delete a record, but parts of it was left

undeleted because of unawareness, the data is also saved somewhere else.

 Insert anomalies − We tried to insert data in a record that does not exist at
all.