Amity School of Engineering & Technology

Amity School of Engineering and Technology

Course Title: Database Management System
Course Level: UG
Course Code: CSE201

1
 Amity School of Engineering & Technology

Course Objectives:

1.The objective of this course is to get students familiar with Databases and their
use.

2.They can identify different types of available database model, concurrency

techniques and new applications of the DBMS.

Pre-requisites: Knowledge about the data, knowledge about the operating

system and organization

Pedagogy for Course Delivery:

1.Classroom Teaching through lectures and presentation

2.Case studies

3.Lab work
2
 Amity School of Engineering & Technology

Course Learning Outcomes

1. Understand the database fundamentals along with conceptual modeling to deal real
life applications.

2. Develop the ability to retrieve and manipulate information for business decision
making from databases

3. Apply normalization techniques for consistent database development.

4. Understand the query processing techniques to automate the real time problems of
databases.

5. Analyze the problems of data management in a concurrent environment.

3
 Amity School of Engineering & Technology

Module III Functional Dependency and Normalization

1.Functional Dependency
2.Types of Functional Dependency
3.Decomposition-Lossy and Loss less Join
4.Normalization using Functional Dependency
5.Normalization
6.Types of Normalization(1NF,2NF, 3NF,
BCNF,4NF,5NF)
7. Multi-valued dependency(4NF)
8.Join dependency (5NF)
4
 Amity School of Engineering & Technology

What is Functional Dependency?

1.Functional Dependency (FD) is a constraint that determines the relation of one
attribute to another attribute in a Database Management System (DBMS).

2.Functional Dependency helps to maintain the quality of data in the database. It

plays a vital role to find the difference between good and bad database design.

3.A functional dependency is denoted by an arrow "→".

4.The functional dependency of X on Y is represented by X → Y. Let's

understand Functional Dependency in DBMS with example.

Y is FD on X
X- Determinant
Y-Dependent
5
 Example:

Amity School of Engineering & Technology

Employee Employee Name Salary City

number

1 Dana 50000 San Francisco

2 Francis 38000 London

3 Andrew 25000 Tokyo

In this example, 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.

Emp_No->Emp_name, City, Salary

Emp_No, Emp_name->City, Salary

6
 Amity School of Engineering & Technology

Key terms
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

7
 Amity School of Engineering & Technology

Rules of Functional Dependencies

Below are the Three most important rules for Functional Dependency in Database:

1.Reflexive rule –. If X is a set of attributes and Y is_subset_of X, then X holds a

value of Y. Example: X →Y

2.Augmentation rule: When x -> y holds, and c is attribute set, then xc -> yc also
holds. That is adding attributes which do not change the basic dependencies.

3.Transitivity rule: This rule is very much similar to the transitive rule in algebra if x -
> y holds and y -> z holds, then x -> z also holds. X -> y is called as functionally that
determines y.

8
 Amity School of Engineering & Technology

Axiom Name Axiom Example

if a is set of attributes, b ⊆ a, then
Reflexivity SSN,Name → SSN
a →b
if a→ b holds and c is a set of SSN → Name then
Augmentation
attributes, then ca→cb SSN,Phone → Name, Phone
if a →b holds and b→c holds, then SSN →Zip and Zip →
Transitivity
a→ c holds City then SSN →City
if a → b and a → c holds then SSN→Name and SSN→Zip th
Union or Additivity *
a→ bc holds en SSN→Name,Zip
Decomposition or if a → bc holds then a → b and SSN→Name,Zip then SSN→
Projectivity* a → c holds Name and SSN→Zip
Address →
if a → b and cb → d hold then Project and Project,Date
Pseudotransitivity*
ac → d holds →Amount then Address,Date
→ Amount
SSN,Date→Amount does not
(NOTE--common ab→ c does NOT imply
mistake) imply a → c and b → c SSN→Amount and Date→A
mount
9
 Amity School of Engineering & Technology

Types of Functional Dependencies in DBMS

There are mainly four types of Functional Dependency in DBMS. Following are the
types of Functional Dependencies in DBMS:

1.Multi-valued Dependency

