Database Management System Unit 3

Unit 3 Schema Refinement and Normal Forms

Database Schema
A Database Schema is the skeleton structure that represents the logical view of the entire database. It defines
how the data is organized and how the relations among them are associated. It formulates all the constraints
that are to be applied on the data.
A database schema defines its entities and the relationship among them. It contains a descriptive detail of the
database, which can be depicted by means of schema diagrams. It’s the database designers who design the
schema to help programmers understand the database and make it useful.

A database schema can be divided broadly into two categories −

 Physical Database Schema: This schema pertains to the actual storage of data and its form of storage
like files, indices, etc. It defines how the data will be stored in a secondary storage.
 Logical Database Schema: This schema defines all the logical constraints that need to be applied on the
data stored. It defines tables, views, and integrity constraints.
Characteristics of good schema
The database should be strong enough to store all the relevant data and requirements.
 Should be able to relate the tables in the database by means of a relation, for example, an employee
works for a department so that employee is related to a particular department. We should be able to
define such a relationship between any two entities in the database.
 Multiple users should be able to access the same database, without affecting the other user. For
example, several teachers can work on a database to update learners’ marks at the same time. Teachers
should also be allowed to update the marks for their subjects, without modifying other subject marks.
 A single database provides different views to different users, it supports multiple views to the user,
depending on his role. In a school database, for example, teachers can see the breakdown of learners’
marks; however, parents are only able to see only their child’s report – thus the parents’ access would
be read only. At the same time, teachers will have access to all the learners’ information and assessment
details with modification rights. All this is able to happen in the same database.

Prepared By- Charu Kavadia Page 1

 Database Management System Unit 3

 Data integrity refers to how accurate and consistent the data in a database is. Databases with lots of
missing information and incorrect information is said to have low data integrity.
 Data independence refers to the separation between data and the application (or applications) in which
it is being used. This allows you to update the data in your application (such as fixing a spelling
mistake) without having to recompile the entire application.
 Data Redundancy refers to having the exact same data at different places in the database. Data
redundancy Increases the size of the database, creates Integrity problems, decreases efficiency and
leads to anomalies. Data should be stored so that it is not repeated in multiple tables.
 Data security refers to how well the data in the database is protected from crashes, hacks and accidental
deletion.
 Data maintenance refers to monthly, daily or hourly tasks that are run to fix errors within a database
and prevent anomalies from occurring. Database maintenance not only fixes errors, but it also detects
potential errors and prevents future errors from occurring.
 It is easy to modify and maintain without affecting other fields or tables in the database.
 Information is easy to retrieve, and user applications are easy to develop and build.
 The database is scalable, meaning that it can be expanded to meet the changing needs of an
organization.

Schema Refinement
Schema Refinement or Normalization is a process of organizing the data in database to avoid data redundancy,
insertion anomaly, update anomaly & deletion anomaly. Normalization means decomposing or splitting the
tables into small tables which will contain less number of attributes in such a way that table design must not
contain any problem of inserting, deleting, updating anomalies and guarantees no redundancy.
A good understating of the semantics of data helps the designer to build efficient design using the concept of
normalization.
Anomalies or Problems without Normalization
1. Redundant Storage: Some information is stored repeatedly and it will occupy extra memory space and it
will also make it difficult to handle and update the database
2. Insertion, Updating and Deletion Anomalies
To understand these anomalies let us take an example of a Student table.

Prepared By- Charu Kavadia Page 2

 Database Management System Unit 3

a. Insertion Anomaly: It may not be possible to store some information unless some other information is
stored as well.
Example- Suppose a new course is introduced i.e. C4, but no student is there who is enrolled for C4 subject, so
data of such student cannot be inserted, or else we will have to set the SID and Sname information as NULL.

b. Deletion Anomaly: It may not be possible to delete some information without losing some other
information as well.
Example- Deletion of S3 student causes the deletion of course. Because of deletion of some data forced to
delete some other useful data.

Insertion and Deletion Anomalies exist only due to redundancy, otherwise they do not exist.
c. Update Anomaly: If one copy of redundant data is updated, then inconsistency is created unless all
redundant copies of data are updated.
Example- If there is updation in the fee from 5000 to 7000, then we have to update FEE column in all the rows,
else data will become inconsistent.

Solutions to Anomalies: Decomposition of Tables – Schema Refinement

Prepared By- Charu Kavadia Page 3
 Database Management System Unit 3

 Process of decomposing a larger relation into smaller relations.

 Each of smaller relations contains subset of attributes of original relation.

There are still some anomalies in above –

What is the Solution??

Solution: decomposing into relations as shown below.
To avoid redundancy and problems due to redundancy, we use refinement technique called decomposition.

Prepared By- Charu Kavadia Page 4

 Database Management System Unit 3

Purpose of Normalization
✓ Minimize the redundancy in data.
✓ Remove insert, update, and delete anomalies during the database activities.

✓ Reduce the need to organize the data when it is modified or enhanced.

✓ Normalization reduces a complex user view to a set of small and sub groups of fields or relations. This
process helps to design a logical data model known as conceptual data model.

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. We read it as X determines Y.
Two tuples sharing the same values of X will necessarily have the same values of Y. If two tuples having the
same value of attribute X also have the same value of attribute Y. If t1.X=t2.X then t1.Y=t2.Y where t1,t2 are
tuples and X,Y are attributes.
The attribute set on the left side of the arrow, X is called Determinant, while on the right side, Y is called the
Dependent. Functional dependencies are used to mathematically express relations among database entities.
 Functional Dependencies are fundamental to the process of Normalization i.e., Functional Dependency
plays key role in differentiating good database design from bad database designs.
 A functional dependency is a “type of constraint that is a generalization of the notation of the key”.
 Functional Dependency describes the relationship between attributes (columns) in a table.
 Functional dependency is represented by an arrow sign (→).

✓ Example1: Student Database

Question1: What is the CGPA of A?

Answer: We cannot answer, because in database have 2 records with A’s. So we cannot answer for CGPA of
A.
Note: But we can find the CGPA’s with respect to RollNo i.e., See the Answer for Question2.

Prepared By- Charu Kavadia Page 5

 Database Management System Unit 3

Question2: What is the CGPA of R4?

Answer: R4→9.1 Note: Rollno → CGPA and RollNo → Name. i.e., here we are establishing the relationships.
This type is known as Functional dependency.
Example 2: [Identifying the FD’s]

Case1:
A →B Here A1 belongs to B1 & B2. So A1 does not have unique value in B. So it is not a FD.
Case1:
A →C Here A1→C1 and A2, A3→C2. So A has unique values in C. So it is in FD.
[Note: try to find all the possibilities. i.e., A→D, B→C, B→D, and C→D]
Example 3:

Cases of dependency:
1) Roll_no → name
44→ xyz
44→ xyz
2) Roll_no → name
44→ xyz
45 → xyz
3) Roll_no → name
44→ xyz
46 → mno
These are valid cases of dependency.
Some more valid cases-
roll_no → { name, phone, dept_name, dept_building },→ Here, roll_no can determine values of fields name,
dept_name and dept_building, hence a valid Functional dependency.
roll_no → dept_name , Since, roll_no can determine whole set of {name, dept_name,dept_building}, it can

Prepared By- Charu Kavadia Page 6

 Database Management System Unit 3

determine its subset dept_name also.

dept_name → dept_building , Dept_name can identify the dept_building accurately,since departments with
different dept_name will also have a different dept_building
More valid functional dependencies: roll_no → name, {roll_no, name} →{dept_name, dept_building}, etc.
INVALID CASES
This is invalid case of dependency as same SID cannot be of two students.
Some invalid cases
name →roll_no: invalid
name → dept_name Students with the same name can have different dept_name, hence this is not a valid
functional dependency.
dept_building → dept_name There can be multiple departments in the same building, For example, in the
above table departments ME and EC are in the same building B2, hence dept_building → dept_name is an
invalid functional dependency.
More invalid functional dependencies: name → roll_no, {name, dept_name} →roll_no, dept_building →
roll_no, etc.

Types of Functional Dependencies in DBMS

1. Non Trivial Functional Dependency: A functional dependency is said to be Non Trivial Functional
Dependency “if and only if the determinant of the functional dependency is either candidate key or super key,
and the dependent can be either prime or nonprime attribute”.
(OR)
Let’s take the functional dependency X → Y (i.e., X determines Y). Here Y is said to be Non Trivial, if it can’t
be determined by any subset of X.
Example: Consider the following determinant ABC → D i.e., ABC determines D but D is not determined by
any subset of A/ BC/C/B/AB i.e., A→D, BC→D, C→D,B→D, AB→D, Functional dependencies don’t exist.
So D is Fully Functional Dependent.
For example,

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}
Completely non-trivial functional dependency:-If X→Y and X∩Y=Ф(null) then it is called completely non-
trivial functional dependency

Prepared By- Charu Kavadia Page 7

 Database Management System Unit 3

2. Partial Functional Dependency: If a non-prime attribute of the relation is getting derived by only a part of
the candidate key, then such dependency is known as Partial Dependency.
(OR)
In a relation having more than one key field, a subset of non-key fields may depend on all key fields but
another subset or a particular non-key field may depend on only one of the key fields. Such dependency is
defined as Partial Dependency.
Example: Consider the following determinants AC→P, A→D, D→P. From these determinants P is not fully
FD on AC. Because, If we find A+ (means A’s Closure) A→D, D→P i.e., A→P. But we don’t have any
requirement of C. C attribute is removed completely. So P is Partially Dependent on AC.
3.Transitive Functional Dependency: If a non-prime attribute of a relation is getting derived by either
another nonprime attribute or the combination of the part of the candidate key along with non-prime attribute,
then such dependency is defined as Transitive dependency. i.e., in a relation, there may be dependency among
non-key fields. Such dependency is called Transitive Functional Dependency.
Example: X→Y, and Y→Z then we can determine X→Z holds.
For example,

