UNIT - III

RELATIONAL DATABASE DESIGN AND NORMALIZATION

Syllabus
ER-to-Relational Mapping – Update anomalies-Functional Dependencies – Inference
rules-minimal cover-properties of relational decomposition- Normalization (upto
BCNF).

ER to Relational Mapping
In this section we will discuss how to map various ER model constructs to
Relational Model construct.

3.1.1 Mapping of Entity Set to Relationship

 An entity set is mapped to a relation in a straightforward way.
 Each attribute of entity set becomes an attribute of the table.
 The primary key attribute of entity set becomes an entity of the table.
 For example - Consider following ER diagram.

The converted employee table is as follows -

EmpID EName Salary

201 Poonam 30000

202 Ashwini 35000

203 Sharda 40000

The SQL statement captures the information for above ER diagram as follows -
CREATE TABLE Employee( EmpID
CHAR(11), EName CHAR(30),
Salary INTEGER,
PRIMARY
KEY(EmpID))

3.1.2 Mapping Relationship Sets(without Constraints) to Tables

 Create a table for the relationship set.
 Add all primary keys of the participating entity sets as fields of the table.
 Add a field for each attribute of the relationship.
 Declare a primary key using all key fields from the entity sets.
 Declare foreign key constraints for all these fields from the
entity sets. For example - Consider following ER model

The SQL statement captures the information for relationship present in

above ER diagram as follows -

CREATE TABLE Works_In (EmpID CHAR(11),

DeptID
CHAR(11),
EName
CHAR(30),
Salary INTEGER,
DeptName CHAR(20),
Building CHAR(10),
PRIMARY KEY(EmpID,DeptID),
FOREIGN KEY (EmpID) REFERENCES Employee,
FOREIGN KEY (DeptID) REFERENCES Department

3.1.3 Mapping Relationship Sets( With Constraints) to Tables

 If a relationship set involves n entity sets and some m of them are
linked via arrows in the ER diagram, the key for anyone of these m
entity sets constitutes a
 key for the relation to which the relationship set is mapped.
 Hence we have m candidate keys, and one of these should be designated
as the
primary key.
 There are two approaches used to convert a relationship sets with key
constraints into table.
 Approach 1 :

o By this approach the relationship associated with more than

one entities is separately represented using a table. For
example - Consider following ER diagram. Each Dept has at
most one manager, according to the key constraint on
Manages.

Here the constraint is each department has at the most one manager to
manage it. Hence no two tuples can have same DeptID. Hence there can
be a separate table named Manages with DeptID as Primary Key. The
table can be defined using following SQL statement

CREATE TABLE Manages(EmpID

CHAR(11),
DeptID INTEGER,
Since DATE,
PRIMARY KEY(DeptID),
FOREIGN KEY (EmpID) REFERENCES Employees,
FOREIGN KEY (DeptID) REFERENCES Departments)
 Approach 2 :

o In this approach , it is preferred to translate a relationship

set with key constraints.
o It is a superior approach because, it avoids creating a distinct
table for the relationship set.
 o The idea is to include the information about the relationship
set in the table corresponding to the entity set with the key,
taking advantage of the key constraint.
o This approach eliminates the need for a separate Manages
relation, and queries asking for a department's manager can
be answered without combining information from two
relations.
o The only drawback to this approach is that space could be
wasted if several departments have no managers.
o The following SQL statement, defining a Dep_Mgr relation that
captures the information in both Departments and Manages,
illustrates the second approach to translating relationship sets
with key constraints :

CREATE TABLE Dep_Mgr ( DeptID

INTEGER,
DName CHAR(20),
Budget REAL,
EmpID CHAR
(11),
since DATE,
PRIMARY KEY (DeptID),

3.1.4 Mapping Weak Entity Sets to Relational Mapping

A weak entity can be identified uniquely only by considering the primary
key of another (owner) entity. Following steps are used for mapping Weka
Entity Set to Relational Mapping
 Create a table for the weak entity set.
 Make each attribute of the weak entity set a field of the table.
 Add fields for the primary key attributes of the identifying owner.
 Declare a foreign key constraint on these identifying owner fields.
 Instruct the system to automatically delete any tuples in the table for
which there are no owners
For example - Consider following ER model
 Following SQL Statement illustrates this mapping

CREATE TABLE Department(DeptID CHAR(11),

DeptName CHAR(20),
Bldg_No CHAR(5),
PRIMARY KEY (DeptID,Bldg_No),
FOREIGN KEY(Bldg_No) References Buildings on delete cascade
)

Mapping of Specialization / Generalization(EER Construct) to Relational

Mapping
The specialialization/Generalization relationship(Enhanced ER Construct)
can be mapped to database tables(relations) using three methods. To
demonstrate the methods, we will take the – InventoryItem, Book, DVD

Method 1 : All the entities in the relationship are mapped to individual tables
 InventoryItem(ID ,
name)
Book(ID,Publisher)
DVD(ID, Manufacturer)
Method 2 : Only subclasses are mapped to tables. The attributes in the
superclass are duplicated in all subclasses. For example -

Book(ID,name,Publisher)
DVD(ID, name,Manufacturer)

Method 3 : Only the superclass is mapped to a table. The

attributes in the subclasses are taken to the superclass. For example -

InventoryItem(ID , name,Publisher,Manufacturer)

This method will introduce null values. When we insert a Book record in
the table, the Manufacturer column value will be null. In the same way,
when we insert a DVD record in the table, the Publisher value will be null.

3.2 Concept of Relational Database Design

 There are two primary goals of relational database design – i) to
generate a set of relation schemas that allows us to store information
without unnecessary redundancy, and ii) to allows us to retrieve
information easily.
 For achieving these goals, the database design need to be
