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.