2.Trivial Functional Dependency

3.Non-Trivial Functional Dependency

4.Transitive Dependency

10
 Amity School of Engineering & Technology

Multivalued Dependency in DBMS

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. Consider the
following Multivalued Dependency Example to understand.
Example:
Car_model Maf_year Color
H001 2017 Metallic
H001 2017 Green
H005 2018 Metallic
H005 2018 Blue
H010 2015 Metallic
H033 2012 Gray

In this example, maf_year and color are independent of each other but dependent on car_model. In
this example, these two columns are said to be multivalue dependent on car_model.
This dependence can be represented like this:
car_model -> maf_year
car_model-> colour 11
 Amity School of Engineering & Technology

Trivial Functional Dependency in DBMS

The Trivial dependency is a set of attributes which are called a trivial if the set of
attributes are included in that attribute.
So, X -> Y is a trivial functional dependency if Y is a subset of X. Let's understand
with a Trivial Functional Dependency Example.
For example:

Emp_id Emp_name
AS555 Harry
AS811 George
AS999 Kevin

Consider this table of with two columns Emp_id and Emp_name.

{Emp_id, Emp_name} -> Emp_id is a trivial functional dependency as Emp_id is a
subset of {Emp_id,Emp_name}.
{Stud_id, Stu_name}->Stu_id is a trivial FD as Stud_id is a subset of {Stud_id,
Stu_name}
12
 Amity School of Engineering & Technology

Emp-id-> Emp_Name – Functional Dependency

Emp_id, Emp_Name-> Emp_id ( Trivial FD)

13
 Amity School of Engineering & Technology

Non Trivial Functional Dependency in DBMS

Functional dependency which also known as a nontrivial dependency occurs when A-
>B holds true where B is not a subset of A. In a relationship, if attribute B is not a
subset of attribute A, then it is considered as a non-trivial dependency.

Company CEO Age

Microsoft Satya Nadella 51
Google Sundar Pichai 46
Apple Tim Cook 57

Example:

(Company} -> {CEO} (if we know the Company, we knows the CEO name)
But CEO is not a subset of Company, and hence it's non-trivial functional
dependency.
14
 Amity School of Engineering & Technology

Transitive Dependency in DBMS

A Transitive Dependency is a type of functional dependency which happens when t is
indirectly formed by two functional dependencies. Let's understand with the following
Transitive Dependency Example.
X->y y->z and x-> z
Example:

Company(x) CEO(y) Age(z)

Microsoft Satya Nadella 51
Google Sundar Pichai 46
Alibaba Jack Ma 54