normalized. That means we have to check whether the schema is it
normal form or not.
 For checking the normal form of the schema, it is necessary to check
the functional dependencies and other data dependencies that exists
within the schema.
Hence before letting us know what the normalization means, it is
necessary to understand the concept of functional dependencies.
3.3 Functional Dependencies
Definition : Let P and Q be sets of columns, then: P functionally
determines Q, written P → Q if and only if any two rows that are equal on (all
the attributes in) P must be equal on (all the attributes in) Q.
In other words, the functional dependency holds if
T1.P = T2.P, then T1.Q=T2.Q
 Where notation T1.P projects the tuple T1 onto the attribute in P.
For example : Consider a relation in which the roll of the student and
his/her name is stored as follows :
R N
1 AAA
2 BBB
3 CCC
4 DDD
5 EEE

Fig. 3.8.1 : Table which holds functional

dependency i.e. R->B
Here, R->N is true. That means the functional dependency holds true here.
Because for every assigned RollNuumber of student there will be unique
name. For instance : The name of the Student whose RollNo is 1 is AAA. But if
we get two different names for the same roll number then that means the
table does not hold the functional dependency. Following is such table –

R N
1 AAA
2 BBB
3 CCC
1 XXX
2 YYY

Fig. 3.8.2 : Table which does not hold

functional dependency

In above table for RollNumber 1 we are getting two different names - “AAA”
and “XXX”. Hence here it does not hold the functional dependency.

3.8.1 Computing Closure Set of Functional Dependency (Armstrong’s Axioms)

The closure set is a set of all functional dependencies implied by a given set
F. It is denoted by F+
The closure set of functional dependency can be computed using basic
three rules which are also called as Armstrong’s Axioms.
These are as follows -
 i) Reflexivity : If X  Y, then X Y
ii) Augmentation : If X Y, then XZ  YZ for any Z
iv) Transitivity : If X  Y and Y  Z, then X  Z
In addition to above axioms some additional rules for computing closure set
of functional dependency are as follows -
 Union : If X  Y and X Z then X YZ
 Decomposition : If X YZ, then X Y and X Z
Example 3.8.1 Compute the closure of the following set of functional
relation scheme R(A,B,C,D,E),
dependencies for aF={A->BC, CD->E, B->D, E->A)
Solution : Consider F as follows
A-
>BC
CD-
>E
B->D
E->A
The closure can be written for each attribute of relation as follows
 (A)+ = Step 1 : {A} -> the attribute itself
Step 2 : {ABC} as A-
>BC Step 3 : {ABCD}
as B->D Step 4 :
{ABCDE} as CD->E
Step 5 : {ABCDE} as E->A and A is
already present Hence (A)+ ={ABCDE}
 (B)+ = Step 1:{B}
Step 2 : {BD} as B->D
Step 3 : {BD} as there is no BD pair on
LHS of F Hence (B)+ ={BD}
 (C)+ = Step 1 :{C}
Step 2 : {C} as there is no single C on LHS
of F Hence (C)+ ={C}
 (D)+ = Step 1 : {D}
Step 3 : {D} as there is no BD pair on LHS of F
 Hence (D)+ ={D}
 (E)+ = Step 1 : {E}
