1 CMSC424, Spring 2005 CMSC424: Database Design Lecture 9.

Slides:



Advertisements
Similar presentations
Schema Refinement: Normal Forms
Advertisements

Chapter 7: Relational Database Design. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Chapter 7: Relational Database Design First Normal.
Manipulating Functional Dependencies Zaki Malik September 30, 2008.
Dr. Kalpakis CMSC 461, Database Management Systems URL: Relational Database Design.
Chapter 3 Notes. 3.1 Functional Dependencies A functional dependency is a statement that – two tuples of a relation that agree on some particular set.
Temple University – CIS Dept. CIS616– Principles of Data Management V. Megalooikonomou Functional Dependencies (based on notes by Silberchatz,Korth, and.
C.1 Appendix C: Advanced Relational Database Design Reasoning with MVDs Higher normal forms Join dependencies and PJNF DKNF.
Topics to be discusses Functional Dependency Key
©Silberschatz, Korth and Sudarshan Relational Database Design First Normal Form Pitfalls in Relational Database Design Functional Dependencies Decomposition.
7.1 Chapter 7: Relational Database Design. 7.2 Chapter 7: Relational Database Design Features of Good Relational Design Atomic Domains and First Normal.
Chapter 7: Relational Database Design. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Chapter 7: Relational Database Design First Normal.
Chapter 7: Relational Database Design. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Chapter 7: Relational Database Design First Normal.
Multivalued Dependency Prepared by Tomasz Kaciak CS157A.
Database System Concepts, 5th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 7: Relational.
Chapter 7: Relational Database Design. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Chapter 7: Relational Database Design First Normal.
Slides adapted from A. Silberschatz et al. Database System Concepts, 5th Ed. Relational Database Design - part 2 - Database Management Systems I Alex Coman,
CMSC424: Database Design Instructor: Amol Deshpande
Functional Dependencies (Part 3) Presented by Nash Raghavan All page numbers are in reference to Database System Concepts (5 th Edition)
1 Functional Dependency and Normalization Informal design guidelines for relation schemas. Functional dependencies. Normal forms. Normalization.
Relational Database Design
Department of Computer Science and Engineering, HKUST Slide 1 7. Relational Database Design.
1 Database Theory and Methodology. 2 The Good and the Bad So far we have not developed any measure of “goodness” to measure the quality of the design,
Chapter 14 Advanced Normalization Transparencies © Pearson Education Limited 1995, 2005.
Chapter 8: Relational Database Design First Normal Form First Normal Form Functional Dependencies Functional Dependencies Decomposition Decomposition Boyce-Codd.
Relational Database Design
©Silberschatz, Korth and Sudarshan7.1Database System Concepts Chapter 7: Relational Database Design First Normal Form Pitfalls in Relational Database Design.
Database System Concepts, 6 th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 8: Relational.
Database System Concepts, 5th Ed. ©Silberschatz, Korth and Sudarshan Chapter 7: Relational Database Design.
Chapter 7: Relational Database Design. 7.2Unite International CollegeDatabase Management Systems Chapter 7: Relational Database Design Features of Good.
 Features of Good Relational Design  Atomic Domains and First Normal Form  Decomposition Using Functional Dependencies  Functional Dependency Theory.
FUNCTIONAL DEPENDENCIES. Chapter Outline 1 Informal Design Guidelines for Relational Databases 1.1Semantics of the Relation Attributes 1.2 Redundant Information.
Computing & Information Sciences Kansas State University Monday, 13 Oct 2008CIS 560: Database System Concepts Lecture 18 of 42 Monday, 13 October 2008.
Database System Concepts, 5th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 7: Relational.
Chapter 7: Relational Database Design. 7.2Unite International CollegeDatabase Management Systems Chapter 7: Relational Database Design Features of Good.
Chapter 7: Relational Database Design. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Chapter 7: Relational Database Design Pitfalls in.
Relational Database Design by Relational Database Design by Dr.S.Sridhar, Ph.D.(JNUD), RACI(Paris, NICE), RMR(USA), RZFM(Germany) DIRECTOR ARUNAI ENGINEERING.
Chapter 8: Relational Database Design First Normal Form First Normal Form Functional Dependencies Functional Dependencies Decomposition Decomposition Boyce-Codd.
Lecture 6 Normalization: Advanced forms. Objectives How inference rules can identify a set of all functional dependencies for a relation. How Inference.
CS143 Review: Normalization Theory Q: Is it a good table design? We can start with an ER diagram or with a large relation that contain a sample of the.
Database System Concepts, 5th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 7: Relational.
BCNF & Lossless Decomposition Prof. Sin-Min Lee Department of Computer Science.
Computing & Information Sciences Kansas State University Tuesday, 27 Feb 2007CIS 560: Database System Concepts Lecture 18 of 42 Tuesday, 27 February 2007.
Functional Dependencies and Normalization 1 Instructor: Mohamed Eltabakh
Computing & Information Sciences Kansas State University Wednesday, 04 Oct 2006CIS 560: Database System Concepts Lecture 17 of 42 Wednesday, 04 October.
Database System Concepts, 5th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 7: Relational.
Chapter 7: Relational Database Design. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Chapter 7: Relational Database Design First Normal.
Database System Concepts ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 7: Relational Database.
1 Lecture 6: Schema refinement: Functional dependencies
1 Dept. of CIS, Temple Univ. CIS616/661 – Principles of Data Management V. Megalooikonomou Integrity Constraints (based on slides by C. Faloutsos at CMU)
CSC 411/511: DBMS Design Dr. Nan Wang 1 Schema Refinement and Normal Forms Chapter 19.
Chapter 7: Relational Database Design. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Chapter 7: Relational Database Design First Normal.
Chapter 7: Relational Database Design
MIS 3053 Database Design And Applications The University Of Tulsa Professor: Akhilesh Bajaj Normal Forms Lecture 1 © Akhilesh Bajaj, 2000, 2002, 2003.
© D. Wong Functional Dependencies (FD)  Given: relation schema R(A1, …, An), and X and Y be subsets of (A1, … An). FD : X  Y means X functionally.
Chapter 7: Relational Database Design. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Chapter 7: Relational Database Design First Normal.
Chapter 8 Relational Database Design. 2 Relational Database Design: Goals n Reduce data redundancy (undesirable replication of data values) n Minimize.
Computing & Information Sciences Kansas State University Friday, 03 Oct 2007CIS 560: Database System Concepts Lecture 16 of 42 Wednesday, 03 October 2007.
Database System Concepts, 5th Ed. Bin Mu at Tongji University Chapter 7: Relational Database Design.
Normalization and FUNctional Dependencies. Redundancy: root of several problems with relational schemas: –redundant storage, insert/delete/update anomalies.
©Silberschatz, Korth and Sudarshan6.1Database System Concepts Chapter 6: Integrity Constraints Domain Constraints Referential Integrity Assertions Triggers.
CSC 411/511: DBMS Design Dr. Nan Wang 1 Schema Refinement and Normal Forms Chapter 19.
Module 5: Overview of Database Design -- Normalization
Relational Database Design by Dr. S. Sridhar, Ph. D
Chapter 7: Relational Database Design
Relational Database Design
Relational Database Design
Chapter 8: Relational Database Design
Temple University – CIS Dept. CIS331– Principles of Database Systems
Relational Database Design
Presentation transcript:

1 CMSC424, Spring 2005 CMSC424: Database Design Lecture 9

2 CMSC424, Spring 2005 Relational Database Design Find a “good” collection of relation schemas; otherwise –Repetition of Information. Leads to anomalies –Inability to represent certain information. Use integrity constraints to refine the schema Main refinement technique: Decomposition –E.g. break ABCD into AB and BCD Must be careful with decomposition

3 CMSC424, Spring 2005 Decomposition All attributes of an original schema (R) must appear in the decomposition (R 1, R 2 ): R = R 1  R 2 Lossless-join decomposition. For all possible legal relations r on schema R r =  R1 (r)  R2 (r) How do you define legal ?

4 CMSC424, Spring 2005 Examples of Join Decompositions

5 CMSC424, Spring 2005 Goal — Devise a Theory for the Following Decide whether a particular relation R is in “good” form. In the case that a relation R is not in “good” form, decompose it into a set of relations {R 1, R 2,..., R n } such that each relation is in good form the decomposition is a lossless-join decomposition Our theory is based on: functional dependencies multivalued dependencies

6 CMSC424, Spring 2005 Normal Forms 1st, 2nd, 3rd, 4th Normal Forms Boyce-Codd Normal Form (BCNF)

7 CMSC424, Spring 2005 First Normal Form Atomic Domains Sometimes a function of how domain is used, rather than intrinsic properties of the domain A set of values as an attribute not acceptable Non-atomic values complicate storage and encourage redundant (repeated) storage of data We will assume 1st normal form compliance

8 CMSC424, Spring 2005 Rest of the normal forms… Need: functional dependencies multi-valued dependencies What are they ? Constraints on the set of legal relations

9 CMSC424, Spring 2005 Functional Dependencies Let R be a relation schema   R and   R The functional dependency    holds on R if and only if for any legal relations r (R): t 1 [  ] = t 2 [  ]  t 1 [  ] = t 2 [  ] Example: Consider r(A,B) with the following instance of r. On this instance, A  B does NOT hold, but B  A does hold. Beware: Difference between holding in one instance, and holding in all legal relations

10 CMSC424, Spring 2005 Functional Dependencies (Cont.) Generalization of the notion of keys K is a superkey for relation schema R if and only if K  R K is a candidate key for R if and only if K  R, and for no   K,   R Functional dependencies allow us to express constraints that cannot be expressed using superkeys.

11 CMSC424, Spring 2005 Functional Dependencies If a relation r is legal under a set F of functional dependencies, we say that r satisfies F. We say that F holds on R if all legal relations on R satisfy the set of functional dependencies F. What’s the difference between r and R above ?

12 CMSC424, Spring 2005 Functional Dependencies (Cont.) A functional dependency is trivial if it is satisfied by all instances of a relation E.g. customer-name, loan-number  customer-name customer-name  customer-name In general,    is trivial if   

13 CMSC424, Spring 2005 Closure of a Set of Functional Dependencies Given a set F set of functional dependencies, there are certain other functional dependencies that are logically implied by F. E.g. If A  B and B  C, then we can infer that A  C F + (closure of F) Set of all functional dependencies logically implied by F Armstrong’s Axioms: if   , then    (reflexivity) if   , then      (augmentation) if   , and   , then    (transitivity) These rules are sound complete

14 CMSC424, Spring 2005 Example R = (A, B, C, G, H, I) F = { A  B A  C CG  H CG  I B  H} some members of F + A  H AG  I CG  HI if   , then    (reflexivity) if   , then      (augmentation) if   , and   , then    (transitivity)

15 CMSC424, Spring 2005 Procedure for Computing F + To compute the closure of a set of functional dependencies F: F + = F repeat for each functional dependency f in F + apply reflexivity and augmentation rules on f add the resulting functional dependencies to F + for each pair of functional dependencies f 1 and f 2 in F + if f 1 and f 2 can be combined using transitivity then add the resulting functional dependency to F + until F + does not change any further

16 CMSC424, Spring 2005 Closure of Functional Dependencies (Cont.) We can further simplify manual computation of F + by using the following additional rules. If    holds and    holds, then     holds (union) If     holds, then    holds and    holds (decomposition) If    holds and     holds, then     holds (pseudotransitivity) The above rules can be inferred from Armstrong’s axioms.

17 CMSC424, Spring 2005 Closure of Attribute Sets For an attriute set ,  + = Closure of  under F is the set of attributes that are functionally determined by  under F:    is in F +     + Algorithm to compute  + : result :=  ; while (changes to result) do for each    in F do begin if   result then result := result   end

18 CMSC424, Spring 2005 Example of Attribute Set Closure R = (A, B, C, G, H, I) F = {A  B A  C CG  H CG  I B  H} (AG) + 1.result = AG 2.result = ABCG(A  C and A  B) 3.result = ABCGH(CG  H and CG  AGBC) 4.result = ABCGHI(CG  I and CG  AGBCH) Is AG a candidate key? Is AG a super key? 1.Does AG  R? == Is (AG) +  R Is any subset of AG a superkey? 1.Does A  R? == Is (A) +  R 2.Does G  R? == Is (G) +  R

19 CMSC424, Spring 2005 Uses of Attribute Closure There are several uses of the attribute closure algorithm: Testing for superkey: To test if  is a superkey, we compute  +, and check if  + contains all attributes of R. Testing functional dependencies To check if a functional dependency    holds (or, in other words, is in F + ), just check if    +. That is, we compute  + by using attribute closure, and then check if it contains . Is a simple and cheap test, and very useful Computing closure of F For each   R, we find the closure  +, and for each S   +, we output a functional dependency   S.

20 CMSC424, Spring 2005 Canonical Cover Sets of functional dependencies may have redundant dependencies that can be inferred from the others Eg: A  C is redundant in: {A  B, B  C, A  C} Parts of a functional dependency may be redundant E.g. on RHS: {A  B, B  C, A  CD} can be simplified to {A  B, B  C, A  D} E.g. on LHS: {A  B, B  C, AC  D} can be simplified to {A  B, B  C, A  D}

21 CMSC424, Spring 2005 Extraneous Attributes Consider a set F of functional dependencies and the functional dependency    in F. Attribute A is extraneous in  if A   and F logically implies (F – {    })  {(  – A)   }. Attribute A is extraneous in  if A   and the set of functional dependencies (F – {    })  {   (  – A)} logically implies F. Note: implication in the opposite direction is trivial in each of the cases above, since a “stronger” functional dependency always implies a weaker one

22 CMSC424, Spring 2005 Testing if an Attribute is Extraneous Consider a set F of functional dependencies and the functional dependency    in F. To test if attribute A   is extraneous in  compute ({  } – A) + using the dependencies in F check that ({  } – A) + contains A; if it does, A is extraneous To test if attribute A   is extraneous in  compute  + using only the dependencies in F’ = (F – {    })  {   (  – A)}, check that  + contains A; if it does, A is extraneous

23 CMSC424, Spring 2005 Canonical Cover A canonical cover for F is a set of dependencies F c such that F logically implies all dependencies in F c, and F c logically implies all dependencies in F, and No functional dependency in F c contains an extraneous attribute, and Each left side of functional dependency in F c is unique. To compute a canonical cover for F: repeat Use the union rule to replace any dependencies in F  1   1 and  1   2 with  1   1  2 Find a functional dependency    with an extraneous attribute either in  or in  If an extraneous attribute is found, delete it from    until F does not change Note: Union rule may become applicable after some extraneous attributes have been deleted, so it has to be re-applied

24 CMSC424, Spring 2005 Example of Computing a Canonical Cover R = (A, B, C) F = {A  BC B  C A  B AB  C} Combine A  BC and A  B into A  BC Set is now {A  BC, B  C, AB  C} A is extraneous in AB  C Check if the result of deleting A from AB  C is implied by the other dependencies Yes: in fact, B  C is already present! Set is now {A  BC, B  C} C is extraneous in A  BC Check if A  C is logically implied by A  B and the other dependencies Yes: using transitivity on A  B and B  C. –Can use attribute closure of A in more complex cases The canonical cover is: A  B B  C

25 CMSC424, Spring 2005 Normalization Using Functional Dependencies When we decompose a relation schema R with a set of functional dependencies F into R 1, R 2,.., R n we want Lossless-join decomposition No redundancy Dependency preservation

26 CMSC424, Spring 2005 Example R = (A, B, C) F = {A  B, B  C) Can be decomposed in two different ways R 1 = (A, B), R 2 = (B, C) Lossless-join decomposition: R 1  R 2 = {B} and B  BC Dependency preserving R 1 = (A, B), R 2 = (A, C) Lossless-join decomposition: R 1  R 2 = {A} and A  AB Not dependency preserving (cannot check B  C without computing R 1 R 2 )