Types of Functional dependencies in DBMS

Prerequisite: Functional dependency and attribute closure

In a relational database management, functional dependency is a concept
that specifies the relationship between two sets of attributes where one attribute
determines the value of another attribute. It is denoted as X → Y, where the
attribute set on the left side of the arrow, X is called Determinant, and Y is
called the Dependent.

Example:
RegNo name dept_name dept_building

42 abc CO A4

43 pqr IT A3

44 xyz CO A4

45 xyz IT A3

46 mno EC B2

47 jkl ME B2

From the above table we can conclude some valid functional dependencies:
● RegNo → { name, dept_name, dept_building },→ Here, RegNo can
determine values of fields name, dept_name and dept_building, hence a valid
Functional dependency
● RegNo → dept_name , Since RegNo can determine whole set of {name,
dept_name, dept_building}, it can determine its subset dept_name also.
● dept_name → dept_building , Dept_name can identify the dept_building
accurately, since departments with different dept_name will also have a
different dept_building
● More valid functional dependencies: RegNo → name, {roll_no, name} ⇢
{dept_name, dept_building}, etc.
Here are some invalid functional dependencies:
● name → dept_name Students with the same name can have different
dept_name, hence this is not a valid functional dependency.

● dept_building → dept_name, There can be multiple departments in the

same building. Example, in the above table departments ME and EC are in
the same building B2, hence dept_building → dept_name is an invalid
functional dependency.

● More invalid functional dependencies: name → RegNo, {name, dept_name}

→ RegNo, dept_building → RegNo, etc.

Armstrong’s axioms/properties of functional dependencies:

1. Reflexivity: If Y is a subset of X, then X→Y holds by reflexivity rule

Example, {RegNo, name} → name is valid.

2. Augmentation: If X → Y is a valid dependency, then XZ → YZ is also

valid by the augmentation rule.
Example, {RegNo, name} → dept_building is valid, hence {RegNo, name,
dept_name} → {dept_building, dept_name} is also valid.

3. Transitivity: If X → Y and Y → Z are both valid dependencies, then X→Z

is also valid by the Transitivity rule.
Example, RegNo→ dept_name & dept_name → dept_building, then RegNo
→ dept_building is also valid.

Types of Functional Dependencies in DBMS

1. Trivial functional dependency
2. Non-Trivial functional dependency
3. Multivalued functional dependency
4. Transitive functional dependency

1. Trivial Functional Dependency

In Trivial Functional Dependency, a dependent is always a subset of the
determinant. i.e. If X → Y and Y is the subset of X, then it is called trivial
functional dependency
Example:
RegNo name age

42 abc 17

43 pqr 18

44 xyz 18

Here, {RegNo, name} → name is a trivial functional dependency, since the

dependent name is a subset of determinant set {RegNo, name}.
Similarly, RegNo → RegNo is also an example of trivial functional
dependency.

2. Non-trivial Functional Dependency

In Non-trivial functional dependency, the dependent is strictly not a subset of
the determinant. i.e. If X → Y and Y is not a subset of X, then it is called Non-
trivial functional dependency.

Example:
RegNo name age

42 abc 17

43 pqr 18

44 xyz 18

Here, RegNo → name is a non-trivial functional dependency, since the

dependent name is not a subset of determinant RegNo. Similarly, {RegNo,
name} → age is also a non-trivial functional dependency, since age is not a
subset of {RegNo, name}
3. Multivalued Functional Dependency
In Multivalued functional dependency, entities of the dependent set are not
dependent on each other. i.e. If a → {b, c} and there exists no functional
dependency between b and c, then it is called a multivalued functional
dependency.
For example,
RegN
o name age

42 abc 17

43 pqr 18

44 xyz 18

45 abc 19

Here, RegNo → {name, age} is a multivalued functional dependency, since the

dependents name & age are not dependent on each other
(i.e. name → age or age → name doesn’t exist !)

4. Transitive Functional Dependency

In transitive functional dependency, dependent is indirectly dependent on
determinant. i.e. If a → b & b → c, then according to axiom of transitivity,
a → c. This is a transitive functional dependency.
For example,
RegN
o name dept building_no

42 abc CO 4

43 pqr EC 2

44 xyz IT 1

45 abc EC 2

Here, RegNo → dept and dept → building_no. Hence, according to the axiom
of transitivity, RegNo → building_no is a valid functional dependency. This is
an indirect functional dependency, hence called Transitive functional
dependency.

5. Fully Functional Dependency