Here, roll_no → dept and dept → building_no. Hence, according to the axiom of transitivity, roll_no →
building_no is a valid functional dependency. This is an indirect functional dependency, hence called
Transitive functional dependency.
4. Trivial Functional Dependency: It is basically related to Reflexive rule. i.e., if X is a set of attributes, and
Y is subset of X then X→Y holds.
Example: ABC→BC is a Trivial Dependency.
For example, X={roll_no,name} and Y = {name}

X → Y is a trivial functional dependency, since the dependent attribute “name” is a subset of determinant set
{roll_no, name}
Prepared By- Charu Kavadia Page 8
 Database Management System Unit 3

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

X= {roll_no} and Y = {roll_no}

5. Multi-Valued 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,

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

Reasoning about Functional Dependencies

1) Armstrong Axioms- Armstrong axioms defines the set of rules for reasoning about functional dependencies
and also to infer all the functional dependencies on a relational database.
Various axioms rules or inference rules:
A) Primary Axioms
i) Reflexivity: If A is set of attributes and B is a subset of A, then A holds B {A → B }.
For example, {roll_no, name} → name is valid.
Explanation:
A= {roll_no, name}
B= {name}
B is subset of A

Prepared By- Charu Kavadia Page 9

 Database Management System Unit 3

ii) Augmentation: If A holds B and C is a set of attributes, then AC holds BC.

Explanation:
If A→B

A={roll_no} B= {name}
A→B = roll_no→name
AC→BC
C = phone number
AC→BC ={roll_no, phone}→{name , phone}

Prepared By- Charu Kavadia Page 10

 Database Management System Unit 3

It means that attributes in dependencies does not change the basic dependencies.
Example 1: {roll_no, phoneno} → {name, phoneno}
Example 2: If {roll_no, name} → dept_building is valid, hence {roll_no, name, dept_name}→ {dept_building,
dept_name} is also valid
iii) Transitivity: If A holds B and B holds C, then A holds C.
{A → B} and {B → C}, then {A → C}
Explanation:

Example: roll_no → dept_name & dept_name → dept_building, then roll_no →dept_building is also valid.

B) Secondary axioms:
i) Union
If A holds B and A holds C, then A holds BC
If {A → B} and {A → C}, then {A → BC}
Explanation:

A ={Roll_no}
B= {name}
C= {phone }
Roll_no→name: valid
Prepared By- Charu Kavadia Page 11
 Database Management System Unit 3

Roll_no→phone: valid
Roll_no→{name , phone}
ii) Decomposition
If A holds BC then A holds B, and A holds C.
If {A → BC} then {A → B}and{A → C}
Explanation:
A ={Roll_no}
B= {name}
C= {phone }
If {A → BC} = Roll_no→{name , phone}
then
{A → B}= Roll_no→name
And {A → C}: valid = Roll_no→phone
iii) Pseudo Transitivity
If A holds B and BC holds D, then AC holds D.
If {A → B} and {BC → D}, then {AC → D}
Explanation:

A ={Roll_no}
B= {name}
C= {phone}
D= dept_name
If {Roll_no → name}
{name, phone → dept_name}
Then, Roll_no, phone → dept_name is valid

Prepared By- Charu Kavadia Page 12

 Database Management System Unit 3

2) Attribute Closure: Attribute closure of an attribute set can be defined as set of attributes which can be
functionally determined from it.
NOTE:
To find attribute closure of an attribute set-
1) add elements of attribute set to the result set.
2) recursively add elements to the result set which can be functionally determined from the elements of result
set.

Example 1: R (A, B, C, D) and set of Functional Dependencies are A→B, B→D, C→B then what is the
Closure of A?
Solution: A+ → {A, B, D} as A→B, B→D exists and C is not FD on A. So it is eliminated.

Example 2: Given R(E_ID, E_NAME, E-CITY, E-STATE)

FDs = { E_ID -> E_NAME, E_ID ->E-CITY, E_ID ->E-STATE, E-CITY->E-STATE }
Find closure of E_ID
Solution: The attribute closure of E_ID can be calculated as:
Add E-ID to the set { E_ID }
(E_ID)+= {E_ID}
Add Attributes which can be derived from any attribute of set. In this case, E_NAME and ECITY,
E-STATE can be derived from E-ID. So these are also a part of closure.
As E-ID-> E_NAME so,
(E_ID)+= {E_ID, E_NAME }
E_ID ->E-CITY
(E_ID)+= {E_ID, E_NAME, E-CITY }
And E_ID ->E-STATE
(E_ID)+= {E_ID, E_NAME, E-CITY,E-STATE }

Prepared By- Charu Kavadia Page 13

 Database Management System Unit 3

As there is no other attribute remaining in relation to be derived from E-ID. So result is:
(E-ID)+ = {E-ID, E-NAME, E-CITY, E-STATE }
[Similarly,(E-NAME)+ = {E-NAME}, (E-CITY)+ = {E-CITY, E_STATE}]

Example 3: Find the attribute closures of given FDs R(ABCDE) = {AB->C, B->D, C->E, D->A}. FIND B+
{B}+= {B} and Find candidate key in Functional dependency.
Solution:
{B}+= {B,D} (As B->D)
{B}+= {B,D,A} (As D->A)
{B}+= {B,D,A,C} (As AB->C)
{B}+= {B,D,A,C,E} (As C->E)
And Candidate Key is B.

Case : Single Candidate key

Example 1: R(A,B,C,D,E,F,G,H)
FD:
AB→C
A→DE
B→F
F→GH
Solution:

Similarly

ARROW: INCOMING EDGE

Find attributes with no incoming edges (attributes not present in RHS of FD), here those attributes will be A
and B
Now to check if any other elements are required for candidate key find closure of AB.
Prepared By- Charu Kavadia Page 14
 Database Management System Unit 3

(AB)+= (AB)
AB→C
(AB)+= (ABC)
A→DE
(AB)+= (ABCDE)
B→F
(AB)+= (ABCDEF)
F→GH
(AB)+= (ABCDEFGH)
So (AB) IS THE CANDIDATE KEY.

Example 4: (case with multiple candidate keys)

R(A,B,C,D,E)
BC→ADE
D→B
Solution:

C is only element with no incoming edges so C is part of prime attribute

{C}+={C}
With C as we cannot find all attributes of relation so C will need another attribute to be part of candidate key
So let’s make combination of C with all attributes: {AC},{BC},{DC},{EC}
{AC}+={AC} : It is not a candidate key
{BC}+={BC}
{BC}+={BCADE} (As BC→ADE)
All attributes covered, so BC is a Candidate Key.
{DC}+={DC}
{DC}+={DCB} (As D→B)
{DC}+={DCBAE} (As BC→ADE)
All attributes covered, so DC is candidate key.

Prepared By- Charu Kavadia Page 15

 Database Management System Unit 3

{EC}+={EC}
As A and E are not part of candidate key we can combine them and also find its closure
{AEC}+={AEC}
Candidate Key: BC, DC

Example 5: R(A,B,C,D,E)
AB→CD
D→A
BC→DE
Solution: Candidate Key: AB, BC, BD (How its calculated, find on your own)

3) Closure of a set of Functional Dependencies

The set of FD’s that is logically implied by F is called the closure of F and written as F+. And it is defined as
“If F is a set FD’s on a relation R, the F+, the closure of F by using the inferences axioms that are not contained
in F+.

Example-Compute the closure of the following set F of functional dependencies for relation schema R = (A,
B, C, D, E). A →BC CD →E B→ D E→ A. List the candidate keys for R.
Solution: Starting with A → BC, we can conclude: A → B and A → C (decomposition)
Since A → B and B → D, then A → D (transitive)
Since A→C and A → D then A → CD (union)
Since A → CD and CD → E, A → E (transitive)
Since A → A, we have (reflexive)
A → ABCDE from the above steps (union)
Since E → A and A → ABCDE then E → ABCDE (transitive)
Since CD → E and E → ABCDE then CD → ABCDE (transitive)
Since B → D then BC → CD (augmentative)
Since B → CD and CD → ABCDE, BC → ABCDE (transitive)
Since CD →E and E→A, CD→A (transitive)
Since BC →CD and CD→A, BC→A (transitive)

Prepared By- Charu Kavadia Page 16

 Database Management System Unit 3

Also, C → C, D → D, E →E, B→B (reflexive)

Since B→B then BD→BD (Augmentive)
Since BD→BD, then BD→B and BD→D (decomposition)
Since B→D and B→B, then B→BD (union)
Etc.
Any functional dependency with A, E, BC, or CD on the left hand side of the arrow is in F+, no matter which
other attributes appear in the FD and these are candidate keys as well. Allow * to represent any set of attributes
in R, then F + also includes all FDs of the form A ∗ → α, BC ∗ → α, CD ∗ → α, E ∗ → α where α is any subset
of {A, B, C, D, E}.

Candidate Keys- A, E, BC, or CD

