SCUJ. Holliday - coen 1784–1 Schedule Today: u Normal Forms. u Section 3.6. Next u Relational Algebra. Read chapter 5 to page 199 After that u SQL Queries. u Read Sections

SCUJ. Holliday - coen 1784–2 Normalization Goal = BCNF = Boyce-Codd Normal Form = all FD’s follow from the fact “key  everything.” Formally, R is in BCNF if for every nontrivial FD for R, if X  A, then X is a superkey. u “Nontrivial” = right-side attribute not in left side. Why? 1. Guarantees no redundancy due to FD’s. 2. Guarantees no update anomalies = one occurrence of a fact is updated, not all. 3. Guarantees no deletion anomalies = valid fact is lost when tuple is deleted.

SCUJ. Holliday - coen 1784–3 Example of Problems Drinkers(name, addr, beerLiked, manf, favoriteBeer) FD’s: 1. name  addr 2. name  favoriteBeer 3. beerLiked  manf ???’s are redundant, since we can figure them out from the FD’s. Update anomalies: If Bill transfers to UC Berkeley, will we remember to change addr in each of his tuples? Deletion anomalies: If nobody likes Bud, we lose track of Bud’s manufacturer.

SCUJ. Holliday - coen 1784–4 Each of the 3 given FD’s is a BCNF violation: Key = { name, beerLiked } u Each of the given FD’s has a left side that is a proper subset of the key. Another Example Beers(name, manf, manfAddr). FD’s: name  manf, manf  manfAddr Only key is name.  Manf  manfAddr violates BCNF with a left side not a super key.

SCUJ. Holliday - coen 1784–5 Decomposition to Reach BCNF Given: relation R, and FD’s F. If there is a non-trivial FD in F, X  B, and X is not a superkey, then R is not in BCNF. Suppose relation R has BCNF violation X  B. We can decompose R into two or more relations so that each of the relations will be in BCNF.

SCUJ. Holliday - coen 1784–6 1. Compute X +. u Cannot be all attributes – why? 2. Decompose R into X + and (R–X + )  X. 3. Find the FD’s for the decomposed relations. u Project the FD’s from F = calculate all consequents of F that involve only attributes from X + or only from (R  X + )  X. R X + X

SCUJ. Holliday - coen 1784–7 Example 1 R= (A,B,C,D) F = {A  BC, C  D} The key is A (why?) The functional dependency C  D violates BCNF (why?) Decomposition: 1. Compute X +. C + = CD 2. Decompose R: R1 = X + and R2 = (R–X + )  X. R1 = CDR2 = ABC 3. Find the FD’s for the decomposed relations. (why?)

SCUJ. Holliday - coen 1784–8 Example 2 R = Drinkers(name, addr, beerLiked,manf,favoriteBeer) F = 1.name  addr 2.name  favoriteBeer 3.beerLiked  manf Pick BCNF violation name  addr Close left side: name + = name addr favoriteBeer. Decomposed relations: Drinkers1(name, addr, favoriteBeer) Drinkers2(name, beerLiked, manf) Projected FD’s (skipping a lot of work):  For Drinkers1 : name  addr and name  favoriteBeer.  For Drinkers2 : beerLiked  manf.

SCUJ. Holliday - coen 1784–9 (Repeating) Decomposed relations: Drinkers1(name, addr, favoriteBeer) Drinkers2(name, beerLiked, manf) Projected FD’s:  For Drinkers1 : name  addr and name  favoriteBeer.  For Drinkers2 : beerLiked  manf. BCNF violations?  For Drinkers1, name is key and all left sides of FD’s are superkeys.  For Drinkers2, { name, beerLiked } is the key, and beerLiked  manf violates BCNF.

SCUJ. Holliday - coen 1784–10 Decompose Drinkers2 First set of decomposed relations: Drinkers1(name, addr, favoriteBeer) Drinkers2(name, beerLiked, manf) Close beerLiked + = beerLiked manf Decompose Drinkers2 into: Drinkers3(beersLiked, manf) Drinkers4(name, beersLiked) Resulting relations are all in BCNF: Drinkers1(name, addr, favoriteBeer) Drinkers3(beerLiked, manf) Drinkers4(name, beerLiked)

SCUJ. Holliday - coen 1784–11 Why Decompose This Way? Eliminate unnecessary redundancy (update and delete anomalies) Loss-less join decomposition (recover original information with join on equality) Dependency preserving (efficient checking of constraints)

SCUJ. Holliday - coen 1784–12 Lossless Join Decomposition If decomposition of a schema to avoid redundant info is not done carefully, we can lose information and generate extra tuples when we try to reconstruct the information from the original table. Consider the decomposition of emp-dept (ename, ssn, bdate, address, dnumber, dname, dmgrssn) into emp-mgr (ename, ssn, bdate, address, dmgrssn) dept (dnumber, dname, dmgrssn) This decomposition solves the redundant info problem. However, there can be problems joining the tables emp-mgr and dept.

SCUJ. Holliday - coen 1784–13 Lossless Join Decomposition emp-dept John /12/ th Street5CS Sue /22/ th Street 1EX Mike /25/7523 A Street3TS Bob /21/62568 Main Street1EX emp-mgr John /12/ th Street Sue /22/ th Street Mike /25/7523 A Street Bob /21/62568 Main Street dept 1EX TS CS

SCUJ. Holliday - coen 1784–14 If we try to recover the original info by doing a join of emp-mgr and dept, we get: emp-mgr join dept John /12/ th Street TS John /12/ th Street CSCS Sue /22/ th Street EX Mike /25/7523 A Street TS Mike /25/7523 A Street CSCS Bob /21/62568 Main Street EXEX There are some extra rows here!! Another way of looking at it is that we lost some information when we decomposed emp-dept into emp-mgr and dept. Why did this happen? We have the functional dependency(dnumber  dname dmgrssn), but not (dmgrssn  dnumber) and we joined on dmgrssn.

