2025

DATABASE MANAGEMENT SYSTEMS

(DBMS) UNIT 4 NOTES

FACULTY
SURESH
suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

UNIT IV
Schema Refinement (Normalization): Purpose of Normalization or schema refinement,
concept of functional dependency, normal forms based on functional dependency(1NF,
2NF and 3 NF), concept of surrogate key, Boyce-codd normal form(BCNF), Lossless join
and dependency preserving decomposition, Fourth normal form(4NF), Fifth Normal
Form (5NF).

SCHEMA REFINEMENT(Normalization)
The problems caused by the data redundant in the tables can be reduced by using
decomposition technique called Schema Refinement (also called as Normalization).
Problems Caused by Redundancy:
Storing the same information redundantly, that is, in more than one place within
a database, can lead to several problems:
Redundant storage: Some information is stored repeatedly.
Update anomalies: If one copy of such repeated data is updated, an
inconsistency is created unless all copies are similarly updated.
Insertion anomalies: It may not be possible to store some information unless
some other information is stored as well.
Deletion anomalies: It may not be possible to delete some information without
losing some other information as well.

Consider a relation Hourly_Emps(ssn,name,lot,rating,hourly_wages,

hours_worked):
Assume that the key attribute is ssn and hourly_wages is depending rating
attribute. That is for a given rating value , there is only one permissible
hourly_wages value. This IC(Integrity Constraint) is the functional dependency.
ssn name lot rating Hourly_wages Hours_worked
11-22 Aaa 48 8 10 40
22-33 Bbb 22 8 10 30
33-44 Ccc 35 5 7 30
44-55 Ddd 35 5 7 32
55-66 Eee 40 8 10 40

Problem in the above table:

Redundant storage: Rating and Hourly_wages (8,10), (5,7) are repeated.
Update Anomalies: if we modify the hourly_wage for in the first record without
making similar change in the second row.
Delete Anomalies: If we delete Ccc and Ddd rows, then we loss the association
between rating and hourly_wage for rating 5.

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

Insert Anomalies: We cannot insert a row unless we know the hourly_wages.

What is decomposition?
 Decomposition is the process of breaking down in parts or elements.
 It replaces a relation with a collection of smaller relations.
 It breaks the table into multiple tables in a database.
 It should always be lossless, because it confirms that the information in the
original relation can be accurately reconstructed based on the decomposed
relations.
 If there is no proper decomposition of the relation, then it may lead to
problems like loss of information.

We can decompose Hourly_Emps into two relations:

Hourly_Emps2(ssn,name,lot,rating,hours_worked)

Wages(rating,hourly_wages)

Hourly_Emps table:
ssn name lot rating Hours_worked
11-22 Aaa 48 8 40
22-33 Bbb 22 8 30
33-44 Ccc 35 5 30
44-55 Ddd 35 5 32
55-66 Eee 40 8 40

Wages table:

rating Hourly_wages
8 10
5 7

Problems Related to Decomposition:

Decomposition may cause some problems unless we careful in decomposition.
There are two important questions for decomposition:
1)Do we need to decompose a relation?

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

2)What problems(if any) does a given decomposition cause?

The first question question can be answered based on the several normal foms have
been proposed for relations. Whether decomposition need or not depends the normal
forms of the relation.
The second question can be answered on the two possible properties of decomposition.

Properties of Decomposition:

Following are the properties of Decomposition,

1. Lossless Decomposition

If we decompose a relation R into relations R1 and R2, then this Decomposition is

Lossless if R1 ⋈ R2 = R (join of R1 and R2 is same as to R).

2. Dependency Preservation

If we decompose a relation R into relations R1 and R2, All dependencies of R either

must be a part of R1 or R2 or must be derivable from combination of FD’s of R1 and R2.

Functional Dependency:
Functional Dependency is when one attribute determines another attribute in a
DBMS system. 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.
A functional dependency is denoted by an arrow →
The functional dependency of X on Y is represented by X →Y
The left side of FD is known as a determinant, the right side of the production is
known as a schema refinement.
For example:
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.

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

Rules of Functional Dependencies

Below given are the Three most important rules for Functional Dependency:
 Reflexive rule : If X is a set of attributes and Y is subset of X, then X holds