In full functional dependency an attribute or a set of attributes uniquely
determines another attribute or set of attributes. If a relation R has attributes X,
Y, Z with the dependencies X->Y and X->Z which states that those
dependencies are fully functional.
6. Partial Functional Dependency
In partial functional dependency a non key attribute depends on a part of the
composite key, rather than the whole key. If a relation R has attributes X, Y,
Z where X and Y are the composite key and Z is non key attribute. Then X->Z
is a partial functional dependency in RBDMS.
Advantages of Functional Dependencies
Functional dependencies having numerous applications in the field of database
management system. Here are some applications listed below:

1. Data Normalization

Data normalization is the process of organizing data in a database in order to

minimize redundancy and increase data integrity. Functional dependencies play
an important part in data normalization. With the help of functional
dependencies we are able to identify the primary key, candidate key in a table
which in turns helps in normalization.

2. Query Optimization

With the help of functional dependencies we are able to decide the connectivity
between the tables and the necessary attributes need to be projected to retrieve
the required data from the tables. This helps in query optimization and improves
performance.

3. Consistency of Data

Functional dependencies ensures the consistency of the data by removing any

redundancies or inconsistencies that may exist in the data. Functional
dependency ensures that the changes made in one attribute does not affect
inconsistency in another set of attributes thus it maintains the consistency of the
data in database.

4. Data Quality Improvement

Functional dependencies ensure that the data in the database to be accurate,

complete and updated. This helps to improve the overall quality of the data, as
well as it eliminates errors and inaccuracies that might occur during data
analysis and decision making, thus functional dependency helps in improving
the quality of data in database.

Conclusion

Functional dependency is very important concept in database management

system for ensuring the data consistency and accuracy.
Armstrong Axioms
The term Armstrong Axioms refers to the sound and complete set of inference
rules or axioms, introduced by William W. Armstrong, that is used to test the
logical implication of functional dependencies. If F is a set of functional
dependencies then the closure of F, denoted as F+, is the set of all functional
dependencies logically implied by F.

Armstrong’s Axioms are a set of rules, that when applied repeatedly,

generates a closure of functional dependencies.

Axioms
● Axiom of Reflexivity: If A is a set of attributes and B is a subset of A,
then A holds B. If B⊆A then A→B. This property is trivial property.

● Axiom of Augmentation: If A→B holds and Y is the attribute set,

then AY→BY also holds. That is adding attributes to dependencies, does not
change the basic dependencies. If A→B, then AC→BC for any C.

● Axiom of Transitivity: Same as the transitive rule in algebra, if A→B holds

and B→C holds, then A→C also holds. A→B is called A functionally which
determines B. If X→Y and Y→Z, then X→Z.

Secondary Rules
These rules can be derived from the above axioms.
● Union: If A→B holds and A→C holds, then A→BC holds.
If X→Y and X→Z then X→YZ.

● Composition: If A→B and X→Y hold, then AX→BY holds.

● Decomposition: If A→BC holds then A→B and A→C hold.

If X→YZ then X→Y and X→Z.

● Pseudo Transitivity: If A→B holds and BC→D holds, then AC→D holds.
If X→Y and YZ→W then XZ→W.

● Self Determination: It is similar to the Axiom of Reflexivity, i.e. A→A for

any A.
● Extensivity: Extensivity is a case of augmentation. If AC→A, and A→B,
then AC→B. Similarly, AC→ABC and ABC→BC. This leads to AC→BC.

Armstrong Relation
Armstrong Relation can be stated as a relation that is able to satisfy all
functional dependencies in the F+ Closure. In the given set of dependencies, the
size of the minimum Armstrong Relation is an exponential function of the
number of attributes present in the dependency under consideration.

Why Armstrong Axioms Refer to the Sound and Complete?

By sound, we mean that given a set of functional dependencies F specified on a
relation schema R, any dependency that we can infer from F by using the
primary rules of Armstrong axioms holds in every relation state r of R that
satisfies the dependencies in F.
By complete, we mean that using primary rules of Armstrong axioms repeatedly
to infer dependencies until no more dependencies can be inferred results in the
complete set of all possible dependencies that can be inferred from F.

Advantages of Using Armstrong’s Axioms in Functional Dependency

● They provide a systematic and efficient method for inferring additional
functional dependencies from a given set of functional dependencies, which
can help to optimize database design.
● They can be used to identify redundant functional dependencies, which can
help to eliminate unnecessary data and improve database performance.
● They can be used to verify whether a set of functional dependencies is a
minimal cover, which is a set of dependencies that cannot be further reduced
without losing information.

****************************************************************