Normalization. Murali Mani. What and Why Normalization? To remove potential redundancy in design

Transcription

1 1 Normalization What and Why Normalization? To remove potential redundancy in design Redundancy causes several anomalies: insert, delete and update Normalization uses concept of dependencies Functional Dependencies Idea used: Decomposition Break R (A, B, C, D) into R1 (A, B) and R2 (B, C, D) Use decomposition judiciously.

2 2 Insert Anomaly s1 s2 sname pnumber p1 Greg p2 ER Note: We cannot insert a professor who has no students. Insert Anomaly: We are not able to insert valid value/(s) Delete Anomaly sname pnumber s1 p1 s2 Greg p2 ER Note: We cannot delete a student that is the only student of a professor. Delete Anomaly: We are not able to perform a delete without losing some valid information. Note: In both cases, minimum cardinality of Professor in the corresponding ER schema is 0

3 3 Update Anomaly sname pnumber s1 p1 s2 Greg p1 Note: To update the name of a professor, we have to update in multiple tuples. Update anomalies are due to redundancy. Update Anomaly: To update a value, we have to update multiple rows. Note the maximum cardinality of Professor in the corresponding ER schema is * pnumber (1,1) Has (0,*) Advisor Professor sname years Keys : Revisited A key for a relation R (a1, a2,, an) is a set of attributes, K that uniquely determine the values for all attributes of R. A key K is minimal: no subset of K is a key. A superkey need not be minimal Prime Attribute: An attribute of a key

4 4 Keys: Example 1 2 sname Greg address 144FL 320FL Primary Key: <> Candidate key: <sname> Some superkeys: {<, address>, <sname>, <>, <, sname>, <, sname, address>} Prime Attribute: {, sname} Functional Dependencies (FDs) 1 2 sname Greg address 144FL 320FL Suppose we have the FD sname address for any two rows in the relation with the same value for sname, the value for address must be the same i.e., there is a function from sname to address Note: We will assume no null values. Any key (primary or candidate) or superkey of a relation R functionally determines all attributes of R

5 5 Properties of FDs Consider A, B, C, Z are sets of attributes Reflexive (also called trivial FD): if A B, then A B Transitive: if A B, and B C, then A C Augmentation: if A B, then AZ BZ Union: if A B, A C, then A BC Decomposition: if A BC, then A B, A C Inferring FDs Why? Suppose we have a relation R (A, B, C) and we have functional dependencies A B, B C, C A what is a key for R? Should we split R into multiple relations? We can infer A ABC, B ABC, C ABC. Hence A, B, C are all keys.

6 6 Algorithm for inference of FDs Computing the closure of set of attributes {A1, A2,, An}, denoted {A1, A2,, An} + 1. Let X = {A1, A2,, An} 2. If there exists a FD B1, B2,, Bm C, such that every Bi X, then X = X C 3. Repeat step 2 till no more attributes can be added. 4. {A1, A2,, An} + = X Inferring FDs: Example 1 Given R (A, B, C), and FDs A B, B C, C A, what are possible keys for R Compute the closure of attributes: {A} + = {A, B, C} {B} + = {A, B, C} {C} + = {A, B, C} So keys for R are <A>, <B>, <C>

7 7 Inferring FDs: Example 2 Consider R (A, B, C, D, E) with FDs A B, B C, CD E, does A E? Let us compute {A} + {A} + = {A, B, C} Therefore A E is false Decomposing Relations s1 s2 Prof sname pnumber p1 Greg p2 FDs: pnumber Professor s1 s2 sname Greg pnumber p1 p2 pnumber p1 p2

8 8 Decomposition: Lossless Join Property Generating spurious tuples Professor sname pnumber S1 p1 S2 Greg p2 Prof sname pnumber s1 p1 s1 p2 s2 Greg p1 s2 Greg p2 Normalization Step Consider relation R with set of attributes A R. Consider a FD A B (such that no other attribute in (A R A B) is functionally determined by A). If A is not a superkey for R, we may decompose R as: Create R (A R B) Create R with attributes A B Key for R = A

9 9 Normal Forms: BCNF Boyce Codd Normal Form (BCNF): For every non-trivial FD X a in R, X is a superkey of R. BCNF example SCI (student, course, instructor) FDs: student, course instructor instructor course Decomposition: SI (student, instructor) Instructor (instructor, course)

10 10 Dependency Preservation We might want to ensure that all specified FDs are captured. BCNF does not necessarily preserve FDs. 2NF, 3NF preserve FDs. SI Instructor student instructor instructor course DB 1 ER ER DB 1 SCI (from SI and Instructor) student instructor ER course DB 1 DB 1 SCI violates the FD student, course instructor Normal Forms: 3NF Third Normal Form (3NF): For every nontrivial FD X a in R, either a is a prime attribute or X is a superkey of R.

11 11 3NF - example Lot (propno, county, lotnum, area, price, taxrate) Candidate key: <county, lotnum> FDs: county taxrate area price Decomposition: Lot (propno, county, lotnum, area, price) County (county, taxrate) 3NF - example Lot (propno, county, lotnum, area, price) County (county, taxrate) Candidate key for Lot: <county, lotnum> FDs: county taxrate area price Decomposition: Lot (propno, county, lotnum, area) County (county, taxrate) Area (area, price)

12 12 Extreme Example Consider relation R (A, B, C, D) with primary key (A, B, C), and FDs B D, and C D. R violates 3NF. Decomposing it, we get 3 relations as: R1 (A, B, C), R2 (B, D), R3 (C, D) Let us consider an instance where we need these 3 relations and how we do a natural join A a1 a2 a3 R1 B b1 b2 b1 C c1 c1 c2 R2 B D b1 d1 b2 d2 R3 C D R1 R2: violates C D A B C D a1 b1 c1 d1 a2 b2 c1 d2 a3 b1 c2 d1 R1 R2 R3: no FD is violated c1 d1 A B C D c2 d2 a1 b1 c1 d1 Define Foreign Keys? Consider the normalization step: A relation R with set of attributes A R, and a FD A B, and A is not a key for R, we decompose R as: Create R (A R B) Create R with attributes A B Key for R = A We can also define foreign key R (A) references R (A) Question: What is key for R?

13 13 How does Normalization Help? ssn name lot did dname Employee (ssn, name, lot, dept) Dept (did, dname) FK: Employee (dept) REFERENCES Dept (did) Employee Works (1, 1) For (0, *) Dept Suppose: employees of a dept are in the same lot FD: dept lot ssn name Employee did (1, 1) Works For (0, *) lot dname Dept Decomposing: Employee (ssn, name, dept) Dept (did, dname) DeptLot (dept, lot) (or) Employee (ssn, name, dept) Dept (did, dname, lot)