Normalization Example 1

Consider the SKU_DATA table: SKU_DATA (SKU, SKU_Description, Department, Buyer) As discussed earlier, this table has three functional dependencies:

SKU : (SKU_Description, Department, Buyer) SKU_Description : (SKU, Department, Buyer) Buyer : Department

Normalization Example 1: The “Step-by-Step” Method Both SKU and SKU_Descripion are candidate keys. Logically, SKU makes more sense as the primary key because it is a surrogate key, so our relation, which is shown in Figure 3-20, is:

SKU_DATA (SKU, SKU_Description, Department, Buyer)

Checking the relation against Figure 3-4, we find that SKU_DATA is in 1NF. Is the SKU_DATA relation in 2NF? A relation is 2NF if and only if it is in 1NF and all non-

key attributes are determined by the entire primary key . Because the primary key SKU is a sin- gle attribute key, all the non-key attributes are therefore dependent on the entire primary key. Thus, the SKU_DATA relation is in 2NF.

Figure 3-20

SKU_DATA

The SKU_DATA Relation

Part 2 Database Design

Is the SKU_DATA relation in 3NF? A relation is in 3NF if and only if it is in 2NF and there are no non-key attributes determined by another non-key attribute . Because we seem to have two non-key attributes (SKU_Description and Buyer) that determine non-key attributes, the relation is not in 3NF!

However, this is where things get a bit tricky. A non-key attribute is an attribute that is neither (1) a candidate key itself , nor (2) part of a composite candidate key. SKU_Description, therefore, is not a non-key attribute (sorry about the double negative). The only non-key attribute is Buyer!

Therefore, we must remove only the functional dependency Buyer : Department We will now have two relations: SKU_DATA_2 (SKU, SKU_Description, Buyer)

BUYER (Buyer, Department)

Is SKU_DATA_2 in 3NF? Yes, it is—there are no non-key attributes that determine another non-key attribute.

Is the SKU_DATA relation in BNCF? A relation is in BCNF if and only if it is in 3NF and every determinant is a candidate key . The determinants in SKU_DATA_2 are SKU and SKU_Description:

SKU : (SKU_Description, Buyer) SKU_Description : (SKU, Buyer)

Both determinants are candidate keys (they both determine all the other attributes in the relation). Thus, every determinant is a candidate key, and the relationship is in BNCF. At this point, we need to check the BUYER relation to determine if it is in BNCF. Work through the steps yourself for BUYER to check your understanding of the “Step-by-Step” method. You will find that BUYER is in BNCF, and therefore our normalized relations, as shown with the sample data in Figure 3-21, are:

SKU_DATA_2 (SKU, SKU_Description, Buyer) BUYER (Buyer, Department)

Both of these tables are now in BCNF and will have no anomalies due to functional dependencies. For the data in these tables to be consistent, however, we also need to define a referential integrity constraint (note that this is step 3D in Figure 3-17):

SKU_DATA_2.Buyer must exist in BUYER.Buyer

Figure 3-21

SKU_DATA_2

The Normalized BUYER and SKU_DATA_2 Relations

BUYER

Chapter 3 The Relational Model and Normalization

This statement means that every value in the Buyer column of SKU_DATA_2 must also exist as a value in the Buyer column of BUYER.

Normalization Example 1: The “Straight-to-BNCF” Method Now let’s rework this example using the “Straight-to-BNCF” method. SKU and SKU_Description determine all of the columns in the table, so they are candidate keys. Buyer is a determinant, but it does not determine all of the other columns, and hence it is not a candidate key. Therefore, SKU_DATA has a determinant that is not a candidate key and is therefore not in BCNF. It will have modification anomalies.

To remove such anomalies, in step 3A in Figure 3-17 we move the columns of functional dependency whose determinant is not a candidate key into a new table. In this case, we place Buyer and Department into a new table:

BUYER (Buyer, Department) Next, in step 3B in Figure 3-17, we make the determinant of the functional dependency the

primary key of the new table. In this case, Buyer becomes the primary key: BUYER (Buyer, Department) Next, following step 3C in Figure 3-17, we leave a copy of the determinant as a foreign key in

the original relation. Thus, SKU_DATA becomes SKU_DATA_2: SKU_DATA_2 (SKU, SKU_Description, Buyer) The resulting tables are thus: SKU_DATA_2 (SKU, SKU_Description, Buyer)

BUYER (Buyer, Department) where SKU_DATA_2.Buyer is a foreign key to the BUYER table.

Both of these tables are now in BCNF and will have no anomalies due to functional dependencies. For the data in these tables to be consistent, however, we also need to define the referential integrity constraint in step 3D in Figure 3-17:

SKU_DATA_2.Buyer must exist in BUYER.Buyer This statement means that every value in the Buyer column of SKU_DATA_2 must also exist

as a value in the Buyer column of BUYER. Sample data for the resulting tables is the same as shown in Figure 3-21.

Note that both the “Step-by-Step” method and the “Straight-to-BCNF” method produced exactly the same results. Use the method you prefer, the results will be the same. To keep this chapter reasonably short, we will use only the “Straight-to-BNCF” method for the rest of the normalization examples.

Normalization Example 1