Chapter 28: Advanced Relational Database Design

Slides:



Advertisements
Similar presentations
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide
Advertisements

Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 16 Relational Database Design Algorithms and Further Dependencies.
Chapter 7: Relational Database Design. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Chapter 7: Relational Database Design First Normal.
METU Department of Computer Eng Ceng 302 Introduction to DBMS Further Dependencies by Pinar Senkul resources: mostly froom Elmasri, Navathe and other books.
C.1 Appendix C: Advanced Relational Database Design Reasoning with MVDs Higher normal forms Join dependencies and PJNF DKNF.
Database System Concepts, 6 th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Appendix B: Advanced.
Chapter 7: Relational Database Design. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Chapter 7: Relational Database Design First Normal.
Multivalued Dependency Prof. Sin-Min Lee Department of Computer Science.
Chapter 7: Relational Database Design. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Chapter 7: Relational Database Design First Normal.
1 CMSC424, Spring 2005 CMSC424: Database Design Lecture 9.
1 Multi-valued Dependencies. 2 Multivalued Dependencies There are database schemas in BCNF that do not seem to be sufficiently normalized. Consider a.
Chapter 14 Advanced Normalization Transparencies © Pearson Education Limited 1995, 2005.
Chapter 11 Relational Database Design Algorithms and Further Dependencies Copyright © 2004 Ramez Elmasri and Shamkant Navathe.
Chapter 8: Relational Database Design First Normal Form First Normal Form Functional Dependencies Functional Dependencies Decomposition Decomposition Boyce-Codd.
©Silberschatz, Korth and Sudarshan7.1Database System Concepts Chapter 7: Relational Database Design First Normal Form Pitfalls in Relational Database Design.
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.
©Silberschatz, Korth and SudarshanC.1Database System Concepts, 5 th Ed. Appendix C: Advanced Relational Database Design.
Lecture 6 Normalization: Advanced forms. Objectives How inference rules can identify a set of all functional dependencies for a relation. How Inference.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide DESIGNING A SET OF RELATIONS (2) Goals: Lossless join property (a must). Dependency.
Database System Concepts, 5th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 7: Relational.
Computing & Information Sciences Kansas State University Tuesday, 27 Feb 2007CIS 560: Database System Concepts Lecture 18 of 42 Tuesday, 27 February 2007.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Chapter 11 Relational Database Design Algorithms and Further Dependencies.
Computing & Information Sciences Kansas State University Wednesday, 04 Oct 2006CIS 560: Database System Concepts Lecture 17 of 42 Wednesday, 04 October.
Relational Database Design Algorithms and Further Dependencies.
Chapter 11: Relational Database Design Algorithms and Further Dependencies Chapter 11: Relational Database Design Algorithms and Further Dependencies 1.
Chapter 7: Relational Database Design. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Chapter 7: Relational Database Design First Normal.
Database System Concepts, 6 th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Appendix B: Advanced.
Relational Database Design Algorithms and Further Dependencies.
Chapter 8 Relational Database Design. 2 Relational Database Design: Goals n Reduce data redundancy (undesirable replication of data values) n Minimize.
©Silberschatz, Korth and Sudarshan6.1Database System Concepts Chapter 6: Integrity Constraints Domain Constraints Referential Integrity Assertions Triggers.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide
10/3/2017.
Relational Database Design Algorithms and Further Dependencies
Functional Dependency and Normalization
Advanced Normalization
Chapter 15 Relational Design Algorithms and Further Dependencies
CHAPTER 14 Basics of Functional Dependencies and Normalization for Relational Databases.
Relational Database Design
Module 5: Overview of Database Design -- Normalization
Chapter 15 Basics of Functional Dependencies and Normalization for Relational Databases.
Relational Database Design by Dr. S. Sridhar, Ph. D
Chapter 7: Relational Database Design
Chapter 8: Relational Database Design
Relational Database Design
Relational Database Design
Chapter 8: Relational Database Design
Advanced Normalization
Chapter 7: Relational Database Design
Module 5: Overview of Normalization
Chapter 7: Relational Database Design
Mulitvalued Dependencies
Appendix C: Advanced Normalization Theory
Normal Form: 4 & 5.
Chapter 8: Relational Database Design
Normalization cs3431.
Chapter 7: Relational Database Design
Relational Database Design Algorithms and Further Dependencies
Chapter 7: Relational Database Design
Relational Database Design
Chapter 7: Relational Database Design
Chapter 7: Relational Database Design
Join Dependencies and Fifth Normal Form
Appendix C: Advanced Relational Database Design
Chapter 7: Relational Database Design
Chapter 7b: Normalization
Chapter 7a: Overview of Database Design -- Normalization
Presentation transcript:

Chapter 28: Advanced Relational Database Design

Outline Reasoning with MVDs Higher normal forms Join dependencies and PJNF DKNF