Step 2 : {EA} as E-
>A Step 3 : {EABC}
as A->BC Step 4 :
{EABCD} as B->D
Step 5 : {EABCD} as CD->E and E is already
present By rearranging we get {ABCDE}
Hence (E)+ ={ABCDE}
 (CD)+ = Step 1:{CD}
Step 2 :{CDE}
Step 3 :{CDEA}
Step 4 :{CDEAB}
By rearranging we get
{ABCDE} Hence (CD)+

Example 3.8.2 Compute the closure of the following set of functional

dependencies for a relation scheme R(A,B,C,D,E), F={A->BC, CD->E,
B->D, E->A) and Find the candidate key.
={ABCDE}

Solution : For finding the closure of functional dependencies - Refer example

2.8.1.
We can identify candidate from the given relation schema with the help of
functional dependency. For that purpose we need to compute the closure set
of attribute. Now we will find out the closure set which can completely
identify the relation R(A,B,C,D).
Let, (A)+ = {ABCDE}
(B)+ = {BD}
(C)+ = {C}
(D)+ = {D}
(E)+ = {ABCDE}
(CD)+ = {ABCDE}
Clearly, only (A)+,(E)+ and (CD)+ gives us {ABCD} i.e. complete relation R.
Hence these are the candidate keys.
3.8.2 Canonical Cover or Minimal Cover
 Formal Definition : A minimal cover for a set F of FDs is a set G of FDs such
that :
1) Every dependency in G is of the form X->A, where A is a single attribute.
2) The closure F+ is equal to the closure G+.
3) If we obtain a set H of dependencies from G by deleting one or more
dependencies or by deleting attributes from a dependency in G, then
F+ H+.
Concept of Extraneous Attributes
Definition : An attribute of a functional dependency is said to be
extraneous if we can remove it without changing the closure of the set of
functional dependencies. The formal definition of extraneous attributes is as
follows:
Consider a set F of functional dependencies and the functional dependency   
in F

 Attribute A is extraneous in if A , and F logically implies (F – {  }) ∪

{( – A )   }
 Attribute A is extraneous in if A and the set of functional dependencies
(F – {   }) ∪ {(  ( – A) } logically implies F.
Algorithm for computing Canonical Cover for set of functional Dependencies F
Fc = F

repeat
Use the union rule to replace any dependencies in Fc of the form
1  1 and 1  2 and 1  12
Find a functional dependency    in Fc with an extraneous attribute either in 
or in .
/* The test for extraneous attributes is done using
Fc, not F */ If an extraneous attribute is found,
delete it from    in Fc .
until (Fc does not change)
Example 3.8.3 Consider the following functional dependencies over the
R(ABCDE) for finding set
attribute minimal cover FD = {A->C, AC->D, B->ADE}
Solution :
Step 1 : Split the FD such that R.H.S contain single attribute.
Hence we get A->C
AC-
>D B-
>A
 B-
>D
B-
>E
Step 2 : Find the redundant entries and delete them. This can be done as
follows -

o For A->C : We find (A)+ by assuming that we delete A->C

temporarily. We get (A)+={A}. Thus from A it is not possible to
obtain C by deleting A->C.
This means we can not delete A->C
o For AC->D : We find (AC)+ by assuming that we delete AC->D
temporarily. We get (AC)+={AC}. Thus by such deletion it is
not possible to obtain D. This means we can not delete AC->D
o For B->A : We find (B)+ by assuming that we delete B->A
temporarily. We get (B)+={BDE}. Thus by such deletion it is
not possible to obtain A. This means we can not delete B->A
o For B->D : We find (B)+ by assuming that we delete B->D
temporarily. We get (B)+={BEACD}. This shows clearly that
even if we delete B->D we can obtain D. This means we can
delete B->A. Thus it is redundant.
o For B->E : We find (B)+ by assuming that we delete B->E
temporarily. We get (B)+={BDAC}. Thus by such deletion it is
not possible to obtain E. This means we can not delete B->E

To summarize we get now

A->C
AC-
>D B-
>A
B->E
Thus R.H.S gets simplified.
Step 3 : Now we will simplify L.H.S.
Consider AC->D. Here we can split A and C. For that we find closure set of
A and C. (A)+ = (AC)
(C)+ = (C)
 Thus C can be obtained from both A as well as C. That also means we need
not have to have AC on L.H.S. Instead, only A can be allowed and C can be
eliminated. Thus after
simplification we get
A->D
To summarize we get now
A-
>C
A-
>D
B-
>A
B-
>E
Thus L.H.S gets simplified.
Step 3 : The simplified L.H.S. and R.H.S can be combined together to form
A-
>CD
B-
>AE
This is a minimal cover or Canonical cover of functional dependencies.
3.4 Concept of Redundancy and Anomalies
Definition : Redundancy is a condition created in database in which same
piece of data is held at two different places.
Redundancy is at the root of several problems associated with relational
schemas.
Problems caused by redundancy : Following problems can be caused by
redundancy-
i) Redundant storage : Some information is stored repeatedly.
ii) Update anomalies : If one copy of such repeated data is updated then
inconsistency is created unless all other copies are similarly updated.
iii) Insertion anomalies : Due to insertion of new record repeated
information get added to the relation schema.
iv) Deletion anomalies : Due to deletion of particular record some
other important information associated with the deleted record get
deleted and thus we may lose some other important information from the
schema.
Example : Following example illustrates the above discussed anomalies or
redundancy problems
 Consider following Schema in which all possible information about