4) Database Keys: They are used to establish and identify the relation between tables. They can also ensure
that each record within a table can be uniquely identified by combination of one or more fields with in a table.
a) Candidate Key: -Candidate Key is minimal set of attributes of a relation which can be used to identify a
tuple uniquely.
Consider student table: student(sno, sname, sphone, age)

Prepared By- Charu Kavadia Page 17

 Database Management System Unit 3

we can take sno as candidate key. we can have more than 1 candidate key in a table.
Prime or Key Attribute: The attributes of the relation which are part of candidate key are called Prime or key
attribute. And rest are called Non-Prime Attributes.
Types of candidate keys:
1. simple (having only one attribute)
2. composite (having multiple attributes as candidate key)
b) Super Key: -Super Key is set of attributes of a relation which can be used to identify a tuple uniquely.
 Adding zero or more attributes to candidate key generates super key.
 A candidate key is a super key but vice versa is not true.
c) Primary Key: It is a candidate key that is most appropriate to become the main key of the table. It is the key
that uniquely identifies the records in a table.
d) Composite Key: A key that consists o0f two or more attributes that uniquely identifies an entity occurrence
is called composite key.
e) Secondary Key or Alternative key: The candidate keys which are not selected for primary key are known
as secondary key.
f) Foreign Key: Tuples in one relation, say r1 (R1) often need to refer tuples in another relation, say r2 (R2).

Normalization
Normalization is a process for evaluating and correcting table structures to minimize database redundancies,
thereby reducing the likelihood of data anomalies. Normalization is a process of designing a consistent
database with minimum redundancy which support data integrity by grating or decomposing given relation into
smaller relations preserving constraints on the relation.
Normalization works through a series of stages called normal forms. The first three stages are described as first
normal form (1NF), second normal form (2NF), and third normal form (3NF). From a structural point of view,
2NF is better than 1NF, and 3NF is better than 2NF.
For most purposes in business database design, 3NF is as high as we need to go in the normalization process.
Normalization of data can hence be looked upon as a process of analyzing the given relation schemas based on
their FDs and primary keys to achieve the desirable properties of
(1) minimizing redundancy
(2) minimizing the insertion, deletion, and update anomalies
Prime and non-prime attributes
Attributes which are parts of any candidate key of relation are called as prime attribute, others are non-prime
attributes.

Prepared By- Charu Kavadia Page 18

 Database Management System Unit 3

First Normal Form (1NF)

It states that the domain of an attribute must include only atomic (simple, indivisible) values and that the value
of any attribute in a tuple must be a single value from the domain of that attribute. Hence, 1NF disallows
having a set of values, a tuple of values, or a combination of both as an attribute value for a single tuple. In
other words, 1NF disallows "relations within relations" or "relations as attributes of tuples." The only attribute
values permitted by 1NF are single atomic (or indivisible) values.
First Normal Form is defined in the definition of relations tables itself. This rule defines that all the attributes
in a relation must have atomic domains. The values in an atomic domain are indivisible units.
• Only atomic attributes (simple, single-value)
• A primary key has been identified
• Every relation is in 1NF by definition.
Example 1: Each attribute must contain only a single value from its pre-defined domain.

Prepared By- Charu Kavadia Page 19

 Database Management System Unit 3

Example 2: Relation STUDENT in following table is not in 1NF because of multi-valued attribute
STUD_PHONE . Its decomposition into 1NF is as follows.

Example 3:

Second Normal Form (2NF)

It is based on the concept of full functional dependency. Second Normal Form applies to relations with
composite keys, that is, relations with a primary key composed of two or more attributes. A relation with a
single-attribute primary key is automatically in at least 2NF. A relation that is not in 2NF may suffer from the
update anomalies.

Prepared By- Charu Kavadia Page 20

 Database Management System Unit 3

To be in second normal form, a relation must be in first normal form and relation must not contain any partial
dependency. A relation is in 2NF if it has No Partial Dependency, i.e., no non-prime attribute (attributes which
are not part of any candidate key) is dependent on any proper subset of any candidate key of the table.
Definition: A relation that is in First Normal Form and every non-primary-key attribute is fully functionally
dependent on the primary key, then the relation is in Second Normal Form (2NF).
If the proper subset of candidate key determines non-prime attribute, it is called partial dependency. This is
Partial Dependency, where an attribute in a table depends on only a part of the primary key and not on the
whole key.
The normalization of 1NF relations to 2NF involves the removal of partial dependencies. If a partial
dependency exists, we remove the partially dependent attribute(s) from the relation by placing them in a new
relation along with a copy of their determinant.
Consider the examples given below.
Example-1: Consider table as following below.

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, COURSE_FEE would be a non-prime attribute, as it does not belong to the one and 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

Prepared By- Charu Kavadia Page 21

 Database Management System Unit 3

2NF tries to reduce the redundant data getting stored in memory. For instance, if there are 100 students taking
C1 course, we don’t 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.
Example 2: 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.

Primary Key= {teacher_id, subject}

Non-prime attributes = age
TEACHER_ID→ AGE: Partial Dependency
In the given table, non-prime attribute 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:

Prepared By- Charu Kavadia Page 22

 Database Management System Unit 3

Example 3: Convert this table into 2NF.

Solution :
Step 1: List all functional dependency

StudentID→ StuName
StudentId→{ CourseId , Grade }
CourseId→ CourseName
Step 2: Break table removing functional dependency

Example 4: A university uses the following relation: Student (IDSt, LastName, IDProf, ProfessorName, Grade)
The attributes IDSt and IDProf are the identification keys.
All attributes a single valued (1NF).
The following functional dependencies exist:
1. The attribute ProfessorName is functionally dependent on attribute IDProf (IDProf -→ProfessorName)
2. The attribute StudentName is functionally dependent on IDSt (IDSt -→ StudentName)
3. The attribute Grade is fully functional dependent on IDSt and IDProf (IDSt, IDProf -→Grade)

Prepared By- Charu Kavadia Page 23

 Database Management System Unit 3

Third Normal Form (3NF)

A relation is in third normal form, if there is no transitive dependency for non-prime attributes and 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 super key
2. Y is a prime attribute (each element of Y is part of some candidate key).
If any one of it is true it will not be transitive dependency

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).
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.

Prepared By- Charu Kavadia Page 24

 Database Management System Unit 3

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.
Consider the examples given below.
In relation STUDENT given in Table

FD set:
{STUD_NO → STUD_NAME,
STUD_NO → STUD_STATE, A->B
STUD_STATE → STUD_COUNTRY, B->C
STUD_NO → STUD_AGE}
Candidate Key:
{STUD_NO}
For this relation in 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. To convert it in third normal form, we will decompose the relation
STUDENT (STUD_NO, STUD_NAME, STUD_STATE,STUD_COUNTRY_STUD_AGE) as:
Table 1:

FD: {STUD_NO → STUD_NAME,

STUD_NO → STUD_STATE, A->B
STUD_NO → STUD_AGE}
STUDENT (STUD_NO, STUD_NAME, STUD_STATE, STUD_AGE)
Table 2:
STATE_COUNTRY (STATE, COUNTRY)

FD : STUD_STATE → STUD_COUNTRY,

Prepared By- Charu Kavadia Page 25

 Database Management System Unit 3

Example 2:

Super key in the table above:

{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.
TRANSITIVE DEPENDENCY HERE ARE:
EMP_ID→EMP_ZIP
EMP_ZIP→EMP_CITY , EMP_STATE
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.

Example 3:

Prepared By- Charu Kavadia Page 26

 Database Management System Unit 3

Classroom → Capacity: TRANSITIVE

• Any partial FDs? NO
• Any transitive FDs? YES !
• How do we eliminate it?
• By breaking into its own table

Boyce-Codd Normal Form(BCNF)

BCNF is an extension to Third Normal Form (3NF) and is slightly stronger than 3NF. BCNF was developed
by Raymond Boyce and E.F. Codd. BCNF is really an extension of 3rd Normal Form (3NF). For this reason it
is frequently termed 3.5NF. 3NF states that all data in a table must depend only on that table’s primary key,
and not on any other field in the table.
At first glance it would seem that BCNF and 3NF are the same thing. However, in some rare cases it does
happen that a 3NF table is not BCNF-compliant. This may happen in tables with two or more overlapping
composite candidate keys.
X→Y
A relation is in BCNF, if and only if, every determinant is a Form (BCNF) candidate key
 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.
BCNF, the table should be in 3NF, and for every FD, LHS is super key.
Example:

1. EMP_ID → EMP_COUNTRY
2. EMP_DEPT → {DEPT_TYPE, EMP_DEPT_NO}

Prepared By- Charu Kavadia Page 27

 Database Management System Unit 3

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:

Candidate keys:
For the first table: EMP_ID
For the second table: EMP_DEPT
For the third table: {EMP_ID, EMP_DEPT}
Example 2:

The above relation is in 1NF, 2NF, 3NF, but not in BCNF. Here is the reason −
Package->Ground
Package : is not a candidate key
x->y
and here x should be super key; and here x(package) is not super key.
Prepared By- Charu Kavadia Page 28
 Database Management System Unit 3

Functional Dependency {Package->Ground}

It has the determinant attribute Package on which Ground depends on is neither a Candidate
Key nor a superset of the candidate key.

Now the above tables are in BCNF.

Candidate key for <Package> table are Package and Ground
Candidate key for <TomorrowBookings> table are {Ground, Begin_Time} and {Ground, End_Time}
Super key = candidate key + extra element(optional)
= {Ground, Begin_Time} +0={Ground, Begin_Time}
={Ground, Begin_Time} + endtime= {Ground, Begin_Time, end_time}

Differences between 3NF and BCNF

Decomposition
Decomposition: It is the process of splitting original table into smaller relations such that attribute sets of two
relations will be the subset of attribute set of original table.
Rules of Decomposition:

Prepared By- Charu Kavadia Page 29

 Database Management System Unit 3

If ‘R’ is a relation splitted into ‘R1’ and ‘R2’ relations, the decomposition done should satisfy following-
1) Union of two smaller subsets of attributes gives all attributes of ‘R’.
R1(attributes) U R2(attributes)=R(attributes)
2) Both relations interaction should not give null value.
R1(attributes) ∩ R2(attributes)!=null
3) Both relations interaction should give key attribute.
R1(attribute)∩R2(attribute)=R(key attribute)