{Company} -> {CEO} (if we know the compay, we know its CEO's name)
{CEO } -> {Age} If we know the CEO, we know the Age
Therefore according to the rule of rule of transitive dependency:
{ Company} -> {Age} should hold, that makes sense because if we know the company
name, we can know his age.
Note: You need to remember that transitive dependency can only occur in a relation of 15
three or more attributes.
 Amity School of Engineering & Technology

Advantages of Functional Dependency

1.Functional Dependency avoids data redundancy. Therefore
same data do not repeat at multiple locations in that database

2.It helps you to maintain the quality of data in the database

3.It helps you to defined meanings and constraints of databases

4.It helps you to identify bad designs

5.It helps you to find the facts regarding the database design

16
 Amity School of Engineering & Technology

Example- A dependency diagram, shown in Fig illustrates the various

dependencies that might exist in a non-normalized table.
A non-normalized table is one that has data redundancy in it.

The following dependencies are identified in this table:

ProjectNo and EmpNo, combined, are the PK.
Partial Dependencies:
ProjectNo —> ProjName
EmpNo —> EmpName, DeptNo,
ProjectNo, EmpNo —> HrsWork
Transitive Dependency:
DeptNo —> DeptName 17
 Amity School of Engineering & Technology

Example Functional Dependencies

Let R be NewStudent(stuId, lastName, major, credits, status, socSecNo)

FDs in R include
 {stuId}→{lastName}, but not the reverse
 {stuId} →{lastName, major, credits, status, socSecNo, stuId}
 {socSecNo} →{stuId, lastName, major, credits, status, socSecNo}
 {credits}→{status}, but not {status}→{credits}

1.ZipCode→Address,City
 16652 is Huntingdon’s ZIP
2.ArtistName→BirthYear
 Picasso was born in 1881
3.Autobrand→Manufacturer, Engine type
 Pontiac is built by General Motors with gasoline engine
4.Author, Title→PublDate
 Shakespeare’s Hamlet was published in 1600
18
 Amity School of Engineering & Technology

What are the FDs?

PRESIDENTS (Pres, Spouse, State, Party, VP, AdminNum, BirthDate, DeathDate)

PRESIDENTS (Pres, Spouse, State, Party, BirthDate, DeathDate)

STATES (State, Pop, Capital, Votes, AdminNo) //AdminNo associates the
administration number when the state was admitted
ELECTIONS (Year, Pres, TotalVotes) // TotalVotes is the electoral college votes
ADMINISTRATIONS (AdminNo, Pres, InaugDate) //a reelected President will
have a second administration
ADMINVPS(VP, AdminNo)
ELECTIONLOSERS(Year, Loser, LoserVotes, Party) // LoserVotes is the
electoral college votes
PARTYHISTORIES(Party, YearStart)

Pres->Spouse, BD,DD
Pres, State->Party
Pres, Party->State 19
Pres->VP
Amity School of Engineering & Technology

20
 Amity School of Engineering & Technology

Axiom Name Axiom Example

if a is set of attributes, b ⊆ a, then
Reflexivity SSN,Name → SSN
a →b
if a→ b holds and c is a set of SSN → Name then
Augmentation
attributes, then ca→cb SSN,Phone → Name, Phone
if a →b holds and b→c holds, then SSN →Zip and Zip →
Transitivity
a→ c holds City then SSN →City
if a → b and a → c holds then SSN→Name and SSN→Zip th
Union or Additivity *
a→ bc holds en SSN→Name,Zip
Decomposition or if a → bc holds then a → b and SSN→Name,Zip then SSN→
Projectivity* a → c holds Name and SSN→Zip
Address →
if a → b and cb → d hold then Project and Project,Date
Pseudotransitivity*
ac → d holds →Amount then Address,Date
→ Amount
SSN,Date→Amount does not
(NOTE--common ab→ c does NOT imply
mistake) imply a → c and b → c SSN→Amount and Date→A
mount
21
 Amity School of Engineering & Technology

Identify the functional dependencies of the corresponding application. Identify

possible redundancies and anomalies in the relation.

22
 Amity School of Engineering & Technology

Decomposition
•Decomposition in DBMS removes redundancy, anomalies and inconsistencies from a
database by dividing the table into multiple tables. A functional decomposition is the
process of breaking down the functions of an organization into progressively greater
(finer and finer) levels of detail.
•The decomposition of a relation scheme R consists of replacing the relation schema
by two or more relation schemas that each contain a subset of the attributes of R and
together include all attributes in R.
•Decomposition helps in eliminating some of the problems of bad design such as
redundancy, inconsistencies and anomalies.
The following are the types −
1.Lossless Decomposition -Decomposition is lossless if it is feasible to reconstruct
relation R from decomposed tables using Joins. This is the preferred choice. The
information will not lose from the relation when decomposed. The join would result in
the same original relation.
2.Lossy Decomposition- As the name suggests, when a relation is decomposed into
two or more relational schemas, the loss of information is unavoidable when the
original relation is retrieved.
23
Amity School of Engineering & Technology

24
Amity School of Engineering & Technology

25
Amity School of Engineering & Technology

26
 Amity School of Engineering & Technology

Consider that we have table STUDENT with three attribute roll_no , sname
and department.

STUDENT:

Roll_no Sname Dept

111 parimal COMPUTER
222 parimal ELECTRICAL

This relation is decomposed into two relation no_name and name_dept :

No_name: Name_dept :

Roll_no Sname Sname Dept

111 parimal parimal COMPUTER
222 parimal parimal ELECTRICAL 27
 Amity School of Engineering & Technology

In lossy decomposition ,spurious tuples are generated when a natural join is applied to
the relations in the decomposition.

stu_joined :

Roll_no Sname Dept

111 Parimal COMPUTER
111 Parimal ELECTRICAL
222 parimal COMPUTER
222 parimal ELECTRICAL

The above decomposition is a bad decomposition or Lossy decomposition.

28
 Amity School of Engineering & Technology

The lossless-join decomposition is always defined with respect to a specific set F of

dependencies.
Consider that we have table STUDENT with three attribute roll_no , sname and
department.
STUDENT :
Roll_no Sname Dept
111 parimal COMPUTER
222 parimal ELECTRICAL

This relation is decomposed into two relation Stu_name and Stu_dept :

Stu_name: Stu_dept :

Roll_no Sname Roll_no Dept

111 parimal 111 COMPUTER
222 parimal 222 ELECTRICAL
29
 Amity School of Engineering & Technology

Now ,when these two relations are joined on the comman column 'roll_no' ,the
resultant relation will look like stu_joined.

stu_joined :

Roll_no Sname Dept

111 parimal COMPUTER
222 parimal ELECTRICAL

In lossless decomposition, no any spurious tuples are generated when a natural

joined is applied to the relations in the decomposition.

30
 Amity School of Engineering & Technology

What is Normalization?
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 Normalization in SQL is to eliminate redundant (repetitive) data and

ensure data is stored logically.

The inventor of the relational model Edgar Codd proposed the theory of
normalization of data with the introduction of the First Normal Form, and he
continued to extend theory with Second and Third Normal Form. Later he joined
Raymond F. Boyce to develop the theory of Boyce-Codd Normal Form.

31
 Amity School of Engineering & Technology

Database Normal Forms

Here is a list of Normal Forms

1.1NF (First Normal Form)

2.2NF (Second Normal Form)

3.3NF (Third Normal Form)

4.BCNF (Boyce-Codd Normal Form)

5.4NF (Fourth Normal Form)

6.5NF (Fifth Normal Form)

7.6NF (Sixth Normal Form)

32
 Amity School of Engineering & Technology

The Theory of Data Normalization in SQL server is still being developed further. For
example, there are discussions even on 6th Normal Form.

However, in most practical applications, normalization achieves its best in

3rd Normal Form.

The evolution of SQL Normalization theories is illustrated below-

Database Normal Forms

33
 Amity School of Engineering & Technology

Database Normalization With Examples

Database Normalization Example can be easily understood with the help of a case study.
Assume, a video library maintains a database of movies rented out. Without any
normalization in database, all information is stored in one table as shown below. Let's
understand Normalization in database with tables example:

Here you see Movies Rented column has multiple values. Now let's move into 1st Normal
34
Forms:
 Amity School of Engineering & Technology

What is Composite Key?

A composite key is a primary key composed of multiple columns used to identify a

record uniquely. In our database, we have two people with the same name Robert
Phil, but they live in different places.

Hence, we require both Full Name and Address to identify a record uniquely. That is
a composite key.
Let's move into second normal form 2NF

35
 Amity School of Engineering & Technology

1NF (First Normal Form) Rules

1.Each table cell should contain a single value.
2.Each record needs to be unique.
1NF Example

36
 Amity School of Engineering & Technology

Before we proceed let's understand a few things –

What is a KEY?
A KEY is a value used to identify a record in a table uniquely. A KEY could be a single
column or combination of multiple columns
Note: Columns in a table that are NOT used to identify a record uniquely are called non-
key columns.(Non key attributes)

What is a Primary Key?

A primary is a single column value used to identify a database record uniquely.

It has following attributes

A primary key cannot be NULL

A primary key value must be unique
The primary key values should rarely be changed
The primary key must be given a value when a new record is inserted.
37
 Amity School of Engineering & Technology

2NF (Second Normal Form) Rules

Rule 1- Be in 1NF
Rule 2- Single Column Primary Key
It is clear that we can't move forward to make our simple database in 2 nd Normalization
form unless we partition the table above.

We have divided our 1NF table into two tables viz. Table 1 and Table2. Table 1
contains member information. Table 2 contains information on movies rented.
We have introduced a new column called Membership_id which is the primary key for
table 1. Records can be uniquely identified in Table 1 using membership id
38
 Amity School of Engineering & Technology

Database - Foreign Key

In Table 2, Membership_ID is the Foreign Key

Foreign Key references the primary key of another Table! It helps connect your Tables

1.A foreign key can have a different name from its primary key
2.It ensures rows in one table have corresponding rows in another
3.Unlike the Primary key, they do not have to be unique. Most often they aren't
4.Foreign keys can be null even though primary keys can not

39
Amity School of Engineering & Technology

40
 Amity School of Engineering & Technology

Why do you need a foreign key?

Suppose, a novice inserts a record in Table B such as

You will only be able to insert values into your foreign key that exist in the unique key
in the parent table. This helps in referential integrity.
The above problem can be overcome by declaring membership id from Table2 as
foreign key of membership id from Table1
Now, if somebody tries to insert a value in the membership id field that does not exist
41
in the parent table, an error will be shown!
 Amity School of Engineering & Technology

What are transitive functional dependencies?

A transitive functional dependency is when changing a non-key column, might cause
any of the other non-key columns to change
Consider the table 1. Changing the non-key column Full Name may change
Salutation.

Let's move into 3NF

Student(Rollno, Name, Department, Year, Hostelname)

FD1-------------Rollno->name, dept, year, hostel
FD2---------------Year->hostelname
FD3----------------Rollno->name, department
42
 3NF (Third Normal Form) :
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).

