Boyce Codd Normal Form

(BCNF)
 More on Third Normal Form
• A relation R is automatically in 3 NF if one of the following holds
(i) R has two attributes
(ii) If 2 NF relation has only one non-key attribute
• If X A is functional dependency in R then R is in 3 NF if one of the following holds
(i) X is super key
(ii) A is contained in the super key or A is prime attribute
• If X A is functional dependency in R then R is not in 3 NF if one the following holds
(i) X is non prime attribute and A is non prime attribute
(ii) X is prime attribute and A is non prime attribute
 Third Normal Form Stu_ID City Status
• Example 1 Kolkata 1
2 Delhi 1
 Student_City (Stu_ID, City, Status) (already in 2NF) 3 Delhi 1
4 Kanpur 4
• Primary key: Stu_ID
• FDs: Stu_ID City, City Status 5 Durgapur 7
• Transitive FD: Stu_ID Status (as Stu_ID City, City Status)
• Therefore, Student_City is not in 3 NF as it has transitive functional dependency
• We decompose the relation into relations which comply with 3 NF
Student City_info
Stu_ID City City Status
Student (Stu_ID, City) (PK: Stu_ID)
1 Kolkata Kolkata 1
City_info ( City, Status) (PK: City)
2 Delhi Delhi 1
3 Delhi Kanpur 4
Above two relations (Student, City_info) are
4 Kanpur Durgapur 7
1. 3 NF
2. Lossless decomposition 5 Durgapur
3. Dependency preserving
 Redundancy In 3 NF
• Relation in 3 NF has certain redundancy
• Example:
Let R =( SID, Advisor, Deptname) with FDs:
(i) SID, Deptname Advisor
(ii) Advisor Deptname
• Relation R is in 3 NF as (a) candidate key for R = (SID, Deptname) and for first FD: X A, X is
candidate key, (b) for second FD: X A , A is contained in the candidate key
SID Advisor Deptname
101 DRK CSE
102 DRK CSE
103 DRK CSE
104 JD BT

• (DRK, CSE) in R is repeated multiple times. So, there is redundancy. This redundancy can
cause update anomaly
 Boyce Codd Normal Form (BCNF)
• However, 3 NF is adequate for database design, still 3 NF does not remove
redundancy ( discussed in previous slide)
• BCNF is used to remove possible redundancy from the relation
• BCNF is extension of 3 NF and more stronger than 3 NF
• Every relation that is in BCNF, is also in 3 NF. However, relation in 3NF may not be
in BCNF

• A relation R is in BCNF if and only if the followings hold

(i) R is in 3 NF
(ii) For every non trivial FD: X , X is super key

• If X is a super key, there cannot be two tuples with same value of X – Hence, BCNF
eliminates redundancy
 BCNF Example 1
• Let, Student (SID, Course, Advisor) SID Course Advisor
1 CSC01 E01
• Candidate key: (SID, Course)
1 ME01 E03
We assume that, 2 BT01 E02
An advisor takes only one course 3 CSC01 E01
A course can be taught by many advisors 3 BT01 E02

A student can take more than one courses

• FDs:
(i) SID, Course Advisor
(ii) Advisor Course
• Student is in 3 NF but not in BCNF
• For FD (i): X , X is candidate key. For FD (ii) X , X( advisor) is not super key.
Hence, Advisor Course violates BCNF rule
• R is not in BCNF
 Decomposition
• If relation schema R doesn’t satisfy a particular normal form, we decompose R
into smaller schemas (R1, R2,R3…)
• The decomposition D of schema R under a set of functional dependencies F is a
collection of schemas (Ri, Fi) where
R = (no new attributes)
where Ri’s need not be disjoint
Fi is a set of functional dependences involving only attributes of Ri
F entails Fi for all i (no new FDs)
 BCNF Decomposition Algorithm
Input: R = (R; F) // R is universal relation//
D := R
while there is a relation schema S ∈ D and S not in BCNF do
Find X → Y in S that violates BCNF // X isn’t a super key in S
Replace S in D with S1 = (X∪ Y, F1), S2 = (S – Y, F2 )
// F1 = all FDs of F involving only attributes of X∪Y
// F2 = all FDs of F involving only attributes of S - (Y)
end
return D
 Decomposition into BCNF (Example 1)
• Student is not in BCNF. So, decompose it
• After decomposition
Instructor_info (Advisor, Course)
Student_info ( SID, Advisor)
• Advisor Course is preserved after decomposition, however, the
decomposition fails to preserve (SID, Course) Advisor
• Both the relations are in BCNF
 BCNF Decomposition Example 2
Consider a relation with schema R(A,B,C,D) and FDs {AB -> C, C -> D,
D -> A}
1. What are all candidate keys of R?
By calculating an attribute closure we can see the candidate keys are: AB, BC, and
BD
2. Indicate all BCNF violations for R.
C->D and D->A
3. Decompose the relations into collections of relations that are in BCNF.
R1= (CD) R2= (ABC)
R1 is in BCNF and C->D is preserved
R2 is not in BCNF due to violation of C->A. Decompose R2 into R21 (CA) and
R22( BC). R22 and R21 are in BCNF
If we start with D->A, D is not super key. This FD violets BCNF rule
Replace R with R1 = (DA) and R2 = ( BCD)
R1 is in BCNF
R2 is not in BCNF due to violation of C->D
Replace R2 with R21 (CD) R22 (BC)
4. Indicate which dependencies if any are not preserved by the BCNF
decomposition.
If we start to decompose on C->D then D->A and AB->C
If we start to decompose on D->A then AB->C
 Desirable Properties of Decompositions

• Not all decomposition of a schema are useful