Theory of Multivalued Dependencies Let D denote a set of functional and multivalued dependencies. The closure D+ of D is the set of all functional and multivalued dependencies logically implied by D. Sound and complete inference rules for functional and multivalued dependencies: 1. Reflexivity rule. If  is a set of attributes and   , then   holds. 2. Augmentation rule. If    holds and  is a set of attributes, then    holds. 3. Transitivity rule. If    holds and   holds, then   holds.

Theory of Multivalued Dependencies (Cont.) 4. Complementation rule. If   holds, then  R –  –  holds. 5. Multivalued augmentation rule. If   holds and   R and   , then     holds. 6. Multivalued transitivity rule. If   holds and   holds, then   –  holds. 7. Replication rule. If   holds, then  . 8. Coalescence rule. If   holds and    and there is a  such that   R and    =  and  , then   holds.

Simplification of the Computation of D+ We can simplify the computation of the closure of D by using the following rules (proved using rules 1-8). Multivalued union rule. If   holds and   holds, then   holds. Intersection rule. If   holds and   holds, then     holds. Difference rule. If If   holds and   holds, then   –  holds and   –  holds.

Example R = (A, B, C, G, H, I) D = {A B B HI CG H} Some members of D+: A CGHI. Since A B, the complementation rule (4) implies that A R – B – A. Since R – B – A = CGHI, so A CGHI. A HI. Since A B and B HI, the multivalued transitivity rule (6) implies that B HI – B. Since HI – B = HI, A HI.

Example (Cont.) Some members of D+ (cont.): B H. Apply the coalescence rule (8); B HI holds. Since H  HI and CG H and CG  HI = Ø, the coalescence rule is satisfied with  being B,  being HI,  being CG, and  being H. We conclude that B H. A CG. A CGHI and A HI. By the difference rule, A CGHI – HI. Since CGHI – HI = CG, A CG.

Normalization Using Join Dependencies Join dependencies constrain the set of legal relations over a schema R to those relations for which a given decomposition is a lossless-join decomposition. Let R be a relation schema and R1 , R2 ,..., Rn be a decomposition of R. If R = R1  R2  ….  Rn, we say that a relation r(R) satisfies the join dependency *(R1 , R2 ,..., Rn) if: r =R1 (r) ⋈ R2 (r) ⋈ …… ⋈ Rn(r) A join dependency is trivial if one of the Ri is R itself. A join dependency *(R1, R2) is equivalent to the multivalued dependency R1  R2 R2. Conversely,   is equivalent to *( (R - ),   ) However, there are join dependencies that are not equivalent to any multivalued dependency.

Project-Join Normal Form (PJNF) A relation schema R is in PJNF with respect to a set D of functional, multivalued, and join dependencies if for all join dependencies in D+ of the form *(R1 , R2 ,..., Rn ) where each Ri  R and R =R1 R2  ...  Rn at least one of the following holds: *(R1 , R2 ,..., Rn ) is a trivial join dependency. Every Ri is a superkey for R. Since every multivalued dependency is also a join dependency, every PJNF schema is also in 4NF.

Example Consider Loan-info-schema = (branch-name, customer-name, loan-number, amount). Each loan has one or more customers, is in one or more branches and has a loan amount; these relationships are independent, hence we have the join dependency *(=(loan-number, branch-name), (loan-number, customer-name), (loan-number, amount)) Loan-info-schema is not in PJNF with respect to the set of dependencies containing the above join dependency. To put Loan-info-schema into PJNF, we must decompose it into the three schemas specified by the join dependency: (loan-number, branch-name) (loan-number, customer-name) (loan-number, amount)

Domain-Key Normal Form (DKNY) Domain declaration. Let A be an attribute, and let dom be a set of values. The domain declaration A  dom requires that the A value of all tuples be values in dom. Key declaration. Let R be a relation schema with K  R. The key declaration key (K) requires that K be a superkey for schema R (K  R). All key declarations are functional dependencies but not all functional dependencies are key declarations. General constraint. A general constraint is a predicate on the set of all relations on a given schema. Let D be a set of domain constraints and let K be a set of key constraints for a relation schema R. Let G denote the general constraints for R. Schema R is in DKNF if D  K logically imply G.

Example Accounts whose account-number begins with the digit 9 are special high-interest accounts with a minimum balance of 2500. General constraint: ``If the first digit of t [account-number] is 9, then t [balance]  2500.'' DKNF design: Regular-acct-schema = (branch-name, account-number, balance) Special-acct-schema = (branch-name, account-number, balance) Domain constraints for {Special-acct-schema} require that for each account: The account number begins with 9. The balance is greater than 2500.

DKNF rephrasing of PJNF Definition Let R = (A1 , A2 ,..., An) be a relation schema. Let dom(Ai ) denote the domain of attribute Ai, and let all these domains be infinite. Then all domain constraints D are of the form Ai  dom (Ai ). Let the general constraints be a set G of functional, multivalued, or join dependencies. If F is the set of functional dependencies in G, let the set K of key constraints be those nontrivial functional dependencies in F+ of the form   R. Schema R is in PJNF if and only if it is in DKNF with respect to D, K, and G.

End of Chapter 28