0% found this document useful (0 votes)
29 views

B.Tech - V - KCS-501 - Unit 3 - 1

Functional dependencies define relationships between attributes in a database table. There are different types of functional dependencies including trivial, non-trivial, complete non-trivial, partial, and transitive. Functional dependencies can be represented as "A -> B" meaning attribute A determines attribute B. Inferences rules can be used to derive new functional dependencies from existing ones. The closure of a set of functional dependencies is all functional dependencies that can be derived from that set.

Uploaded by

Manav Gora
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
29 views

B.Tech - V - KCS-501 - Unit 3 - 1

Functional dependencies define relationships between attributes in a database table. There are different types of functional dependencies including trivial, non-trivial, complete non-trivial, partial, and transitive. Functional dependencies can be represented as "A -> B" meaning attribute A determines attribute B. Inferences rules can be used to derive new functional dependencies from existing ones. The closure of a set of functional dependencies is all functional dependencies that can be derived from that set.

Uploaded by

Manav Gora
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

Functional Dependencies

The functional dependency is a relationship that exists between two attributes. It


typically

Functional dependency in DBMS, as the name suggests is a relationship between


attributes of a table dependent on each other. Introduced by E. F. Codd, it helps in
preventing data redundancy and gets to know about bad designs.

To understand the concept thoroughly, let us consider P is a relation with attributes A


and B. Functional Dependency is represented by -> (arrow sign)

Then the following will represent the functional dependency between attributes with an
arrow sign −

A -> B

Above suggests the following:

Example
The following is an example that would make it easier to understand functional
dependency −

We have a <Department> table with two attributes − DeptId and DeptName.


DeptId = Department ID
DeptName = Department Name

The DeptId is our primary key. Here, DeptId uniquely identifies the DeptName attribute.
This is because if you want to know the department name, then at first you need to have
the DeptId.

DeptId DeptName

001 Finance

002 Marketing

003 HR

Therefore, the above functional dependency between DeptId and DeptName can be
determined as DeptId is functionally dependent on DeptName −

DeptId -> DeptName

For 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
o A → B has trivial functional dependency if B is a subset of A.
o The following dependencies are also trivial like: A → A, B → B

Example:

1. Consider a table with two columns Employee_Id and Employee_Name.


2. {Employee_id, Employee_Name} → Employee_Id is a trivial functional dependency as
3. Employee_Id is a subset of {Employee_Id, Employee_Name}.
4. Also, Employee_Id → Employee_Id and Employee_Name → Employee_Name are trivial d
ependencies too.

2. Non-trivial functional dependency


o A → B has a non-trivial functional dependency if B is not a subset of A.
o When A intersection B is NULL, then A → B is called as complete non-trivial.

Example:

1. ID → Name,
2. Name → DOB

Completely Non - Trivial Functional Dependency


It occurs when A intersection B is null in −

A ->B

3. Partial Dependency
Partial Dependency occurs when a non-prime attribute is functionally dependent on part
of a candidate key.
The 2nd Normal Form (2NF) eliminates the Partial Dependency.
Let us see an example −

Example
<StudentProject>
StudentID ProjectNo StudentName ProjectName

S01 199 Katie Geo Location

S02 120 Ollie Cluster Exploration

In the above table, we have partial dependency; let us see how −


The prime key attributes are StudentID and ProjectNo, and
StudentID = Unique ID of the student
StudentName = Name of the student
ProjectNo = Unique ID of the project
ProjectName = Name of the project

As stated, the non-prime attributes i.e. StudentName and ProjectName should be


functionally dependent on part of a candidate key, to be Partial Dependent.
The StudentName can be determined by StudentID, which makes the relation Partial
Dependent.
The ProjectName can be determined by ProjectNo, which makes the relation Partial
Dependent.
Therefore, the <StudentProject> relation violates the 2NF in Normalization and is
considered a bad database design.
To remove Partial Dependency and violation on 2NF, decompose the tables −
<StudentInfo>
StudentID ProjectNo StudentName

S01 199 Katie

S02 120 Ollie

<ProjectInfo>
ProjectNo ProjectName

199 Geo Location

120 Cluster Exploration

4. Transitive dependency in DBMS


A functional dependency is said to be transitive if it is indirectly formed by two
functional dependencies. For e.g.

X -> Z is a transitive dependency if the following three functional dependencies


hold true:

 X->Y
 Y does not ->X
 Y->Z

Note: A transitive dependency can only occur in a relation of three of more


attributes. This dependency helps us normalizing the database in 3NF
(3rd Normal Form).

Example: Let’s take an example to understand it better:

Book Author Author_age

Game of Thrones George R. R. Martin 66

Harry Potter J. K. Rowling 49

Dying of the Light George R. R. Martin 66

{Book} ->{Author} (if we know the book, we knows the author name)

{Author} does not ->{Book}

{Author} -> {Author_age}


Therefore as per the rule of transitive dependency: {Book} -> {Author_age}
should hold, that makes sense because if we know the book name we can know
the author’s age.

Inference Rule (IR):


o The Armstrong's axioms are the basic inference rule.
o Armstrong's axioms are used to conclude functional dependencies on a relational
database.
o The inference rule is a type of assertion. It can apply to a set of FD(functional
dependency) to derive other FD.
o 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.

1. If X ⊇ Y then X → Y

Example:

1. X = {a, b, c, d, e}
2. Y = {a, b, c}

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.

1. If X → Y then XZ → YZ

Example:

1. For R(ABCD), if A → B then AC → BC

3. Transitive Rule (IR3)


In the transitive rule, if X determines Y and Y determine Z, then X must also determine Z.
1. If X → Y and Y → Z then X → Z

4. Union Rule (IR4)


Union rule says, if X determines Y and X determines Z, then X must also determine Y and Z.

1. 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.

1. If X → YZ then 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.

1. 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)
Closures of a set of functional dependencies
A Closure is a set of FDs is a set of all possible FDs that can be derived from a given
set of FDs. It is also referred as a Complete set of FDs. If F is used to donate the set of
FDs for relation R, then a closure of a set of FDs implied by F is denoted by F+. Let's
consider the set F of functional dependencies given below:

F = {A -> B, B -> C, C -> D}

from F, it is possible to derive following dependencies.


A -> A ...By using Rule-4, Self-Determination.
A -> B ...Already given in F.
A -> C ...By using rule-3, Transitivity.
A -> D ...By using rule-3, Transitivity.

Now, by applyiing Rule-6 Union, it is possible to derive A+ -> ABCD and it can be
denoted using A -> ABCD. All such type of FDs derived from each FD of F form a
closure of F. Steps to determine F+example:

 Determine each set of attributes X that appears as a left hand side of some FD in
F.
 Determine the set X+ of all attributes that are dependent on X, as given in above
example.
 In other words, X+ represents a set of attributes that are functionally determined
by X based on F. And, X+ is called the Closure of X under F.
 All such sets of X+, in combine, Form a closure of F.

Algorithm : Determining X+, the closure of X under F.

Input : Let F be a set of FDs for relation R.

Steps:
1. X+ = X //initialize X+ to X
2. For each FD : Y -> Z in F Do
If Y ⊆ X+ Then //If Y is contained in X+
X+ = X+ ∪ Z //add Z to X+
End If
End For
3. Return X+ //Return closure of X

Output : Closure X+ of X under F

You might also like