Database Management Systems UNIT-III

Unit – III
LEARNING MATERIAL

DATABASE DESIGN
1. Functional Dependencies
 A Functional Dependency describes the relationship between the
attributes within a relation.
 An attribute is functionally dependent on another attribute if we can use the
value of one attribute to determine the value of another attribute.
 Formally, functional dependency is defined as;

In a given relation R, X and Y are attributes. Attribute Y

is
functionally dependent on attribute X if each value of X
determines exactly one value of Y.
This is represented as X à Y
and read as X determines Y.
 For example, consider the following relation Result.

Result (Student#, StudName, Course#, CourseName,

Grade)
 In this relation, {Student#, Course#} together can determine exactly one
value of Grade. This can be represented as

{Student#, Course#} à
Grade
 This type of dependency is called as functional dependency. In the above
example Grade is functionally dependent on {Student#, Course#}.
 Other functional dependencies in the above example are:

Student# à StudName
Course# à CourseName

 As an another example, consider the relation R(A,B) with the following instance of R.

A B

Department of Information Technology A.Y.2019-20 II-II GEC Page 1

 Database Management Systems UNIT-III

1 4

1 5

3 7

 On this instance, the functional dependency A  B does not hold because, for
the value 1 of A, it is not determining exactly one value; rather it is
determining two values (4 and 5).
 But the functional dependency B  A holds on this relation.
 As another example, consider the following relation Employee.

EmpID EmpName DeptID DeptName

0001 John Doe 1 Human Resources

0002 Jane Doe 2 Marketing

0003 John Smith 1 Human Resources

0004 Jane Smith 3 Sales

Employee relation
 The functional dependencies that holds on this relation are;

EmpID  EmpName
EmpID  DeptID
DeptID  DeptName

1.1 Full Functional Dependency

 In a given relation R, X and Y are attributes. Attribute Y is fully functionally
dependent on attribute X only if it is not functionally dependent on sub-set of
X where X is composite in nature.
 For example, consider the following relation Result.

Result (Student#, StudName, Course#, CourseName,

Grade)
 One FD holds for this relation is {Student#, Course#} à Grade.
 In this, Grade is fully functionally dependent on {Student#, Course#} and not
on sub-set of {Student#, Course#}.

Department of Information Technology A.Y.2019-20 II-II GEC Page 2

 Database Management Systems UNIT-III

 This means Grade cannot be determined either by Student# or by Course#

alone. It can be determined using Student# and Course# together. Hence,
Grade is fully functionally dependent on {Student#, Course#}.

1.2 Partial Functional Dependency

 In a given relation R, X and Y are attributes. Attribute Y is partially dependent
on attribute X only if it is dependent on sub-set of attribute X where X is
composite in nature.
 Consider again the Result relation.

Result (Student#, StudName, Course#, CourseName,

Grade)
 The primary key for this relation is {Student#, Course#}.
 The FD, Student# à StudName, is a partial dependency because part of the
key {Student#, Course#} is determining StudName.
 i.e. Student# alone is determining StudName but not the entire key.
 Other partial dependency(PD) for this relation is
Course# à CourseName

1.3 Transitive Dependency

 In a given relation R, if attribute X determines attribute Y and attribute Y
determines attribute Z, then attribute X determines attribute Z. Such a
dependency is called transitive dependency.
 The following figure shows transitive dependency.

 Here,
Course# à Iname and Iname à Room# so Course# à Room#

2. Closer of a Set of Functional Dependencies

Department of Information Technology A.Y.2019-20 II-II GEC Page 3

 Database Management Systems UNIT-III

 Given a set F of functional dependencies, there are certain other functional

dependencies that are logically implied by F.
 For example: If A  B and B C, then we can infer that A C.
 The set of all functional dependencies logically implied by F is the closure of
F.

 We denote the closure of F by F+. F+ is a superset of F.

 For example, let F = { AB, BC }. Then F+ = { AB, BC, AC }.
 We can find F+, by repeatedly applying Armstrong’s Axioms.
2.1 Armstrong’s Axioms
 Let X, Y, and Z to denote sets of attributes over a relation schema R.

 Reflexivity: If then X  Y.
 Augmentation: If X  Y, then XZ  YZ for any Z.
 Transitivity: If X  Y and Y  Z, then X  Z.
 It is helpful to use some additional rules while reasoning about F+.
 Union: If X  Y and X  Z, then X YZ.
 Decomposition: If X  YZ, then X  Y and X  Z.
Example
Let F be the following set of functional dependencies: {AB→CD, B→DE,
C→F, E→G, A→B }. Use Armstrong’s axioms to show that {A→FG } is
logically implied by F.

Sol 1 AB Given

: 2 A  AB 1, Augmentation

3 AB  CD Given

4 A  CD 2,3, Transitivity

5 B  DE Given

6 A  DE 1,5, Transitivity

7 A  ACD 4, Augmentation

8 ACD  CDE 6, Augmentation twice

9 A  CDE 7,8, Transitivity

10 A  CE 9, Trivial dependency

Department of Information Technology A.Y.2019-20 II-II GEC Page 4

 Database Management Systems UNIT-III

11 CF Given

12 CE  FE 11, Augmentation

13 EG Given

14 FE  FG 13, Augmentation

15 CE  FG 12,14, Transitivity

16 A  FG 10,15, Transitivity

Example1 for F+
Assume that there are 4 attributes A, B, C, D, and that
F = { A  B, B  C }. Then, F+ includes all the following FDs:
F+ = { A  A, A  B, A  C, B  B, B  C, C  C, D  D, AB  A,
AB  B, AB  C, AC  A, AC  B, AC  C, AD  A, AD  B,
AD  C, AD  D, BC  B, BC  C, BD  B, BD  C, BD  D,
CD  C, CD  D, ABC  A, ABC  B, ABC  C, ABD  A,
ABD  B, ABD  C, ABD  D, BCD  B, BCD  C, BCD  D,
ABCD  A, ABCD  B, ABCD  C, ABCD  D }

Example 2 for F+
Let R = (A,B,C,G,H,I) and let F = { AB, AC, CG  H, CG  I, B  H } then
some members of F+ are;
A  B, B  H then A  H [Transitivity rule]
A  B, A  C then A  BC [Union rule]
CG  H, CG  I then CG  HI[Union rule]
A  H, A  BC then A  BCH [Union rule]

Algorithm 2.1: Finding F+

Department of Information Technology A.Y.2019-20 II-II GEC Page 5

 Database Management Systems UNIT-III

3. Closure of Attribute Sets

 We can observe from Algorithm 3.1 that, It is easy to generate the FDs in F+
from the closures of the attribute sets.
 Given a set of attributes α, the closure of α under F (denoted by α+ ) is the
set of attributes that are functionally determined by α under F.
Example 3.1
Assume that there are 4 attributes A, B, C, D, and that
F = { A  B, B  C }. To compute F+, we first get:
A+ = {A}
= {AB} [AB]
= {ABC} [BC]
B+ = {B}
= {BC} [BC]
C+ = {C}
D+ = {D}
AB+ = AC+ = ABC+ = {ABC}
AD+ = {AD}
BC+ = {BC}
BD+ = BCD+ = {BCD} [BC]
CD+ = {CD}
ABD+ = ABCD+ = {ABCD}
ACD+ = {ACD}
From attribute closure, it is easy to find the members of F+.
For example, from A+ = ABC, we get { AA, AB, AC, AAB, AAC,
AABC }.
Similarly, we can find the other members of F+ from the attribute closures.
Example 3.2
Let R = (A, B, C, G, H, I) and let F = { AB, AC, CGH, CGI, BH }. Compute
(AG)+. Is AG is a candidate key for R?
Sol: (AG)+ = {AG}
= {ABCG} [AB and AC]
(AG)+ = {ABCGHI} [CGH and CGI]
Now, check any sub set of {AG} is a candidate key.

Department of Information Technology A.Y.2019-20 II-II GEC Page 6

 Database Management Systems UNIT-III

A+ = {ABCH} ≠ R
G+ = {G} ≠ R
Since, (AG)+ = R (i.e. AG determines all attributes of R) and no proper
subset of {AG} is a candidate key for R So, AG is a candidate key for R.

3.1 Use of Attribute Closure

There are several uses of the attribute closure:
 Testing for superkey
 To test if α is a superkey, we compute α+, and check if α+ contains all
attributes of R.
 Testing functional dependencies
 To check if a functional dependency α β holds (or, in other words, is in

F+), just check if β

 That is, we compute α+ by using attribute closure, and then check if it
contains β.
 It is a simple and cheap test, and very useful.
 We can compute closure of F by computing attribute closures.

Example 3.3
Consider the relation R = {A,B,C,D,E,F,G,H} with a set of FDs F={CDàA, ECàH,
GHBàAB, CàD, EGàA, HàB, BEàCD, ECàB}. Find all the candidate keys of R.
Sol: Tricks for finding all the candidate keys
 If an attribute never appears on the RHS of any FD, it must be part of the
key.
 If an attribute never appears on the LHS of any FD, but appears on the RHS
of any FD, it must not be part of any key.
 Based on the above tricks, we notice that:
o EFG never appear on RHS of any FD. So, EFG must be part of ANY key
of R.
o A never appears on LHS of any FD, but appears on RHS of some FD.
So, A is not part of ANY key of R.
o We now see if EFG is itself a key…
o EFG+ = EFGA ≠ R; So, EFG alone is not key.

Department of Information Technology A.Y.2019-20 II-II GEC Page 7

 Database Management Systems UNIT-III

o Check by adding single attribute with EFG (except A):

o BEFG+ = ABCDEFGH = R; it’s a key [BE→CD, EG→A, EC→H]
o CEFG+ = ABCDEFGH = R; it’s a key [EG→A, EC→H, H→B, BE→CD]
o DEFG+ = ADEFG ≠ R; it’s not a key [EG→A]
o EFGH+ = ABCDEFGH = R; it’s a key [EG→A, H→B, BE→CD]
o If we add any further attribute(s), they will form the superkey.
Therefore, we can stop here searching for candidate key(s).
o Therefore, candidate keys are: {BEFG, CEFG, EFGH}

Example 3.4
Consider the relation R(X, Y, Z, V, W) which satisfies the following functional
dependencies.
F = { XY  Z, YZ  V, ZV  W, VW  X, XW  Y }
Which of the following functional dependencies are also satisfied by the relation
R?
i) XZ  V ii) YZV  X iii) Z  W iv) X  Z
Sol: To check whether these functional dependencies hold on R, we need to
compute the attribute closure of the attributes lying on the LHS of FDs. If
attribute closure contains the attributes on RHS respectively, then the
corresponding FD holds on R.
i) (XZ)+ = { XZ }, V not in { XZ }. So, XZ  V does not hold on R.
ii) (YZV)+ = {YZVWX}, X in {YZVWX}. So, YZV  X holds on R.
iii) Z+ = {Z}, W not in { Z }. So, Z  W does not hold on R.
iv) X+ = {X}, Z not in { X }. So, X  Z does not hold on R.
4. Canonical Cover
 Sets of functional dependencies may have redundant dependencies that can
be inferred from the others.
 For example: A  C is redundant in: {A  B, B C, A C}
 Parts of a functional dependency may be redundant.
 For example, on RHS: { A  B, B  C, A CD } can be simplified to
{ A  B, B  C, A  D }
Because, in A  CD, A  C can be obtained from
AB and BC then AC.
Hence, AC is considered as redundant.
Department of Information Technology A.Y.2019-20 II-II GEC Page 8
 Database Management Systems UNIT-III

 Similarly, on LHS: {A  B, B  C, AC  D} can be simplified to

{ A  B, B  C, C  D }
Because, in AC  D, A  D can be obtained as
AB and BC then AC.
AC = AAC
AAC and ACD then AD
Hence, AD is considered as redundant.
 Intuitively, a canonical cover of F is a minimal set of functional dependencies
equivalent to F, having no redundant dependencies or redundant parts of
dependencies

4.1 Extraneous Attributes

 Consider a set F of functional dependencies and the functional dependency
αβ in F.
o Attribute A is extraneous in α if A Є α and
and F logically implies (F – {αβ }) U {( α – A)  β }.
o Attribute A is extraneous in if A Є βand the set of functional
dependencies (F – {αβ}) U { α(β – A)} logically implies F.
 For example, given F = {A  C, AB  C }, B is extraneous in AB  C because
{A  C, AB  C} logically implies A  C (i.e. the result of
dropping B from AB  C).
 As another example, given F = {A  C, AB  CD}, C is extraneous in AB  CD
since AB  C can be inferred even after deleting C. This can be verified from
AB+ = ABCD in {A  C, AB  D}

4.1.1 Testing if an Attribute is Extraneous

 Consider a set F of functional dependencies and the functional dependency
αβ in F.
 To test if attribute A Єαis extraneous in α
1. Compute ({α} – A)+ using the dependencies in F.
2. Check ({α} – A)+ contains β; if it does, A is extraneous in α
 To test if attribute A Є β is extraneous in β
1. Compute α+ using only the dependencies in
F` = (F – {αβ}) U {α(β – A)}

Department of Information Technology A.Y.2019-20 II-II GEC Page 9

 Database Management Systems UNIT-III

2. Check that α+ contains A; if it does, A is extraneous in β

Canonical Cover
 A canonical cover for F is a set of dependencies Fc such that
o F logically implies all dependencies in Fc, and
o Fc logically implies all dependencies in F, and
o No functional dependency in Fc contains an extraneous attribute, and
o Each left side of functional dependency in Fc is unique
 To compute a canonical cover for F:

 Note: Union rule may become applicable after some extraneous attributes
have been deleted, so it has to be re-applied.

Example 4.1
Let R = (A,B,C) and F = { A  BC, B  C, A  B, AB  C }. Compute canonical
cover for R.
Sol:
 Combine A  BC and A  B into A  BC
o Set is now {A  BC, B  C, AB  C}
 A is extraneous in AB  C
o Check if the result of deleting A from AB  C is implied by the other
dependencies.
o Yes: in fact, B  C is already present!
o Set is now {A  BC, B  C}
 C is extraneous in A  BC
o Check if A  C is logically implied by A  B and the other dependencies.
o Yes: using transitivity on A  B and B  C.

Department of Information Technology A.Y.2019-20 II-II GEC Page 10

 Database Management Systems UNIT-III

 Thus, The canonical cover is: Fc = { A  B, B  C }

5. Properties of Decomposition

 Decomposition of a relation is done when a relation in relational model is not

in appropriate normal form. In such a situation, a relation is decomposed into
two or more relations.
 If there is no proper decomposition of the relation, then it may lead to
problems like loss of information.
 Hence, every decomposition should satisfy the following properties.
o Lossless decomposition (or Lossless join decomposition)
o Dependency preserving decomposition

5.1 Lossless join decomposition

 A decomposition of R into R1 and R2 is lossless join decomposition if at least
one of the following conditions is satisfied.
o R1 ∩ R2  R1 or
o R1 ∩ R2  R2
 In other words, the decomposition of relation R into R1 and R2
is lossless when the join of R1 and R2 yield the same relation as in R.
Otherwise it is said to be lossy decomposition.

To identify whether a decomposition is lossy or

lossless, it must satisfy the following conditions:
 R1 ∪ R2 = R
 R1 ∩ R2 ≠ Φ and
 R1 ∩ R2 → R1 or R1 ∩ R2 → R2

Example 5.1
 Consider Supplier_Parts schema:
Supplier_Parts(S#, Sname, City, P#, Qty)
 Having dependencies: S# → Sname, S# → City, (S#, P#) → Qty
Department of Information Technology A.Y.2019-20 II-II GEC Page 11
 Database Management Systems UNIT-III

 Decomposed as: Supplier(S#, Sname, City, Qty); Parts(P#, Qty)

 Take Natural Join to reconstruct:

S# Sname City P# Qty

3 Smith London 301 20

2 Steve Boston 20 10

5 Nick NY 400 40

5 Nick NY 301 10

S# Sname City Qty P# Qty

3 Smith London 20 301 20

2 Steve Boston 10 20 10

5 Nick NY 40 400 40

5 Nick NY 10 301 10

Natural join

S# Sname City P# Qty

3 Smith London 301 20

2 Steve Boston 20 10

2 Steve Boston 301 10

5 Nick NY 400 40
Extra tuples
5 Nick NY 20 10

5 Nick NY 301 10

Department of Information Technology A.Y.2019-20 II-II GEC Page 12

 Database Management Systems UNIT-III

 After natural join, we got two extra tuples. Therefore, the decomposition as:
Supplier(S#, Sname, City, Qty); Parts(P#, Qty) is a lossy
decomposition.
 This is because; we decomposed Supplier_Parts relation on the common
attribute Qty which is not a candidate key for Supplier or Parts.
 Decompositions not based on candidate keys leads to lossy decompositions.
 This decomposition does not preserve {S#,P#}  Qty.

Example 5.2
 Consider schema: Supplier_Parts(S#, Sname, City, P#, Qty)
 Having dependencies: S# → Sname, S# → City, (S#, P#) → Qty
 Decomposed as: Supplier(S#, Sname, City); Parts(S#, P#, Qty)

 Take Natural Join to reconstruct:

S# Sname City P# Qty

3 Smith London 301 20

2 Steve Boston 20 10

5 Nick NY 400 40

5 Nick NY 301 10

S# Sname City S# P# Qty

3 Smith London 3 301 20

2 Steve Boston 2 20 10

5 Nick NY 5 400 40

5 Nick NY 5 301 10

Natural join

Department of Information Technology A.Y.2019-20 II-II GEC Page 13

 Database Management Systems UNIT-III

S# Sname City P# Qty

3 Smith London 301 20

2 Steve Boston 20 10

5 Nick NY 400 40

5 Nick NY 301 10

 After natural join, we get back the original relation. Therefore, the
decomposition as: Supplier(S#, Sname, City); Parts(S#, P#, Qty) is a
lossless decomposition.
 Here, the common attribute S# is a candidate key in Supplier.
 This decomposition preserves all dependencies.

Example 5.3

Let R = (A, B, C) and let F = { AB, BC }. Check if the decomposition of R into
D is lossless?
i) D = { R1(A, B), R2(B, C) } ii) D = { R1(A, B), R2(A, C) }
Sol: i) Check R1 ∩ R2  R1 or R1 ∩ R2  R2
R1 ∩ R2 = (A, B) ∩ (B, C) = B and B+ = BC = R2
Hence, the decomposition is lossless.
ii) R1 ∩ R2 = (A, B) ∩ (A, C) = A and A+ = AB = R1
Hence, the decomposition is lossless.

5.2 Dependency Preserving Decomposition

 Let Fi be the set of dependencies in F+ that include only attributes in Ri.
 A decomposition is dependency preserving, if(F1UF2U…UFn )+ =F+

Let R be the original relational schema having FD set F.

Let R1 and R2 having FD set F1 and F2 respectively, are
the decomposed sub-relations of R. The decomposition of
R is said to be preserving if
 F1 ∪ F2 ≡ F {Decomposition Preserving Dependency}
 If F1 ∪ F2 ⊂ F {Decomposition NOT Preserving
Dependency} and
 F1 ∪ F2 ⊃ F {this is not possible}
Department of Information Technology A.Y.2019-20 II-II GEC Page 14
 Database Management Systems UNIT-III

 To check if a dependency αβ is preserved in a decomposition of R into R1,

R2, …, Rn we apply the following test (with attribute closure done with respect
to F ).

 If result contains all attributes in β, then the functional dependency αβ is

preserved.
 We apply the test on all dependencies in F to check if decomposition is
dependency preserving.
 This procedure takes polynomial time, instead of the exponential time
required to compute F+ and(F1 ∩ F2 ∩ … ∩ Fn)+.

Example 5.4
Let R = (ABCDEF) and F = { A→BCD, A→EF, BC→AD, BC→E, BC→F, B→F, D→E }.
Let the decomposition D = { ABCD, BF, DE }. Check whether this decomposition
is dependency preserving.
Sol: On projections

R1(ABCD) R2(BF) R3(DE)

ABCD BF DE

BCAD

Need to check for: A→BCD, A→EF, BC→AD, BC→E, BC→F, B→F, D→E
(BC)+/F1 = ABCD; (ABCD)+/F2 = ABCDF; (ABCDF)+/F3 = ABCDEF. Preserves
BC→E, BC→F
(A)+/F1 = ABCD; (ABCD)+/F2 = ABCDF; (ABCDF)+/F3 = ABCDEF. Preserves
A→EF
Since, this decomposition preserves all FDs in F So, this decomposition is
dependency preserving.

Example 5.5

Department of Information Technology A.Y.2019-20 II-II GEC Page 15

 Database Management Systems UNIT-III

Let R = (ABCDEF) and F = { AB → CD, C → D, D → E, E → F }. Let the

decomposition D = { AB, CDE, EF }. Check whether this decomposition is
dependency preserving.

Sol: On projections
R2(CDE
R1(AB) R3(EF)
)

CD EF

DE

Need to check for: AB → CD, C → D, D → E, E → F

(AB)+/F1 = AB; (AB)+/F2 = AB; (AB)+/F3 = AB. Does not preserves AB→CD.
Hence, this decomposition is not dependency preserving.
6. Normal Forms
 Normalization or Schema Refinement is a technique of organizing the data in
the database.
 Normalization is a systematic approach for decomposing a large table into
smaller tables in order to reduce data redundancy.
 Redundancy refers to repetition of same data or duplicate copies of same data
stored in different locations.
 Normalization is used for mainly two purpose:
1. Reducing data redundancy
2. Ensuring data dependencies make sense, that is, data is logically stored
 Data redundancy causes the following serious problems. Hence, it should be
reduced as much as possible. It is not possible to eliminate 100% data
redundancy.
o Update Anomalies: If one copy of such repeated data is updated, an
inconsistency is created unless all copies similarly updated.
o Insertion Anomalies: It is not be possible to store certain information
unless some other, unrelated, information is stored as well.
Example 6.1
Consider the following table.

Department of Information Technology A.Y.2019-20 II-II GEC Page 16

 Database Management Systems UNIT-III

CourseI
FID Fname HireDate CourseName
D

389 Dr. Giddens 10-Feb-1985 ENG_206 English

407 Dr. Steve 19-Apr-1999 CP_101 C Programming

407 Dr. Steve 19-Apr-1999 CO_201 Comp. Org.

Faculty_Course table

Suppose a new faculty called Dr. Nick has joined the institution and has not
yet assigned the course. Then it is not possible to insert this new faculty to
Faculty_Course table because it violates the primary key constraint.
(because CourseID is null in this case)(Primary key for this table is {FacultyID,
CourseID}

o Deletion Anomalies: It may not be possible to delete certain information

without losing some other information.
Suppose in the above Faculty_Course table, Dr. Giddens left the institution.
So, he must be deleted from the Faculty_Course table. Deleting Dr. Giddens
from this table causes the deletion of English course information also.
 Normal forms form the basis for normalization.
 A normal form specifies a set of conditions that the relational schema must
satisfy in terms of its constraints.
 Most common normal forms are:
o First Normal Form (1 NF)
o Second Normal Form (2 NF)
o Third Normal Form (3 NF)
 Informally, a relation is often described as normalized if it meets third normal
form. Most 3NF relations are free of insertion, update, and deletion anomalies.
 Additional Normal Forms:
o Elementary Key Normal Form (EKNF)
o Boyce-codd Normal Form (BCNF)
o Multivalued Dependencies And Fourth Normal Form (4 NF)
o Essential Tuple Normal Form (ETNF)

Department of Information Technology A.Y.2019-20 II-II GEC Page 17

 Database Management Systems UNIT-III

o Join Dependencies And Fifth Normal Form (5 NF)

o Sixth Normal Form (6NF)
o Domain/Key Normal Form (DKNF)

6.1 First Normal Form (1 NF)

 A relation is in first Normal Form (1 NF) if and only if all attributes contain
atomic values only.
 In other words, a relation doesn’t have multivalued attributes.
 For example, consider the following Course table.

 This table is not in 1NF because; the attribute Content does not contain
atomic values.
 To convert it into 1NF table, we rearrange the table as shown below (i.e.
create a row for each value of Content).

6.2 Prime and Non-Prime Attributes

 Prime Attributes - attributes that belongs to any candidate key are called
Prime Attributes.
 Non-Prime Attributes - Attributes that does not belongs to any candidate
key are called Non Prime Attributes.
 Prime attributes are also called as key attributes and non prime attributes
are called as non key attributes.
 For example, consider the following relation.

Result (Student#, StudName, Course#, CourseName,

Grade)
Department of Information Technology A.Y.2019-20 II-II GEC Page 18
 Database Management Systems UNIT-III

 The candidate key for this relation is {Student#, Course#}.

 Therefore, Student# and Course# are the prime attributes of Result
relation because they are part of the candidate key.
 And StudName, CourseName and Grade are the non-prime attributes
because they are not part of the candidate key {Student#, Course#}.
 If Prime attribute is determined by other attribute set, then more than one
candidate key is possible.
 For example, If A is candidate key, and X→A, then, X is also candidate key.

6.3 Second Normal Form (2NF)

 A relation is said to be in Second Normal Form (2NF) if and only if:
o It is in First Normal Form (1NF).
o No partial dependency exists between key attributes and non-key
attributes.
 For example, consider the following relation

 For this relation the key is {Stu_ID, Proj_ID}.

 It has two partial dependencies:
1. Stu_ID à Stu_Name
2. Proj_ID à Proj_Name.
 Hence, it is not in 2NF.
 To convert it into 2NF, we decompose it into two relations as shown below.

 The resulting two relations are in 2NF because there are no partial
dependencies in these relations.
Department of Information Technology A.Y.2019-20 II-II GEC Page 19
 Database Management Systems UNIT-III

6.4 Third Normal Form (3NF)

 A relation is said to be in third Normal Form (3NF) if and only if:
o It is in Second Normal Form (2NF).
o No transitive dependency exists between key attributes and non-key
attributes.
 For example, consider the following relation.

 The key for this relation is Stu_ID.

 This relation has no partial dependencies because key consist single attribute.
Hence, it is in 2NF.
 It has a transitive dependency Stu_ID à Zip à City
 Hence, it is not in 3NF. To convert it into 3NF, decompose it into 2 relations as
given below.

 The resulting two relations are in 3NF.

 There is always a lossless-join, dependency-preserving decomposition into 3NF

Example 6.1
Let R = ABCDEFGH and F = {A→B, ABCD→E, EF→GH, ACDF→EG}. Find the 3NF
decompositions of R.
Sol: Compute Canonical Cover (Fc)
 Make RHS a single attribute: {A→B, ABCD→E, EF→G, EF→H, ACDF→E,
ACDF→G}.
 Minimize LHS: ACD→E instead of ABCD→E
 Eliminate redundant FDs
o ACDF→G be removed
Department of Information Technology A.Y.2019-20 II-II GEC Page 20
 Database Management Systems UNIT-III

o ACDF→E be removed
 Fc = {A→B, ACD→E, EF→G, EF→H}
 Candidate key = ACDF
 3NF Decomposition = {AB, ACDE, EFG, EFH} U {ACDF}

6.5 Boyce-Codd Normal Form (BCNF)

 A relation is said to be in BCNF if and only if
o It is in 3NF
o all the determinants are candidate keys only.
 BCNF relation is a strong 3NF relation. i.e. all BCNF relations are in 3NF but the
reverse is not true.
 For example, consider the following Result relation.

 This table has two candidate keys – {Student#, Course#} and {EmailID,
Course#}.
 This table is in 3NF because it has no partial and transitive dependencies
between key and non-key attributes.
 But this table is not in BCNF because all determinants are not candidate keys.
This can be observed from the following FDs;
o {Student#, Course#} à Marks
o {EmailID, Course#} à Marks
o Student# à EmailID
o EmailID à Student#
 To make this table into BCNF compliant, we need to decompose the Result
table into two tables as shown below;

 The resulting two tables are in BCNF.

Department of Information Technology A.Y.2019-20 II-II GEC Page 21
 Database Management Systems UNIT-III

Example 6.2
Let R = (A, B, C ) and F = {AB, BC}. Find BCNF decompositions of R.
Sol: Key = {A}
 Hence, R is not in BCNF (Because in BC, B is not the key)
 BCNF decompositions: R1= (A, B) and R2 = (B, C)

6.6 Comparison of BCNF and 3NF

 It is always possible to decompose a relation into a set of relations that are in
3NF such that:
o the decomposition is lossless
o the dependencies are preserved
 It is always possible to decompose a relation into a set of relations that are in
BCNF such that:
o the decomposition is lossless
o it may not be possible to preserve dependencies.
S. No. 3 NF BCNF

It concentrates on Primary It concentrates on

1
Key Candidate Key

Redundancy is high as
2 0% redundancy
compared to BCNF

A dependency X → Y is
allowed in 3NF if A dependency X → Y is
3
X is a super key or Y is a allowed if X is a super key
part of some key.

6.7 Multi-valued Dependencies and 4NF

 Suppose that we have a relation as shown below with attributes course,
teacher, and book, which we denote as CTB.
 The meaning of a tuple is that teacher T can teach course C, and book B is a
recommended text for the course.
 There are no FDs; the key is CTB.
 However, the recommended texts for a course are independent of the
instructor.

Department of Information Technology A.Y.2019-20 II-II GEC Page 22

 Database Management Systems UNIT-III

Course(C Teacher(
Book(B)
) T)

Physics10
Green Mechanics
1

Physics10
Green Optics
1

Physics10
Brown Mechanics
1

Physics10
Brown Optics
1

Maths301 Green Mechanics

Maths301 Green Vectors

Maths301 Green Geometry

 There are three points to note here:

o The relation schema CTB is in BCNF; thus we would not consider
decomposing it further if we looked only at the FDs that hold over CTB.
o There is redundancy. The fact that Green can teach Physics101 is
recorded once per recommended text for the course. Similarly, the fact
that Optics is a text for Physics101 is recorded once per potential
teacher.
o The redundancy can be eliminated by decomposing CTB into CT and CB.
 The redundancy in this example is due to the constraint that the texts for a
course are independent of the instructors, which cannot be expressed in terms
of FDs.
 This constraint is an example of a multivalued dependency, or MVD.
 Now, we formally define multi-valued dependency as
 Let R be a relation schema and let X and Y be the attributes of R. The
multivalued dependency X  Y is said to hold over R if, each X value is
associated with a set of Y values and this set is independent of the values in
the other attributes.
 The above relation (CTB relation) has the following MVDs

Department of Information Technology A.Y.2019-20 II-II GEC Page 23

 Database Management Systems UNIT-III

o Course  Teacher
o Teacher  Book
 As another example, consider the following relation Person.

Phones( Dogs_Like(
Man(M)
P) D)

M1 P1 D1

M1 P2 D2

M2 P3 D2

M1 P1 D2

M1 P2 D1

 The key for this relation is MPD

 Meaning of the tuples in Person relation is
o Man M have phones P, and likes the dogs D.
o M1 have phones P1 and P2, and likes the dogs D1 and D2.
o M2 have phones P3, and likes the dog D2.
 This relation consists multi-valued dependencies as
o Man →→ Phones
o Man →→ Dogs_Like
 If two or more independent relations are kept in a single relation, then
multivalued dependency is possible. For example, Let there are two relations:
o Student(SID, Sname) where (SID → Sname)
o Course(CID, Cname) where (CID → Cname)
 There is no relation defined between Student and Course. If we kept them in a
single relation named Student_Course, then MVD will exists because of m:n
Cardinality.
 If two or more MVDs exist in a relation, then while converting into SVAs, MVD
exists.

SID Sname CID Cname

S1 A C1 C

Department of Information Technology A.Y.2019-20 II-II GEC Page 24

 Database Management Systems UNIT-III

S1 A C2 B

S2 B C1 C

S2 B C2 B

Student_Course table

 The multi-valued dependencies that exist on this table are

o SID →→ CID
o SID →→ Cname
 We use multivalued dependencies in two ways:
o To test relations to determine whether they are legal under a given set
of functional and multivalued dependencies.
o To specify constraints on the set of legal relations. We shall thus
concern ourselves only with relations that satisfy a given set of
functional and multivalued dependencies.
 A MVD X →→ Y in R is called a trivial MVD is
o Y is a subset of X (X ⊇ Y) or
o X ∪ Y = R. Otherwise, it is a non trivial MVD.

Department of Information Technology A.Y.2019-20 II-II GEC Page 25