Employee is stored.
1) Redundant storage : Note that the information about DeptID,
DeptName and
DeptLoc is repeated.
2) Update anomalies : In above table if we change DeptLoc of Pune to
Chennai, then it will result inconsistency as for DeptID 101 the
DeptLoc is Pune. Or otherwise, we need to update multiple copies of
DeptLoc from Pune to Chennai. Hence this is an update anomaly.
3) Insertion anomalies : For above table if we want to add new
tuple say (5, EEE,50000) for DeptID 101 then it will cause
repeated information of (101, XYZ,Pune) will occur.
4) Deletion anomalies : For above table, if we delete a record for EmpID
4, then automatically information about the DeptID 102,DeptName
PQR and DeptLoc Mumbai will get deleted and one may not be aware
about DeptID 102. This causes deletion anomaly.
 3.10 Decomposition
 Decomposition is the process of breaking down one table into multiple
tables.
 Formal definition of decomposition is -
 A decomposition of relation Schema R consists of replacing the relation
Schema by two relation schema that each contain a subset of attributes
of R and together include all attributes of R by storing projections of
the instance.
For example - Consider the following table
Employee_Department table as follows -
Eid Ename Age City Salary Deptid DeptName
E001 ABC 29 Pune 20000 D001 Finance
E002 PQR 30 Pune 30000 D002 Production
E003 LMN 25 Mumbai 5000 D003 Sales
E004 XYZ 24 Mumbai 4000 D004 Marketing
E005 STU 32 Hyderabad25000 D005 Human Resource
We can decompose the above relation Schema into two relation schemas
as Employee (Eid, Ename, Age, City, Salary) and Department (Deptid,
Eid, DeptName). as follows -
Employee Table
Eid Ename Age City Salary
E001 ABC 29 Pune 20000
E002 PQR 30 Pune 30000
E003 LMN 25 Mumbai 5000
E004 XYZ 24 Mumbai 4000
E005 STU 32 Hyderabad 25000

Department Table
Deptid Eid DeptName
D001 E001 Finance
D002 E002 Production
D003 E003 Sales
D004 E004 Marketing
D005 E005 Human Resource
 The decomposition is used for eliminating redundancy.
  For example : Consider following relation Schema R in which we
assume that the grade determines the salary, the redundancy is
caused

Schema R

 Hence, the above table can be decomposed into two Schema S and T as
follows :

Sch ema S Schem a T

Name eid deptnam Grade Grade Salary
e
2 8000
AAA 121 Accounts 2
3 7000
AAA 132 Sales 3
4 7000
BBB 101 Marketing 4
2 8000
CCC 106 Purchase 2

Problems Related to Decomposition :

Following are the potential problems to consider :
1) Some queries become more expensive.
2) Given instances of the decomposed relations, we may not be able to
reconstruct the corresponding instance of the original relation!
3) Checking some dependencies may require joining the instances of the
decomposed relations.
4) There may be loss of information during decomposition.
Properties Associated With Decomposition
There are two properties associated with decomposition and those are –
1) Loss-less Join or non Loss Decomposition : When all information
found in the original database is preserved after decomposition, we call
it as loss less or non loss decomposition.
2) Dependency Preservation : This is a property in which the constraints
on the original table can be maintained by simply enforcing some
constraints on each of the smaller relations.
 3.10.1 Non-loss Decomposition or Loss-less Join
The lossless join can be defined using following three conditions :
i) 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) ∪ Att(R2) = Att(R)
ii) Intersection of attributes of R1 and R2 must not be NULL.
Att(R1) ∩ Att(R2) ≠ Φ
iii)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)