a value of Y.
 Augmentation rule: When x -> y holds, and Z is attribute set, then XZ ->
YZ also holds. That is adding attributes which do not change the basic
dependencies.
 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.
 Union Property:If x->y and x -> z are true then x -> yz us also true.
 Decomposition Property: If x -> y is d z is subset of y, then x -> z is
implied.
 This property is reverse of union property.
 Psudo Transitive rule: If x -> y and wy -> z aregiven, then xw -> z is true.

Types of Functional Dependencies

 Multivalued dependency:
 Trivial functional dependency:
 Non-trivial functional dependency:
 Transitive dependency:

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.
Example:
Car_model Maf_year Color

H001 2017 Metallic

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

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

Trivial Functional dependency:

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.

For example:
Emp id Emp name

AS555 Harry

AS811 George

AS999 Kevin
Consider this table 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}.

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

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

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.

Transitive dependency:
A transitive is a type of functional dependency which happens when t is
indirectly formed by two functional dependencies.
Example:
Company CEO Age

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 three or more attributes.

Fully Functional Dependency:

Full Functional Dependency : In a relation , there exists Full Functional
Dependency between any two attributes X and Y, when X is functionally
dependent on Y and is not functionally dependent on any proper subset of Y.
Example: ABC->D
D is fully functionally Dependent on ABC if D cannot dependant on any sub set
of ABC.
AB -> D
A -> D
B -> D

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

BC -> D
Not possible the above because AB can not determine D, or A cannot determine
D, BC also can not determine D.

Partial Functional Dependency : In a relation, there exists Partial Dependency,

when a non prime attribute (the attributes which are not a part of any candidate
key ) is functionally dependent on a proper subset of Candidate Key.

Closure Of Functional Dependency : Introduction

 The Closure Of Functional Dependency means the complete set of all
possible attributes that can be functionally derived from given functional
dependency using the inference rules known as Armstrong’s Rules.
 If “F” is a functional dependency then closure of functional dependency
can be denoted using “{F}+”.
 There are three steps to calculate closure of functional dependency. These
are:
Step-1 : Add the attributes which are present on Left Hand Side in the original
functional dependency.
Step-2 : Now, add the attributes present on the Right Hand Side of the functional
dependency.
Step-3 : With the help of attributes present on Right Hand Side, check the other
attributes that can be derived from the other given functional dependencies.
Repeat this process until all the possible attributes which can be derived are
added in the closure.
 Seems difficult? Check out the example explained below and it will surely
clear your doubt on how to calculate closure of functional dependency.

Closure Of Functional Dependency : Examples

Example-1 : Consider the table student_details having (Roll_No, Name,Marks,
Location) as the attributes and having two functional dependencies.
FD1 : Roll_No -> Name, Marks
FD2 : Name ->Marks, Location

Now, We will calculate the closure of all the attributes present in the relation
using the three steps mentioned below.

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

Step-1 : Add attributes present on the LHS of the first functional dependency to the closure.
{Roll_no}+ = {Roll_No}
Step-2 : Add attributes present on the RHS of the original functional
dependency to the closure.
{Roll_no}+ = {Roll_No, Marks}
Step-3 : Add the other possible attributes which can be derived using attributes present
on the RHS of the closure. So Roll_No attribute cannot functionally determine any
attribute but Name attribute can determine other attributes such as Marks and Location
using 2nd Functional Dependency(Name-> Marks, Location).

Therefore, complete closure of Roll_No will be :

{Roll_no}+ = {Roll_No, Marks, Name, Location}
Similarly, we can calculate closure for other attributes too i.e “Name”.
Step-1 : Add attributes present on the LHS of the functional dependency to the closure.
{Name}+ = {Name}
Step-2 : Add the attributes present on the RHS of the functional dependency to the closure.
{Name}+ = {Name, Marks, Location}
Step-3 : Since, we don’t have any functional dependency where “Marks or Location”
attribute is functionally determining any other attribute , we cannot add more attributes
to the closure. Hence complete closure of Name would be :
{Name}+ = {Name, Marks, Location}
NOTE : We don’t have any Functional dependency where marks and location can
functionally determine any attribute. Hence, for those attributes we can only add the
attributes themselves in their closures. Therefore,
{Marks}+ = {Marks}
and
{Location}+ = { Location}

