1 CS122A: Introduction to Data Management Lecture #13: Relational DB Design Theory (II) Instructor: Chen Li.

Slides:



Advertisements
Similar presentations
Schema Refinement and Normal Forms
Advertisements

Schema Refinement and Normal Forms Given a design, how do we know it is good or not? What is the best design? Can a bad design be transformed into a good.
Database Management Systems, 3ed, R. Ramakrishnan and J. Gehrke1 Schema Refinement and Normal Forms Chapter 19.
1 Normalization. 2 Normal Forms v If a relation is in a certain normal form (BCNF, 3NF etc.), it is known that certain kinds of redundancies are avoided/minimized.
CS Schema Refinement and Normal Forms Chapter 19.
Normalization DB Tuning CS186 Final Review Session.
Schema Refinement and Normal Forms
1 Normalization Chapter What it’s all about Given a relation, R, and a set of functional dependencies, F, on R. Assume that R is not in a desirable.
Schema Refinement and Normal Forms. The Evils of Redundancy v Redundancy is at the root of several problems associated with relational schemas: – redundant.
1 Schema Refinement and Normal Forms Chapter 19 Raghu Ramakrishnan and J. Gehrke (second text book) In Course Pick-up box tomorrow.
Schema Refinement and Normalization Nobody realizes that some people expend tremendous energy merely to be normal. Albert Camus.
Cs3431 Normalization Part II. cs3431 Attribute Closure : Example Consider R (A, B, C, D, E) with FDs A  B, B  C, CD  E Does A  E hold ? (Is A  E.
1 Schema Refinement and Normal Forms Yanlei Diao UMass Amherst April 10, 2007 Slides Courtesy of R. Ramakrishnan and J. Gehrke.
Database Management Systems, R. Ramakrishnan and J. Gehrke 1 Schema Refinement and Normal Forms Chapter 19 Instructor: Mirsad Hadzikadic.
Schema Refinement and Normal Forms Jianlin Feng School of Software SUN YAT-SEN UNIVERSITY courtesy of Joe Hellerstein for some slides.
Normal Forms1. 2 The Problems of Redundancy Redundancy is at the root of several problems associated with relational schemas: Wastes storage Causes problems.
CSCD34 - Data Management Systems - A. Vaisman1 Schema Refinement and Normal Forms.
Schema Refinement and Normalization. Functional Dependencies (Review) A functional dependency X  Y holds over relation schema R if, for every allowable.
Schema Refinement and Normal Forms Chapter 19 1 Database Management Systems 3ed, R.Ramakrishnan & J.Gehrke.
1 Schema Refinement, Normalization, and Tuning. 2 Design Steps v The design steps: 1.Real-World 2. ER model 3. Relational Schema 4. Better relational.
Database Management Systems 1 Raghu Ramakrishnan Database Design Review Aug 24, 2015 Instructor: Xintao Wu.
LECTURE 5: Schema Refinement and Normal Forms SOME OF THESE SLIDES ARE BASED ON YOUR TEXT BOOK.
Functional Dependencies and Normalization R&G Chapter 19 Lecture 26 Science is the knowledge of consequences, and dependence of one fact upon another.
Christoph F. Eick: Functional Dependencies, BCNF, and Normalization 1 Functional Dependencies, BCNF and Normalization.
Functional Dependencies And Normalization R&G Chapter 19.
Database Systems/COMP4910/Spring02/Melikyan1 Schema Refinement and Normal Forms.
CSC 411/511: DBMS Design Dr. Nan Wang 1 Schema Refinement and Normal Forms Chapter 19.
1 Schema Refinement and Normal Forms Week 6. 2 The Evils of Redundancy  Redundancy is at the root of several problems associated with relational schemas:
Database Management Systems, R. Ramakrishnan and J. Gehrke1 Schema Refinement and Normal Forms Chapter 15.
Announcements Program 3 due Friday Homework 2 out today, due Mon Read: Chapter 3.
Database Management Systems, 3ed, R. Ramakrishnan and J. Gehrke1 Schema Refinement and Normal Forms Chapter 19.
Schema Refinement and Normalization Nobody realizes that some people expend tremendous energy merely to be normal. Albert Camus.
1 Schema Refinement and Normal Forms Chapter The Evils of Redundancy  Redundancy is at the root of several problems associated with relational.
Ch 7: Normalization-Part 1
CS542 1 Schema Refinement Chapter 19 (part 1) Functional Dependencies.
Database Management Systems, 3ed, R. Ramakrishnan and J. Gehrke1 Schema Refinement and Normal Forms Chapter 19.
1 Schema Refinement and Normal Forms Chapter The Evils of Redundancy  Redundancy causes several problems associated with relational schemas: 
Normalization and FUNctional Dependencies. Redundancy: root of several problems with relational schemas: –redundant storage, insert/delete/update anomalies.
CSC 411/511: DBMS Design Dr. Nan Wang 1 Schema Refinement and Normal Forms Chapter 19.
1 CS122A: Introduction to Data Management Lecture #12: Relational DB Design Theory (1) Instructor: Chen Li.
LECTURE 5: Schema Refinement and Normal Forms 1. Redundency Problem Redundent Storage Update Anomaly If one copy updated, an inconsistancy may occur Insertion.
CSC 411/511: DBMS Design Dr. Nan Wang 1 Schema Refinement and Normal Forms Chapter 19.
Schema Refinement & Normal Forms.
Functional Dependencies and Schema Refinement
Introduction to Database Systems Functional Dependencies
Schema Refinement and Normal Forms
UNIT - 3 DATABASE DESIGN Functional Dependencies
Module 5: Overview of Database Design -- Normalization
Normalization First Normal Form (1NF) Boyce-Codd Normal Form (BCNF)
Functional Dependencies, BCNF and Normalization
Handout 4 Functional Dependencies
Functional Dependencies, BCNF and Normalization
Schema Refinement & Normalization Theory
Functional Dependencies
Schema Refinement and Normalization
Module 5: Overview of Normalization
Normalization Murali Mani.
Schema Refinement and Normal Forms
Functional Dependencies and Normalization
LECTURE 5: Schema Refinement and Normal Forms
Functional Dependencies
Normalization Part II cs3431.
Schema Refinement and Normalization
Normalization cs3431.
Chapter 19 (part 1) Functional Dependencies
Schema Refinement and Normal Forms
Schema Refinement and Normalization
Schema Refinement and Normal Forms
Chapter 7a: Overview of Database Design -- Normalization
Functional Dependencies and Normalization
Presentation transcript:

1 CS122A: Introduction to Data Management Lecture #13: Relational DB Design Theory (II) Instructor: Chen Li

2 Third Normal Form (3NF)  Relation R is in 3NF if it is in 2NF and it has no transitive dependencies to non-prime attributes. Violation

3 Example  Workers(eno, ename, esal, dno, dname, dfloor) where: eno  ename, eno  esal, eno  dno, dno  dname, dno  dfloor Q1: What are the candidate keys for Workers? Q2: What are the prime attributes for Workers? Q3: Why is Workers not in 3NF? Q4: What’s the fix? Emp(eno, ename, esal, dno) Dept(dno, dname, dfloor) Don’t forget this! (Else “lossy join” !!) A1: eno A2: eno A3: Two inferable FDs, eno  dname and eno  dfloor, each violate 3NF.

4 Boyce-Codd Normal Form (BCNF)  Rel’n R with FDs F is in BCNF if, for all X  A in F +  A X ( trivial FD), or else  X is a superkey (i.e., contains a key) for R. Violation

5 Boyce-Codd Normal Form (BCNF)  R is in BCNF if the only non-trivial FDs that hold over R are key constraints ! ( i.e., key  attr)  Everything depends on “the key, the whole key, and nothing but the key”(so help me Codd )

6 Boyce-Codd Normal Form (Cont’d.)  Ex : Supply2(sno, sname, pno) where: sno  sname, sname  sno Q1: What are the candidate keys for Supply2? Q2: What are the prime attributes for Supply2? Q3 Is Supply2 in 3NF? Q4: Why is Supply2 not in BCNF? Q5: What’s the fix? Supplier2(sno, sname) Supplies2(sno, pno) A1: (sno, pno), (sname, pno) A2: sno, sname, pno A3: Yes, it is in 3NF. A4: Each of its FDs has a left-hand-side that isn’t a candidate key. (Just a part of one.) Note: Overlapping...!

7 3NF Revisited (Alternative Def’n)  Rel’n R with FDs F is in 3NF if, for all X  A in F+  A X ( trivial FD), or else  X is a superkey (i.e., contains a key) for R, or else  A is part of some key for R.  If R is in BCNF, clearly it is also in 3NF.

8 Summary of normal forms (in terms of their violations Attributes in R Prime attributes (proper subset of a key) Non-Prime attributes 2NF violation 3NF violation BCNF violation Keys

9 Decomposition of a Relation Scheme  Suppose that relation R contains attributes A1... An. A decomposition of R consists of replacing R by two or more relations such that:  Each new relation scheme contains a subset of the attributes of R (and no attributes that do not appear in R ), and  Every attribute of R appears as an attribute of one of the new relations.  Intuitively, decomposing R means we will store instances of the relations produced by the decomposition instead of storing instances of R.  E.g., decompose SNLRWH into SNLRH and RW.

10 Example Decomposition  Decompositions should be used only when needed.  Suppose SNLRWH has 2 FDs: S  SNLRWH and R  W  Second FD causes violation of 3NF (W values repeatedly associated with R values). Easiest fix is to create a relation RW to store these associations, and then to remove W from the main schema: I.e.: Decompose SNLRWH into SNLRH and RW.  The information to be stored consists of SNLRWH tuples. (If we just store the projections of these tuples onto SNLRH and RW, are there any potential problems that we should be aware of?... 

11 Reminder:  Problems due to R  W :  Update anomaly : Can we change W in just the 1st tuple of SNLRWH?  Insertion anomaly : What if we want to insert an employee and don ’ t know the hourly wage for his rating?  Deletion anomaly : If we delete all employees with rating 5, we lose the information about the wage for rating 5! HourlyEmps2 Wages How about two smaller tables?

12 Decompositions: Possible Problems  There are three potential problems to consider: 1. Some queries become more expensive. E.g., how much did sailor Joe earn? (S = W*H now requires a join) 2. Given instances of the decomposed relations, we may not be able to reconstruct the corresponding instance of the original relation! (If “lossy”...) Fortunately, not a problem in the SNLRWH example! 3. Checking some dependencies may require joining the instances of the decomposed relations. Fortunately, also not in the SNLRWH example.  Tradeoff : Must consider these issues vs. redundancy.

13 Lossless Join Decompositions  Decomposition of R into X and Y is lossless-join w.r.t. a set of FDs F if, for every instance r that satisfies F:  ( r ) ( r ) = r  It is always true that r ( r ) ( r )  In general, the other direction does not hold! If it does, then the decomposition is called lossless-join.  Must ensure that X and Y overlap, and that the overlap contains a key for one of the two relations.  Definition extends to decomposition into 3 or more relations in a straightforward way.  Decompositions must be lossless! (Avoids Problem (2).)

14 Decomposition not lossless-join (bad) HourlyEmps3 Hours

15 Dependency Preserving Decomposition  Consider CSJDPQV, C is key, JP  C and SD  P.  BCNF decomposition: CSJDQV and SDP  Problem: Checking JP  C requires a join!  Dependency preserving decomposition (intuitive):  If R is decomposed into X, Y and Z, and we enforce the FDs that hold on X, on Y, and on Z, then all FDs that were given to hold on R must also hold. (Avoids Problem (3).)  Projection of set of FDs F : If R is decomposed into X,... projection of F onto X (denoted F X ) is the set of FDs U  V in F + ( closure of F ) such that U,V both in X.

16 Dependency Preserving Decomp. (Cont’d.)  Decomposition of R into X and Y is dependency preserving if (F X union F Y ) + = F +  I.e., if we consider only dependencies in the closure F + that can be checked in X without considering Y, and in Y without considering X, they imply all dependencies in F +. R XY F FXFX FYFY

17 Dependency Preserving Decomp. (Cont’d.)  Important to consider F +, not F, in this definition:  R(ABC), A  B, B  C, C  A,  2NF? Yes  3NF? Yes  BCNF? Yes  Decomposed into AB and BC.  Is this dependency preserving? (Is C  A preserved?)

18 Dependency Preserving Decomp. (Cont’d.)  Dependency preserving does not imply lossless join:  R(ABC), only A  B,  2NF? No  If decomposed into AB and BC. Dependencency preserving? Yes. Lossless join? No  And vice-versa! (So we need to check for both.)  Must make sure some relation contains a key for R !!!

19 3NF Revisited  If R is in 3NF, some redundancy is possible. 3NF is a compromise to use when BCNF isn’t achievable (e.g., no “good ” decomp, or performance considerations).  Important : A lossless-join, dependency-preserving decomposition of R into a collection of 3NF relations is always possible.

20 BCNF Revisited Note: A lossless-join, dependency-preserving decomposition of R into a collection of BCNF relations is NOT always possible.

21 Summary of normalization theory