What is Functional Dependency?

A functional dependency is a constraint that specifies the relationship between two sets of attributes
where one set can accurately determine the value of other sets. It is denoted as X → Y, where X is a
set of attributes that is capable of determining the value of Y. The attribute set on the left side of the
arrow, X is called Determinant, while on the right side, Y is called the Dependent.

Key Terms Description

Axiom Axioms is a set of inference rules used to infer all the functional dependencies on a relational
database.

Decomposition It is a rule that suggests if you have a table that appears to contain two entities which are
determined by the same primary key then you should consider breaking them up into two different
tables.

Dependent It is displayed on the right side of the functional dependency diagram.

Determinant It is displayed on the left side of the functional dependency Diagram.

Union It suggests that if two tables are separate, and the PK is the same, you should consider putting
them. together

Rules of Functional Dependencies

1. Reflexivity: If Y is a subset of X, then X→Y holds by reflexivity rule

For example, {roll_no, name} → name is valid.
2. Augmentation: If X → Y is a valid dependency, then XZ → YZ is also valid by the
augmentation rule.
For example, If {roll_no, name} → dept_building is valid, hence {roll_no, name, dept_name}
→ {dept_building, dept_name} is also valid.→
3. Transitivity: If X → Y and Y → Z are both valid dependencies, then X→Z is also valid by
the Transitivity rule.

1
 For example, roll_no → dept_name & dept_name → dept_building, then roll_no →
dept_building is also valid.

Types of Functional Dependencies in DBMS

● Trivial functional dependency

● Non-Trivial functional dependency
● Multivalued functional dependency
● Transitive functional dependency

1. Trivial Functional Dependency

In Trivial Functional Dependency, a dependent is always a subset of the determinant.

i.e. If X → Y and Y is the subset of X, then it is called trivial functional dependency

For example,

roll_no name age

42 abc 17

43 pqr 18

44 xyz 18

Here, {roll_no, name} → name is a trivial functional dependency, since the dependent name is a
subset of determinant set {roll_no, name}

Similarly, roll_no → roll_no is also an example of trivial functional dependency.

2
2. Non-trivial Functional Dependency
In Non-trivial functional dependency, the dependent is strictly not a subset of the determinant.

i.e. If X → Y and Y is not a subset of X, then it is called Non-trivial functional dependency.

For example,

roll_no name age

42 abc 17

43 pqr 18

44 xyz 18

Here, roll_no → name is a non-trivial functional dependency, since the dependent name is not a
subset of determinant roll_no

Similarly, {roll_no, name} → age is also a non-trivial functional dependency, since age is not a subset
of {roll_no, name}

3. Multivalued Functional Dependency

In Multivalued functional dependency, entities of the dependent set are not dependent on each other.

i.e. If a → {b, c} and there exists no functional dependency between b and c, then it is called a
multivalued functional dependency.

For example,

roll_no name age

3
 42 abc 17

43 pqr 18

44 xyz 18

45 abc 19

Here, roll_no → {name, age} is a multivalued functional dependency, since the dependents name &
age are not dependent on each other(i.e. name → age or age → name doesn’t exist !)

4. Transitive Functional Dependency

In transitive functional dependency, dependent is indirectly dependent on determinant.

i.e. If a → b & b → c, then according to axiom of transitivity, a → c. This is a transitive functional

dependency

For example,

enrol_no name dept building_no

42 abc CO 4

4
 43 pqr EC 2

44 xyz IT 1

45 abc EC 2

Here, enrol_no → dept and dept → building_no,

Hence, according to the axiom of transitivity, enrol_no → building_no is a valid functional dependency.
This is an indirect functional dependency, hence called Transitive functional dependency.

5
What is Normalization?

● Database normalization is the process of organizing the attributes of the database to reduce
or eliminate data redundancy (having the same data but at different places) .
● Normalization is a database design technique that reduces data redundancy and eliminates
undesirable characteristics like Insertion, Update and Deletion Anomalies.
● Normalization rules divides larger tables into smaller tables and links them using
relationships.
● The purpose of Normalisation in SQL is to eliminate redundant (repetitive) data and ensure
data is stored logically.

Objective of Normalization

1. It is used to remove the duplicate data and database anomalies from the relational table.

2. Normalization helps to reduce redundancy and complexity by examining new data types used
in the table.

3. It is helpful to divide the large database table into smaller tables and link them using
relationship.

4. It avoids duplicate data or no repeating groups into a table.