Solution :
Step 1 : Here Att(R1) ∪ Att(R2) = Att(R) i.e R1(A,B,C) ∪ R2(A,D)=(A,B,C,D) i.e
R.
Thus first condition gets satisfied.
Step 2 : Here R1 ∩ R2={A}. Thus Att(R1) ∩ Att(R2) ≠ . Here the second
condition gets satisfied.
Step 3 : Att(R1) ∩ Att(R2) -> {A}. Now (A)+={A,B,C}  attributes of
R1. Thus the third condition gets satisfied.
This shows that the given decomposition is a lossless join.
Example 3.10.2 Consider the following relation R(A,B,C,D,E,F) and FDs A-
>BC, C->A,
D->E, F->A, E->D is the decomposition of R into R1(A,C,D), R2(B,C,D),
and R3(E,F,D). Check for lossless.
Solution :

is satisfied as (A,C,D)∪ (B,C,D) ∪ (E,F,D)={A,B,C,D,E,F} which is

Step 1 : R1 R2 R3=R. Here the first condition for checking lossless join

nothing but R.
Step 2 : Consider R1∩ R2={CD} and R2∩R3={D}. Hence second
condition of intersection not being  gets satisfied.
Step 3 : Now, consider R1(A,C,D) and R2(B,C,D). We find R1∩R2={CD}
(CD)+ = {ABCDE}  attributes of R1 i.e.{A,C,D}. Hence condition 3 for
checking lossless join for R1 and R2 gets satisfied.
Step 4 : Now, consider R2(B,C,D) and R3(E,F,D) . We find R2∩R3={D}.
(D)+={D,E} which is neither complete set of attributes of R2 or R3.[Note that
F is missing for being attribute of R3].
 Hence it is not lossless join decomposition. Or in other words we can say
it is a
lossy decomposition.
Example 3.10.3 Suppose that we decompose schema R=(A,B,C,D,E) into
(A,B,C) (C,D,E) Show that it is not a lossless decomposition.
Solution :Step 1 : Here we need to assume some data for the
attributes A, B, C, D, and E. Using this data we can represent the
relation as follows –
Relation R
A B C D E
a 1 x p q
b 2 x r s

Relation R1 = (A,B,C)
A B C
a 1 x
b 2 x

Relation R2 = (C,D,E)
C D E
x p q
X r s

based on common attribute C. We get R1 ⋈ R2 as

Step 2 : Now we will join these tables using natural join, i.e. the join

A B C D E
a 1 x p q Here we get more rows
or tuples than original
a 1 x r s
relation R
b 2 x p q

b 2 x r s
 Clearly R1 ⋈ R2  R. Hence it is not lossless decomposition.

3.10.2 Dependency Preservation

dependency preserving for a set F of Functional dependency if - (F1 ∪

 Definition : A Decomposition D = {R1, R2, R3….Rn} of R is

F2 ∪ … ∪ Fm) = F.
 If decomposition is not dependency-preserving, some dependency is
lost in the decomposition.

Example 3.10.4 Consider the relation R (A, B, C) for functional dependency set
{A -> B and
B -> C} which is decomposed into two relations R 1 = (A, C) and R2 = (B,
C). Then check if this decomposition dependency preserving or not.
Solution : This can be solved in following steps :

Step 1 : For checking whether the decomposition is dependency

preserving or not we need to check
following condition

F+ = (F1 F2)+
Step 2 : We have with us the F+ ={ A->B and B->C }
Step 3 : Let us find (F1)+ for relation R1 and (F2)+ for relation R2

R1(A,C) R2(B,C)
A->A Trivial B->B Trivial
C->C Trivial C->C Trivial
A->C In (F)+A->B->C and it is B->C In (F)+ B->C and it is Non-
Nontrivial AC->AC Trivial Trivial BC->BC Trivial
A->B but is not useful as B is not We can not obtain C->B
part of R1 set
We can not obtain C->A

Step 4 : We will eliminate all the trivial relations and useless relations. Hence
we can obtain R1 and R2 as
R1(A,C) R2(B,C)
A->C Nontrivial

B->C Non-Trivial
 (F1∪ F2)+ = {A->C, B->C} {A->B, B->C} i.e.(F)+

Thus the condition specified in step 1 i.e. F+=(F1 F2)+ is not true. Hence
it is not dependency preserving decomposition.

Example 3.10.5 Let relation R(A,B,C,D) be a relational schema with