• We require two properties to be satisfied
1. Lossless join property
2. Dependency preserving property
 Decomposition
• If relation schema R doesn’t satisfy a particular normal form, we decompose R
into smaller schemas (R1, R2,R3…)
• The decomposition D of schema R under a set of functional dependencies F is a
collection of schemas (Ri, Fi) where
R = (no new attributes)
where Ri’s need not be disjoint
Fi is a set of functional dependences involving only attributes of Ri
F entails Fi for all i (no new FDs)
 Lossless Decompositions

• Decomposition must be lossless: It must be possible to reconstruct the original

relation from the relations in the decomposition

• Formally, a decomposition D= {R1,…,Rn} of a schema, R, is lossless with respect

to the set of functional dependencies F on R, if every valid instance r of R that
satisfies F can be reconstructed from its components:
r = r1 * r2* …… * rn
where each ri =(r)
• ‘Loss’ in lossless refers to loss of information, not loss of tuples
 Lossy Decomposition

• In Lossy decomposition, we may get spurious tuples after project and natural join
operations are applied, which might give wrong information
• The following is always the case :
r ⊆ r1 * r2* ... * rn
• But the following is not always true:
r ⊇ r1 * r2* ... * rn
 Dependency Preservation
• If every FD specified in either appeared directly in one of the relation schemas in
decomposition D or could be inferred from the dependencies that appear in some ,
then we say the decomposition is dependency preserving decomposition
• This is important as each FD in F represents some constraints on database
• If dependency is lost after decomposition, we have to join two or more relations in
decomposition and check that dependency holds in the result of the join. This is
impractical and inefficient
• Decomposition D = (R1, R2,…,Rk) of schema R preserves a set of dependencies F
((F) ∪…………………. ∪ (F))+ =
Here, (F) = projection of F on R= { X| X}
 Claim

• It is possible to find a dependency preserving decomposition D with

respect to F such that each relation Ri in D in 3NF
• A BCNF decomposition is not necessarily dependency preserving but
always lossless
• BCNF + lossless + dependency preserving is sometimes unachievable
 BCNF Decomposition Not Dependency Preserving
It is not always possible to get a BCNF decomposition that is dependency
preserving
Given: R = (ABCFGH); FDs: {ABH→C, BGH→F, F→AH, BH→G})
step 1: Find a FD that violates BCNF
Not ABH → C or BGH → F, since BH is a key of R
F→ AH violates BCNF since F is not a super key
step 2: Split R into:
R1 = (FAH, {F → AH}) R2 = (BCFG; {})
Note 1: Both R1 and R2 are in BCNF
Note 2: The decomposition is lossless (since F is a key of R1)
Note 3: FDs : ABH→ C, BGH→ F, BH→ G are not in R1 or R2 , and they can’t be
derived from closure of F(R1) ∪ F(R2)
Hence the decomposition is not dependency-preserving
 BCNF and Not Dependency Preserving

• Relation R (J, K, L)
FDs: { J, K} L
L K
Candidate key: {J,K} , { J, L}
• R is already in 3 NF
• R is not in BCNF for L K as L is not candidate key
• Decompose R:
R1 ( L, K) and R2 (J, L)
• FD: L K is preserved in R1. But, R fails to preserve {J, K} L
• This implies: testing for {J, K} L requires a join
• R is not in BCNF
• It is better in 3 NF since all dependencies are preserved in R
 Decomposition into BCNF
• Let R ( A,B,C,D,E) , FD: { A BC, C DE}

• First, find key for R. Here, { A} is the key

• Look at FD: A BC. Is A key? Answer is yes. So FD does not violate BCNF rule

• Look at FD: C DE. Is C key? No. So, FD violates BCNF rule. We decompose R into R1
(C,D,E) and R2 ( A, B, C) i.e., creating sub schemas , one with attributes of violating FD and
the other with the original attributes minus RHS of violating FD

• R1 ( C, D, E) is in BCNF as C is key. R2( A, B, C ) is in BCNF as A BC is preserved here and A

is key

• This is an example of BCNF decomposition with dependency preservation

 ?????

Q. Let , R is a relation with attributes (A, B, C, D) and FDs are

AB C
B D
C A
1. Prove that R is not in BCNF
2. Decompose R into appropriate schemas that are in BCNF
3. Does the decomposition preserve dependencies?

Answer in next slide

Keys are: AB, BC
R is not in BCNF as B D is the violating FD
Decompose R into R1 and R2
R1 =(A, B, C) R2= (B, D)
R2 is in 3 NF and BCNF and preserves B D
R1 is in 3 NF but not in BCNF due to C A
Decompose R1 into R11 and R12
R11= (C, A) R12 ( B, C)
R11 preserves C A. R12 has no FDs
R11 and R12 are in BCNF
FD: AB C is lost. To keep it, we take join of R11 and R12. But R1 is not 3NF. So
decomposition is in 3 NF.
Else decomposition is in BCNF
 Design Goals of Database Design

• Goal for a relational database design is:

• BCNF
• Lossless join
• Dependency preservation
• If we cannot achieve this, we accept one of
• Lack of dependency preservation
• Redundancy due to use of 3NF
Comparison Between 3 NF and BCNF
3 NF BCNF

It concentrates on primary key It concentrates on candidate key

Decomposition is lossless Decomposition is lossless

It is always dependency preserving It is not always dependency

preserving
It is less stricter than BCNF It is more stricter than 3 NF

A 3 NF relation is not always BCNF A BCNF relation is always 3 NF

A dependency XY is allowed in 3 NF if A dependency XY is allowed in BCNF

either X is super key or Y is part of if X is super key
super key