5. It reduces the chances for anomalies to occur in a database.

Types of Anomalies

Following are the types of anomalies that make the table inconsistency, loss of integrity, and
redundant data.

1. Data redundancy occurs in a relational database when two or more rows or columns have the same
value or repetitive value leading to unnecessary utilization of the memory.

Student Table:

StudRegistration CourseID StudName Address Course

6
 205 6204 James Los Angeles Economics

205 6247 James Los Angeles Economics

224 6247 Trent Bolt New York Mathematics

230 6204 Ritchie Rich Egypt Computer

230 6208 Ritchie Rich Egypt Accounts

There are two students in the above table, 'James' and 'Ritchie Rich', whose records are repetitive
when we enter a new CourseID. Hence it repeats the studRegistration, StudName and address
attributes.

175.4K

Triggers in SQL (Hindi)

2. Insert Anomaly: An insert anomaly occurs in the relational database when some attributes or data
items are to be inserted into the database without existence of other attributes. For example, In the
Student table, if we want to insert a new courseID, we need to wait until the student enrolled in a
course. In this way, it is difficult to insert new record in the table. Hence, it is called insertion
anomalies.

3. Update Anomalies: The anomaly occurs when duplicate data is updated only in one place and not
in all instances. Hence, it makes our data or table inconsistent state. For example, suppose there is a
student 'James' who belongs to Student table. If we want to update the course in the Student, we
need to update the same in the course table; otherwise, the data can be inconsistent. And it reflects
the changes in a table with updated values where some of them will not.

7
4. Delete Anomalies: An anomaly occurs in a database table when some records are lost or deleted
from the database table due to the deletion of other records. For example, if we want to remove Trent
Bolt from the Student table, it also removes his address, course and other details from the Student
table. Therefore, we can say that deleting some attributes can remove other attributes of the database
table.

So, we need to avoid these types of anomalies from the tables and maintain the integrity, accuracy of
the database table. Therefore, we use the normalization concept in the database management
system.

Types of Normalization

1. First Normal Form (1NF)

2. Second Normal Form (2NF)

3. Third Normal Form (3NF)

4. Boyce and Codd Normal Form (BCNF)

5. Fourth Normal Form (4NF)

6. Fifth Normal Form (5NF)

First Normal Form (1NF): If a relation contain composite or multi-valued attribute, it violates first
normal form, or a relation is in first normal form if it does not contain any composite or multi-valued
attribute. A relation is in first normal form if every attribute in that relation is singled valued attribute.

1NF (First Normal Form) Rules

● Each table cell should contain a single value.

● Each record needs to be unique.

The table will be in First Normal Form (1NF) if all the attributes of the table contain only atomic
values. We can also say that if a table holds the multivalued data items in attributes or composite

8
values, the relation cannot be in the first normal form. So, we need to make it first normal form by
making the entries of the table atomic.

1. There are only Single Valued Attributes.(Atomic)

2. Attribute Domain does not change.
3. There is a Unique name for every Attribute/Column.
4. The order in which data is stored, does not matter.

Example-1:

Relation STUDENT in table 1 is not in 1NF because of multi-valued attribute STUD_PHONE. Its
decomposition into 1NF has been shown in table 2.

Second Normal Form (2NF): A Relation will be in 2NF if it follows the following condition:

1. The table or relation should be in 1NF or First Normal Form.

2. All the non-prime attributes should be fully functionally dependent on the candidate key.

3. The table should not contain any partial dependency.

4. Rule 1- Be in 1NF

5. Rule 2- Single Column Primary Key

9
Note – If the proper subset of candidate key determines non-prime attribute, it is called partial

dependency.

A functional dependency X --> Y is full functional dependency if removal of any attribute 'k' from X

means that the dependency does not hold any more. Full functional dependency is minimal in size.

Partial Functional Dependency Indicates that if A and B are attributes of a table, B is partially

dependent on A if there is some attribute that can be removed from A and yet the dependency still

holds.

A key is a set of attributes that uniquely identifies an entire tuple, a function dependency allow us to

express constraints that uniquely identify the values of certain attribute.

Example-1:

Consider table as following below.

STUD_NO COURSE_NO COURSE_FEE

1 C1 1000

2 C2 1500

1 C4 2000

4 C3 1000

4 C1 1000

2 C5 2000

{Note that, there are many courses having the same course fee. }

Here,

COURSE_FEE cannot alone decide the value of COURSE_NO or STUD_NO;