Types of Decomposition
1) Lossless Decomposition
2) Lossy Decomposition
1) Lossless Decomposition
 Consider there is a relation R which is decomposed into sub relations R1 , R2 , …. , Rn.
 This decomposition is called lossless join decomposition when the join of the sub relations results in
the same relation R that was decomposed, i.e. no data should be lost and should satisfy all the rules of
decomposition.
 For lossless join decomposition, we always have-

Example- Consider the following relation R( A , B , C )

Consider this relation is decomposed into two sub relations R1( A , B ) and R2( B , C )-

Prepared By- Charu Kavadia Page 30

 Database Management System Unit 3

The two sub relations are-

For lossless decomposition, we must have-

R1 ⋈ R2 = R
Now, if we perform the natural join (⋈) of the sub relations R1 and R2, we get-

This relation is same as the original relation R. Thus, we conclude that the above decomposition is lossless join
decomposition.
Note-
Lossless join decomposition is also known as non-additive join decomposition.
This is because the resultant relation after joining the sub relations is same as the decomposed relation.
No extraneous tuples appear after joining of the sub-relations.
2) Lossy Join Decomposition
 Consider there is a relation R which is decomposed into sub relations R1, R2, …. , Rn.
 This decomposition is called lossy join decomposition when the join of the sub relations does not result
in the same relation R that was decomposed.
 The natural join of the sub relations is always found to have some extraneous tuples.
 For lossy join decomposition, we always have-

Prepared By- Charu Kavadia Page 31

 Database Management System Unit 3

Example- Consider the following relation R( A , B , C )

Consider this relation is decomposed into two sub relations as R1( A , C ) and R2( B , C )-

The two sub relations are-

For lossy decomposition, we must have-

R1 ⋈ R2 ⊃ R
Now, if we perform the natural join ( ⋈ ) of the sub relations R1 and R2 we get-

Prepared By- Charu Kavadia Page 32

 Database Management System Unit 3

This relation is not same as the original relation R and contains some extraneous tuples. Clearly, R1 ⋈ R2 ⊃ R.
Thus, we conclude that the above decomposition is lossy join decomposition.
Note-
Lossy join decomposition is also known as careless decomposition.
This is because extraneous tuples get introduced in the natural join of the sub-relations.
Extraneous tuples make the identification of the original tuples difficult.

Canonical Cover (Fc)

A minimal set of functional dependencies that has the same closure as the original set F.
Extraneous attributes = attribute of FDs that we can remove without changing the closure of FDs.
Steps to find Canonical Cover

Example 1: Given a relational Schema R (A, B, C, D) and set of Function Dependency FD = {B → A, AD →

BC, C → ABD}. Find the canonical cover?
Solution:
Given FD = {B → A, AD → BC, C → ABD}, now decompose the FD using decomposition rule (Armstrong
Axiom).
1. B → A
2. AD → B ( using decomposition inference rule on AD → BC)
3. AD → C ( using decomposition inference rule on AD → BC)
4. C → A ( using decomposition inference rule on C → ABD)
5. C → B ( using decomposition inference rule on C → ABD)
6. C → D ( using decomposition inference rule on C → ABD)
Now set of FD = {B → A, AD → B, AD → C, C → A, C → B, C → D }
The next step is to find closure of the left side of each of the given FD by including that FD and excluding that
FD, if closure in both cases are same then that FD is redundant and we remove that FD from the given set,
otherwise if both the closures are different then we do not exclude that FD.
Calculating closure of all FDs {B → A, AD → B, AD → C, C → A, C → B, C → D }

Prepared By- Charu Kavadia Page 33

 Database Management System Unit 3

1a. Closure B+ = BA using FD = {B → A, AD → B, AD → C, C → A, C → B, C → D}

1b. Closure B+ = B using FD = {AD → B, AD → C, C → A, C → B, C → D}
From 1 a and 1 b, we found that both the Closure( by including B → A and excluding B → A ) are not
equivalent, hence FD B → A is important and cannot be removed from the set of FD.
2 a. Closure AD+ = ADBC using FD = {B →A, AD → B, AD → C, C → A, C → B, C → D}
2 b. Closure AD+ = ADCB using FD = {B → A, AD → C, C → A, C → B, C → D}
From 2a and 2b, we found that both the Closure (by including AD → B and excluding AD → B) are
equivalent, hence FD AD → B is not important and can be removed from the set of FD.
Hence resultant FD = { B → A, AD → C, C → A, C → B, C → D }
3 a. Closure AD+ = ADCB using FD = { B →A, AD → C, C → A, C → B, C → D }
3 b. Closure AD+ = AD using FD = { B → A, C → A, C → B, C → D }
From 3 a and 3 b, we found that both the Closure (by including AD → C and excluding AD → C ) are not
equivalent, hence FD AD → C is important and cannot be removed from the set of FD.
Hence resultant FD = { B → A, AD → C, C → A, C → B, C → D }
4 a. Closure C+ = CABD using FD = { B →A, AD → C, C → A, C → B, C → D }
4 b. Closure C+ = CBDA using FD = { B → A, AD → C, C → B, C → D }
From 4 a and 4 b, we found that both the Closure (by including C → A and excluding C → A) are equivalent,
hence FD C → A is not important and can be removed from the set of FD.
Hence resultant FD = { B → A, AD → C, C → B, C → D }
5 a. Closure C+ = CBDA using FD = { B →A, AD → C, C → B, C → D }
5 b. Closure C+ = CD using FD = { B → A, AD → C, C → D }
From 5 a and 5 b, we found that both the Closure (by including C → B and excluding C → B) are not
equivalent, hence FD C → B is important and cannot be removed from the set of FD.
Hence resultant FD = { B → A, AD → C, C → B, C → D }
6 a. Closure C+ = CDBA using FD = { B →A, AD → C, C → B, C → D }
6 b. Closure C+ = CBA using FD = { B → A, AD → C, C → B }
From 6 a and 6 b, we found that both the Closure( by including C → D and excluding C → D) are not
equivalent, hence FD C → D is important and cannot be removed from the set of FD.
Hence resultant FD = { B → A, AD → C, C → B, C → D }

Since FD = { B → A, AD → C, C → B, C → D } is resultant FD, now we have checked the redundancy of

attribute, since the left side of FD AD → C has two attributes, let's check their importance, i.e. whether they
both are important or only one.
Closure AD+ = ADCB using FD = { B →A, AD → C, C → B, C → D }
Closure A+ = A using FD = { B →A, AD → C, C → B, C → D }

Prepared By- Charu Kavadia Page 34

 Database Management System Unit 3

Closure D+ = D using FD = { B →A, AD → C, C → B, C → D }

Since the closure of AD+, A+, D+ that we found are not all equivalent, hence in FD AD → C, both A and D are
important attributes and cannot be removed.
Hence resultant FD = { B → A, AD → C, C → B, C → D } and we can rewrite as
FD = { B → A, AD → C, C → BD } is Canonical Cover of FD = { B → A, AD → BC, C → ABD }.

Example 2: Given a relational Schema R( W, X, Y, Z) and set of Function Dependency FD = { W → X, Y →

X, Z → WXY, WY → Z }. Find the canonical cover?
Solution: Given FD = {W → X, Y → X, Z → WXY, WY → Z }, now decompose the FD using
decomposition rule( Armstrong Axiom ).
1. W → X
2. Y → X
3. Z → W ( using decomposition inference rule on Z → WXY )
4. Z → X ( using decomposition inference rule on Z → WXY )
5. Z → Y ( using decomposition inference rule on Z → WXY )
6. WY → Z
Now set of FD = { W → X, Y → X, WY → Z, Z → W, Z → X, Z → Y }
The next step is to find closure of the left side of each of the given FD by including that FD and excluding that
FD, if closure in both cases are same then that FD is redundant and we remove that FD from the given set,
otherwise if both the closures are different then we do not exclude that FD.
Calculating closure of all FD { W → X, Y → X, Z → W, Z → X, Z → Y, WY → Z }
1 a. Closure W+ = WX using FD = { W → X, Y → X, Z → W, Z → X, Z → Y, WY → Z }
1 b. Closure W+ = W using FD = { Y → X, Z → W, Z → X, Z → Y, WY → Z }
From 1 a and 1 b, we found that both the Closure (by including W → X and excluding W → X ) are not
equivalent, hence FD W → X is important and cannot be removed from the set of FD.
Hence resultant FD = { W → X, Y → X, Z → W, Z → X, Z → Y, WY → Z }
2 a. Closure Y+ = YX using FD = { W → X, Y → X, Z → W, Z → X, Z → Y, WY → Z }
2 b. Closure Y+ = Y using FD = { W → X, Z → W, Z → X, Z → Y, WY → Z }
From 2 a and 2 b we found that both the Closure (by including Y → X and excluding Y → X ) are not
equivalent, hence FD Y → X is important and cannot be removed from the set of FD.
Hence resultant FD = { W → X, Y → X, Z → W, Z → X, Z → Y, WY → Z }
3 a. Closure Z+ = ZWXY using FD = { W → X, Y → X, Z → W, Z → X, Z → Y, WY → Z }
3 b. Closure Z+ = ZXY using FD = { W → X, Y → X, Z → X, Z → Y, WY → Z }
From 3 a and 3 b, we found that both the Closure (by including Z → W and excluding Z → W ) are not
equivalent, hence FD Z → W is important and cannot be removed from the set of FD.