Example-2 : Consider a relation R(A,B,C,D,E) having below mentioned

functional dependencies.
FD1 : A -> BC
FD2 : C -> B
FD3 : D -> E
FD4 : E -> D

Now, we need to calculate the closure of attributes of the relation R. The closures
will be:
{A}+ = {A, B, C}
{B}+ = {B}
{C}+ = {B, C}

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

{D}+ = {D, E}
{E}+ = {E}
Closure Of Functional Dependency : Calculating Candidate Key
 “A Candidate Key of a relation is an attribute or set of attributes that can
determine the whole relation or contains all the attributes in its closure."
 Let’s try to understand how to calculate candidate keys.
Example-1 : Consider the relation R(A,B,C) with given functional dependencies :
FD1 : A -> B
FD2 : B -> C
Now, calculating the closure of the attributes as :
{A}+ = {A, B, C}
{B}+ = {B, C}
{C}+ = {C}
Clearly, “A” is the candidate key as, its closure contains all the attributes present
in the relation “R”.
Example-2 : Consider another relation R(A, B, C, D, E) having the Functional
dependencies :
FD1 : A -> BC
FD2 : C-> B
FD3 : D -> E
FD4 : E -> D
Now, calculating the closure of the attributes as :
{A}+ = {A, B, C}
{B}+ = {B}
{C}+ = {C, B}
{D}+ = {E, D}
{E}+ = {E, D}
In this case, a single attribute is unable to determine all the attribute on its own
like in previous example. Here, we need to combine two or more attributes to
determine the candidate keys.
{A, D}+ = {A, B, C, D, E}
{A, E}+ = {A, B, C, D, E}
Hence, "AD" and "AE" are the two possible keys of the given relation “R”. Any
other combination other than these two would have acted as extraneous
attributes.

NOTE : Any relation “R” can have either single or multiple candidate keys.

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

Closure Of Functional Dependency : Key Definitions

1. Prime Attributes: Attributes which are part of candidate keys. For example
: If AD and AE are candidate keys then A, D, and E attributes are prime
attributes.
2. Non-Prime Attributes: Attributes other than prime attributes which does
not take part in formation of candidate keys. Example: B and C are non
Prime attributes.
3. Extraneous Attributes: Attributes which does not make any effect on
removal from candidate key.

For example : Consider the relation R(A, B, C, D) with functional dependencies :

FD1 : A-> BC
FD2 : B-> C
FD3 : D -> C
Here, Candidate key can be “AD” only. Hence,
Prime Attributes : A, D.
Non-Prime Attributes : B, C
Extraneous Attributes : B, C(As if we add any of the to the candidate key, it will
remain unaffected). Those attributes, which if removed does not affect closure of
that set.

Explain different keys in tables:

Super Key:
Super Key is an attribute (or set of attributes) that is used to uniquely identifies all
attributes in a relation.
Example:
We have a given relation R(A, B, C, D, E, F) and we shall check for being super keys by
following given dependencies:

Functional dependencies Super key

AB->CDEF YES
CD->ABEF YES
CB->DF NO
D->BC NO
By Using key AB we can identify rest of the attributes (CDEF) of the table. Similarly Key
CD. But, by using key CB we can only identifies D and F not A and E. Similarly key D.

Candidate Keys
Candidate Keys are super keys for which no proper subset is a super key. In other
words candidate keys are minimal super keys.

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

Example: AB, CD are candidate keys

Primary Key:
It is a candidate key that is chosen by the database designer to identify entities with in
an entity set. Primary key is the minimal super keys.
Examples: Employee table
Employee (
Employee ID,
FullName,
SSN,
DeptID
)
1. Candidate Key: are individual columns in a table that qualifies for uniqueness of all the rows.
Here in Employee table EmployeeID & SSN are Candidate keys.

2. Primary Key: is the columns you choose to maintain uniqueness in a table. Here in Employee
table you can choose either EmployeeID or SSN columns, EmployeeID is preferable choice, as SSN is
a secure value.

