Normalization.ppt
- 2. 2 Study Objectives • Understand what normalization is and what role it plays in database design • Learn about the normal forms 1NF, 2NF, 3NF, BCNF, and 4NF • Identify how normal forms can be transformed from lower normal forms to higher normal forms • Understand normalization and E-R modeling are used concurrently to produce a good database design • Understand some situations require denormalization to generate information efficiently
- 3. 3 Why Normalization? • To produce well-structured relations – Any relational database should contain minimal data redundancy and allows users to insert, delete, and update rows without causing data inconsistencies (anomalies). – Goal of Normalization: producing well-structured relations by eliminating anomalies
- 4. 4 Type of Anomalies • Update (Modification) Anomaly – Changing data in a row forces changes to other rows because of duplication • Deletion Anomaly – Deleting rows may cause a loss of data that would be needed for other future rows • Insertion Anomaly – Adding new rows forces user to create duplicate data
- 5. 5 Each Anomaly Examples Consider the following table that stores data about auto parts and suppliers. This seemingly harmless table contains potential problems. Part# Description Supplier Address City State 100 Coil Dynar 45 Eastern Ave. Denver CO 101 Muffler GlassCo 1638 S. Front Seattle WA 102 Wheel Cover A1 Auto 7441 E. 4th Street Detroit MI 103 Battery Dynar 45 Eastern Ave. Denver CO 104 Radiator United Parts 346 Taylor Drive Austin TX 105 Manifold GlassCo 1638 S. Front Seattle WA 106 Converter GlassCo 1638 S. Front Seattle WA Suppose, we need to add another part. 107 Tail Pipe GlassCo 1638 S. Front Seattle WA
- 6. 6 Update Anomaly What if GlassCo moves to Olympia? How many rows have to be changed in order to ensure that the new address is recorded – Address and City Part# Description Supplier Address City State 100 Coil Dynar 45 Eastern Ave. Denver CO 101 Muffler GlassCo 1638 S. Front Seattle WA 102 Wheel Cover A1 Auto 7441 E. 4th Street Detroit MI 103 Battery Dynar 45 Estern Ave. Denver CO 104 Radiator United Parts 346 Taylor Drive Austin TX 105 Manifold GlassCo 1638 S. Front Seattle WA 106 Converter GlassCo 1638 S. Front Seattle WA 107 Tail Pipe GlassCo 1638 S. Front Seattle WA
- 7. 7 Deletion Anomaly Suppose you no longer carries part number 102 and decide to delete that row from the table? Part# Description Supplier Address City State 100 Coil Dynar 45 Eastern Ave. Denver CO 101 Muffler GlassCo 1638 S. Front Seattle WA 102 Wheel Cover A1 Auto 7441 E. 4th Street Detroit MI 103 Battery Dynar 45 Estern Ave. Denver CO 104 Radiator United Parts 346 Taylor Drive Austin TX 105 Manifold GlassCo 1638 S. Front Seattle WA 106 Converter GlassCo 1638 S. Front Seattle WA 107 Tail Pipe GlassCo 1638 S. Front Seattle WA
- 8. 8 Now, looking at the remaining data below, what is the address of A1 Auto? - supplier (A1 Auto) address must be deleted as well Part# Description Supplier Address City State 100 Coil Dynar 45 Eastern Ave. Denver CO 101 Muffler GlassCo 1638 S. Front Seattle WA 103 Battery Dynar 45 Estern Ave. Denver CO 104 Radiator United Parts 346 Taylor Drive Austin TX 105 Manifold GlassCo 1638 S. Front Seattle WA 106 Converter GlassCo 1638 S. Front Seattle WA 107 Tail Pipe GlassCo 1638 S. Front Seattle WA
- 9. 9 Insertion Anomaly Next, you want to add a new supplier – “CarParts.” But you have not yet ordered parts from that supplier – No PK and description Part# Description Supplier Address City State 100 Coil Dynar 45 Eastern Ave. Denver CO 101 Muffler GlassCo 1638 S. Front Seattle WA 103 Battery Dynar 45 Estern Ave. Denver CO 104 Radiator United Parts 346 Taylor Drive Austin TX 105 Manifold GlassCo 1638 S. Front Seattle WA 106 Converter GlassCo 1638 S. Front Seattle WA 107 Tail Pipe GlassCo 1638 S. Front Seattle WA ??? ???????? CarParts 101 Mariposa Orlando FL
- 10. 10 Utilizing Functional Dependency Theory • As a solution for taking care of Anomalies • Normalization is based on functional dependencies. • Functional Dependency: The value of one attribute determines the value of another attribute • Notation: (arrow) • A B when value of A (of a valid instance) defines the value of B (B is functionally dependent upon A). – SSN defines Name, Address (not vice versa) • A is the determinant in a functional dependency
- 11. 11 Example of Functional Dependency • SSN -> Name, Birth-date, Address – VIN -> Make, Model, Color – ISBN -> Title, Author • Not acceptable dependencies – Partial dependency – Transitive dependency – Hidden dependency
- 12. 12 First Normal Form (1NF) • To be in First Normal Form (1NF), – Each column must contain only a single value – Repeating groups of records (redundancy) must be eliminated • Eliminate duplicative columns from the same table. – There must not be a composite and a multi-valued attributes. • Transformation from model to relation
- 14. 14 1NF Example (con’t.) Conversion to 1NF PK
- 15. 15 Another 1NF Example Cust_ID L_Name F_Name Address 104 Suchecki Ray 123 Pond Hill Road, Detroit, MI, 48161 Cust_ID SalesRep_Name Rep_Office Order_1 Order_2 Order_3 1022 Jones 412 10 14 19 PK PK
- 16. 16 Second Normal Form • In order to be in 2NF, a relation must be in 1NF and a relation must not have any partial dependencies. – Any attributes must not be dependent on a portion of primary key. • The other way to understand 2NF is that each non-key attribute (not a part of PK) in the relation must be functionally dependent upon the primary key.
- 17. 17 2NF Example PK PK OrderNum, PartNum NumOrdered, QuotedPrice OrderNum OrderDate / PartNum Description Each arrow shows partial dependency
- 18. 18 2NF Example PK PK PK PK
- 19. 19 Third Normal Form • In order to be in Third Normal Form, a relation must first fulfill the requirements to be in 2NF. • Additionally, all attributes that are not dependent upon the primary key must be eliminated. In other words, there should be no transitive dependencies. – remove columns that are not dependent upon the primary key.
- 20. 20 Example of 3NF PK: Cust_ID
- 21. 21 Transitive dependency • All attributes are functionally dependent on Cust_ID. – Cust_ID Name, Salesperson • However, there is a transitive dependency. – Region is functionally dependent on Salesperson but Salesperson is not a “Determinants.” – Salesperson Region
- 22. 22 • What kind of anomaly will happen if the company needs to add a new salesperson (John Doe) to the North region right away? • What kind of anomaly will happen tomorrow if the company deletes the customer number 6837 from the table today? • What kind of anomaly will happen if Smith (salesperson) must be reassigned to the East region right away?
- 23. 23 Decomposing the SALES relation PK PK FK
- 24. 24 Relations in 3NF Now, there are no transitive dependencies… Both relations are in 3rd NF CustID Name and CustID Salesperson Salesperson Region
- 25. Stop Here! • Very interesting logic. • If you are interested in learning this topic, please let me know. • We will explore together in detail! 25
- 26. 26 Boyce-Codd Normal Form (BCNF) • Special case of 3NF. • A relation is in BCNF if it’s in 3NF and there is no hidden dependencies. • Below is in 3NF but not in BCNF
- 27. 27 BCNF Stu_ID Advisor Major GPA 123 Nasa Physics 4.0 123 Elvis Music 3.3 456 King Literature 3.2 789 Jackson Music 3.7 678 Nasa Physics 3.5 Student Advisor (part of determinant) is functionally dependent on Major. Don’t confuse with Transitive Dependency!
- 28. 28 Stu_ID Advisor Major GPA 123 Nasa Physics 4.0 123 Elvis Music 3.3 456 King Literature 3.2 789 Jackson Music 3.7 678 Nasa Physics 3.5 • What kind of anomaly will happen if the advisor “Nasa” in physics is replaced by “Einstein”? • What kind of anomaly will happen if MIS professor John Doe must be assigned to the new major (MIS)? • What kind of anomaly will happen if the student number 789 withdraw from school so that it must be deleted from the table?
- 29. 29 BCNF Advisor is functionally dependent on Major. • Stu_ID, Advisor major, GPA • Major Advisor Don’t confuse with Transitive Dependency!
- 30. 30 Conversion to BCNF Stu_ID Advisor GPA 123 Nasa 4.0 123 Elvis 3.3 456 King 3.2 789 Jackson 3.7 678 Nasa 3.5 Advisor Major Nasa Physics Elvis Music King Literature Jackson Music Student Advisor FK
- 31. 31 3NF and BCNF • In practice, most relation schemas that are in 3NF are also in BCNF (if there is no hidden dependency) • In general, it is best to have relation schemas in BCNF. If that is not possible, 3NF will do. However, 2NF and 1NF are not considered good relation schema designs.
- 32. 32 Normalization and Database Design • Normalization should be part of the design process – Un-normalized: • Data updates less efficient • Indexing more cumbersome • E-R Diagram provides macro view • Normalization provides micro view of entities – Focuses on characteristics of specific entities – May yield additional entities • Generally, most database designers do not attempt to implement anything higher than Third Normal Form or Boyce-Codd Normal Form.