Functional dependency

Functional dependency
• A functional dependency is an association between
two attributes of the same relational database table.
• One of the attributes is called the determinant and
the other attribute is called the determined.
• For each value of the determinant there is
associated one and only one value of the
determined.
 Functional dependency
• If A is the determinant and B is the determined then
we say that A functionally determines B and
graphically represent this as A -> B. The symbols A -
>B· can also be expressed as B is functionally
determined by A.

Since for each value of A there is associated one and only one value of B.
 Example

Since for A = 3 there is associated more than one value of B.

 Functional Dependancy
Functional dependency can also be defined as follows:
•An attribute in a relational model is said to be functionally dependent
on another attribute in the table if it can take only one value for a given
value of the attribute upon which it is functionally dependent.
Example
 Example
• Here in Supplier table
• Sno              -             Supplier number of supplier that is unique
• Sname       -             Supplier name
• City             -             City of the supplier
• Status      -     Status of the city e.g. A grade cities may have status 10, B grad
cities             may have status 20 and so on.
• Here, Sname is FD on Sno. Because, Sname can take only one value for the given
value of Sno (e.g. S 1) or in other words there must be one Sname for supplier
number S1.
• FD is represented as:
• Sno à Sname
• FD is shown by à which means that Sname is functionally dependent on Sno.
Dependency diagram
Here, following functional dependencies exist in supplier
table
Sno         -       Sname
Sname     -       Sno
Sno         -       City
Sno         -       Status
FUNCTIONAL DEPENDANCY Diagram
• The FD diagram of relation P is
•                  
FUNCTIONAL DEPENDANCY Diagram
Types of Functional Dependency

• Various Types of Functional Dependencies are –

• Single Valued Functional Dependency
• Fully Functional Dependency
• Partial Functional Dependency
• Transitive Functional Dependency
• Multivalued Functional dependancy
Single Valued Functional Dependency –
• Database is a collection of related information in which one information depends
on another information. The information is either single-valued or multi-valued.
For example, the name of the person or his.her date of birth are single valued
facts. But the qualification of a person is a multivalued facts.
• A simple example of single value functional dependency is when A is the primary
key of an entity (eg. SID) and B is some single valued attribute of the entity (eg.
Sname). Then, A → B must always hold.
Full Functional Dependancy
• A functional dependency P → Q is full functional dependency if
removal of any attribute A from P means that the dependency does
not hold any more. ie
• If AD → C, is fully functional dependency, then we cannot remove A
or D. i.e. C is fully functional dependent on AD. If we are able to
remove A or D, then it is not full functional dependency.
Partial Functional Dependency –

• A Functional Dependency in which one or more non key attributes are

functionally depending on a part of the primary key is called partial
functional dependency. or
• where the determinant consists of key attributes, but not the entire
primary key, and the determined consist of non-key attributes.

For example, Consider a Relation R(A,B,C,D,E) having FD : AB → CDE where PK is AB. Then, { A → C
; A → D; A → E; B → C; B → D; B → E } all are Partial Dependencies.
Transitive Dependency –

• Giv en a relation R(A,B,C)  then dependency like A–>B,

B–>C   is a transitive dependency, since   A–>C is
implied.
Multivalued dependency 

• Multivalued dependency occurs when there are more than

one independent multivalued attributes in a table.
• A Multi-Value Dependency (MVD) occurs when two or more
independent multi valued facts about the same attribute occur within
the same table. It means that if in a relation R having A, B and C as
attributes, B and C are multi-value facts about A, which is represented
as A->->B and A ->-> C, then multi value dependency exit only if B and
C are independent on each other
 Join Dependency

• A Join Dependency exist if a relation R is equal to the join of the

projections X, Y, …., Z. where X, Y, … Z are projections of R.
Candidate Functional Dependency (CFD)

A candidate functional dependency is functional dependence that

includes all attributes of the table. It should also be noted that a well-
formed dependency diagram must have at least one candidate
functional dependency and that there can be more than one
candidate functional dependence for a given dependency diagram.
 Normalization

• Normalization
Data normalization is a technique of organizing the data in database.
Normalization of data can be defined as a process during which
redundant relation schemas are decomposed by breaking up their
attributes into smaller relation schemas that process desirable
properties
Normalisation
 First Normal Form

•A relation is said to be in 1NF if and only if every cell/entry of the

relation has at most a single value. In other words “a relation is in 1NF
if and only if all underlying domains contain atomic values or single
value only.”
•The objective of normalizing a table is to remove its repeating groups
and ensure that all entries of the resulting table have at most a single
value.
Unnormalized table

Course Course Name Teacher Roll Name   System Hourly Total

 
Code  
   
Name  
No  
 
 
   
Used  
Rate  
Hours
 
C1  
Visual Basic  
ABC  
100  
A1  
   
P–I  
20  
7
 
 
 
 
 
   
101  
A2  
   
P – II  
30  
3
 
 
 
 
 
   
102  
A3  
   
Celeron  
10  
6
 
 
 
 
 
   
103  
A4  
   
P – IV  
40  
1
 
C2  
Oracle & Dev  
DEF  
100  
A1  
   
P–I  
20  
7
 
 
 
 
 
   
104  
A5  
   
P – III  
35  
3
 
 
 
 
 
   
105  
A6  
   