3. Alternate Key: Candidate column other the Primary column, like if EmployeeID is PK then SSN
would be the Alternate key.

4. Super Key: If you add any other column/attribute to a Primary Key then it become a super key,
like EmployeeID + FullName is a Super Key.

5. Composite Key: If a table do have a single columns that qualifies for a Candidate key, then you
have to select 2 or more columns to make a row unique. Like if there is no EmployeeID or SSN
columns, then you can make FullName + DateOfBirth as Composite primary Key. But still there can
be a narrow chance of duplicate row.

Example: Consider a Relation or Table R1.

Let A,B,C,D,E are the attributes of this relation.

R(A,B,C,D,E)
A→BCDE This means the attribute 'A' uniquely determines the other attributes B,C,D,E.
BC→ADE This means the attributes 'BC' jointly determines all the other attributes
A,D,E in the relation.

Primary Key :A
Candidate Keys :A, BC
Super Keys : A,BC,ABC

ABC are not Candidate Keys since both are not minimal super keys.

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

Normalization
Normalization is the process of minimizing redundancy from a relation or set of
relations. Redundancy in relation may cause insertion, deletion and updation
anomalies. So, it helps to minimize the redundancy in relations. Normal forms are used
to eliminate or reduce redundancy in database tables.

Here are the most commonly used normal forms:

 First normal form(1NF)
 Second normal form(2NF)
 Third normal form(3NF)
 Boyce & Codd normal form (BCNF)
 Fourth normal Form(4NF)
 Fifth Normal Form(5NF)

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

102 Jon Kanpur 8812121212, 9900012222

103 Ron Chennai 7778881212

104 Lester Bangalore 9990000123,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.
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

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

103 Ron Chennai 7778881212

104 Lester Bangalore 9990000123
104 Lester Bangalore 8123450987

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(No partial dependency exist)
Partial Dependency:- X ->Y is called partial dependency when Y is non prime
key and X is proper subset of candidate key.
(if set is ‘AB’ then its proper subsets are A or B but not AB).
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
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 id teacher age
111 38
222 38

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

333 40
teacher_subject table:
teacher_id subject

111 Maths
111 Physics
222 Biology
333 Physics
333 Chemistry
Now the tables comply with Second normal form (2NF).
Check THE GIVEN TABLE IS IN 2nf OR NOT?
Problem 1: Check the R(A,B,C,D) is in 2NF or not which contains following
Functional Dependencies?
A->B
C->D
Solution:
1) Find candidate key: AC is candidate key because [AC]+ = ABCD
2) Prime keys are A and C
3) Non-Prime Keys are B and D
4) Check the A-> B for partial dependency.
A->B partial dependency because the A is proper subset of candidate key AC
and B is non-prime attribute.
5) Check the C-> D for partial dependency.
C->D partial dependency because the C is proper subset of candidate key AC
and D is non-prime attribute.
Conclusion: Since both are partial dependencies , the relation is not in 2NF.

Problem 2: Check the R(A,B,C,D) is in 2NF or not which contains following

Functional Dependencies?
AB->C
C->D
Solution:
1) Find candidate key: AB is candidate key because [AB]+ = ABCD
2) Prime keys are A and B
3) Non-Prime Keys are C and D
4) Check the AB -> C for partial dependency.
AB->C is not partial dependency because the AB is not proper subset of
candidate key AB and C is non-prime attribute.
5) Check the C-> D for partial dependency.
C->D is not partial dependency because the C is not proper subset of candidate
key AB and D is non-prime attribute.

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

Conclusion: Since both are non-partial dependencies , the relation is in 2NF.

Problem 3: Check the R(A,B,C,D) is in 2NF or not which contains following

Functional Dependencies?
AB->C
BC->D
A->D
Solution:
1) Find candidate key: AB is candidate key because [AB]+ = ABCD
2) Prime keys are A and B
3) Non-Prime Keys are C and D
4) Check the AB -> C for partial dependency.
AB->C is not partial dependency because the AB is not proper subset of
candidate key AB and C is non-prime attribute.
5) Check the BC -> D for partial dependency.
BC -> D is not partial dependency because the BC is not proper subset of
candidate key AB and D is non-prime attribute.
6)Check the A-> D for partial dependency.
A->D partial dependency because the A is proper subset of candidate key AC
and D is non-prime attribute.

