Normalization. VI. Normalization of Database Tables. Need for Normalization. Normalization Process. Review of Functional Dependence Concepts

Size: px

Start display at page:

Download "Normalization. VI. Normalization of Database Tables. Need for Normalization. Normalization Process. Review of Functional Dependence Concepts"

Olivia Fields
6 years ago
Views:

1 VI. Normalization of Database Tables Normalization Evaluating and correcting relational schema designs to minimize data redundancies Reduces data anomalies Assigns attributes to tables based on functional dependencies Normal forms First normal form (1NF) Second normal form (2NF) Third normal form (3NF) Need for Normalization Used while designing a new database structure Analyzes the relationships among the attributes within each entity Determines if the structure can be improved Improves the existing data structure and creates an appropriate database design Normalization Process Objective is to ensure that each table conforms to the concept of well-formed relations Each table represents a single subject No data item will be unnecessarily stored in more than one table All attributes in a relation are dependent on the primary key Each table is void of insertion, update, and deletion anomalies Normalization Process Review of Functional Dependence Concepts Ensures that all tables are in at least 3NF There are higher normal forms, not likely to be encountered in a business environment Works one relation at a time Starts by: Identifying the dependencies of a relation (table) Progressively breaking the relation into new set of relations Concept Functional dependence Functional dependence (Generalized definition) Fully functional dependence (composite key) Definition The attribute B is fully functionally dependent on the attribute A if each value of A determines one and only one value of B. Attribute A determines attribute B if all of the rows in the table that agree in value for attribute A also agree in value for attribute B. If attribute B is functionally dependent on a composite key A but not on any Subset of that composite key, the attribute B is fully functionally dependent on A. 1

Types of Functional Dependencies Partial dependency: Functional dependence in which the determinant is only part of the primary key Assumption - One candidate key Straight forward Easy to identify

2 Types of Functional Dependencies Partial dependency: Functional dependence in which the determinant is only part of the primary key Assumption - One candidate key Straight forward Easy to identify Transitive dependency: An attribute functionally depends on another nonkey attribute Conversion to First Normal Form Repeating group: Group of multiple entries of same type can exist for any single key attribute occurrence Existence proves the presence of data redundancies Enable reducing data redundancies Steps Eliminate the repeating groups Identify the primary key Identify all dependencies Conversion to First Normal Form Dependency diagram: Depicts all dependencies found within given table structure Helps to get an overview of all relationships among table s attributes Makes it less likely that an important dependency will be overlooked Conversion to First Normal Form 1NF describes tabular format in which: All key attributes are defined There are no repeating groups in the table All attributes are dependent on the primary key All relational tables satisfy 1NF requirements Some tables contain partial dependencies Subject to data redundancies and various anomalies First Normal Form (1NF) Dependency Diagram Conversion to Second Normal Form Steps Make new tables to eliminate partial dependencies Reassign corresponding dependent attributes Table is in 2NF when it: Is in 1NF Includes no partial dependencies 2

Second Normal Form (2NF) Conversion Results Conversion to Third Normal Form Steps Make

determines other values within a row Reassign corresponding dependent attributes Table

(3NF) Conversion Results Requirements for Good Normalized Set of Tables Evaluate PK

be further subdivided Atomicity: Characteristic of an atomic attribute Identify new

Granularity: Level of detail represented by the values stored in a table s row Maintain

3 Second Normal Form (2NF) Conversion Results Conversion to Third Normal Form Steps Make new tables to eliminate transitive dependencies Determinant: Any attribute whose value determines other values within a row Reassign corresponding dependent attributes Table is in 3NF when it: Is in 2NF Contains no transitive dependencies Third Normal Form (3NF) Conversion Results Requirements for Good Normalized Set of Tables Evaluate PK assignments and naming conventions Refine attribute atomicity Atomic attribute: Cannot be further subdivided Atomicity: Characteristic of an atomic attribute Identify new attributes and new relationships Refine primary keys as required for data granularity Granularity: Level of detail represented by the values stored in a table s row Maintain historical accuracy and evaluate using derived attributes The Completed Database The Completed Database 3

The Completed Database The Completed Database General Hardware Company: Unnormalized Data General Hardware Company: First Normal Form Year Depa rt-ment Commission of Manage r Unit Percentage Hire

99 1962 24013 Saw 26.25 3071 204 21765 Dicken s 10 1998 73 Scott Drill 32.99 809 26722 Pliers 11.50 734 361 16386 Carlyle 20 2001 73 Scott Wrench 12.95 3729 21765 Drill 32.99 3110 26722 Pliers 11.

50 473 137 24013 Baker 10 1995 73 Scott Saw 26.25 170 137 26722 Baker 10 1995 73 Scott Pliers 11.50 688 186 16386 Adams 15 2001 59 Lop ez Wrench 12.95 1745 186 19440 Adams 15 2001 59 Lop ez Hammer 17.

