Functional Dependency and Normalization

Chapter four
Functional Dependency
 The attributes of a table is said to be dependent on each other when an attribute of a
table uniquely identifies another attribute of the same table.
 For example: Suppose we have a student table with attributes: Stu_Id, Stu_Name, Stu_Age.
Here Stu_Id attribute uniquely identifies the Stu_Name attribute of student table because if
we know the student id we can tell the student name associated with it. This is known as
functional dependency and can be written as Stu_Id->Stu_Name or in words we can say
Stu_Name is functionally dependent on Stu_Id.
 Formally:
If column A of a table uniquely identifies the column B of same table then it can
represented as A->B (Attribute B is functionally dependent on attribute A)
 Types of Functional Dependencies
·         Trivial functional dependency
·         non-trivial functional dependency
·         Multivalued dependency
·         Transitive dependency
Trivial functional dependency in DBMS 
 The dependency of an attribute on a set of attributes is known as trivial
functional dependency if the set of attributes includes that attribute.
 Symbolically: 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.
 Also, Student_Id -> Student_Id & Student_Name -> Student_Name are trivial
dependencies too.
Non trivial functional dependency in DBMS
 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.
 For example:
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.
Multivalued dependency in DBMS
 Multivalued dependency occurs when there are more than one independent multivalued attributes in
a table.
 For example: Consider a bike manufacture company, which produces two colors (Black and white) in
each model every year.

 HereHere columns COLOR and MANUF_YEAR are dependent on BIKE_MODEL and independent of each other.
 In this case, these two columns can be called as multivalued dependent on BIKE_MODEL. The representation of
these dependencies is shown below:
1.      BIKE_MODEL   →  →  MANUF_YEAR  
2.      BIKE_MODEL   →  →  COLOR  
 This can be read as "BIKE_MODEL multidetermined MANUF_YEAR" and "BIKE_MODEL multidetermined COLOR".
 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} (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.
Normalization
 Normalization is the process of organizing the data in the database.
 Normalization is used to minimize the redundancy from a relation or set of relations. It is also used
to eliminate the undesirable characteristics like Insertion, Update and Deletion Anomalies.
 Normalization divides the larger table into the smaller table and links them using relationship.
  The normal form is used to reduce redundancy from the database table.
Types of Normal Forms
 There are the four types of normal forms to cover on this subject :
First Normal Form (1NF)
 A relation will be 1NF if it contains an atomic value.
 It states that an attribute of a table cannot hold multiple values. It must hold only single-valued
attribute.
 First normal form disallows the multi-valued attribute, composite attribute, and their combinations.
 Example: Relation EMPLOYEE is not in 1NF because of multi-valued attribute EMP_PHONE.
 EMPLOYEE table:
 The decomposition of the EMPLOYEE table into 1NF has been shown below:
  
Second Normal Form (2NF)
 In the 2NF, relational must be in 1NF.
 In the second normal form, all non-key attributes are fully functional dependent on
the primary key
 Example: Let's assume, a school can store the data of teachers and the subjects they
teach. In a school, a teacher can teach more than one subject.
 TEACHER table
 In the given table, non-prime attribute TEACHER_AGE is dependent on TEACHER_ID which is a
proper subset of a candidate key. That's why it violates the rule for 2NF.
 To convert the given table into 2NF, we decompose it into two tables:
Third Normal Form (3NF)
 A relation will be in 3NF if it is in 2NF and not contain any transitive partial dependency.
 3NF is used to reduce the data duplication. It is also used to achieve the data integrity.
 If there is no transitive dependency for non-prime attributes, then the relation must be in third
normal form.
 A relation is in third normal form if it holds atleast one of the following conditions for every non-
trivial function dependency X → Y.
1. X is a super key.
2. Y is a prime attribute, i.e., each element of Y is part of some candidate key.
 Example:
 EMPLOYEE_DETAIL table:
 Super key in the table above:
 1.      {EMP_ID}, {EMP_ID, EMP_NAME}, {EMP_
ID, EMP_NAME, EMP_ZIP}....so on  
 Candidate key: {EMP_ID}
 Non-prime attributes: In the given table, all
attributes except EMP_ID are non-prime.
 Here, EMP_STATE & EMP_CITY dependent on
EMP_ZIP and EMP_ZIP dependent on EMP_ID.
The non-prime attributes (EMP_STATE,
EMP_CITY) transitively dependent on super
key(EMP_ID). It violates the rule of third
normal form.
 That's why we need to move the EMP_CITY
and EMP_STATE to the new <EMPLOYEE_ZIP>
table, with EMP_ZIP as a Primary key.
 EMPLOYEE table:
 Boyce Codd normal form (BCNF)
 BCNF is the advance version of 3NF. It is stricter than 3NF.
 A table is in BCNF if every functional dependency X → Y, X is the super key of the table.
 For BCNF, the table should be in 3NF, and for every FD, LHS is super key.
 Example: Let's assume there is a company where employees work in more than one department.
EMPLOYEE table:

 In the above table Functional dependencies are as follows:

1. EMP_ID  →  EMP_COUNTRY  
2. EMP_DEPT  →   {DEPT_TYPE, EMP_DEPT_NO}  
 Candidate key: {EMP-ID, EMP-DEPT}
 The table is not in BCNF because neither EMP_DEPT nor EMP_ID alone are keys.
 In the above table Functional dependencies are as follows:
1. EMP_ID  →  EMP_COUNTRY  
2. EMP_DEPT  →   {DEPT_TYPE, EMP_DEPT_NO}  
 Candidate key: {EMP-ID, EMP-DEPT}
 The table is not in BCNF because neither EMP_DEPT nor EMP_ID alone are
keys.
 To convert the given table into BCNF, we decompose it into three tables: look at
the right side tables.

 Functional dependencies:
1. EMP_ID   →    EMP_COUNTRY  
2. EMP_DEPT   →   {DEPT_TYPE, EMP_DEPT_NO}  
 Candidate keys:
For the first table: EMP_ID 
For the second table: EMP_DEPT
For the third table: {EMP_ID, EMP_DEPT}
 Now, this is in BCNF because left side part of both the functional dependencies
is a key.