COURSE_FEE together with STUD_NO cannot decide the value of COURSE_NO;

COURSE_FEE together with COURSE_NO cannot decide the value of STUD_NO;

Hence,

10
COURSE_FEE would be a non-prime attribute, as it does not belong to the one only candidate key

{STUD_NO, COURSE_NO} ;

But, COURSE_NO -> COURSE_FEE, i.e., COURSE_FEE is dependent on COURSE_NO, which is a proper

subset of the candidate key. Non-prime attribute COURSE_FEE is dependent on a proper subset of

the candidate key, which is a partial dependency and so this relation is not in 2NF.

To convert the above relation to 2NF,

we need to split the table into two tables such as :

Table 1: STUD_NO, COURSE_NO

Table 2: COURSE_NO, COURSE_FEE

Table 1 Table 2

STUD_NO COURSE_NO COURSE_NO COURSE_FEE

1 C1 C1 1000

2 C2 C2 1500

1 C4 C3 1000

4 C3 C4 2000

4 C1 C5 2000

2 C5

Note – 2NF tries to reduce the redundant data getting stored in memory. For instance, if there are

100 students taking C1 course, we dont need to store its Fee as 1000 for all the 100 records, instead

once we can store it in the second table as the course fee for C1 is 1000.

Third Normal Form (3NF):

11
 1. The table or relation should be in 2NF.

2. It should not contain any transitive dependency. A Transitive Dependency is that any

non-prime attribute determines or depends on the other non-prime attribute.

A relation is in 3NF if FD X determines Y ('X' -> 'Y') satisfies one of the following condition:

1. If X -> Y is a trivial FD, i.e., Y is a subset of X.

2. If X -> Y, where X is a Super key.

3. If X -> Y, (Y - X) is a prime attribute.

A relation is in third normal form, if there is no transitive dependency for non-prime attributes as well

as it is in second normal form.

A relation is in 3NF if at least one of the following condition holds in every non-trivial function

dependency X –> Y:

1. X is a super key.
2. Y is a prime attribute (each element of Y is part of some candidate key).

In other words,

A relation that is in First and Second Normal Form and in which no non-primary-key attribute is

transitively dependent on the primary key, then it is in Third Normal Form (3NF).

Example-1:

In relation STUDENT given in Table 4,

FD set:

12
{STUD_NO -> STUD_NAME, STUD_NO -> STUD_STATE, STUD_STATE -> STUD_COUNTRY, STUD_NO ->

STUD_AGE}

Candidate Key:

{STUD_NO}

For this relation in table 4, STUD_NO -> STUD_STATE and STUD_STATE -> STUD_COUNTRY are true.

So STUD_COUNTRY is transitively dependent on STUD_NO. It violates the third normal form. To

convert it in third normal form, we will decompose the relation STUDENT (STUD_NO, STUD_NAME,

STUD_PHONE, STUD_STATE, STUD_COUNTRY_STUD_AGE) as:

STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_AGE)

STATE_COUNTRY (STATE, COUNTRY)

Example (Table violates 3NF)

<MovieListing>

Movie_ID Listing_ID Listing_Type DVD_Price ($)

0089 007 Comedy 100

0090 003 Action 150

0091 007 Comedy 100

The above table is not in 3NF because it has a transitive functional dependency −

Movie_ID -> Listing_ID

Listing_ID -> Listing_Type

Therefore, Movie_ID -> Listing_Type i.e. transitive functional dependency.

Example (Table converted to 3NF)

13
To form it in 3NF, you need to split the tables and remove the transitive functional dependency.

<Movie>

Movie_ID Listing_ID DVD_Price ($)

0089 007 100

0090 003 150

0091 007 100

<Listing>

Listing_ID Listing_Type

007 Comedy

003 Action

007 Comedy

Let us see the result again that is a table in 3NF now −

14
 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:

EMP_ID EMP_COUNTRY EMP_DEPT DEPT_TYPE EMP_DEPT_NO

264 India Designing D394 283

264 India Testing D394 300

364 UK Stores D283 232

15
 364 UK Developing D283 549

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:

EMP_COUNTRY table:

EMP_ID EMP_COUNTRY

264 India

264 India

EMP_DEPT table:

EMP_DEPT DEPT_TYPE EMP_DEPT_NO

Designing D394 283

Testing D394 300

Stores D283 232

Developing D283 549

16
EMP_DEPT_MAPPING table:

EMP_ID EMP_DEPT

D394 283

D394 300

D283 232

D283 549

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.

17