Note – If A->B and B->C are two FDs then A->C is called transitive
dependency.
The normalization of 2NF relations to 3NF involves the removal of
transitive dependencies.

•If a transitive dependency exists, we remove the

transitively dependent attribute(s) from the relation by
placing the attribute(s) in a new relation along with a
copy of the determinant.

43
 Example-1:
In relation STUDENT given in Table

FD set:
{STUD_NO -> STUD_NAME,
STUD_NO -> STUD_STATE,
STUD_STATE -> STUD_COUNTRY,
STUD_NO -> STUD_AGE
STUD_NO-> STUD_COUNTRY}

Candidate Key:
{STUD_NO}

For this relation in given table , 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.
44
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)

45
 Example 2:
Below is a student table that has student id, student name, subject id, subject
name, and address of the student as its columns.

In the above student table,

stu_id -> subid, and
subid -> sub.
Therefore, stu_id -> sub.

This implies that the table possesses a transitive functional dependency, and it does
not fulfill the third normal form criteria.

Now to change the table to the third normal form, you need to divide the table as
shown below: 46
As you can see in both the tables,
•All the non-key attributes are now fully functional, dependent only on
the primary key.
•In the first table, columns name, subid, and addresses only depend
on stu_id.
•In the second table, the subject only depends on subid.