Conclusion: Since one partial dependency exist in the above , the relation is Not in 2NF.

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.
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 , X is a super key of table or Y is a prime
attribute of table.

Example: Suppose a company wants to store the complete address of each

employee, they create a table named employee_details that looks like this:
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

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

1201 Steve 222999 MP Gwalior Ratan

Candidate Keys: {emp_id}

Super keys: {emp_id}, {emp_id, emp_name}, {emp_id, emp_name, emp_zip}…so
on
Prime attribute : emp_id
Non-prime attributes: emp_name, emp_zip,emp_state, emp_city, emp_district

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

emp_id -> emp_name , emp_zip

Here emp_id is superkey.

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

emp_zip -> emp_state,emp_city, emp_district

Here emp_zip is superkey

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

Check THE GIVEN TABLE IS IN 3nf OR NOT?

Problem 1: Check the R(A,B,C) is in 3NF or not which contains following Functional
Dependencies?
A->B
B->C
Solution:
1) Find candidate key: A is candidate key because [A]+ = ABC
2) Prime keys : A
3) Non-Prime Keys : B and C
4) Check the A-> B for 3NF.
A->B is satisfying 3NF because the A is super key(LHS is true) and B prime
attribute(RHS is false). Atleast one is true
5) Check the B-> C for 3NF.
B->C is not satisfying 3NF because the B is not super key(LHS is false) and C
prime attribute(RHS is false). Both are false
Conclusion: Since one FD is not 3NF , then relation is not in 3NF.

Problem 2 Check the R(A,B,C) is in 3NF or not which contains following Functional
Dependencies?
AB->C
C->B
Solution:
1) Find candidate key: AB is candidate key because [AB]+ = ABC. And also AC is also
candidate key because as per C->B, B is replace by C in the candidate key AB i.e AC.
We have now two candidate keys AB and AC.
2) Prime keys : A,B,C
3) Non-Prime Keys : Null
4) Check the AB-> C for 3NF.
AB->C is satisfying 3NF because the AB is super key(LHS is true) and B prime
attribute(RHS is true). Both are true
5) Check the C-> B for 3NF.
C->B is satisfying 3NF because the C is not super key(LHS is false) but B is
prime attribute(RHS is True ). Atlease one is true
Conclusion: Since both FDs are in 3NF , then relation is in 3NF.

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.

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

Example: Suppose there is a company wherein employees work in more than

one department. They store the data like this:
emp_id emp_nationality emp_dept dept_type dept_no_of_emp

1001 Austrian Production D001 200

1001 Austrian stores D001 250

1002 American design D134 100

1002 American Purchasing D134 600

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 super 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
emp_dept table:
emp_dept dept_type dept_no_of_emp

Production D001 200

stores D001 250

design D134 100

Purchasing D134 600

emp_dept_mapping table:
emp_id emp_dept

1001 Production

1001 stores

1002 design

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

1002 Purchasing
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.
Fourth normal form (4NF)
o A relation will be in 4NF if it is in Boyce Codd normal form and has no
multi-valued dependency.
o 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.
Example
STUDENT

STU_ID COURSE HOBBY

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.
So to make the above table into 4NF, we can decompose it into two tables:
STUDENT_COURSE

STU ID COURSE

21 Computer

21 Math

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

34 Chemistry

74 Biology

59 Physics
STUDENT_HOBBY

STU ID HOBBY

21 Dancing

21 Singing

34 Dancing

74 Cricket

59 Hockey

Example 2:
PERSON MOBILE FOOD LIKES
Mahesh 9893 / 9424 Burger / pizza
Ramesh 9191 Pizza

Person->-> mobile,
Person ->-> food_likes

So to make the above table into 4NF, we can decompose it into two tables:
Person_mobile Table:
PERSON MOBILE
Mahesh 9893
Mahesh 9424
Ramesh 9191

Person_FoodLIkes Table:
PERSON FOOD LIKES
Mahesh Burger
Mahesh pizza

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

PERSON FOOD LIKES

Ramesh Pizza

Join dependency in DBMS