Prepared By- Charu Kavadia Page 35

 Database Management System Unit 3

Hence resultant FD = { W → X, Y → X, Z → W, Z → X, Z → Y, WY → Z }
4 a. Closure Z+ = ZXWY using FD = { W → X, Y → X, Z → W, Z → X, Z → Y, WY → Z }
4 b. Closure Z+ = ZWYX using FD = { W → X, Y → X, Z → W, Z → Y, WY → Z }
From 4 a and 4 b, we found that both the Closure (by including Z → X and excluding Z → X ) are equivalent,
hence FD Z → X is not important and can be removed from the set of FD.
Hence resultant FD = { W → X, Y → X, Z → W, Z → Y, WY → Z }
5 a. Closure Z+ = ZYWX using FD = { W → X, Y → X, Z → W, Z → Y, WY → Z }
5 b. Closure Z+ = ZWX using FD = {W → X, Y → X, Z → W, WY → Z }
From 5 a and 5 b, we found that both the Closure (by including Z → Y and excluding Z → Y ) are not
equivalent, hence FD Z → X is important and cannot be removed from the set of FD.
Hence resultant FD = { W → X, Y → X, Z → W, Z → Y, WY → Z }
6 a. Closure WY+ = WYZX using FD = { W → X, Y → X, Z → W, Z → Y, WY → Z }
6 b. Closure WY+ = WYX using FD = { W → X, Y → X, Z → W, Z → Y }
From 6 a and 6 b, we found that both the Closure (by including WY → Z and excluding WY → Z) are not
equivalent, hence FD WY → Z is important and cannot be removed from the set of FD.
Hence resultant FD = { W → X, Y → X, Z → W, Z → Y, WY → Z }
Since FD = { W → X, Y → X, Z → W, Z → Y, WY → Z } is resultant FD now, we have checked the
redundancy of attribute, since the left side of FD WY → Z has two attributes at its left, let's check their
importance, i.e. whether they both are important or only one.
Closure WY+ = WYZX using FD = { W → X, Y → X, Z → W, Z → Y, WY → Z }
Closure W+ = WX using FD = { W → X, Y → X, Z → W, Z → Y, WY → Z }
Closure Y+ = YX using FD = { W → X, Y → X, Z → W, Z → Y, WY → Z }
Since the closure of WY+, W+, Y+ that we found are not all equivalent, hence in FD WY → Z, both W and
Y are important attributes and cannot be removed.
Hence resultant FD = { W → X, Y → X, Z → W, Z → Y, WY → Z } and we can rewrite as:
FD = {W → X, Y → X, Z → WY, WY → Z } is Canonical Cover of FD = { W → X, Y → X, Z → WXY,
WY → Z }.

Example 3: Given a relational Schema R (V, W, X, Y, Z) and set of Function Dependency FD = {V → W,

VW → X, Y → VXZ}. Find the canonical cover?
Solution: Given FD = {V → W, VW → X, Y → VXZ}. Now decompose the FD using decomposition rule
(Armstrong Axiom).
1. V → W
2. VW → X
3. Y → V ( using decomposition inference rule on Y → VXZ )

Prepared By- Charu Kavadia Page 36

 Database Management System Unit 3

4. Y → X ( using decomposition inference rule on Y → VXZ )

5. Y → Z ( using decomposition inference rule on Y → VXZ )
Now set of FD = {V → W, VW → X, Y → V, Y → X, Y → Z}.
The next step is to find closure of the left side of each of the given FD by including that FD and excluding that
FD, if closure in both cases are same then that FD is redundant and we remove that FD from the given set,
otherwise if both the closures are different then we do not exclude that FD.
Calculating closure of all FD {V → W, VW → X, Y → V, Y → X, Y → Z}.
1 a. Closure V+ = VWX using FD = {V → W, VW → X, Y → V, Y → X, Y → Z}
1 b. Closure V+ = V using FD = {VW → X, Y → V, Y → X, Y → Z}
From 1 a and 1 b, we found that both the Closure( by including V → W and excluding V → W ) are not
equivalent, hence FD V → W is important and cannot be removed from the set of FD.
Hence resultant FD = {V → W, VW → X, Y → V, Y → X, Y → Z}.
2 a. Closure VW+ = VWX using FD = {V → W, VW → X, Y → V, Y → X, Y → Z}
2 b. Closure VW+ = VW using FD = {V → W, Y → V, Y → X, Y → Z}
From 2 a and 2 b, we found that both the Closure( by including VW → X and excluding VW → X ) are not
equivalent, hence FD VW → X is important and cannot be removed from the set of FD.
Hence resultant FD = {V → W, VW → X, Y → V, Y → X, Y → Z}.
3 a. Closure Y+ = YVXZW using FD = {V → W, VW → X, Y → V, Y → X, Y → Z}
3 b. Closure Y+ = YXZ using FD = {V → W, VW → X, Y → X, Y → Z}
From 3 a and 3 b, we found that both the Closure( by including Y → V and excluding Y → V ) are not
equivalent, hence FD Y → V is important and cannot be removed from the set of FD.
Hence resultant FD = {V → W, VW → X, Y → V, Y → X, Y → Z}.
4 a. Closure Y+ = YXVZW using FD = {V → W, VW → X, Y → V, Y → X, Y → Z}
4 b. Closure Y+ = YVZWX using FD = {V → W, VW → X, Y → V, Y → Z}
From 4 a and 4 b, we found that both the Closure( by including Y → X and excluding Y → X ) are equivalent,
hence FD Y → X is not important and can be removed from the set of FD.
Hence resultant FD = {V → W, VW → X, Y → V, Y → Z}.
5 a. Closure Y+ = YZVWX using FD = {V → W, VW → X, Y → V, Y → Z}
5 b. Closure Y+ = YVWX using FD = {V → W, VW → X, Y → V}
From 5 a and 5 b, we found that both the Closure( by including Y → Z and excluding Y → Z ) are not
equivalent, hence FD Y → Z is important and cannot be removed from the set of FD.
Hence resultant FD = {V → W, VW → X, Y → V, Y → Z}.
Since FD = { V → W, VW → X, Y → V, Y → Z } is resultant FD now, we have checked the redundancy of
attribute, since the left side of FD VW → X has two attributes at its left, let's check their importance, i.e.
whether they both are important or only one.

Prepared By- Charu Kavadia Page 37

 Database Management System Unit 3

Closure VW+ = VWX using FD = {V → W, VW → X, Y → V, Y → Z}

Closure V+ = VWX using FD = {V → W, VW → X, Y → V, Y → Z}
Closure W+ = W using FD = {V → W, VW → X, Y → V, Y → Z}
Since the closure of VW+, V+, W+ we found that all the Closures of VW and V are equivalent, hence in FD
VW → X, W is not at all an important attribute and can be removed.
Hence resultant FD = {V → W, V → X, Y → V, Y → Z} and we can rewrite as
FD = {V → WX, Y → VZ} is Canonical Cover of FD = {V → W, VW → X, Y → VXZ}.

Decomposition into 3NF

STEP 1: Calculate the Candidate Key of given R by using an arrow diagram and then using the closure of an
attribute on R, such that from the calculated candidate key, we can separate the prime attributes and non-prime
attributes.
STEP 2: Verify each FD with Definition of 3NF (First it should be in 2NF and if there exist a non-trivial
dependency between two sets of attributes X and Y such that X → Y (i.e., Y is not a subset of X) then Either X
is Super Key or Y is a prime attribute).
STEP 3: Make a set of FD which does not satisfy 3NF, i.e. all those FD which do not have an attribute on the
left side of FD as a super key or attribute on the right side of FD as a prime attribute.
STEP 4: Convert the table R in 3NF by decomposing R such that each decomposition based on FD should
satisfy the definition of 3NF.
STEP 5: Once the decomposition based on FD is completed, create a separate table of attributes in the
Candidate key.
STEP 6: All the decomposed R obtained from STEP 4 and STEP 5 forms the required decomposition where
each decomposition is in 3NF.

Example 1: Given a relation R( X, Y, Z) and Functional Dependency set FD = { X → Y and Y → Z },

determine whether the given R is in 3NF? If not convert it into 3 NF.
Solution:
Let us construct an arrow diagram on R using FD to calculate the candidate key.

From above arrow diagram on R, we can see that an attribute X is not determined by any of the given FD,
hence X will be the integral part of the Candidate key, i.e. no matter what will be the candidate key, and how
many will be the candidate key, but all will have X compulsory attribute.

Prepared By- Charu Kavadia Page 38

 Database Management System Unit 3