47
 Amity School of Engineering & Technology

3NF (Third Normal Form) Rules

Rule 1- Be in 2NF
Rule 2- Has no transitive functional dependencies
To move our 2NF table into 3NF, we again need to again divide our table.
3NF Example
Below is a 3NF example in SQL database:

48
 Amity School of Engineering & Technology

We have again divided our tables and created a new table which stores Salutations.

•There are no transitive functional dependencies, and hence our table is in 3NF.
•In Table 3 Salutation ID is primary key, and in Table 1 Salutation ID is foreign to
primary key in Table 3.

49
Super Key

Super key is a set of over one key that can identify a record uniquely in a
table, and the Primary Key is a subset of Super Key.

Let’s understand this with the help of an example.

50
 Amity School of Engineering & Technology
Boyce Codd normal form (BCNF)

BCNF is the advance version of 3NF. It is stricter than 3NF. Boyce Codd Normal Form
is also known as 3.5 NF.

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 every Right-Hand Side (RHS) attribute
of the functional dependencies should depend on the super key of that particular
table. i.e. LHS is super key.

Example: You have a functional dependency X → Y. In the particular functional

dependency, X has to be the part of the super key of the provided table.

Any table is said to be in BCNF, if its candidate keys do not have any partial
dependency on the other attributes.
i.e.; in any table with (x, y, z) columns, if (x, y)->z and z->x then it’s a
violation of BCNF. If (x, y) are keys and (x, y)->z, then there should not be
any reverse dependency, directly or partially. 51
The subject table follows these conditions:

•Each student can enroll in multiple subjects.

•Multiple professors can teach a particular subject.
•For each subject, it assigns a professor to the student.

In the above table, student_id and subject together form the primary key because
using student_id and subject; you can determine all the table columns.

Stuid, subject -> professor (1)

Another important point to be noted here is that one professor teaches only one
subject, but one subject may have two professors.

Which exhibit there is a dependency between subject and professor, i.e. subject 52
depends on the professor's name.
Above table follows all the Normal forms except the Boyce Codd Normal Form.

However, there exists yet another dependency –

professor → subject (2)
As you can see stuid, and subject forms the primary key, which means the subject
attribute is a prime attribute.

BCNF does not follow in the table as a subject is a prime attribute, the professor is a
non-prime attribute.
To transform the table into the BCNF, you will divide the table into two parts. One table
will hold stuid which already exists and the second table will hold a newly created column
profid.

And in the second table will have the columns profid, subject, and professor,
which satisfies the BCNF. 53
 Amity School of Engineering & Technology
(BCNF): Example 2

For BCNF, the table should be in 3NF, and every Right-Hand Side (RHS) attribute of
the functional dependencies should depend on the super key of that particular table. i.e.
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
364 UK Designing D283 549

54
 Amity School of Engineering & Technology

In the above table Functional dependencies are as follows:

EMP_ID → EMP_COUNTRY
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
364 UK

55
 Amity School of Engineering & Technology

EMP_DEPT table:
EMP_DEPT DEPT_TYPE EMP_DEPT_NO

Designing D394 283

Testing D394 300
Stores D283 232
Designing D283 549

EMP_DEPT_MAPPING table:

EMP_ID EMP_DEPT

264 283

264 300

364 232

364 549

56
BCNF Example and Assessment Questions
Professor(Prof_code,Dept,HOD,Percent_Time)
It is assumed that-
1.A professor can work in more than one department.
2.The percentage of the time he/she spends in each department is given
3.Each department has only one HOD.

FD1 Prof_code, Department->HOD, Percent_time

FD2 Department->HOD
FD3 HOD, Prof_code-> Department, Percent_time

Table 1
Department, Prof_code->Percent_time
Table 2
Department->HOD
57
 Amity School of Engineering & Technology

Fourth normal form (4NF)

A relation will be in 4NF if it is in Boyce Codd normal form and has no multi-valued
dependency. For a dependency A → B, if for a single value of A, multiple values of
B exists, then the relation will be a multi-valued dependency.
STUDENT STU_ID(A) COURSE(B) HOBBY(C )

21 Computer Dancing
21 Math Singing
34 Chemistry Dancing
74 Biology Cricket
59 Physics Hockey

The given STUDENT table is in 3NF, but the COURSE and HOBBY are two
independent entity.

Hence, there is no relationship between COURSE and HOBBY.

In the STUDENT relation, a student with STU_ID, 21 contains two

courses, Computer and Math and two hobbies, Dancing and Singing. So there is a
Multi-valued dependency on STU_ID, which leads to unnecessary repetition of data. 58
 Amity School of Engineering & Technology

So to make the above table into 4NF, we can decompose it into two tables:
STUDENT_COURSE
STU_ID COURSE

21 Computer
21 Math
34 Chemistry
74 Biology
59 Physics

STUDENT_HOBBY
STU_ID HOBBY

21 Dancing
21 Singing
34 Dancing
74 Cricket
59 Hockey
59
 Amity School of Engineering & Technology

Fifth normal form (5NF)

A relation is in 5NF if it is in 4NF and not contains any join dependency and joining
should be lossless.
5NF is satisfied when all the tables are broken into as many tables as possible in order
to avoid redundancy.
5NF is also known as Project-join normal form (PJ/NF).
Example
SUBJECT LECTURER SEMESTER

