Unit-3 ADBMS(CE Sem-4)
Functional Dependency
The functional dependency is a relationship that exists between two attributes. It typically
exists between the primary key and non-key attribute within a table. 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 at most one Y value.
1. X → Y
The left side of FD is known as a determinant, the right side of the production is known
as a dependent.
example:
Assume we have an employee table with attributes: Emp_Id, Emp_Name, Emp_Address.Here
Emp_Id attribute can uniquely identify the Emp_Name attribute of employee table because if we
know the Emp_Id, we can tell that employee name associated with it.
Functional dependency can be written as:
Emp_Id → Emp_Name
We can say that Emp_Name is functionally dependent on Emp_Id.
Types of Functional dependency
1. Trivial functional dependency
The dependency of an attribute on a set of attributes is known as trivial functional
dependency if the set of attributes includes that [Link]: A ->B is trivial functional
dependency if B is a subset of A. The following dependencies are also trivial: A->A & B->B
.For example: 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.
SSP, Sector-22 Gandhinagar Page 1
Unit-3 ADBMS(CE Sem-4)
Also, Student_Id -> Student_Id & Student_Name -> Student_Name are trivial dependencies too.
A → B has trivial functional dependency if B is a subset of A.
The following dependencies are also trivial like: A → A, B → B
Example:
Consider a table with two columns Employee_Id and Employee_Name.
{Employee_id, Employee_Name} → Employee_Id is a trivial functional dependency as
Employee_Id is a subset of {Employee_Id, Employee_Name}.
Also, Employee_Id → Employee_Id and Employee_Name → Employee_Name are trivial
dependencies too.
2. Non-trivial functional dependency
A → B has a non-trivial functional dependency if B is not a subset of A.
When A intersection B is NULL, then A → B is called as complete non-trivial.
Example:
ID → Name,
Name → DOB
If a functional dependency X->Y holds true where Y is not a subset of X then this dependency is
called non trivial Functional dependency.
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 [emp_name is a subset of {emp_id, emp_name}]
Refer: trivial functional dependency.
Completely non trivial FD:
If a FD X->Y holds true where X intersection Y is null then this dependency is said to be
completely non trivial function dependency.
Inference Rule (IR):
The Armstrong's axioms are the basic inference rule.
Armstrong's axioms are used to conclude functional dependencies on a relational
database.
The inference rule is a type of assertion. It can apply to a set of FD(functional
dependency) to derive other FD.
SSP, Sector-22 Gandhinagar Page 2
Unit-3 ADBMS(CE Sem-4)
Using the inference rule, we can derive additional functional dependency from the initial
set.
The Functional dependency has 6 types of inference rule:
1. Reflexive Rule (IR1)
In the reflexive rule, if Y is a subset of X, then X determines Y.
If X is a set of attributes and Y is a subset of X, then X Y holds. each subset of Y is
functionally dependent on X.
2. Augmentation Rule (IR2)
The augmentation is also called as a partial dependency. In augmentation, if X determines Y,
then XZ determines YZ for any Z.
If X → Y then XZ → YZ
If X Y holds and Z is a set of attributes, then ZX ZY holds.
3. Transitive Rule (IR3)
In the transitive rule, if X determines Y and Y determine Z, then X must also determine Z.
If X → Y and Y → Z then X → Z holds.
4. Union Rule (IR4)
Union rule says, if X determines Y and X determines Z, then X must also determine Y and Z.
If X → Y and X → Z then X → YZ
Proof:
1. X → Y (given)
2. X → Z (given)
3. X → XY (using IR2 on 1 by augmentation with X. Where XX = X)
4. XY → YZ (using IR2 on 2 by augmentation with Y)
5. X → YZ (using IR3 on 3 and 4)
5. Decomposition Rule (IR5)
Decomposition rule is also known as project rule. It is the reverse of union rule.
This Rule says, if X determines Y and Z, then X determines Y and X determines Z separately.
If X YZ holds, then so do X Y and X Z.
Proof:
1. X → YZ (given)
2. YZ → Y (using IR1 Rule)
3. X → Y (using IR3 on 1 and 2)
6. Pseudo transitive Rule (IR6)
In Pseudo transitive Rule, if X determines Y and YZ determines W, then XZ determines W.
Pseudotransitivity Rule --- If X Y and WY Z hold then so does WX Z.
SSP, Sector-22 Gandhinagar Page 3
Unit-3 ADBMS(CE Sem-4)
If X → Y and YZ → W then XZ → W
Proof:
1. X → Y (given)
2. WY → Z (given)
3. WX → WY (using IR2 on 1 by augmenting with W)
4. WX → Z (using IR3 on 3 and 2)
Fully Functional Dependency
An attribute is fully functional dependent on another attribute, if it is Functionally Dependent on
that attribute and not on any of its proper subset.
For example, an attribute Q is fully functional dependent on another attribute P, if it is
Functionally Dependent on P and not on any of the proper subset of P.
Let us see an example −
<Employee>
Emp_id Emp_salary
101 10000
102 15000
103 12000
104 15000
<Employeeproject>
Emp_id Project_id Days
101 001 100
102 002 200
103 003 150
104 004 250
The above relations states that −
Days are the number of days spent on the project.
EmpID, ProjectID, salary -> Days
However, it is not fully functional dependent.
Whereas the subset {EmpID, ProjectID} can easily determine the {Days} spent on the project by
the employee.
This summarizes and gives our fully functional dependency −
{EmpID, ProjectID} -> (Days)
SSP, Sector-22 Gandhinagar Page 4
Unit-3 ADBMS(CE Sem-4)
Partial Functional Dependency
A functional dependency A → B is said to be partial if removal of any subset of A still able to
recognize B uniquely.
Partial Dependency is a form of Functional dependency that holds on a set of attributes. It is
about the complete dependency of a right hand side attribute on one of the left hand side
attributes.
For example, in a functional dependency PQ → R, if either P alone or Q alone can uniquely
identify R, then this is said to be Partial Functional Dependency. We read this as R is partially
functionally dependent on P or R is partially functionally dependent on Q.
Another example: Assume the set of FDs for a relation Student as follows;
F = {regno → name, regno → dob, {regno, phone} → gender, regno → gender}
Here, in FD {regno, phone} → gender, the attribute gender is partially dependent on regno
attribute or left hand side. Here, phone is not required to identify gender uniquely.
Lossless and Lossy Decomposition in DBMS
Decomposition in DBMS removes redundancy, anomalies and inconsistencies from a database
by dividing the table into multiple tables.
The following are the types −
Lossless Decomposition
Decomposition is lossless if it is feasible to reconstruct relation R from decomposed tables using
Joins. This is the preferred choice. The information will not lose from the relation when
decomposed. The join would result in the same original relation.
Let us see an example −
<EmpInfo>
Emp_ID Emp_Name Emp_Age Emp_Location Dept_ID Dept_Name
E001 Jacob 29 Alabama Dpt1 Operations
E002 Henry 32 Alabama Dpt2 HR
E003 Tom 22 Texas Dpt3 Finance
SSP, Sector-22 Gandhinagar Page 5
Unit-3 ADBMS(CE Sem-4)
Decompose the above table into two tables:
<EmpDetails>
Emp_ID Emp_Name Emp_Age Emp_Location
E001 Jacob 29 Alabama
E002 Henry 32 Alabama
E003 Tom 22 Texas
<DeptDetails>
Dept_ID Emp_ID Dept_Name
Dpt1 E001 Operations
Dpt2 E002 HR
Dpt3 E003 Finance
Now, Natural Join is applied on the above two tables −
The result will be −
Emp_ID Emp_Name Emp_Age Emp_Location Dept_ID Dept_Name
E001 Jacob 29 Alabama Dpt1 Operations
E002 Henry 32 Alabama Dpt2 HR
E003 Tom 22 Texas Dpt3 Finance
Therefore, the above relation had lossless decomposition i.e. no loss of information.
Lossy Decomposition
when a relation is decomposed into two or more relational schemas, the loss of information is
unavoidable when the original relation is retrieved.
Let us see an example −
SSP, Sector-22 Gandhinagar Page 6
Unit-3 ADBMS(CE Sem-4)
<EmpInfo>
Emp_ID Emp_Name Emp_Age Emp_Location Dept_ID Dept_Name
E001 Jacob 29 Alabama Dpt1 Operations
E002 Henry 32 Alabama Dpt2 HR
E003 Tom 22 Texas Dpt3 Finance
Decompose the above table into two tables −
<EmpDetails>
Emp_ID Emp_Name Emp_Age Emp_Location
E001 Jacob 29 Alabama
E002 Henry 32 Alabama
E003 Tom 22 Texas
<DeptDetails>
Dept_ID Dept_Name
Dpt1 Operations
Dpt2 HR
Dpt3 Finance
Now, you won’t be able to join the above tables, since Emp_ID isn’t part of
the DeptDetails relation.
Therefore, the above relation has lossy decomposition.
SSP, Sector-22 Gandhinagar Page 7
Unit-3 ADBMS(CE Sem-4)
Remove functional dependencies Example (IMP)
For example, suppose the following set of FDs is given in the algorithm:
Z -> A B -> X AX -> Y ZB -> Y
Because ZB -> Y Can be derived from other FDs in the set, it can be shown to be redundant.
The following argument can be given:
Z -> A by augmentation rule will yield ZB -> AB.
B -> X and AX -> Y by pseudo-transitivity rule will yield AB -> Y.
ZB -> AB and AB -> Y by transitivity rule will yield ZB -> Y.
Multivalued Dependency (MVD) in DBMS
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.
Suppose a person named Geeks is working on 2 projects Microsoft and Oracle
and has 2 hobbies namely Reading and Music. This can be expressed in a
tabular format in the following way.
Project and Hobby are multivalued attributes as they have more than one value
for a single person i.e., Geeks.
SSP, Sector-22 Gandhinagar Page 8
Unit-3 ADBMS(CE Sem-4)
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 = t4; t2 = t3
Then multivalued (MVD) dependency exists.
To check the MVD in given table, we apply the conditions stated above and we
check it with the values in the given table.
SSP, Sector-22 Gandhinagar Page 9