P – II  
30  
1
 
 
 
 
 
   
101  
A2  
   
P – II  
30  
2
 
C3  
C++  
KJP  
106  
A7  
   
P – IV  
40  
3
 
 
 
 
 
   
107  
A8  
   
P – IV  
40  
2
 
 
 
 
 
   
108  
A9  
   
P–I  
20  
1
 
C4  
Java  
Kumar  
109  
A10  
   
Cyrix  
20  
2
Approaches to normalize table
• In general, there are two basic approaches to normalize tables.
 Flattening the Table
Course Course Name Teacher Roll Name System Hourly Total
 
Code  
   
Name  
No  
   
Used  
Rate  
Hours

 
C1  
Visual Basic  
ABC  
100  
A1  
P–I  
20  
7

 
C1  
Visual Basic  
ABC  
101  
A2  
P – II  
30  
3

 
C1  
Visual Basic  
ABC  
102  
A3  
Celeron  
10  
6

 
C1  
Visual Basic  
ABC  
103  
A4  
P – IV  
40  
1

 
C2  
Oracle & Dev  
DEF  
100  
A1  
P–I  
20  
7

 
C2  
Oracle & Dev  
DEF  
104  
A5  
P – III  
35  
3

 
C2  
Oracle & Dev  
DEF  
105  
A6  
P – II  
30  
1

 
C2  
Oracle & Dev  
DEF  
101  
A2  
P – II  
30  
2

 
C3  
C++  
KJP  
106  
A7  
P – IV  
40  
3

 
C3  
C++  
KJP  
107  
A8  
P – IV  
40  
2

 
C3  
C++  
KJP  
108  
A9  
P–I  
20  
1

 
C4  
Java  
Kumar  
109  
A10  
Cyrix  
20  
2
Approaches to normalize table
 STUDENT (Decomposition)Normalised
Data Course Roll Name System Hourly Total
Course Course Name Teacher
Code   Name  
Code  
No  
   
Used  
Rate  
Hours
     

C1 Visual Basic ABC  

C1  
100  
A1  
P–I  
20  
7
C1 101 A2 P – II 30 3
     

C2 Oracle & Dev DEF            

C1 102 A3 Celeron 10 6
     

C3 C++ KJP            

     
C1 103 A4 P – IV 40 1
C4 Java Kumar
           

     

 
C2  
100  
A1  
P–I  
20  
7
 
C2  
104  
A5  
P – III  
35  
3
 
C2  
105  
A6  
P – II  
30  
1
 
C2  
101  
A2  
P – II  
30  
2

 
C3  
106  
A7  
P – IV  
40  
3
 
C3  
107  
A8  
P – IV  
40  
2
 
C3  
108  
A9  
P–I  
20  
1
33
C4 109 A10 Cyrix 20 2
Anomalies in 1NF Relation
• Insert anomalies:
 
• We cannot insert the information about the student until he joins any
course e.g. we cannot store information about the roll no 110 until he
join any course, similarly we are unable to store the information
about the course until there is a student who enroll into that course.
 
.
Anomalies in 1NF Relation
• Update anomalies:
 
• This relation is also susceptible to update anomalies because the
course in which a student studies may appear many times in the
table. If a teacher moves to another course, we are now faced with
two problems: we either search the entire table looking for that
teacher and update his or her course_code value or we miss one or
more tuples of that STUDENT and end up with an inconsistent
database. For small tables, this type of anomaly may not seem to be
much of a problem.
Anomalies in 1NF Relation
• Delete anomalies:
 
• This relation experiences deletion anomalies whenever we delete the last tuple of a
particular student. In this case, we not only delete the course information that connects
that student to a particular course, but also lose other information about the system on
which this student works.
 
• Let us consider, the case where we have to delete the information of student having
rollno 109, then we also lose the information about course_code C4 . Also if we have to
delete the information of java course we lose the information about the student Kumar.
•
 Second Normal Form (2N
• A relation R is in 2NF if and only if it is in 1NF and every non-key
attribute is fully functional dependent on the primary key
• As per the Second Normal Form there must not be any partial
dependency of any column on primary key
• If we follow second normal form, then every non-prime attribute
should be fully functionally dependent on prime key attribute. That is,
if X → A holds, then there should not be any proper subset Y of X, for
which Y → A also holds true.
 Example

We see here in Student_Project relation that the prime key attributes are
Stu_ID and Proj_ID. According to the rule, non-key attributes, i.e. Stu_Name
and Proj_Name must be dependent upon both and not on any of the prime
key attribute individually. But we find that Stu_Name can be identified by
Stu_ID and Proj_Name can be identified by Proj_ID independently. This is
called partial dependency, which is not allowed in Second Normal Form.
We broke the relation in two as depicted in
the above picture. So there exists no partial
dependency.
 Third Normal Form

• For a relation to be in Third Normal Form, it must be in Second

Normal form and the following must satisfy −
• No non-prime attribute is transitively dependent on prime key
attribute.
• For any non-trivial functional dependency, X → A, then either −
• X is a superkey or,
• A is prime attribute.
 Example

We find that in the above Student_detail relation, Stu_ID is the key and only prime key
attribute. We find that City can be identified by Stu_ID as well as Zip itself. Neither Zip is
a superkey nor is City a prime attribute. Additionally, Stu_ID → Zip → City, so there
exists transitive dependency.