Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright © 2016 Pearson Education, Inc. Modern Database Management 12 th Edition Jeff Hoffer, Ramesh Venkataraman, Heikki Topi CHAPTER 4: PART C LOGICAL.

Similar presentations


Presentation on theme: "Copyright © 2016 Pearson Education, Inc. Modern Database Management 12 th Edition Jeff Hoffer, Ramesh Venkataraman, Heikki Topi CHAPTER 4: PART C LOGICAL."— Presentation transcript:

1 Copyright © 2016 Pearson Education, Inc. Modern Database Management 12 th Edition Jeff Hoffer, Ramesh Venkataraman, Heikki Topi CHAPTER 4: PART C LOGICAL DATABASE DESIGN AND THE RELATIONAL MODEL

2 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-2 DATA NORMALIZATION  Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that avoid unnecessary duplication of data  The process of decomposing relations with anomalies to produce smaller, well-structured relations

3 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-3 FUNCTIONAL DEPENDENCIES  Functional Dependency: The value of one set of attributes (the determinant) determines the value of another attribute.  X functionally determines Y: X  Y, where X is called a determinant.  Problem 4-33 (Fig. 4-33), p.195, 196. 3

4 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-4 FIGURE 4-2 4

5 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-5 FIGURE 4-23 5

6 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-6 CANDIDATE KEYS  Candidate Key: Attribute or a set of attributes that uniquely identifies a row.  Each non-key field is functionally dependent on every candidate key  One of the candidate keys will become the primary key  E.g., perhaps there is both credit card number and SS# in a table…in this case both are candidate keys.  Primary vs. candidate key: Fig. 4-16, p.171 6

7 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-7 Figure 4.22 Steps in normalization 3 rd normal form is generally considered sufficient

8 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-8 FIRST NORMAL FORM  A relation is in 1NF if it contains no multivalued attributes; i.e., every attribute value is atomic.  Fig. 4-25 is not in 1 st Normal Form (multivalued attributes)  it is not a relation.  Fig. 4-26 is in 1 st Normal form.  All relations are in 1 st Normal Form. 8

9 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-9 ANOMALIES ANOMALIES IN EMPLOYEE2 (FIG. 4-2B)  Insertion–can’t enter a new employee without having the employee take a class (or at least empty fields of class information)  Deletion–if we remove employee 140, we lose information about the existence of a Tax Acc class  Modification–giving a salary increase to employee 100 forces us to update multiple records 9 Why do these anomalies exist? Because there are two themes (entity types) in this one relation. This results in data duplication and an unnecessary dependency between the entities.

10 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-10 SECOND NORMAL FORM A relation is in 2NF if it is in 1NF and every non-key attribute is fully functionally dependent on the primary key. No partial functional dependencies (i.e., every non-key attribute must be defined by the entire key, not by only part of the key). A B C D: A B  C, A  D. 2NF? Is Fig. 4-23b (p. 181) in 2NF? 10

11 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-11 11 SECOND NORMAL FORM (2NF)  A relation is in 2NF if  Primary key consists of a single attribute; or  Primary key consists of all attributes.  Fig. 4-2b  Fig. 4-1 + Fig. 4-7

12 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-12 FIGURE 4-1 12

13 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-13 FIGURE 4-7 13

14 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-14 14 EMPLOYEE-COURSE RELATIONS IN 2NF EmpIDSalaryDeptNameNameCourseTitleDateCompletedEmpID Both are full functional dependencies

15 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-15 THIRD NORMAL FORM  A relation is in 3NF if it is in 2NF and no transitive dependencies exists, where a transitive dependency is a functional dependency between non-key attributes.  A B C D: A B  C, C  D. 2NF? 3NF?  Solution: Non-key determinant with transitive dependencies go into a new table; non-key determinant becomes primary key in the new table and stays as foreign key in the old table. 15

16 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-16 16 Relation with transitive dependency (a) SALES relation with simple data

17 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-17 17 Relation with transitive dependency CustID  Name CustID  Salesperson CustID  Region BUT Salesperson  Region Transitive dependency (not 3 rd NF)

18 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-18 18 Removing a transitive dependency (a) Decomposing the SALES relation

19 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-19 19 Relations in 3NF Now, there are no transitive dependencies… Both relations are in 3 rd NF CustID  Name CustID  Salesperson Salesperson  Region

20 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-20 Table with multivalued attributes, not in 1 st normal form Note: This is NOT a relation.

21 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-21 Table with no multivalued attributes and unique rows, in 1 st normal form Note: This is a relation, but not a well-structured one.

22 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-22 ANOMALIES IN THIS TABLE  Insertion–if new product is ordered for order 1007 of existing customer, customer data must be re-entered, causing duplication  Deletion–if we delete the Dining Table from Order 1006, we lose information concerning this item’s finish and price  Update–changing the price of product ID 4 requires update in multiple records Why do these anomalies exist? Because there are multiple themes (entity types) in one relation. This results in duplication and an unnecessary dependency between the entities.

23 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-23 OrderID  OrderDate, CustomerID, CustomerName, CustomerAddress Therefore, NOT in 2 nd Normal Form CustomerID  CustomerName, CustomerAddress ProductID  ProductDescription, ProductFinish, ProductStandardPrice OrderID, ProductID  OrderQuantity Figure 4-27 Functional dependency diagram for INVOICE

24 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-24 Partial dependencies are removed, but there are still transitive dependencies Getting it into Second Normal Form Figure 4-28 Removing partial dependencies

25 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-25 25 Transitive dependencies are removed. Figure 4-29 Removing partial dependencies Getting it into Third Normal Form

26 Chapter 4 Copyright © 2016 Pearson Education, Inc. 4-26


Download ppt "Copyright © 2016 Pearson Education, Inc. Modern Database Management 12 th Edition Jeff Hoffer, Ramesh Venkataraman, Heikki Topi CHAPTER 4: PART C LOGICAL."

Similar presentations


Ads by Google