following functional dependencies {A->B, B->C,C->D, and D->B}. The
decomposition of R into (A,B), (B,C) and (B,D). Check whether this
decomposition is dependency preserving or not.
Solution :
Step 1 : Let (F)+ = {A->B, B->C, C->D,D->B}.
Step 2 : We will find (F1)+, (F2)+, (F3)+ for relations R1(A,B) , R2(B,C) and
R3(B,D) as follows -
R1(A,B) R2(B,C) R3(B,D)
A->A Trivial B->B Trivial B->B Trivial
B->B Trivial C->C Trivial D->D Trivial
A->B ∵ (F)+ B->C ∵ (F)+ and B-> D ∵ (F)+ as
it’s non Trivial and B->C->D and
and it’s non Trivial it’s non Trivial
B->A can not C->B ∵ In (F)+
be obtained and C->D->C D->B ∵ (F)+ and
and it is it’s non Trivial
AB->AB
Nontrivial BD->BD Trivial
BC->BC Trivial

Step 3 : We will eliminate all the trivial relations and useless relations.
Hence we can obtain R1 ∪ R2 ∪ R3 as
R1(A, R2(B,C) R2(B,D)
B) A- B- B->
>B >C D D-
C- >B
>B

Step 5 : This proves that F+=(F1 F2 F3)+. Hence given

decomposition is dependency preserving.
3.11 Normal Forms AU : Dec.-14, 15, May-18, Marks 16

 Normalization is the process of reorganizing data in a database so that it

meets
two basic requirements:
1) There is no redundancy of data (all data is stored in only one place),
and
2) data dependencies are logical (all related data items are stored
together)
 The normalization is important because it allows database to take up
less disk space.
 It also help in increasing the performance.

3.11.1 First Normal Form

The table is said to be in 1NF if it follows following rules -
i) It should only have single (atomic) valued attributes/columns.
ii) Values stored in a column should be of the same domain
iii) All the columns in a table should have unique names.
iv) And the order in which data is stored, does not matter.
Consider following Student table
Student
sid sname Phone
1 AAA 11111
22222

2 BBB 33333
3 CCC 44444
55555

As there are multiple values of phone number for sid 1 and 3, the above
table is not in 1NF. We can make it in 1NF. The conversion is as follows -
sid sname Phone
1 AAA 11111
1 AAA 22222
2 BBB 33333
3 CCC 44444
3 CCC 55555
 3.11.2 Second Normal Form
Before understanding the second normal form let us first discuss the
concept of partial functional dependency and prime and non prime attributes.

Concept of Partial Functional Dependency

Partial dependency means that a nonprime attribute is functionally
dependent on part of a candidate key.
For example : Consider a relation R(A,B,C,D) with functional
dependency
{AB->CD,A->C}
Here (AB) is a candidate key because
(AB)+ = {ABCD}={R}
Hence {A,B} are prime attributes and {C,D} are non prime attribute. In A-
>C, the non prime attribute C is dependent upon A which is actually a part of
candidate key AB. Hence due to A->C we get partial functional dependency.

Prime and Non Prime Attributes

 Prime attribute : An attribute, which is a part of the candidate-key,
is known as a prime attribute.
 Non-prime attribute : An attribute, which is not a part of the prime-
key, is said to be a non-prime attribute.
 Example : Consider a Relation R={A,B,C,D} and candidate key as
AB, the Prime attributes : A, B
Non Prime attributes : C, D
The Second Normal Form
For a table to be in the Second Normal Form, following conditions must be
followed
i) It should be in the First Normal form.
ii) It should not have partial functional dependency.
For example : Consider following table in which every information about
a the Student is maintained in a table such as student id(sid), student
name(sname), course id(cid) and course name(cname).

Student_Course
sid sname cid cnam
e
1 AAA 101 C
2 BBB 102 C++
3 CCC 101 C
4 DDD 103 Java
 This table is not in 2NF. For converting above table to 2NF we must follow
the following steps -
Step 1 : The above table is in 1NF.
Step 2 : Here sname and sid are associated similarly cid and cname
are associated with each other. Now if we delete a record with sid=2,
then automatically the course C++ will also get deleted. Thus,
sid->sname or cid->cname is a partial functional dependency, because
{sid,cid} should be essentially a candidate key for above table. Hence
to bring the above table to 2NF we must decompose it as follows :

Student
Here candidate key is
sid sname cid (sid,cid)
and
1 AAA 101 (sid,cid)->sname
2 BBB 102
3 CCC 101
4 DDD 103

Course
cid cnam
e Here candidate key is
cid
101 C
Here cid-
102 >cname

101 C
103 Java

Thus now table is in 2NF as there is no partial functional dependency

3.11.3 Third Normal Form
Before understanding the third normal form let us first discuss the
concept of transitive dependency, super key and candidate key