4 The Completed Database The Completed Database General Hardware Company: Unnormalized Data General Hardware Company: First Normal Form Year Depa rt-ment Commission of Manage r Unit Percentage Hire Price Quan tity Baker Scott Hammer Saw Pliers Adams Lopez Wrench Hammer Drill Saw Dicken s Scott Drill Pliers Carlyle Scott Wrench Drill Pliers SALESPERSON/PRODUCT Table Records contain multivalued attributes. Year Depart-ment Commission of Manager Unit Percentage Hire Price Quantity Baker Scott Hammer Baker Scott Saw Baker Scott Pliers Adams Lop ez Wrench Adams Lop ez Hammer Adams Lop ez Drill Adams Lop ez Saw Dickens Scott Drill Dickens Scott Pliers Carlyle Scott Wrench Carlyle Scott Drill Carlyle Scott Pliers SALESPERSON/PRODUCT Table Attributes and Dependencies Salesperson Commission Percentag e Year of Hire Department Manager Unit Price Quantity Salesperson Commission Percentage Year of Hire Department Manager Unit Price Department Manager, Quantity, all other attributes indicates a candidate key (if left side is minimal) 23 General Hardware Company: Second Normal Form Salesperson Quantity QUANTITY Table Salesperson Salesperson Commission Percentage Unit Price Wrench Hammer Drill Saw Pliers PRODUCT Table Year of Hire Department Manager 137 Baker Scott 186 Adams Lopez 204 Dickens Scott 361 Carlyle Scott SALESPERSON Table 24 4

5 General Hardware Company: Third Normal Form Third Normal Form Salesperson Salesperson Commission Year of Department Percentage Hire 137 Baker Adams Dickens Carlyle SALESPERSON Table Unit Price Wrench Hammer Drill Saw Pliers PRODUCT Table Department Manager 59 Lopez 73 Scott DEPARTMENT Table Salesperson Quantity QUANTITY Table 25 There is one exception to the rule that in third normal form, nonkey attributes are not allowed to define other nonkey attributes. The rule does not hold if the defining nonkey attribute is a candidate key of the table. Candidate keys in a relation may define other nonkey attributes without violating third normal form. 26 Third Normal Form Important points about the third normal form structure are: It is completely free of data redundancy. All foreign keys appear where needed to logically tie together related tables. It is the same structure that would have been derived from a properly drawn entity-relationship diagram of the same business environment. 27 Functional Dependencies Source Designer determines obvious dependencies Generate full set mathematically Use inference rules to generate the closure set Benefits Make 2NF and 3NF analysis more precise Formal method of determining keys 28 Functional Dependencies Armstrong s Axioms (inference rules) Reflexive If X includes Y, then X Y Augmentation If X Y, then XZ YZ Transitive If X Y and Y Z, then X Z Functional Dependencies Additional rules Decomposition If X YZ then X Y Union If X Y and X Z then X YZ Pseudotransitive If X Y and WY Z then WX Z

6 PurchaseInfo: (purchaseorderid, supplierid, supplier, street, city, state, zipcode, movieid, title, quantity, dateordered) Initial functional dependencies: FD1: purchaseorderid supplierid, dateordered FD2: supplierid supplier FD3: supplierid street, zipcode FD4: zipcode city, state FD5: street, city, state zipcode FD6: movieid title FD7: movieid, dateordered quantity Derived dependencies FD8: purchaseorderid, supplierid, street supplierid, street (reflexivity) FD9: zipcode, dateordered city, state, dateordered (augmentation) FD10: purchaseorderid supplier (transitivity) FD11: zipcode state (decomposition) FD12: supplierid supplier, street, zipcode (union) More derived dependencies FD13: supplierid supplier, street, city, state, zipcode (union and transitivity) FD14: purchaseorderid supplierid, dateordered, supplier, street, city, state, zipcode (union and transitivity) FD15: movieid, dateordered title, quantity (augmentation, union and decomposition) FD16: purchaseorderid, movieid supplierid, supplier, street, city, state, zipcode, title, quantity, dateordered (pseudo-transitivity) Schemas in 3NF PurchaseOrder: (purchaseorderid, supplierid, dateordered) PurchaseOrderDetail: (purchaseorderid, movieid, quantity) Movie: (movieid, title) Supplier: (supplierid, supplier, street, zipcode) Zipcode: (zipcode, city, state) Note: Elimination of redundancy Representation of functional dependencies as key dependencies that can be enforced by the DBMS Data Normalization Check The basic idea in checking the structural worthiness of relational tables, created through ER diagram conversion, with the data normalization rules is to: Check to see if there are any partial functional dependencies. Check to see if there are any transitive dependencies

7 Normalization and Database Design Normalization should be part of the design process After ER modeling and conversion to relational schemas Proposed relations must be in normal form before table structures are created Denormalization Design goals Creation of normalized relations Processing requirements and speed of database tables expands when tables are decomposed to conform to normalization requirements Joining a larger number of tables: Takes additional input/output (I/O) operations and processing logic Reduces system speed Denormalization Defects in unnormalized tables Data updates are less efficient because tables are larger Indexing is more cumbersome No simple strategies for creating virtual tables known as views 7

Database Systems: Design, Implementation, and Management Tenth Edition. Chapter 6 Normalization of Database Tables

Database Systems: Design, Implementation, and Management Tenth Edition Chapter 6 Normalization of Database Tables Objectives In this chapter, students will learn: What normalization is and what role it