Calculate the closure of X

X + = XYZ (from the closure method we studied earlier)
Since the closure of X contains all the attributes of R, hence X is Candidate Key
From the definition of Candidate Key (Candidate Key is a Super Key whose no proper subset is a Super
key)
Since all key will have X as an integral part, and we have proved that X is Candidate Key, Therefore, any
superset of X will be Super Key but not the Candidate key.
Hence there will be only one candidate key X

Definition of 3NF: A relational schema R is said to be in 3NF, First, it should be in 2NF and, no non-prime
attribute should be transitively dependent on the Key of the table.
If X → Y and Y → Z exist then X → Z also exists which is a transitive dependency, and it should not hold.
Since R has 3 attributes: - X, Y, Z, and Candidate Key is X, Therefore, prime attribute (part of candidate key)
is X while a non-prime attribute are Y and Z
Given FD are X → Y and Y → Z
So, we can write X → Z (which is a transitive dependency)
In above FD X → Z, a non-prime attribute( Z) is transitively depending on the key of the table( X ) hence as
per the definition of 3NF it is not in 3 NF, because no non-prime attribute should be transitively dependent
on the key of the table.

Now check the above table is in 2 NF.

a) FD: X → Y is in 2NF ( as Key is not breaking and its Fully functional dependent )
b) FD: Y → Z is also in 2NF( as it does not violate the definition of 2NF)
Hence above table R( X, Y, Z ) is in 2NF but not in 3NF.

We can also prove the same from Definition 2: First, it should be in 2NF and if there exists a non-trivial
dependency between two sets of attributes X and Y such that X → Y (i.e., Y is not a subset of X) then
a) Either X is Super Key
b) Or Y is a prime attribute.
Since we have just proved that above table R is in 2 NF.

Let's check it for 3NF using definition 2.

a) FD: X → Y is in 3NF (as X is a super Key)
b) FD: Y → Z is not in 3NF (as neither Y is Key nor Z is a prime attribute)

Prepared By- Charu Kavadia Page 39

 Database Management System Unit 3

Hence because of Y → Z using definition 2 of 3NF, we can say that above table R is not in 3NF.

Convert the table R( X, Y, Z) into 3NF:

Since due to FD: Y → Z, our table was not in 3NF, let's decompose the table
FD: Y → Z was creating issue, hence one table R1(Y, Z)
Create one Table for key X, R2(X, Y), since X → Y
Hence decomposed tables which are in 3NF are:
R1(Y, Z)
R2(X, Y)

Example 2: Given a relation R( X, Y, Z, W, P) and Functional Dependency set FD = { X → Y, Y → P, and Z

→ W}, determine whether the given R is in 3NF? If not convert it into 3 NF.
Solution:
Construct an arrow diagram on R using FD to calculate the candidate key.

From above arrow diagram on R, we can see that an attributes XZ is not determined by any of the given FD,
hence XZ will be the integral part of the Candidate key, i.e. no matter what will be the candidate key, and how
many will be the candidate key, but all will have XZ compulsory attribute.
Calculate the closure of XZ
XZ+ = XZYPW
Since the closure of XZ contains all the attributes of R, hence XZ is Candidate Key
From the definition of Candidate Key (Candidate Key is a Super Key whose no proper subset is a Super key).
Since all key will have XZ as an integral part, and we have proved that XZ is Candidate Key, Therefore, any
superset of XZ will be Super Key but not the Candidate key.
Hence there will be only one candidate key XZ.

Definition of 3NF: First it should be in 2NF and if there exists a non-trivial dependency between two sets of
attributes X and Y such that X → Y ( i.e., Y is not a subset of X) then
a) Either X is Super Key
b) Or Y is a prime attribute.
Since R has 5 attributes: - X, Y, Z, W, P and Candidate Key is XZ, Therefore, prime attribute (part of
candidate key) are X and Z while a non-prime attribute are Y, W, and P
Prepared By- Charu Kavadia Page 40
 Database Management System Unit 3

Given FD are X → Y, Y → P, and Z → W and Super Key / Candidate Key is XZ

a) FD: X → Y does not satisfy the definition of 3NF, that neither X is Super Key nor Y is a prime
attribute.
b) FD: Y → P does not satisfy the definition of 3NF, that neither Y is Super Key nor P is a prime
attribute.
c) FD: Z → W does not satisfy the definition of 3NF, that neither Z is Super Key nor W is a prime
attribute.
Now check the above table is in 2 NF.
a) FD: X → Y is in 2NF (as there is no partial dependency, it does not violate the definition of 2NF)
b) FD: Y → P is also in 2NF (as there is no partial dependency, it does not violate the definition of 2NF)
c) FD: Z → W is also in 2NF ( as there is no partial dependency, it does not violate the definition of 2NF)
Hence above table R( X, Y, Z ) is in 2NF but not in 3NF.

Convert the table R( X, Y, Z, W, P) into 3NF

Since all the FD = { X → Y, Y → P, and Z → W} were not in 3NF, let us convert R in 3NF
R1(X, Y) {Using FD X → Y}
R2(Y, P) {Using FD Y → P}
R3(Z, W) {Using FD Z → W}
And create one table for Candidate Key XZ
R4( X, Z) { Using Candidate Key XZ }
All the decomposed tables R1, R2, R3, and R4 are in 2NF( as there is no partial dependency) as well as in
3NF.
Hence decomposed tables are:
R1(X, Y), R2(Y, P), R3( Z, W), and R4( X, Z)

Example 3: Given a relation R( P, Q, R, S, T, U, V, W, X, Y) and Functional Dependency set FD = { PQ →

R, P → ST, Q → U, U → VW, and S → XY}, determine whether the given R is in 3NF? If not convert it into
3 NF.
Solution:
Construct an arrow diagram on R using FD to calculate the candidate key.

Prepared By- Charu Kavadia Page 41

 Database Management System Unit 3

From above arrow diagram on R, we can see that an attribute PQ is not determined by any of the given FD,
hence PQ will be the integral part of the Candidate key, i.e. no matter what will be the candidate key, and how
many will be the candidate key, but all will have PQ compulsory attribute.

Calculate the closure of PQ

PQ+ = P Q R S T U X Y V W
Since the closure of XZ contains all the attributes of R, hence PQ is Candidate Key
From the definition of Candidate Key (Candidate Key is a Super Key whose no proper subset is a Super
key)
Since all key will have PQ as an integral part, and we have proved that XZ is Candidate Key, Therefore, any
superset of PQ will be Super Key but not Candidate key.
Hence there will be only one candidate key PQ

Definition of 3NF: First it should be in 2NF and if there exists a non-trivial dependency between two sets of
attributes X and Y such that X → Y (i.e., Y is not a subset of X) then
c) Either X is Super Key
d) Or Y is a prime attribute.
Since R has 10 attributes: - P, Q, R, S, T, U, V, W, X, Y, V, W and Candidate Key is PQ, Therefore, prime
attribute (part of candidate key) are P and Q while a non-prime attribute are R S T U V W X Y V W
Given FD are {PQ → R, P → ST, Q → U, U → VW and S → XY} and Super Key / Candidate Key is PQ
a) FD: PQ → R satisfy the definition of 3NF, as PQ Super Key
b) FD: P → ST does not satisfy the definition of 3NF, that neither P is Super Key nor ST is the prime
attribute
c) FD: Q → U does not satisfy the definition of 3NF, that neither Q is Super Key nor U is a prime
attribute
d) FD: U → VW does not satisfy the definition of 3NF, that neither U is Super Key nor VW is a prime
attribute
e) FD: S → XY does not satisfy the definition of 3NF, that neither S is Super Key nor XY is a prime
attribute

Convert the table R( X, Y, Z, W, P) into 3NF

Since all the FD = { P → ST, Q → U, U → VW, and S → XY } were not in 3NF, let us convert R in 3NF
R1(P, S, T) {Using FD P → ST }
R2(Q, U) {Using FD Q → U }
R3( U, V, W) { Using FD U → VW }

Prepared By- Charu Kavadia Page 42

 Database Management System Unit 3

R4( S, X, Y) { Using FD S → XY }
R5( P, Q, R) { Using FD PQ → R, and candidate key PQ }
All the decomposed tables R1, R2, R3, R4, and R5 are in 2NF( as there is no partial dependency) as well as in
3NF.
Hence decomposed tables are:
R1(P, S, T), R2(Q, U), R3(U, V, W), R4( S, X, Y), and R5( P, Q, R)

Decomposition into BCNF

