UNIT 3

By:
Navjot Kaur
System Programming Domain
Functional Dependency
 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.

X → Y
The left side of FD is known as a determinant, the right side of
the production is known as a dependent.
 Functional Dependency
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.
 Functional Dependency
• Functional Dependency (FD) determines the relation of one
attribute to another attribute in a database management
system (DBMS) system.
• Functional dependency helps you to maintain the quality of
data in the database.
• A functional dependency is denoted by an arrow →.
• The functional dependency of X on Y is represented by X → Y.
 Functional Dependency
XY X Y
1 1
For a value of X the value of Y must be same
2 1
Everywhere. If X is same the Y must be same. 3 2
4 3
FD: XY
2 5
if t1.X = t2.X
then t1.Y = t2.Y
 Fully Functional Dependency
XY
Y is Fully Functional Dependent on X if Y is Functional Dependent
on X but not functional dependent of any proper subset of X
 Functional Dependency
XY Eid Enam Dept
e
Y is Fully Functional Dependent on X 101 A Mkt
102 B Fin
if Y is Functional Dependent on X
103 B HR
but not functional dependent of any proper
subset of X.
Eid,ename  dept
Subsets:

Eid dept
Enamedept
 Functional Dependency

• If we know the value of Employee number, we can obtain

Employee Name, city, salary, etc.
• By this, we can say that the city, Employee Name, and salary
are functionally depended on Employee number.
Functional Dependency Rules

• Three most important rules for Functional Dependency:

 Types of Functional Dependency
1. Multivalued dependency
2. Trivial functional dependency
3. Non-trivial functional dependency
4. Transitive dependency
 Types of Functional Dependency

1. Multivalued dependency
• Multivalued dependency occurs in the situation where there
are multiple independent multivalued attributes in a single
table.
• A multivalued dependency is a complete constraint between
two sets of attributes in a relation.
• It requires that certain tuples be present in a relation.
 Types of Functional Dependency
1. Multivalued dependency

maf_year and color are independent of each other but dependent on

car_model. these two columns are said to be multivalue dependent on
car_model.
 Types of Functional Dependency

1. Multivalued dependency

car_model -> maf_year

car_model-> colour
 Trivial Dependency
Eid,ename  Eid Eid Enam Dept
e
101 A Mkt
102 B Fin
103 A HR
But CEO is not a subset of Company, and hence it's non-trivial functional
dependency.
 Non Trivial Dependency
Eid,ename  dept Eid Enam Dept
e
101 A Mkt
102 B Fin
103 A HR
 Types of Functional Dependency

1. Trivial functional dependency

A → B has trivial functional dependency if B is a subset of A.

The following dependencies are also trivial like: A → A, B → B
 Types of Functional Dependency
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.
 Types of Functional Dependency
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
 Closure

The set of all those attributes which can be functionally

determined from an attribute set is called as a closure of that
attribute set.

Closure of attribute set {X} is denoted as {X}+.

 Closure
Step-01: Add the attributes contained in the attribute set for
which closure is being calculated to the result set.

Step-02:
Recursively add the attributes to the result set which can be
functionally determined from the attributes already contained
in the result set.
Closure helps to find all possible candidate keys in a
relation.
 Closure: Example

1. R(ABCD)

FD {A B, B C, C D}

A +: means what A can determine

= {A B C D} A will determine itself because of reflexive rule (self loop)

A can determine all attributes of R. (property of candidate key)

CK = {A}
 Closure: Example
1. R(ABCD)

FD {A B, B C, C D}

B+ = { BCD}

B cant be CK because it does not det. A

C+ = {CD} not a CK

D+= {D} not a CK

Only A is Candidate Key

 Closure: Example
1. R(ABCD)

FD {A B, B C, C D}

Prime Attribute: which is used in making the candidate key

Prime Attribute = {A}

Non Prime: {BCD}

 Closure: Example
2. R(ABCD)

FD { AB, BC, CD, DA)

 Closure: Example
3. R(A,B,C,D,E)

FD : {AB, BC, CD, DE}

Find closure of A,B,C,D,E, AD+, CD+

 Closure
