1. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-1 Functional Dependencies and Normalization

2. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-2 Functional Dependency A functional dependency occurs when the value of one (a set of) attribute(s) determines the value of a second (set of) attribute(s): StudentID  StudentName StudentID  (DormName, DormRoom, Fee) The attribute on the left side of the functional dependency is called the determinant Functional dependencies may be based on equations: ExtendedPrice = Quantity X UnitPrice (Quantity, UnitPrice)  ExtendedPrice Function dependencies are not equations!

3. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-3 Functional Dependencies Are Not Equations ObjectColor  Weight ObjectColor  Shape ObjectColor  (Weight, Shape)

4. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-4 Composite Determinants Composite determinant: A determinant of a functional dependency that consists of more than one attribute (StudentName, ClassName)  (Grade)

5. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-5 Functional Dependency Rules If A  (B, C), then A  B and A  C If (A,B)  C, then neither A nor B determines C by itself

6. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-6 Functional Dependencies in the SKU_DATA Table SKU  (SKU_Description, Department, Buyer) SKU_Description  (SKU, Department, Buyer) Buyer  Department

7. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-7 Functional Dependencies in the ORDER_ITEM Table (OrderNumber, SKU)  (Quantity, Price, ExtendedPrice) (Quantity, Price)  (ExtendedPrice)

8. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-8 What Makes Determinant Values Unique? A determinant is unique in a relation if, and only if, it determines every other column in the relation You cannot find the determinants of all functional dependencies simply by looking for unique values in one column: –Data set limitations –Must be logically a determinant

9. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-9 Keys A key is a combination of one or more columns that is used to identify rows in a relation A composite key is a key that consists of two or more columns

10. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-10 Candidate and Primary Keys A candidate key is a key that determines all of the other columns in a relation A primary key is a candidate key selected as the primary means of identifying rows in a relation: –There is one and only one primary key per relation –The primary key may be a composite key –The ideal primary key is short, numeric and never changes

11. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-11 Modification Anomalies Deletion Anomaly Insertion Anomaly Update Anomaly

12. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-12 Modification Anomalies The EQUIPMENT_REPAIR table before and after an incorrect update operation on AcquisitionCost for Type = Drill Press:

13. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-13 Normal Forms Relations are categorized as a normal form based on which modification anomalies or other problems that they are subject to:

14. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-14 Normal Forms 1NF – A table that qualifies as a relation is in 1NF 2NF – A relation is in 2NF if all of its nonkey attributes are dependent on all of the primary key 3NF – A relation is in 3NF if it is in 2NF and has no determinants except the primary key Boyce-Codd Normal Form (BCNF) – A relation is in BCNF if every determinant is a candidate key “I swear to construct my tables so that all nonkey columns are dependent on the key, the whole key and nothing but the key, so help me Codd.”

15. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-15 Eliminating Modification Anomalies from Functional Dependencies in Relations Put all relations into Boyce-Codd Normal Form (BCNF):

16. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-16 BCNF algorithm 1.Identify the functional dependencies f in table 2.Identify candidate keys in table 3.Find a determinate d in f which is not a candidate key for the table 1.Move all columns of that functional dependency to a new table, with d serving as the new table's key. 2.Leave a copy of d in the original table to act as a foreign key. 4.Repeat until there no longer exists a functional dependency in the original table whose determinant is not a candidate key.

17. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-17 Putting a Relation into BCNF: EQUIPMENT_REPAIR

18. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-18 Putting a Relation into BCNF: EQUIPMENT_REPAIR EQUIPMENT_REPAIR (ItemNumber, Type, AcquisitionCost, RepairNumber, RepairDate, RepairAmount) ItemNumber  (Type, AcquisitionCost) RepairNumber  (ItemNumber, Type, AcquisitionCost, RepairDate, RepairAmount) ITEM (ItemNumber, Type, AcquisitionCost) REPAIR (ItemNumber, RepairNumber, RepairDate, RepairAmount) Where REPAIR.ItemNumber must exist in ITEM.ItemNumber

19. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-19 Putting a Relation into BCNF: New Relations

20. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-20 Putting a Relation into BCNF: SKU_DATA

21. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-21 Putting a Relation into BCNF: SKU_DATA SKU_DATA (SKU, SKU_Description, Department, Buyer) SKU  (SKU_Description, Department, Buyer) SKU_Description  (SKU, Department, Buyer) Buyer  Department SKU_DATA (SKU, SKU_Description, Buyer) BUYER (Buyer, Department) Where BUYER.Buyer must exist in SKU_DATA.Buyer

22. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-22 Putting a Relation into BCNF: New Relations

23. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-23 Another BCNF algorithm example Item_ID | Description | Price | Date | Customer_Name | Addr | City | St | ZIP | Phone Functional dependencies? Candidate keys? Resulting tables in BCNF? Original naive design for table recording an item sale to a customer:

24. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-24 Multivaled Dependencies A multivaled dependency occurs when a determinant determines a particular set of values: Employee  Degree Employee  Sibling PartKit  Part The determinant of a multivaled dependency can never be a primary key

25. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-25 Multivaled Dependencies

26. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-26 Eliminating Anomolies from Multivaled Dependencies Multivalued dependencies are not a problem if they are in a separate relation, so: –Always put multivaled dependencies into their own relation –This is known as Fourth Normal Form (4NF)

27. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-27 Normalization: Advantages and Disadvantages

28. adapted from DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-28 Choosing Not to Use BCNF BCNF is used to control anomalies from functional dependencies There are times when BCNF is not desirable The classic example is ZIP codes. ZIP  (City, State), but does that mean that there should always be a ZIP table? –ZIP codes almost never change –Any anomalies are likely to be caught by normal business practices –Not having to use SQL to join data in two tables will speed up application processing