STEP 1: Calculate the Candidate Key of given R by using an arrow diagram and then using the closure of an
attribute on R, such that from the calculated candidate key, we can separate the prime attributes and non-prime
attributes.
STEP 2: Verify each FD with Definition of BCNF (First it should be in 3NF and if there exist a non-trivial
dependency between two sets of attributes X and Y such that X → Y (i.e., Y is not a subset of X) then X is
Super Key
STEP 3: Make a set of FD which does not satisfy BCNF, i.e. all those FD which do not have an attribute on
the left side of FD as a super key
STEP 4: Convert the table R in BCNF by decomposing R such that each decomposition based on FD should
satisfy the definition of BCNF.
STEP 5: Once the decomposition based on FD is completed, create a separate table of attributes in the
Candidate key.
STEP 6: All the decomposed R obtained from STEP 4 and STEP 5 forms the required decomposition where
each decomposition is in BCNF.
(Note - All BCNF is 3NF but vice versa may or may not be true.)

Example 1: Given a relation R( X, Y, Z) and Functional Dependency set FD = { XY → Z and Z → Y },

determine whether the given R is in BCNF? If not convert it into BCNF.
Solution:
Construct an arrow diagram on R using FD to calculate the candidate key.

From the above arrow diagram on R, we can see that an attribute X is not determined by any of the given FD,
hence X will be the integral part of the Candidate key, i.e. no matter what will be the candidate key, and how
many will be the candidate key, but all will have X compulsory attribute.

Prepared By- Charu Kavadia Page 43

 Database Management System Unit 3

Calculate the closure of X

X+ = X
Since the closure of X contains only X, hence it is not a candidate key.
Let us check the combination of Y, i.e. XY, XZ.
a) XY + = XYZ ( from the closure method we studied earlier)
Since the closure of XY contains all the attributes of R, hence XY is Candidate Key
b) XZ + = XZY (from the closure method we studied earlier)
Since the closure of XZ contains all the attributes of R, hence XZ is Candidate Key
Hence there are two candidate key XY and XZ
Since R has 3 attributes: - X, Y, Z, and Candidate Key is XY and XZ, Therefore, prime attribute(part of
candidate key) are X, Y, and Z while a non-prime attribute is none.

Using the Definition of 3NF to check whether R is in 3NF?: First, it should be in 2NF and if there exists a
non-trivial dependency between two sets of attributes X and Y such that X → Y ( i.e. Y is not a subset of X)
then
a) Either X is Super Key
b) Or Y is a prime attribute.
Given FD are XY → Z, and Z → Y and Super Key / Candidate Key are XZ and XY
a) FD: X Y → Z satisfies the definition of 3NF, as XY is Super Key also Z is a prime attribute.
b) FD: Z → Y satisfies the definition of 3NF, even though Z is not Super Key but Y is a prime attribute.
Since both FD of R, XY → Z and Z → Y satisfy the definition of 3NF hence R is in 3 NF

Using the Definition of BCNF to check whether R is in BCNF?: First, it should be in 3NF and if there exists
a non-trivial dependency between two sets of attributes X and Y such that X → Y ( i.e. Y is not a subset of X)
then
a) X is Super Key
Given FD are XY → Z, and Z → Y and Super Key / Candidate Key is XZ and XY
b) FD: X Y → Z satisfies the definition of BCNF, as XY is Super Key.
c) FD: Z → Y does not satisfy the definition of BCNF, as Z is not Super Key Since both FD of R, XY → Z
and Z → Y satisfy the definition of 3NF hence R is in 3 NF
Convert the table R( X, Y, Z) into BCNF:
Since due to FD: Z → Y, our table was not in BCNF, let's decompose the table
FD: Z→ Y was creating an issue, hence one table R1( Z, Y )
Create Table for key XY R2(X, Y) as XY was candidate key
Create Table for key XZ R2(X, Z) as XZ was candidate key

Prepared By- Charu Kavadia Page 44

 Database Management System Unit 3

Note: When we have more than one key( eg: XY and XY) then while decomposing keep in mind that you
compare both R2 and R3 with R1 such that among R1 and R2 or R1 and R3 there should be at least one
common attribute and, that common attribute must be key in any of the table.

Considering R1( Z, Y) and R2(X, Y) both tables have one common attribute Y, but Y is not key in any of the
table R1 and R2, hence we discard R2(X, Y) i.e. discarding candidate key XY.
Considering R1( Z, Y) and R3(X, Z) both tables have one common attribute Z, and Z is key of the table R1,
hence we include R3(X, Z) i.e. including candidate key XZ.

Hence decomposed tables which are in BCNF:

R1(Z, Y)
R2(X, Z)

Example 2: Given a relation R( X, Y, Z) and Functional Dependency set FD = { X → Y and Y → Z },

determine whether the given R is in BCNF? If not convert it into BCNF.
Solution:
Construct an arrow diagram on R using FD to calculate the candidate key.

From the above arrow diagram on R, we can see that an attribute X is not determined by any of the given FD,
hence X will be the integral part of the Candidate key, i.e. no matter what will be the candidate key, and how
many will be the candidate key, but all will have X compulsory attribute.

Let us calculate the closure of X

X + = XYZ (from the closure method we studied earlier)
Since the closure of X contains all the attributes of R, hence X is Candidate Key
From the definition of Candidate Key (Candidate Key is a Super Key whose no proper subset is a Super
key)

Using the Definition of BCNF to check whether R is in BCNF?: First, it should be in 3NF and if there exists
a non-trivial dependency between two sets of attributes X and Y such that X → Y ( i.e. Y is not a subset of X)
then
a) X is Super Key

Prepared By- Charu Kavadia Page 45

 Database Management System Unit 3

First, we check that table is in 3NF?

Using the Definition of 3NF to check whether R is in 3NF?: If there exists a non-trivial dependency
between two sets of attributes X and Y such that X → Y ( i.e. Y is not a subset of X) then
a) Either X is Super Key
b) Or Y is a prime attribute.
a) FD: X → Y is in 3NF (as X is a super Key)
b) FD: Y → Z is not in 3NF (as neither Y is Key nor Z is a prime attribute)
Hence because of Y → Z using definition 2 of 3NF, we can say that above table R is not in 3NF.
Convert the table R( X, Y, Z) into 3NF:
Since due to FD: Y → Z our table was not in 3NF, let's decompose the table
FD: Y → Z was creating issue, hence one table R1(Y, Z)
Create one Table for key X, R2(X, Y), since X → Y

Hence decomposed tables which are in 3NF:

R1(X, Y)
R2(Y, Z)
Both R1(X, Y) and R2(Y, Z) are in BCNF

Identify Normal Form

STEP 1: Calculate the Candidate Key of given R by using an arrow diagram and then using the closure of an
attribute on R, such that from the calculated candidate key we can separate the prime attributes and non-prime
attributes.
STEP 2: Verify each FD's in the reverse engineering process, i.e. 1st check BCNF, if not then 3NF, if not then
2NF, and so on.
STEP 3: If a table is in BCNF then it is in 3NF, 2NF, and 1NF, similarly if the table is in 3NF THEN it is in
2NF and 1NF. Hence, we can say that if a table is in the higher normal form then by default it is in lower
normal form.
STEP 4: Verify first FD with Definition of BCNF (First it should be in 3NF and if there exists a non-trivial
dependency between two sets of attributes X and Y such that X → Y (i.e., Y is not a subset of X) then X is
Super Key.
STEP 5: If for any FD STEP 5 fails(it signifies that table is not in BCNF), then verify that FD and remaining
FD with Definition of 3NF( First it should be in 2NF and if there exist a non-trivial dependency between two
sets of attributes X and Y such that X → Y ( i.e. Y is not a subset of X) then X is Super Key or Y is a prime
attribute

Prepared By- Charu Kavadia Page 46

 Database Management System Unit 3

STEP 6: If for any FD STEP 6 fails (it signifies that table is not in BCNF), then verify that FD and remaining
FD with Definition of 2NF (No non-prime attribute should be partially dependent on the key of table).
STEP 7: If for any FD STEP 7 fails (it signifies that table is not in 2NF), hence no need to check it for 1NF, as
by default it is in 1NF.
STEP 8: If all the FD's satisfy the definition of BCNF then we can say that given R is in BCNF, if any FD fails
for BCNF and that FD and remaining FD satisfy for 3NF then we say R is in 3NF, similarly if any FD fails for
3NF and that FD and remaining FD satisfy for 2NF then we say R is in 2NF, otherwise the table is in 1NF.

Definition of 2NF: No non-prime attribute should be partially dependent on Candidate Key. i.e. there should
not be a partial dependency from X → Y.
Definition of 3NF: First, it should be in 2NF and if there exists a non-trivial dependency between two sets of
attributes X and Y such that X → Y (i.e. Y is not a subset of X) then
a) Either X is Super Key
b) Or Y is a prime attribute.
Definition of BCNF: First, it should be in 3NF and if there exists a non-trivial dependency between two sets
of attributes X and Y such that X → Y (i.e., Y is not a subset of X) then
a) X is Super Key

Example 1: Given a relation R( P, Q, R, S, T, U, V, W, X) and Functional Dependency set FD = { PQ → R,

QS → TU, PS → VW, and P → X }, determine whether the given R is in which normal form?
Solution:
Construct an arrow diagram on R using FD to calculate the candidate key.

From the above arrow diagram on R, we can see that an attribute PQS is not determined by any of the given
FD, hence PQS will be the integral part of the Candidate key, i.e. no matter what will be the candidate key, and
how many will be the candidate key, but all will have PQS compulsory attribute.
Let us calculate the closure of PQS
PQS + = P Q R S T U X V W (from the closure method we studied earlier)
Since the closure of PQS contains all the attributes of R, hence PQS is Candidate Key
From the definition of Candidate Key (Candidate Key is a Super Key whose no proper subset is a Super
key)

Prepared By- Charu Kavadia Page 47

 Database Management System Unit 3