Example-

Consider a relation R ( A , B , C , D , E , F , G ) with the functional dependencies-

A → BC

BC → DE

D→F

CF → G
 Closure
Closure of attribute A-

A+ = { A }

= { A , B , C } ( Using A → BC )

= { A , B , C , D , E } ( Using BC → DE )

= { A , B , C , D , E , F } ( Using D → F )

= { A , B , C , D , E , F , G } ( Using CF → G )

Thus,

A+ = { A , B , C , D , E , F , G }
 Closure
Closure of attribute D-

D+ = { D }

= { D , F } ( Using D → F )

We can not determine any other attribute using attributes D and F contained in the
result set.

Thus,

D+ = { D , F }
 Closure
Closure of attribute set {B, C}-

{ B , C }+= { B , C }

= { B , C , D , E } ( Using BC → DE )

= { B , C , D , E , F } ( Using D → F )

= { B , C , D , E , F , G } ( Using CF → G )

Thus,

{ B , C }+ = { B , C , D , E , F , G }
 Normalization
What is it and what is need of normalization:
Process of organizing data in DB.
1.Minimize redundancy in relation
2.Divide big table into small tables
Need
To remove anomalies
 Normalization
• If a database design is not perfect, it may contain anomalies.
Problems Without Normalization
If a table is not properly normalized and have data redundancy
then it will not only consume extra memory space but will also
make it difficult to handle and update the database, without
facing data loss.

Insertion, Updation and Deletion Anomalies are very frequent if

database is not normalized.

To understand these anomalies let us take an example of a

Student table.
Problems Without Normalization

We have data of 4 Computer Sci. students.

As we can see, data for the fields branch, hod(Head of

Department) and office_tel is repeated for the students who are in
the same branch in the college, this is Data Redundancy.
Problems Without Normalization
Data Redundancy: Sid Name Age Branch Branch HOD
_code _name
Duplicate data in the table 1 A 18 101 CSE XYZ
Disadvantage: 2 B 19 101 CSE XYZ
3 C 18 101 CSE XYZ
1.Insertion, deletion and
4 D 21 102 ECE PQR
update Anomalies 5 E 20 102 ECE PQR
6 F 19 103 ME KLM
INSERTION ANOMALY:
When certain data attributes cant be inserted into the database
without the presence of other data.
In this table, a new branch civil cant be added until you have the sid
of the student who took admission in that branch civil. You cant
enter data without sid because entire branch data is kept in a single
table.
 Anomalies
1. 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.
 Anomalies
2. Deletion anomalies − We tried to delete a record that is
unwanted but it leads to deletion of the data that us wanted.
Example: we wanted to delete details of student but did not
want to delete branch information. Now because branch info.
Is not stored separately so it will also be deleted.

3. Insert anomalies − We tried to insert data in a record that

does not exist at all.
 Anomalies

Insertion anomaly:

If a tuple is inserted in referencing relation and referencing attribute value is not

present in referenced attribute, it will not allow inserting in referencing relation.

For Example, If we try to insert a record in STUDENT_COURSE with STUD_NO

=7, it will not allow.
 Anomalies

Deletion and Updation anomaly: If a tuple is deleted or updated from referenced

relation and referenced attribute value is used by referencing attribute in
referencing relation, it will not allow deleting the tuple from referenced relation.

For Example, If we try to delete a record from STUDENT with STUD_NO =1.
 Anomalies
1. 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.
 Anomalies
2. 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.

3. Insert anomalies − We tried to insert data in a record that

does not exist at all.
 Anomalies

Insertion anomaly:

If a tuple is inserted in referencing relation and referencing attribute value is not

present in referenced attribute, it will not allow inserting in referencing relation.

For Example, If we try to insert a record in STUDENT_COURSE with STUD_NO

=7, it will not allow.
 Anomalies

Deletion and Updation anomaly: If a tuple is deleted or updated from referenced

relation and referenced attribute value is used by referencing attribute in
referencing relation, it will not allow deleting the tuple from referenced relation.

For Example, If we try to delete a record from STUDENT with STUD_NO =1.