Concept of Transitive Dependency

A functional dependency is said to be transitive if it is indirectly formed by
two functional dependencies. For example -
X -> Z is a transitive dependency if the following functional dependencies hold
true :
 X- >
Y Y-
>Z
Concept of Super key and Candidate Key
Superkey : A super key is a set or one of more columns (attributes) to
uniquely identify rows in a table.
Candidate key : The minimal set of attribute which can uniquely
identify a tuple is known as candidate key. For example consider
following table
RegID RollNo Sname

101 1 AAA
102 2 BBB
103 3 CCC
104 4 DDD

Superkeys
 {RegID}
 {RegID, RollNo}
 {RegID,Sname}
 {RollNo,Sname}
 {RegID, RollNo,Sname}
Candidate Keys
 {RegID}
 {RollNo}

Third Normal Form

A table is said to be in the Third Normal Form when,
i) It is in the Second Normal form.(i.e. it does not have partial functional
dependency)
ii) It doesn't have transitive
dependency. Or in other words
In other words 3NF can be defined as : A table is in 3NF if it is in 2NF and
for each functional dependency
X- > Y

at least one of the following conditions hold :

i) X is a super key of table
ii) Y is a prime attribute of table
 For example : Consider following table Student_details as follows -
sid sname zipcode cityname state
1 AAA 11111 Pune Maharashtra
2 BBB 22222 Surat Gujarat
3 CCC 33333 Chennai Tamilnadu
4 DDD 44444 Jaipur Rajastan
5 EEE 55555 Mumbai Maharashtra
Here
Super keys : {sid},{sid,sname},{sid,sname,zipcode}, {sid,zipcode,cityname}… and
so on.
Candidate keys : {sid}
Non-Prime attributes : {sname,zipcode,cityname,state}
The dependencies can be
denoted as sid->sname
sid->zipcode
zipcode-
>cityname
cityname-
>state
The above denotes the transitive dependency. Hence above table is not in 3NF.
We can convert it into 3NF as follows :
Student
sid sname zipcode
1 AAA 11111
2 BBB 22222
3 CCC 33333
4 DDD 44444
5 EEE 55555

Zip
zipcode cityname state
11111 Pune Maharashtra
22222 Surat Gujarat
33333 Chennai Tamilnadu
 44444 Jaipur Rajasthan
55555 Mumbai Maharashtr
a
Example 3.11.1 Consider the relation R = {A, B, C, D, E, F, G, H, I, J}
and the set of functional dependencies F= {{A, B} C, A {D, E}, B
F, F {G, H}, D {I, J} }
1.What is the key for R ? Demonstrate it using the inference rules.
2.Decompose R into 2NF, then 3NF relations.
Solution : Let,
A  DE (given)
 A  D, A  E
As D  I J, A  I J
Using union rule we get
A  DEIJ

As A A
we get A  ADEIJ
Using augmentation rule we compute AB
AB  ABDEIJ
But AB  C (given)
 AB  ABCDEIJ
B  F (given) F  GH  B  GH (transitivity)
 AB  AGH is also true

Similarly AB  AF ∵BF
(given) Thus now using union rule
AB  ABCDEFGHIJ
 AB is a key
The table can be converted to 2NF as
R1 = (A, B, C)
R2 = (A, D, E, I, J)
R3 = (B, F, G, H)
 The above 2NF relations can be converted to 3NF as follows
R1 = (A, B, C)
R2 = (A, D, E)
R3 = (D, I, J)
R4 = (B, E)
R5 = (E, G, H).

University Questions
What is database normalization ? Explain the first normal form, second
normal form and third normal form. AU : May-18, Marks 13; Dec.-15, Marks 16
What are normal forms. Explain the types of normal form with an example.

3.12 Boyce / Codd Normal Form (BCNF)

Boyce and Codd Normal Form is a higher version of the Third Normal
form. This form deals with certain type of anomaly that is not handled by 3NF.
A 3NF table which does not have multiple overlapping candidate keys
is said to be in BCNF.
Or in other words,
For a table to be in BCNF, following conditions must be satisfied :
i) R must be in 3rd Normal Form
ii) For each functional dependency ( X → Y ), X should be a super Key.
In simple words if Y is a prime attribute then X can not be non prime
attribute.
For example - Consider following table that represents that a Student
enrollment for the course -

Enrollment Table
sid course Teacher
1 C Ankita
1 Java Poonam
2 C Ankita
3 C++ Supriya
4 C Archana
 From above table following observations can be made :
 One student can enroll for multiple courses. For example student