Since all key will have PQS as an integral part, and we have proved that PQS is Candidate Key, Therefore, any
superset of PQS will be Super Key but not a Candidate key.
Hence there will be only one candidate key PQS
Since R has 9 attributes: - P, Q, R, S, T, U, V, W, X, and Candidate Key is PQS, Therefore, prime attributes
(part of candidate key) are P Q and S while a non-prime attribute is R T U V W X
Given FD are { PQ → R, QS → TU, PS → VW, and P → X } and Super Key / Candidate Key is PQS
NOTE: To solve such questions, we apply reverse engineering, i.e. 1st check BCNF, if not then 3NF, if not then
2NF, and so on.
a. FD: PQ → R does not satisfy the definition of BCNF, as PQ is not Super Key, hence the table is not in
BCNF (because if one dependency fails, all fails) now we check the same FD for 3NF.
b. FD: PQ → R even does not satisfy the definition of 3NF, as PQ is not Super Key or R is not a prime
attribute, hence table is not in 3NF also (because if one dependency fails, all fails) now we check same
FD for 2NF
c. FD: PQ → R even does not satisfy the definition of 2NF, as PQ is not Super Key and R which is not
prime attribute depending on part of the key (partial dependency), hence table is not in 2NF also
(because if one dependency fails, all fails).
Hence from the above three statements, we can say that table R ( P, Q, R, S, T, U, V, W, X) is in 1NF
only.

Example 2: Given a relation R( P, Q, R, S, T, U, V, W ) and Functional Dependency set FD = { PQ → R, P →

ST, Q → U, and U → VW }, determine given R is in which normal form?
Solution:
Construct an arrow diagram on R using FD to calculate the candidate key.

From the above arrow diagram on R, we can see that an attribute PQ is not determined by any of the given FD,
hence PQ will be the integral part of the Candidate key, i.e. no matter what will be the candidate key, and how
many will be the candidate key, but all will have PQ compulsory attribute.
Let us calculate the closure of PQ
PQ + = P Q R S T U V W (from the closure method we studied earlier)
Since the closure of PQ contains all the attributes of R, hence PQ is Candidate Key
From the definition of Candidate Key (Candidate Key is a Super Key whose no proper subset is a Super
key)
Prepared By- Charu Kavadia Page 48
 Database Management System Unit 3

Since all key will have PQ as an integral part, and we have proved that PQ is Candidate Key, Therefore, any
superset of PQ will be Super Key but not Candidate key.
Hence there will be only one candidate key PQ
Since R has 8 attributes: - P, Q, R, S, T, U, V, W and Candidate Key is PQ. Therefore, prime attribute (part of
candidate key) are P and Q while a non-prime attribute is R S T U V W
Given FD are { PQ → R, P → ST, Q → U, and U → VW } and Super Key / Candidate Key is PQ
NOTE: To solve such questions, we apply reverse engineering, i.e. 1st check BCNF, if not then 3NF, if not then
2NF, and so on.
a. FD: PQ → R satisfies the definition of BCNF, as PQ is Super Key, hence no need to check it for
further normal forms, as it satisfies the highest one. Now we check another dependency in a reverse
engineering manner.
b. FD: P → ST does not satisfy the definition of BCNF, as P is not Super Key, hence table is not in BCNF
(because if one dependency fails, all fails) now we check the same FD for 3NF.
c. FD: P → ST even does not satisfy the definition of 3NF, as P is not Super Key or S T is not a prime
attribute, hence table is not in 3NF also (because if one dependency fails, all fails) now we check same
FD for 2NF.
d. FD: P → ST even does not satisfy the definition of 2NF, as P is not Super Key and S T which is not
prime attribute depending on part of the key (partial dependency), hence table is not in 2NF also
(because if one dependency fails, all fails).
Hence from the above three statements b, c, and d we can say that table R ( P, Q, R, S, T, U, V, W, ) is in
1NF only.

Example 3: Given a relation R( P, Q, R, S, T, U ) and Functional Dependency set FD = { PQ → R, SR→ PT,

T → U }, determine given R is in which normal form?
Solution:
Construct an arrow diagram on R using FD to calculate the candidate key.

From the above arrow diagram on R, we can see that an attribute QS is not determined by any of the given FD,
hence QS will be the integral part of the Candidate key, i.e. no matter what will be the candidate key, and how
many will be the candidate key, but all will have QS compulsory attribute.
Let us calculate the closure of QS
QS + = QS (from the closure method we studied earlier)

Prepared By- Charu Kavadia Page 49

 Database Management System Unit 3

Since closure QS does not contain all the attributes of R, hence QS is not the Candidate key.
On making a combination of QS with another attribute, we found that PQS and RQS determine all the
attributes of R, hence PQS and RQS are candidate keys of R.
Since R has 6 attributes: - P, Q, R, S, T, U and Candidate Key is PQS and RQS, Therefore, prime attributes
(part of candidate key) are P Q R and S while a non-prime attribute is T U
Given FD are { PQ → R, SR→ PT, T → U } and Super Key / Candidate Key is PQS and RQS
NOTE: To solve such questions, we apply reverse engineering, i.e. 1st check BCNF, if not then 3NF, if not then
2NF, and so on.
a. FD: PQ → R does not satisfy the definition of BCNF, as PQ is not Super Key, hence table is not in
BCNF (because if one dependency fails, all fails) now we check the same FD for 3NF
b. FD: PQ → R satisfies the definition of 3NF, even though PQ is not Super Key but R is attributed,
hence the table is in 3NF now we check other FD's using reverse engineering process.
c. FD: SR → PT does not satisfy the definition of 3NF, as SR is not Super Key or P T is not prime
attribute (as P is prime but the combination should be prime attribute), hence table is not in 3NF
(because if one dependency fails, all fails). now we check the same FD for 2NF
d. FD: SR → PT does not satisfy the definition of 2NF, as SR is not Super Key or P T which is not prime
attribute depending on part of the key (partial dependency), hence table is not in 2NF also (because if
one dependency fails, all fails).
Hence from the above two statements c and d, we can say that table R ( P, Q, R, S, T, U) is in 1NF only.

Example 4: Given a relation R( P, Q, R, S, T) and Functional Dependency set FD = { QR → PST, S → Q },

determine given R is in which normal form?
Solution:
Construct an arrow diagram on R using FD to calculate the candidate key.

From the above arrow diagram on R, we can see that an attribute R is not determined by any of the given FD,
hence R will be the integral part of the Candidate key, i.e. no matter what will be the candidate key, and how
many will be the candidate key, but all will have R compulsory attribute.
Let us calculate the closure of R
R + = R (from the closure method we studied earlier)
Since closure R does not contain all the attributes of R, hence R is not Candidate key.

Prepared By- Charu Kavadia Page 50

 Database Management System Unit 3

On making a combination of R with another attribute, we found that RS and RQ determine all the attributes of
R, hence RS and RQ are candidate keys of R.
Since R has 5 attributes: - P, Q, R, S, T and Candidate Keys are RS and RQ, Therefore prime attributes (part of
candidate key) are S Q R while a non-prime attribute is TP
Given FD are { QR → PST, S → Q } and Super Key / Candidate Key is RS and RQ
NOTE: To solve such questions, we apply reverse engineering, i.e. 1st check BCNF, if not then 3NF, if not then
2NF, and so on.
a. FD: QR → PST satisfies the definition of BCNF, as QR is Super Key, we check other FD for BCNF
b. FD: S → Q does not satisfy the definition of BCNF, as S is not Super Key, hence table is not in BCNF
(because if one dependency fails, all fails) now we check the same FD for 3NF
c. FD: S → Q satisfies the definition of 3NF, even though S is not Super Key but Q is the prime attribute,
hence the table is in 3NF.
Since there were only two FD's, out of which one ( QR → PST ) satisfy BCNF while the other ( S → Q)
satisfy 3NF, hence the highest normal form is 3NF R(P, Q, R, S, T) is in 3NF.

Example 5: Given a relation R( A, B, C) and Functional Dependency set FD = { A → B, B → C, and C →

A}, determine given R is in which normal form?
Solution:
Construct an arrow diagram on R using FD to calculate the candidate key.

From the above arrow diagram on R, we can see that all the attributes are determined by all the attributes of the
given FD, hence we will check all the attributes (i.e., A, B, and C) for candidate keys
Let us calculate the closure of A
A + = ABC (from the closure method we studied earlier)
Since closure A contains all the attributes of R, hence A is the Candidate key.
Let us calculate the closure of B
B + = BAC (from the closure method we studied earlier)
Since closure B contains all the attributes of R, hence B is the Candidate key.
Let us calculate the closure of C
C + = CAB (from the closure method we studied earlier)
Since closure C contains all the attributes of R, hence C is the Candidate key.
Hence three Candidate keys are: A B and C
Prepared By- Charu Kavadia Page 51
 Database Management System Unit 3

Since R has 3 attributes: - A B and C, Candidate Keys are A B and C, Therefore, prime attributes (part of
candidate key) are A B C while there is no non-prime attribute
Given FD are { A → B, B → C, and C → A } and Super Key / Candidate Key is A B and C
NOTE: To solve such questions, we apply reverse engineering, i.e. 1st check BCNF, if not then 3NF, if not then
2NF, and so on.
a. FD: A → B satisfy the definition of BCNF, as A is Super Key, we check other FD for BCNF
b. FD: B → C satisfy the definition of BCNF, as B is Super Key, we check other FD for BCNF
c. FD: C à A satisfy the definition of BCNF, as C is Super Key
Since there were only three FD's and all FD: { A → B, B → C and C → A } satisfy BCNF, hence the
highest normal form is BCNF.
Therefore R(A, B, C ) is in BCNF.

Prepared By- Charu Kavadia Page 52

 Database Management System Unit 3

Prepared By- Charu Kavadia Page 53