If a table can be recreated by joining multiple tables and each of this table have a subset
of the attributes of the table, then the table is in Join Dependency. It is a generalization
of Multivalued Dependency.
o If the join of R1 and R2 over C is equal to relation R, then we can say that a join
dependency (JD) exists, Where R1 and R2 are the decompositions R1(A, B, C) and
R2(C, D) of a given relations R (A, B, C, D).

Join Dependency can be related to 5NF.

Fifth normal form (5NF)

A relation is in 5NF, only if it is already in 4NF and it cannot be decomposed further
and join dependency not exist.
o 5NF is satisfied when all the tables are broken into as many tables as possible in
order to avoid redundancy.
o 5NF is also known as Project-join normal form (PJ/NF).
Example
<Employee>
EmpName EmpSkills EmpJob (Assigned Work)
Tom Networking EJ001
Harry Web Development EJ002
Katie Programming EJ002
The above table can be decomposed into the following three tables; therefore it is not in
5NF:
<EmployeeSkills>
EmpName EmpSkills
Tom Networking
Harry Web Development
Katie Programming
<EmployeeJob>
EmpName EmpJob
Tom EJ001
Harry EJ002
Katie EJ002
<JobSkills>

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

EmpSkills EmpJob
Networking EJ001
Web Development EJ002
Programming EJ002
Our Join Dependency:
{(EmpName, EmpSkills ), ( EmpName, EmpJob), (EmpSkills, EmpJob)}
The above relations have join dependency, so they are not in 5NF. That would mean
that a join relation of the above three relations is equal to our original
relation <Employee>.
LOSS LESS JOIN DECOPOSITION
If we decompose a relation R into relations R1 and R2,
 Decomposition is lossy if R1 ⋈ R2 ⊃ R
 Decomposition is lossless if R1 ⋈ R2 = R
To check for lossless join decomposition using FD set, following conditions must
hold:
1. Union of Attributes of R1 and R2 must be equal to attribute of R. Each attribute
of R must be either in R1 or in R2.
Att(R1) U Att(R2) = Att(R)
2. Intersection of Attributes of R1 and R2 must not be NULL.
Att(R1) ∩ Att(R2) ≠ Φ
3. Common attribute must be a key for at least one relation (R1 or R2)
Att(R1) ∩ Att(R2) -> Att(R1) or Att(R1) ∩ Att(R2) -> Att(R2)
For Example, A relation R (A, B, C, D) with FD set{A->BC} is decomposed into R1(ABC)
and R2(AD) which is a lossless join decomposition as:
1. First condition holds true as Att(R1) U Att(R2) = (ABC) U (AD) = (ABCD) =
Att(R).
2. Second condition holds true as Att(R1) ∩ Att(R2) = (ABC) ∩ (AD) ≠ Φ
3. Third condition holds true as Att(R1) ∩ Att(R2) = A is a key of R1(ABC) because
A->BC is given.
Example:
Consider a
relation R(A,B,C,D)

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

Dependency Preserving Decomposition

If we decompose a relation R into relations R1 and R2, All dependencies of R
either must be a part of R1 or R2 or must be derivable from combination of FD’s
of R1 and R2.
For Example, A relation R (A, B, C, D) with FD set{A->BC} is decomposed into
R1(ABC) and R2(AD) which is dependency preserving because FD A->BC is a
part of R1(ABC).
Consider a relation R with some functional dependency(FD)....

R is decomposed or divided into R1 with FD { f1 } and R2 with { f2 }, then

there can be three cases:

suresh.mentor@gmail.com
Database Management Systems B. Tech (CSE) II Year II Sem

f1 U f2 = F -----> Decomposition is dependency preserving.

f1 U f2 is a subset of F -----> Not Dependency preserving.

Example: consider a relation R(A,B,C) with the functional dependencies

A->B
B->C
C->A
Functional dependency set={ A->B , B->C, C->A }
Further decompose the R into R1(A,B) and R2(B,C) with the functional
dependencies:
R1 Functional dependency F1 R2 Functional dependency F2
A->B B->C
B->A C->B
( B->A will get from B->C&C->A) ( C->B will get from C->A&A->B)

Now union of F1 and F2 is

So, the dependency is preserved.

suresh.mentor@gmail.com