with sid=1 can enroll for C as well as Java.
 For each course, a teacher is assigned to the student.
 There can be multiple teachers teaching one course for example
course C can be taught by both the teachers namely - Ankita and
Archana.
 The candidate key for above table can be (sid,course), because using
these two columns we can find
 The above table holds following dependencies
o (sid,course)->Teacher
o Teacher->course
 The above table is not in BCNF because of the dependency teacher-
>course. Note that the teacher is not a superkey or in other words,
teacher is a non prime attribute and course is a prime attribute and
non-prime attribute derives the prime attribute.
 To convert the above table to BCNF we must decompose above table
into Student and Course tables

Student
sid Teacher
1 Ankita
1 Poonam
2 Ankita
3 Supriya
4 Archana

Course
Teacher course
Ankita C
Poonam Java
Ankita C
Supriya C++
Archana C

Now the table is in BCNF

 Example 3.12.1 Consider a relation(A,B,C,D) having following FDs.{AB->C,
C->A, B->D}. Find out the normal form of R.
AB->D,
Solution :
Step 1 : We will first find out the candidate key from the
given FD. (AB)+ = {ABCD} = R
(BC)+ =

{ABCD} = R

(AC) + = {AC}

R
There is no involvement of D on LHS of the FD rules. Hence D can not be part
of any
candidate key. Thus we obtain two candidate keys (AB)+ and (BC)+. Hence
prime attributes = {A,B,C}
Non prime attributes = {D}
Step 2 : Now, we will start checking from reverse manner, that means
from BCNF, then 3NF, then 2NF.
Step 3 : For R being in BCNF for X->Y the X should be candidate key or
super key.
From above FDs consider C->D in which C is not a candidate key or
super key. Hence given relation is not in BCNF.
Step 4 : For R being in 3NF for X->Y either i) the X should be candidate
key or super key or ii) Y should be prime attribute. (For prime and non
prime attributes refer step 1)

o For AB->C or AB->D the AB is a candidate key. Condition

for 3NF is satisfied.
o Consider C->A. In this FD the C is not candidate key but A
is a prime attribute. Condition for 3NF is satisfied.
o Now consider B->D. In this FD, the B is not candidate key,
similarly D is not a prime attribute. Hence condition for 3NF
fails over here.
Hence given relation is not in 3NF.
Step 5 : For R being in 2NF following condition should not occur.
Let X->Y, if X is a proper subset of candidate key and Y is a non prime
attribute. This is a case of partial functional dependency.
For relation to be in 2NF there should not be any partial functional dependency.
o For AB->C or AB->D the AB is a complete candidate key.
Condition for 2NF is satisfied.
 o Consider C->A. In this FD the C is not candidate key. Condition
for 2NF is satisfied.
o Now consider B->D. In this FD, the B is a part of candidate
key(AB or BC), similarly D is not a prime attribute. That means
partial functional dependency occurs here. Hence condition
for 2NF fails over here.
Hence given relation is not in 2NF.
Therefore we can conclude that the given relation R is in 1NF.
Example 3.12.2 Consider a relation R(ABC) with following FD A->B, B->C
What is the normal form of R ?
and C->A.
Solution :
Step 1 : We will find the candidate key
(A)+ = {ABC} =R
(B)+ = {ABC} =R
(C)+ = {ABC} =R
Hence A, B and C all are candidate keys

Prime attributes = {A,B,C}

Non prime attribute{}
Step 2 : For R being in BCNF for X->Y the X should be candidate key or super
key.
From above FDs

o Consider A->B in which A is a candidate key or super key.

Condition for BCNF is satisfied.
o Consider B->C in which B is a candidate key or super key.
Condition for BCNF is satisfied.
o Consider C->A in which C is a candidate key or super key.
Condition for BCNF is satisfied.
This shows that the given relation R is in BCNF.
Example 3.12.3 Prove that any relational schema with two attributes is in
BCNF.
Solution : Here, we will consider R={A,B} i.e. a relational schema with two
attributes. Now various possible FDs are A->B, B->A.
From the above FDs
o Consider A->B in which A is a candidate key or super key. Condition
for
 o BCNF is satisfied.
o Consider B->A in which B is a candidate key or super key.
Condition for BCNF is satisfied.
o Consider both A->B and B->A with both A and B is candidate
key or super key. Condition for BCNF is satisfied.
o No FD holds in relation R. In this {A,B} is candidate key or
super key. Still condition for BCNF is satisfied.
This shows that any relation R is in BCNF with two attributes.