Boyce Codd Normal Form

A table is in BCNF if every determinant is a candidate key. A table can be

in 3NF but not in BCNF. This occurs when a non key attribute is a determinant
of a key attribute. The dependency diagram may look like the one below

The table is in 3NF. A and B are the keys and C and D depend on both A and
B. There are no transitive dependencies existing between the non key
attributes, C and D.
The table is not in BCNF because a dependency exists between C and B. In
other words if we know the value of C we can determine the value of B.
We can also show the dependencies as
ABCD
CB

An example table from the University Database might be as follows:

If we know the Student Number and Teacher Code we know
theOffering (class) the student is in. We also know the review date for that
student and teacher (Student progress is reviewed for that class by the
teacher and student).
S_Num

T_Code

Offering#

Review Date

123599

FIT104

01764

2nd March

123599

PIT305

01765

12th April

123599

PIT107

01789

2nd May

346700

FIT104

01764

3rd March

346700

PIT305

01765

7th May

The dependencies are

S_Num, T_Code Offering#, Review Date
which means that the table is in third normal form. The table is not in BCNF as if we
know the offering number we know who the teacheris. Each offering can only have one
teacher!
Offering# T_Code

A non key attribute is a determinant.

If we look at the table we can see a combination of T_Code andOffering# is
repeated several times. eg FIT104 and 01764.
Converting to BCNF
The situation is resolved by following the steps below
1

The determinant, Offering#, becomes part of the key and the dependant
attribute T_Code, becomes a non key attribute. So the Dependency diagram is now
S_Num, Offering# T_Code, Review Date
There are problems with this structure as T_Code is now dependant on only part of the
key. This violates the rules for 2NF, so the table needs to be divided with the partial
dependency becoming a new table. The dependencies would then be
S_Num, Offering# T_Code, Review Date
Offering# T_Code
The original table is divided into two new tables. Each is in 3NF and in BCNF.
StudentReview
S_Num

Offering#

Review Date

123599

01764

2nd March

123599

01765

12th April

123599

01789

2nd May

346700

01764

3rd March

346700

01765

7th May

OfferingTeacher
Offering#

T_Code

01764

FIT104

01765

PIT305

01789

PIT107

A table is in fourth normal form (4NF) if and only if it is in BCNF and contains no more than
one multi-valued dependency.
1. Anomalies can occur in relations in BCNF if there is more than one multi-valued
dependency.
2. If A--->B and A--->C but B and C are unrelated, i.e., A---> (B, C) is false, and then we
have more than one multi-valued dependency.
3. A relation is in 4NF when it is in BCNF and has no more than one multi-valued
dependency.
Example to understand 4NF:Take the following table structure as an example:
info(employee#, skills, hobbies)

Take the following table:

employee#

skills

hobbies

Programming

Golf

Programming

Bowling

Analysis

Golf

Analysis

Bowling

Analysis

Golf

Analysis

Gardening

Management

Golf

Management

Gardening

This table is difficult to maintain since adding a new hobby requires multiple new rows
corresponding to each skill. This problem is created by the pair of multi-valued dependencies
EMPLOYEE#--->SKILLS and EMPLOYEE#--->HOBBIES. A much better alternative would be
to decompose INFO into two relations:
skills(employee#, skill)

employee#

skills

Programming

Analysis

Analysis

Management

hobbies(employee#, hobby)

Employee#

hobbies

Golf

Bowling

Golf

Gardening

A table is in fifth normal form (5NF) or Project-Join Normal Form (PJNF) if it is in 4NF and it
cannot have a lossless decomposition into any number of smaller tables.
Properties of 5NF:

Anomalies can occur in relations in 4NF if the primary key has three or more fields.

5NF is based on the concept of join dependence - if a relation cannot be decomposed any
further then it is in 5NF.

Pair wise cyclical dependency means that:

o You always need to know two values (pair wise).
o For any one you must know the other two (cyclical).

Example to understand 5NF

Take the following table structure as an example of a buying table. This is used to track buyers,
what they buy, and from whom they buy. Take the following sample data:

buyer
Sally
Mary
Sally
Mary
Sally

vendor
Liz Claiborne
Liz Claiborne
Jordach
Jordach
Jordach

item
Blouses
Blouses
Jeans
Jeans
Sneakers

Problem:- The problem with the above table structure is that if Claiborne starts to sell Jeans then
how many records must you create to record this fact?
The problem is there are pair wise cyclical dependencies in the primary key. That is, in order to
determine the item you must know the buyer and vendor, and to determine the vendor you must
know the buyer and the item, and finally to know the buyer you must know the vendor and the
item.

Solution:- The solution is to break this one table into three tables; Buyer-Vendor, Buyer-Item,
and Vendor-Item. So following tables are in the 5NF.

Buyer-Vendor

buyer

vendor

Sally

Liz Claiborne

Mary

Liz Claiborne

Sally

Jordach

Mary

Jordach

Buyer-Item

buyer

item

Sally

Blouses

Mary

Blouses

Sally

Jeans

Mary

Jeans

Sally

Sneakers

Vendor-Item
vendor

item

Liz Claiborne

Blouses

Jordach

Jeans

Jordach

Sneakers

Note:- There is also one more normal form i.e. 6 NF. A table is in sixth normal form (6NF) or
Domain-Key normal form (DKNF) if it is in 5NF and if all constraints and dependencies that
should hold on the relation can be enforced simply by enforcing the domain constraints and the
key constraints specified on the relation. The 6NF is more of a practical scenario and is out of
scope of this tutorial.