1. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-1 COS 346 Day 5

2. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-2 Agenda Questions? Assignment 1 Is Corrected –2 A’s, 3 B’s, 1 C and 1 D –Pay attention to details! Problems with reports and forms MultiTable Examples in Appendix A Assignment Two is posted –Marcia’s Dry Cleaning Project on page 97 & 98, question A through F –Due Feb 5 at 3:35 PM (next Class) Discussion on The Relational Model and Normalization –More in class work

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

4. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-4 Deletion Anomalies Deleting facts about one entity causes the deletion of facts about another entity

5. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-5 Insertion Anomalies We cannot store facts about entity until we have another entity of different type to store –Add scuba to following

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

7. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-7 Fixing Anomalies Split the relation

8. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-8 Normalization Normalization eliminates modification anomalies –Deletion anomaly: deletion of a row loses information about two or more entities –Insertion anomaly: insertion of a fact in one entity cannot be done until a fact about another entity is added Anomalies can be removed by splitting the relation into two or more relations; each with a different, single theme However, breaking up a relation may create referential integrity constraints Normalization works through classes of relations called normal forms

9. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-9 Relationship of Normal Forms

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

11. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-11 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.”

12. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-12 Normal Forms (Part 2) Any table of data is in 1NF if it meets the definition of a relation A relation is in 2NF if all its non-key attributes are dependent on all of the key (no partial dependencies) –If a relation has a single attribute key, it is automatically in 2NF A relation is in 3NF if it is in 2NF and has no transitive dependencies A relation is in BCNF if every determinant is a candidate key A relation is in fourth normal form if it is in BCNF and has no multi-value dependencies Fifth Normal form is too theoretical to bother with To be in Domain/Key Normal Form (DK/NF) every constraint on the relation must be a logical consequence of the definition of keys and domains.

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

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

15. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-15 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

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

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

18. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-18 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

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

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

21. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-21 Multivalued Dependencies

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

23. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-23 Fixing 4thNF (Generally Speaking) A relation R(A,B,C) –A->->B –A->->C –B and C are independent Create R(A,B) andR1(A,C)

24. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-24 Fifth Normal Form (5NF) The Fifth Normal Form concerns dependencies that are obscure and beyond the scope of this text. Punt!

25. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-25 Domain/Key Normal Form (DK/NF) To be in Domain/Key Normal Form (DK/NF) every constraint on the relation must be a logical consequence of the definition of keys and domains. Ultimate Normal Form –1981 Fagin NO possible anomalies

26. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-26 DK/NF Terminology Constraint –A rule governing static values of attributes Key –A unique identifier of a tuple Domain –A description of an attribute’s allowable values

27. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-27 De-normalized Designs When a normalized design is unnatural, awkward, or results in unacceptable performance, a de-normalized design is preferred Example –Normalized relation CUSTOMER (CustNumber, CustName, Zip) CODES (Zip, City, State) –De-Normalized relations CUSTOMER (CustNumber, CustName, City, State, Zip)

28. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 3-28 David M. Kroenke’s Database Processing Fundamentals, Design, and Implementation (10 th Edition) End of Presentation: Chapter Three