Computer Anshika Semester 1

Computer John Semester 1
Math John Semester 1
Math Akash Semester 2
Chemistry Praveen Semester 1

In the above table, John takes both Computer and Math class for Semester 1 but he
doesn't take Math class for Semester 2. In this case, combination of all these fields
required to identify a valid data.
60
 Amity School of Engineering & Technology

Suppose we add a new Semester as Semester 3 but do not know about the subject and
who will be taking that subject so we leave Lecturer and Subject as NULL.
But all three columns together acts as a primary key, so we can't leave other two
columns blank.
So to make the above table into 5NF, we can decompose it into three relations P1, P2
& P3:

61
 Amity School of Engineering & Technology

P1
SEMESTER SUBJECT

Semester 1 Computer
Semester 1 Math
Semester 1 Chemistry
Semester 2 Math

P2

SUBJECT LECTURER

Computer Anshika
Computer John
Math John
Math Akash
Chemistry Praveen

62
 Amity School of Engineering & Technology

P3
SEMSTER LECTURER

Semester 1 Anshika
Semester 1 John
Semester 1 John
Semester 2 Akash
Semester 1 Praveen

63
 Amity School of Engineering & Technology

First normal form (1NF)

As per the rule of first normal form, an attribute (column) of a table cannot hold
multiple values. It should hold only atomic values.
Example: Suppose a company wants to store the names and contact details
of its employees. It creates a table that looks like this:

emp_id emp_name emp_address emp_mobile

101 Herschel New Delhi 8912312390
8812121212
102 Jon Kanpur
9900012222
103 Ron Chennai 7778881212
9990000123
104 Lester Bangalore
8123450987

Two employees (Jon & Lester) are having two mobile numbers so the
company stored them in the same field as you can see in the table above.
64
This table is not in 1NF as the rule says “each attribute of a table must have
atomic (single) values”, the emp_mobile values for employees Jon & Lester
violates that rule.
To make the table complies with 1NF we should have the data like this:
emp_id emp_name emp_address emp_mobile
101 Herschel New Delhi 8912312390
102 Jon Kanpur 8812121212
102 Jon Kanpur 9900012222
103 Ron Chennai 7778881212
104 Lester Bangalore 9990000123
104 Lester Bangalore 8123450987

65
Second normal form (2NF)
A table is said to be in 2NF if both the following conditions hold:
Table is in 1NF (First normal form)
No non-prime attribute is dependent on the proper subset of any candidate
key of table.
An attribute that is not part of any candidate key is known as non-prime
attribute.
Example: Suppose a school wants to store the data of teachers and the
subjects they teach. They create a table that looks like this: Since a teacher
can teach more than one subjects, the table can have multiple rows for a
same teacher.

teacher_id subject teacher_age

111 Maths 38
111 Physics 38
222 Biology 38
333 Physics 40
333 Chemistry 40
66
Candidate Keys: {teacher_id, subject}
Non prime attribute: teacher_age
The table is in 1 NF because each attribute has atomic values. However, it is
not in 2NF because non prime attribute teacher_age is dependent on
teacher_id alone which is a proper subset of candidate key. This violates the
rule for 2NF as the rule says “no non-prime attribute is dependent on the
proper subset of any candidate key of the table”.
To make the table complies with 2NF we can break it in two tables like this:

teacher_details table: teacher_subject table:

teacher_id teacher_age teacher_id subject
111 38 111 Maths
222 38 111 Physics
333 40 222 Biology
333 Physics
333 Chemistry

Now the tables comply with Second normal form (2NF). 67

Third Normal form (3NF)
A table design is said to be in 3NF if both the following conditions hold:
Table must be in 2NF
Transitive functional dependency of non-prime attribute on any super key
should be removed.
An attribute that is not part of any candidate key is known as non-prime
attribute.
In other words 3NF can be explained like this: A table is in 3NF if it is in 2NF
and for each functional dependency X-> Y at least one of the following
conditions hold:
X is a super key of table
Y is a prime attribute of table
An attribute that is a part of one of the candidate keys is known as prime
attribute.
Example: Suppose a company wants to store the complete address of each
employee, they create a table named employee_details that looks like this:

68
emp_id emp_name emp_zip emp_state emp_city emp_district

1001 John 282005 UP Agra Dayal Bagh

1002 Ajeet 222008 TN Chennai M-City

1006 Lora 282007 TN Chennai Urrapakkam

1101 Lilly 292008 UK Pauri Bhagwan

1201 Steve 222999 MP Gwalior Ratan

Super keys: {emp_id}, {emp_id, emp_name}, {emp_id, emp_name, emp_zip}

…so on
Candidate Keys: {emp_id}
Non-prime attributes: all attributes except emp_id are non-prime as they are
not part of any candidate keys.
.

69
Here, emp_state, emp_city & emp_district dependent on emp_zip. And,
emp_zip is dependent on emp_id that makes non-prime attributes (emp_state,
emp_city & emp_district) transitively dependent on super key (emp_id). This
violates the rule of 3NF
To make this table complies with 3NF we have to break the table into two
tables to remove the transitive dependency:
employee table:

emp_id emp_name emp_zip

1001 John 282005
1002 Ajeet 222008
1006 Lora 282007
1101 Lilly 292008
1201 Steve 222999

70
employee_zip table:

emp_zip emp_state emp_city emp_district

282005 UP Agra Dayal Bagh
222008 TN Chennai M-City
282007 TN Chennai Urrapakkam
292008 UK Pauri Bhagwan
222999 MP Gwalior Ratan

71
Boyce Codd normal form (BCNF)
It is an advance version of 3NF that’s why it is also referred as 3.5NF. BCNF is
stricter than 3NF. A table complies with BCNF if it is in 3NF and for every
functional dependency X->Y, X should be the super key of the table.
Example: Suppose there is a company wherein employees work in more than
one department. They store the data like this:

emp_nationalit dept_no_of_e
emp_id emp_dept dept_type
y mp

Production
1001 Austrian D001 200
and planning

1001 Austrian stores D001 250

design and
1002 American technical D134 100
support
Purchasing
1002 American D134 600
department

72
Functional dependencies in the table above:
emp_id -> emp_nationality
emp_dept -> {dept_type, dept_no_of_emp}
Candidate key: {emp_id, emp_dept}
The table is not in BCNF as neither emp_id nor emp_dept alone are keys.
To make the table comply with BCNF we can break the table in three tables
like this:
emp_nationality table:

emp_id emp_nationality
1001 Austrian
1002 American

73
emp_dept table:
emp_dept dept_type dept_no_of_emp
Production and
D001 200
planning
stores D001 250
design and technical
D134 100
support
Purchasing
D134 600
department

emp_dept_mapping table:

emp_id emp_dept
1001 Production and planning
1001 stores
1002 design and technical support
1002 Purchasing department
74
Functional dependencies:
emp_id -> emp_nationality
emp_dept -> {dept_type, dept_no_of_emp}
Candidate keys:
For first table: emp_id
For second table: emp_dept
For third table: {emp_id, emp_dept}
This is now in BCNF as in both the functional dependencies left side part is a
key.

75
 S.NO 4NF 5NF
A relation in 4NF must also be in BCNF(Boyce A relation in 5NF must also be in 4NF(Fourth Normal
1.
Codd Normal Form). Form).

A relation in 4NF must not have any multi-valued

2. A relation in 5NF must not have any join dependency.
dependency.

3. A relation in 4NF may or may not be in 5NF. A relation in 5NF is always in 4NF

Fourth Normal Form is less stronger in Fifth Normal form is more stronger than Fourth
4.
comparison to Fifth Normal form. Normal Form.

If a relation is in Fourth Normal Form then it will If a relation is in Fifth Normal Form then it will less
5.
have more redundancy. redundancy.

If a relation is in Fifth Normal Form then it cannot be

If a relation is in Fourth Normal Form then it may
6. decomposed further into sub-relations without any
be decomposed further into sub-relations.
modification in meaning or facts.

76
Thanks

77