1. Database Normalization beyond 3NF Using BCNF, 4NF, 5NF, and 6NF

2. 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.

3. 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.

4. 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
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.

5. Loan tables in BCNF To satisfy BCNF we decompose into two tables:
Branch _Number
Loan_ID (PK)
Loan_Amount 1
3141
150000
3444
25000 2
6501
30000
and
Customer_ID (PK)
Loan_ID (PK)
100512
3141
122099
3444
099344
6501

6. 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.

7. 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
Blue
5.0L V8
Taurus
3.5L V6
Green
2.0L Eco
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.

8. Car tables in 4NF Car_Model (PK) Engine_Type (PK) Mustang 3.7L V6
Taurus
3.5L V6
2.0L Eco
Car_Model (PK)
Color (PK)
Mustang
Red
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.

9. Fifth Normal Form (5NF) - or -
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.

10. 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
BluRay Players
Sony
LCD TVs
Denise
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.

11. Electronics Tables in 5NF
Buyer
Manufacturer
Steve LG
Sony
Denise
Manufacturer
Product LG
Plasma TVs
BluRay Players
Sony
LCD TVs
3D TVs
Buyer
Product
Steve
Plasma TVs
BluRay Players
LCD TVs
Denise
3D TVs
Now the addition of LCD TVs from LG means one new row in one table.

12. 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.

13. Example of 5NF but not 6NF
Here is a table listing one teacher’s class:
Student_Num
First_Name
Last_Name
Grade
100
Homer
Simpson F
101
Stan
Smith A
102
Lois
Griffin
103
Cleveland
Brown C
This table could be broken down into smaller tables and, if needed, recreated using joins.

14. Student tables in 6NF Student_Num First_Name 100 Homer 101 Stan 102
Lois
103
Cleveland
Student_Num
Last_Name
100
Simpson
101
Smith
102
Griffin
103
Brown
Student_Num
Grade
100 F
101 A
102
103 C
These tables are in 6NF, but you can see that they are not really practical.

15. 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.