SCUJ. Holliday - coen 1784–15 Lossless Join Decomposition In a lossless join decomposition into R1 and R2, at least one of the following dependencies is in F + R1  R2  R1 or R1  R2  R2 Example: R = (A, B, C)F = { A  B, B  C} Decomposition is: R1 = (A, B) R2 = (B, C) This is a lossless join decomposition because R1  R2 = {B} and B  BC, so R1  R2  R2 What about the decomposition R1 = (A, C) R2 = (B, C) ?

SCUJ. Holliday - coen 1784–16 Dependency Preserving Decomposition This property ensures that checking updates for violation of FD’s is efficient. Dependency preservation: Let Fi be the set of dependencies in F + that includes only attributes in Ri. The decomposition is dependency preserving if (  Fi ) + = F + that is, for a 2 relation decomposition (F1  F2) + = F + Example: R = (A, B, C)F = { A  B, B  C} R1 = (A, B) R2 = (B, C)This is dependency preserving. What about the decomposition R1 = (A, C) R2 = (B, C) ?

SCUJ. Holliday - coen 1784–17 3NF One FD structure causes problems: If you decompose, you can’t check all the FD’s only in the decomposed relations. If you don’t decompose, you violate BCNF. Structure: AB  C and C  B. Example 1: title city  theatre and theatre  city. Example 2: street city  zip, zip  city. Keys: {A, B} and {A, C}, but C  B has a left side that is not a superkey. Decompose into BC and AC. u But you can’t check the FD AB  C in only these relations.

SCUJ. Holliday - coen 1784–18 “Elegant” Workaround Define the problem away. A relation R is in 3NF iff (if and only if) for every nontrivial FD X  A, either: 1. X is a superkey, or 2. A is prime = member of at least one key. Thus, the canonical problem goes away: you don’t have to decompose because all attributes are prime.

SCUJ. Holliday - coen 1784–19 What 3NF Gives You There are two important properties of a decomposition: 1.We should be able to recover from the decomposed relations the data of the original. u Recovery involves projection and join. 2.We should be able to check that the FD’s for the original relation are satisfied by checking the projections of those FD’s in the decomposed relations. You can always decompose into BCNF and satisfy (1). We can decompose into 3NF and satisfy both (1) and (2). But it is not always possible to decompose into BNCF and get both (1) and (2). u Street-city-zip is an example of this point.

SCUJ. Holliday - coen 1784–20 BCNF and 3NF BCNF: Whenever a non-trivial functional dependency X  A holds in R, then X is a superkey of R. 3NF: Whenever a non-trivial functional dependency X  A holds in R, then X is a superkey of R OR each attribute of A is a member of a candidate key (prime).

SCUJ. Holliday - coen 1784–21 Exercise Consider the schema and 2 sets of FD’s F and E: emp-dept (ename, ssn, bdate, address, dnumber, dname, dmgrssn) F ={ ssn  ename bdate address dnumber, dnumber  dname dmgrssn } E ={ ssn  ename address dnumber, ssn  dname bdate, dnumber  dname dmgrssn } Are F and E equivalent?

SCUJ. Holliday - coen 1784–22 3NF Decomposition Find the canonical form for F A canonical cover of a set of dependencies, F, has the following properties:  No functional dependency contains an extraneous attribute. That is, an attribute that can be removed from the dependency without changing the closure of F.  Each left side of a functional dependency in F is unique.

SCUJ. Holliday - coen 1784–23 3NF Decomposition Algorithm 1. Calculate the canonical cover of F 2. set j = 0 3. for each FD A  B in F c, do if none of current schemas contain AB then j = j+1 Rj = (A B) 4. if none of the schemas in the result contains a candidate key for the original R, then: j = j + 1 and Rj = (any candidate key)

SCUJ. Holliday - coen 1784–24 3NF Example Example: R = (A, B, C, D, E) F = {A  BC, C  DE, DE  A) Soln: Candidate keys are: A, C, and DE F is in canonical form. R1 = (A, B, C), R2 = (C, D, E), R3 = (A, D, E) No natural join produces spurious tuples, so the decomposition is lossless. Dependencies are preserved. All relations are in 3NF.

SCUJ. Holliday - coen 1784–25 Example - BCNF R = (b-name, b-city, assets, c-name, loan#, amount) F = {b-name  b-city assets, loan#  amount b-name} Primary key = {loan#, c-name} ** R is not in BCNF "b-name  b-city assets" is a non-trivial FD that holds on R and "b-name  R" is not in F + (that is, b-name is not a super key). Split R into R1 and R2 R1 = (b-name, b-city, assets) R2 = (b-name, c-name, loan#, amount)

SCUJ. Holliday - coen 1784–26 Continued R1 = (b-name, b-city, assets) R2 = (b-name, c-name, loan#, amount) **Now R1 is in BCNF, but R2 is not (why?) So, we split R2 into R3 and R4 R3 = (b-name, loan#, amount) R4 = (c-name, loan#) The final decomposition is R1, R3, R4

SCUJ. Holliday - coen 1784–27 Exercise 1.Find the keys. 2.How should this be decomposed? R = (A, B, C, D, E) F = {A  BC, C  DE, DE  A)

SCUJ. Holliday - coen 1784–28 Answers R = (A, B, C, D, E) F = {A  BC, C  DE, DE  A) Keys are: A, C, and DE R is already in BCNF.