Boyce-Codd Normal Form (BCNF)
The Boyce-Codd normal form is a step up from the 3NF,
but not as restrictive as the 4NF.
Boyce-Codd tells us:
If attribute Y is functionally dependent on attribute
X, then attribute X must be the primary key.
 Most of the time, if a table is in 3NF, it is in BCNF.
 When a table contains only 1 candidate key, then the
BCNF is the same as 3NF.
Example of 3NF but not BCNF
Consider this table from a bank’s loan database:
Branch_Number
Customer_ID
(PK)
Loan_ID (PK)
Loan_Amount
1
100512
3141
150000
1
122099
3444
25000
2
099344
6501
30000
Since one loan could have multiple customers, our primary key would have to be
Loan ID + Customer ID. Doing that would give us data duplication of the Branch
Number and the Loan Amount. Loan ID also determines the Loan Amount, but it
isn’t a primary key itself, so this table is not in BCNF.
Loan tables in BCNF
To satisfy BCNF we decompose into two tables:
Branch _Number Loan_ID (PK)
Loan_Amount
1
3141
150000
1
3444
25000
2
6501
30000
and
Customer_ID (PK)
Loan_ID (PK)
100512
3141
122099
3444
099344
6501
Fourth Normal Form (4NF)
 In order for a table to be in 4NF, it must first be in 3NF
and it must not have more than one multivalued
dependency. That is, if one value of attribute X will
determine multiple values of attribute Y, then there
can be no other attribute that has multiple values
given that same X value.
Example of 3NF but not 4NF
Consider this table from a Ford dealership:
Car_Model (PK)
Engine_Type
(PK)
Color (PK)
Mustang
3.7L V6
Red
Mustang
3.7L V6
Blue
Mustang
5.0L V8
Red
Taurus
3.5L V6
Green
Taurus
2.0L Eco
Green
You can see that Mustang comes up with multiple values for both Engine
and Color. These multivalued dependencies keep the table from being in
4NF.
Car tables in 4NF
Car_Model (PK)
Engine_Type (PK)
Mustang
3.7L V6
Mustang
5.0L V8
Taurus
3.5L V6
Taurus
2.0L Eco
Car_Model (PK)
Color (PK)
Mustang
Red
Mustang
Blue
Taurus
Green
Here, one Model may come up with more than one Engine
or Color but the data redundancy is minimized by creating
two tables.
Fifth Normal Form (5NF)
 In order for a table to be in 5NF it must first be in 4NF
and one of these two conditions must apply:
It cannot be broken down into smaller tables
- or It can be broken down, but all resulting tables
would use the same key.
This is the most complete way to remove data
redundancy, but it results in more complex databases
due to the high number of tables.
Example of 4NF but not 5NF
Here is a table about buyers who purchase products from
manufacturers to stock in an electronics store:
Buyer
Manufacturer
Product
Steve
LG
Plasma TVs
Steve
LG
BluRay Players
Steve
Sony
LCD TVs
Denise
LG
BluRay Players
Denise
Sony
LCD TVs
Denise
Sony
3D TVs
If the store decided to start getting LCD TV’s from LG, then you would have
to add two rows that have two out of three values identical.
Electronics Tables in 5NF
Buyer
Manufacturer
Manufacturer
Product
Steve
LG
LG
Plasma TVs
Steve
Sony
LG
BluRay Players
Denise
LG
Sony
LCD TVs
Denise
Sony
Sony
3D TVs
Buyer
Product
Steve
Plasma TVs
Steve
BluRay Players
Steve
LCD TVs
Denise
BluRay Players
Denise
LCD TVs
Denise
3D TVs
Now the addition of LCD TVs from LG means one new row in one table.
Sixth Normal Form (6NF)
 A table is in 6NF only if it is already in 5NF and every
join dependency on that table is trivial.
If a table “T” can be broken down into smaller tables and then
recreated when needed by using table joins, that is a join dependency
on T. A trivial join dependency occurs when you can only recreate “T”
by using table “T” itself.
Example of 5NF but not 6NF
Here is a table listing one teacher’s class:
Student_Nu
m
First_Name
Last_Name
Grade
100
Homer
Simpson
F
101
Stan
Smith
A
102
Lois
Griffin
A
103
Cleveland
Brown
C
This table could be broken down into smaller tables and, if
needed, recreated using joins.
Student tables in 6NF
Student_Num
First_Name
Student_Num
Last_Name
100
Homer
100
Simpson
101
Stan
101
Smith
102
Lois
102
Griffin
103
Cleveland
103
Brown
Student_Num
Grade
100
F
101
A
102
A
103
C
These tables are in 6NF, but you can see that they are not really practical.
 As you progress from BCNF up to 6NF the restrictions
on tables get more and more. The simplicity gained
from normalizing the tables may not be worth the
added complexity of the database and queries. In
most cases, normalizing to the 3NF will be adequate.