1. Chapter 6 Relational Database Design 6.1 Pitfalls in Relational-Database DesignPitfalls in Relational-Database Design 6.2 DecompositionDecomposition 6.3 Normalization Using Functional DependenceNormalization Using Functional Dependence 6.4 BCNF decompositionBCNF decomposition 6.5 3NF decomposition3NF decomposition 6.6 Fourth Normal FormFourth Normal Form 6.7 ExerciseExercise

2. Chapter 6 Relational Database Design In general, the goal of a relational-database design is to generate a set of relation schemas that allows us to store information without unnecessary redundancy, yet also allows us to retrieve information easily. One approach is to design schemas that are in an appropriate normal form.

3. 6.1 Pitfalls in Relational-Database Design Among the undesirable properties that a bad design may have are. ① Repetition of information ② Inability to represent certain information Example: The information concerning loans is now kept in one single relation, lending, which is defined over the relation schema. Lending-schema=(branch-name, branch-city, assets, customer-name, loan-number, amount)

4. 6.1 Pitfalls in Relational-Database Design branch- name branch-cityassetscustomer -name loan- number amount DowntownBrooklyn9000000JonesL-171000 RedwoodPalo Alto2100000SmithL-232000 PerryridgeHorseneck1700000HayesL-151500 DowntownBrooklyn9000000JacksonL-141500 MianusHorseneck400000JonesL-93500 Round HillHorseneck8000000TurnerL-11900 Lending Figure A

5. 6.1 Pitfalls in Relational-Database Design Problems: ① add a new loan The loan is made by the Perryridge branch to Adams in the amount of $1500. Let the loan-number be L-31. We add the tuple (Perryridge, Horseneck, 1700000,Adams, L-31, 1500) ⅰ Repeating information wastes space. ⅱ Repeating information complicates updating the database.

6. 6.1 Pitfalls in Relational-Database Design ② we cannot represent directly the information concerning a branch.(branch-name, branch-city,assets) unless there exists at least one loan at the branch. The problem is that tuples in the lending relation require values for loan-number, amount and customer-name. Solution: introduce null values to handle updates through views.(difficult)

7. 6.2 Decomposition A bad design suggests that we should decompose a relation schema that has many attributes into several schemas with fever attributes. Careless decomposition, however, many lead to another form of bad design.

8. 6.2 Decomposition Example: Consider an alternative design in which Lending-schema is decomposed into the following two schemas: Branch-customer-schema=(branch-name, branch-city, assets,customer-name) Customer-loan-schema=(customer-name,loan-number, amount)

9. 6.2 Decomposition branch- name branch-cityassetscustomer -name DowntownBrooklyn9000000Jones RedwoodPalo Alto2100000Smith PerryridgeHorseneck1700000Hayes DowntownBrooklyn9000000Jackson MianusHorseneck400000Jones Round HillHorseneck8000000Turner customer -name loan- number amount JonesL-171000 SmithL-232000 HayesL-151500 JacksonL-141500 JonesL-93500 TurnerL-11900 Branch-customer BCustomer-loan C

10. 6.2 Decomposition Suppose that we wish to find all branches that have loans with amount less than $1000. We should write. branch- name branch-cityassetscustomer -name loan- number amount DowntownBrooklyn9000000JonesL-171000 DowntownBrooklyn9000000JonesL-93500 RedwoodPalo Alto2100000SmithL-232000 PerryridgeHorseneck1700000HayesL-151500 DowntownBrooklyn9000000JacksonL-141500 MianusHorseneck400000JonesL-171000 MianusHorseneck400000JonesL-93500 Round HillHorseneck8000000TurnerL-11900 Figure D

11. 6.2 Decomposition Problems: Additional tuples: (Downtown, Brooklyn, 9000000,Jones, L-93, 500) (Mianus, Horsereck, 400000,Jones, L-17, 1000) Consider the query, “Find all branches that have made a loan in an amount less than $1000”. Figure A Mianus Round Hill Figure D Mianus Round Hill Downtown ∏ branch-name (  amount<1000 (branch-customer customer-loan))

12. 6.2 Decomposition Loss information: If a customer happens to have several loans from different branches, we cannot tell which loan belongs to which branch. Although we have more tuples in branch-customer customer-loan, we actually have less information. We are no longer able, in general, to represent in the database information about which customers are borrowers form which branch.

13. 6.2 Decomposition Lossy decomposition: Because of this loss of information, we call the decomposition of Lending- schema into Branch-customer-schema and customer- loan-schema a lossy decomposition, or a lossy-join decomposition.

14. 6.2 Decomposition Lossless-join decomposition: A decomposition that is not a lossy-join decomposition is a lossless-join decomposition. Let C represent a set of constrains on the database. A decomposition {R 1,R 2 ……R n } of a relation schema R is a lossless-join decomposition for R if for all relation r on schema R that are legal under C. r=∏ R 1 (r) ∏ R 2 (r) …… ∏ R n (r)

15. 6.3 Normalization Using Functional Dependence Lossless-join Decomposition: We must first present a criterion for determining whether a decomposition is lossy. Let R be a relation schema, and let F be a set of functional dependencies on R. This decomposition is a lossless-join decomposition of R if at least one of the following functional dependencies are in F +. ① R 1 ∩R 2 →R 1 ② R 1 ∩R 2 →R 2

16. 6.3 Normalization Using Functional Dependence Example: We now show that our decomposition of Lending-schema is a lossless-join decomposition by showing a sequence of steps that generate the decomposition ① Branch-schema=(branch-name,branch-city, assets) Loan-info-schema=(branch-name,customer- name,loan-number, amount) branch-name→{branch-name,branch-city,assets} Branch-schema∩Loan-info-schema={branch-name}

17. 6.3 Normalization Using Functional Dependence ② Loan-info-schema Loan-schema=(branch-name, loan-number, amount) Borrower-schema=(customer-name, loan-number) This step results is a lossless-join decomposition. loan-number→{loan-number,branch-name,amount} Loan-schema∩Borrower-schema={loan-number}

18. 6.3 Normalization Using Functional Dependence Example: Suppose that we decompose the schema R=(A,B,C,D,E,F) into R 1 ={CF,BE,ECD,AB}; R 2 ={ABE,CDEF}. Determine which decomposition is a lossless-join decomposition if the following set F of functional dependencies holds. {ABE }∩{ CDEF}= {E} E→A A→B E→B F={A→B,C→F,E→A,CE→D} E→A E→B E→AB E→ABE R 2 is a lossless-join decomposition

19. 6.3 Normalization Using Functional Dependence F={A→B,C→F,E→A,CE→D} ABCDEF CFb 11 b 12 a3a3 b 14 b 15 a6a6 BEb 21 a2a2 b 23 b 24 a5a5 b 26 ECDb 31 b 32 a3a3 a4a4 a5a5 b 36 ABa1a1 a2a2 b 43 b 44 b 45 b 46 b 21 a6a6 a2a2 Another Algorithm: Lossy-join decomposition

20. 6.3 Normalization Using Functional Dependence ABCDEF ABEa1a1 a2a2 b 13 b 14 a5a5 b 16 CDEFb 21 b 22 a3a3 a4a4 a5a5 a6a6 a1a1 a2a2 Lossless-join decomposition F={A→B,C→F,E→A,CE→D}

21. 6.3 Normalization Using Functional Dependence Dependency Preservation: There is another goal in relational-database design: dependency preservation. Let F be a set of functional dependencies on a schema R, and let R 1,R 2 ……R n be a decomposition of R. The restriction of F to R i is the set F i of all functional dependencies in F + that include only attributes of R i.

22. 6.3 Normalization Using Functional Dependence Let F ’ =F 1 ∪ F 2 ∪ …… ∪ F n. F ’ is a set of functional dependencies on schema R. if F ’+ = F + is true, then every dependency in F is logically implied by F’, and, if we verify that F ’ is satisfied, we have verified that F is satisfied. We say that a decomposition having the property F ’+ = F + is a dependency-preserving decomposition.

23. 6.3 Normalization Using Functional Dependence Normal Form: The process of further normalization—here in after abbreviated to just normalization—is built around the concept of normal forms. A relvar is said to be in a particular normal form if it satisfies a certain prescribed set of conditions.

24. 6.3 Normalization Using Functional Dependence ① First normal form: A relvar is in 1NF if and only if, in every legal value of that relvar, every tuple contains exactly one value for each attribute. Customer- name Customer- city Customer- street JonesBrooklynRay HayesPalo AltoHeroes Customer- name Customer- city Customer -street Jones Hayes Brooklyn Palo Alto Ray Heroes City

25. 6.3 Normalization Using Functional Dependence ② Second normal form (definition assuming only one candidate key, which we assume is the primary key): A relvar is in 2NF if and only if it is in 1NF and every nonkey attribute is irreducibly dependent on the primary key. Example: Relation R=(BNO,Title, Author, Price,Lo-No, Card, Name, Dept,Date) F={BNO→Title, Author, Price, Lo-No Card →Name, Dept BNO,Card →Date}

26. 6.3 Normalization Using Functional Dependence Candidate key {BNO,Card} {BNO,Card} →Title BNO →Title ∈ F So, it not in 2NF BNOTitleCard 1AW 2BW 3CW Redundancy

27. 6.3 Normalization Using Functional Dependence ③ Third normal form(definition assuming only one candidate key, which we further assume is the primary key): A relvar is in 3NF if and only if it is in 2NF and every nonkey attribute is nontransitively dependent on the primary key. Note: “ No transitive dependences ” implies no mutual dependencies.

28. 6.3 Normalization Using Functional Dependence Example: Relvar student=(SNO, SNAME, SAGE,MASTER,CLASS, SEX) F={SNO→SNAME, SNO →SAGE, SNO →SEX,SNO →CLASS,CLASS →MASTER} Candidate key {SNO} SNO →CLASS CLASS →MASTER MASTER transitively dependent on SNO.

29. 6.3 Normalization Using Functional Dependence ④ Boyce/codd normal form(BCNF): A relvar is in BCNF if and only if every nontrivial, left-irreducible FD has a candidate key as its determinant. A relation schema R is in BCNF with respect to a set F of functional dependencies if for all functional dependencies in F + of the form  → , where  R and  R, at least one of the following holds: ⅰ  →  is a trivial functional dependency (that is   ) ⅱ  is a superkey for schema R

30. 6.3 Normalization Using Functional Dependence Examples: ① customer-schema=(customer-name,customer- street, customer-city) ② branch-schema=(branch-name,assets,branch-city) customer-name→{customer-street,customer-city} branch-name→ {assets,branch-city} customer-name is a candidate key customer-schema is in BCNF branch-schema is a candidate key branch-schema is in BCNF

31. 6.3 Normalization Using Functional Dependence ③ loan-info-schema=(branch-name, customer- name,loan-number, amount) loan-number→{amount,branch-name} loan-number is not a candidate key loan-number → {amount,branch-name} is not a trivial dependency. loan-info-schema is not in BCNF (Downtown,John Bell,L-44,1000) (Downtown,Jane Bell,L-44,1000)

32. 6.4 BCNF decomposition loan-info-schema=(branch-name, customer- name,loan-number, amount) loan-info-schema is not in BCNF. Redundancy exist, so we should decompose it. loan-schema=(loan-number, branch-name, amount) borrower-schema=(customer-name,loan-number) loan-number→{amount,branch-name} loan-number is a candidate key of loan-schema loan-schema and borrower-schema are both in BCNF

33. 6.4 BCNF decomposition If R is not in BCNF, we can decompose R into a collection of BCNF schemas R 1,R 2 ……R n. Which not only a BCNF decomposition, but also a lossless-join decomposition.

34. 6.4 BCNF decomposition Algorithm: result:={R}; done:=false; compute F + ; while (not done) do if (there is a schema R i in result that is not in BCNF) then begin let    be a nontrivial functional dependency that holds on R i such that   R i is not in F +,and  ∩  =  ; result:=(result-R i ) ∪ (R i -  ) ∪ ( ,  ); end else done:=true;

35. 6.4 BCNF decomposition Example: Lending-schema={branch-name,branch-city, assets,customer- name,loan-number,amount} A candidate key for this schema is: branch-name is not a superkey. Thus,Lending-schema is not in BCNF, so decompose it. BCNF decomposition : {loan-number,customer-name} branch-name→{branch-city,assets} loan-number→{amount,branch-name} F =F =

36. 6.4 BCNF decomposition R 1 =branch-name ∪ {branch-city assets} branch-name→{branch-city,assets} {branch-name,branch-city, assets,customer- name,loan-number,amount}  {branch-name} + ① branch-name→ {branch-name,branch-city, assets,customer-name,loan-number,amount} is not in F + ② branch-name∩{branch-city,assets}=  R 2 ={branch-name,branch-city, assets,customer- name,loan-number,amount}-{branch-city,assets}

37. 6.4 BCNF decomposition Branch-schema={branch-name,branch-city, assets} Loan-info-schema={branch-name,customer-name,loan- number,amount} branch-name is a key for Branch-schema, Thus,Branch-schema is in BCNF. loan-number is not a key for Loan-info-schema. Thus,Loan-info-schema is not in BCNF loan-number→{amount,branch-name} F’ = Decompose Loan-info-schema

38. 6.4 BCNF decomposition R 2 = loan-number ∪ {amount,branch-name} loan-number→{amount,branch-name} {branch-name,customer-name,loan- number,amount}  {loan-number} + ① branch-name→{branch-name,customer-name,loan- number,amount} is not in F’ + ② loan-number∩{amount,branch-name}=  R 3 = {branch-name,customer-name,loan- number,amount}-{amount,branch-name}

39. 6.4 BCNF decomposition Loan-schema={branch-name,loan-number,amount} Borrower-schema={customer-name,loan-number} Branch-schema and Borrower-schema are in BCNF. Branch-schema={branch-name,branch-city, assets} Loan-schema={branch-name,loan-number,amount} Borrower-schema={customer-name,loan-number} Lending-schema=(branch-name,branch-city, assets,customer-name,loan-number,amount)

40. 6.4 BCNF decomposition Algorithm: Input: a schema R and R satisfied the FDs F. Output: R is a lossless-join decomposition which satisfies the FDs F and for each subschemas R i is a BCNF decomposition which satisfies F i =∏ R i (F)

41. 6.4 BCNF decomposition ① initialize the result closure  to {R},  ={R} ② if all subschemas in  are BCNF then turn to ④. Let us find a subschemas S in  that is not in BCNF. According to the definition of BCNF, there must has a FD X→A and A-X= , X do not include any candidate key of S, S-X-A≠ . ③ Let S={S 1,S 2 }, S 1 is XA, S 2 is S-A ∪ (A∩X), replace the S with {S 1,S 2 } turn to ② ④ Stop decomposing and output 

42. 6.4 BCNF decomposition Compute candidate key: If x + =u and y + is a proper subset of x + ( y + ≠u). then the attributes in R can be classified into four groups: L: the attributes appear only on the left-hand side of FD R: the attributes appear only on the right-hand side of FD LR: the attributes appear both on the left-hand side and left-hand side of FD N: the attributes do not appear on the FD

43. 6.4 BCNF decomposition ③ L+N unknown: ② the classification of (L+N) must appear in candidate key ① the classification of R are not candidate key ⅰ L+N =x1 x1 + =u then have only one candidate key ⅱ L+N =x1 x1 + ≠u find an attribute in R and add it to the x1.repeat!

44. 6.4 BCNF decomposition Example: Relvar R=(O,I,S,Q,B,D) satisfies the following FDs. F={S→D, I →B, IS →Q, B →O} Give a lossless-join decomposition into BCNF of the schema R L: S, I R: D, Q, O LR: B (SI) + =SIDBQO=U have only one candidate key. S→D IS  S not in BCNF S→D D-S≠  S do not include IS Decompose: R 1 =SD R 2 =OISQB

45. 6.4 BCNF decomposition F R 2 ={I→B, IS →Q, B →O} L: S, I R: Q, O LR: B (SI) + =SIBOQ=U have only one candidate key. I→B IS  I B-I≠  not in BCNF Decompose: R 21 =IB R 22 =OISQ F R 21 ={I→B} F R 22 ={IS →Q}  =(R 1, R 21, R 22 )

46. 6.4 BCNF decomposition Example: Relvar R=(A,B,C,D) satisfies the following FDs. F={A→D, C→D, D →B} Give a lossless-join decomposition into BCNF of the schema R L: A,C R: B LR: D (AC) + =ACDB=U have only one candidate key. Decompose: R 1 =AD R 2 =ACB F R2 ={C→B, A →B} ……

47. 6.4 BCNF decomposition Not every BCNF decomposition is dependency preserving. Example: Banker-schema={branch-name,customer-name,banker-name} banker-name→{branch-name} {branch-name,customer-name}→banker-name F =F = banker-name is not a key for Banker-schema. Thus, Banker-schema is not in BCNF. Decompose it.

48. 6.4 BCNF decomposition Banker-branch-schema={banker-name,branch-name} Customer-banker-schema={customer-name,banker-name} F 1 ={banker-name→branch-name} F 2 =  {branch-name,customer-name}→banker-name in F + {branch-name,customer-name}→banker-name not in {F 1 ∪ F 2 } + {F 1 ∪ F 2 } + <>F + and the decomposition is not dependency preserving

49. 6.4 BCNF decomposition This example demonstrates that not every BCNF decomposition is dependency preserving. Moreover, it demonstrates that we cannot always satisfy all three design goals: ③ Dependency preservation ② Lossless join ① BCNF

50. 6.5 3NF decomposition A relation schema R is in 3NF with respect to a set F of functional dependencies if, for all functional dependencies in F + of the form  → , where  R and  R, at least one of the following holds: ①  →  is a trivial functional dependency (that is   ) ②  is a superkey for schema R ③ each attribute A in  -  is contained in a candidate key for R.

51. 6.5 3NF decomposition Banker-schema={branch-name,customer-name,banker-name} banker-name→ {branch-name} {branch-name,customer-name}→banker-name F =F = banker-name is not a key for Banker-schema. Thus, Banker-schema is not in BCNF. Example: {branch-name,customer-name} is a candidate key for Banker-schema. Banker-schema is in 3NF.

52. 6.5 3NF decomposition If R is not in 3NF, we can decompose R into a collection of 3NF schemas R 1,R 2 ……R n, which is not only a lossless-join decomposition, but also a dependency-preserving decomposition.

53. 6.5 3NF decomposition Algorithm: let F c be a canonical cover for F’; i:=0; for each functional dependency    in F c do if none of the schemas R j, j=1,2……,i contains   then begin i:=i+1; R i :=   ; end If none of the schemas R j, j=1,2……,i contains a candidate key for R then begin i:=i+1; R i := any candidate key for R ; end Return(R 1,R 2,……,R i )

54. 6.5 3NF decomposition Example: Relvar R=(O,I,S,Q,B,D) satisfies the following FDs. F={S→D, I→B, IS →Q, B →O} Give a lossless-join, dependency-preserving decomposition into 3NF of the schema R. F=F C  ={SD,IB,ISQ,BO} L: S,I R: D,Q,O LR: B (IS) + =ISDBQO=U have only one candidate key.

55. 6.5 3NF decomposition Example: Banker-info-schema={branch-name,customer-name,banker- name,office-number} Banker-name→{branch-name,office-number} {customer-name,branch-name}→banker-name R 1 = banker-name ∪ {branch-name,office-number} R 2 = {customer-name,branch-name} ∪ banker-name 3NF decomposition:

56. 6.5 3NF decomposition Banker-office-schema={banker-name,branch-name,office-number} Banker-schema={customer-name,branch-name,banker-name} banker-schema contains a candidate key for banker-info-schema Banker-info-schema={branch-name,customer-name,banker- name,office-number} Banker-office-schema={banker-name,branch-name,office-number} Banker-schema={customer-name,branch-name,banker-name}

57. 6.5 comparison of BCNF and 3NF Advantage of 3NF: It is always possible to obtain a 3NF design without sacrificing a lossless join or dependency preservation. If we do not eliminate all transitive dependencies, we may have to use null values to represent some of the possible meaningful relationships among data items, and there is the problem of repetition of information. Disadvantage of 3NF: If a schema is in 3NF but not in BCNF,then redundancy will occur.

58. 6.6 Fourth Normal Form Consider banking example: BC-schema={loan-number,customer-name,customer- street,customer-city} customer-name→{customer-street,customer-city} customer-name is not a key for BC-schema, so BC- schema is not a BCNF schema. Remove this functional dependency, BC-schema is a BCNF schema. But repetition of information are still exist.

59. 6.6 Fourth Normal Form Solution: multivalued dependencies As we did for functional dependencies, we shall use multivalued dependencies to define a normal form for relation schemas. This normal form, called fourth normal form(4NF), is more restrictive than BCNF. 4NF schema is in BCNF, BCNF schema is not in 4NF

60. 6.6.1 Multivalued Dependencies Functional dependencies rule out certain tuples from being in a relation. If A→B, then we cannot have two tuples with the same A value but different B values. Multivalued dependencies do not rule out the existence of certain tuples. Instead, they require that other tuples of a certain form be present in the relation. For this, functional dependencies sometimes are referred to as equality-generating dependencies, and multivalued dependencies are referred to as tuple-generating dependencies.

61. 6.6.1 Multivalued Dependencies Definition: Let R be a relation schema and let  R and  R. then multivalued dependency  →→  holds on R if, in any legal relation r( R ), for all pairs of tuples t 1 and t 2 in r such that t 1 [  ]=t 2 [  ], there exist tuples t 3 and t 4 in r such that t 1 [  ]=t 2 [  ]=t 3 [  ]=t 4 [  ] t 3 [  ]=t 1 [  ] t 3 [R-  -  ]=t 2 [R-  -  ] t 4 [  ]=t 2 [  ] t 4 [R-  -  ]=t 1 [R-  -  ]

62. 6.6.1 Multivalued Dependencies Intuitively, the multivalued dependency  →→  says that the relationship between  and  is independent of the relationship between  and R- . If the multivalued dependency  →→  is satisfied by all relations on schema R, then  →→  is a trivial multivalued dependency on schema R. thus,  →→  is trivial if   or  ∪  =R.   R-  -  t 1  1…  I  i+1…  j  j+1…  n t 2  1…  I b i+1… b j b j+1… b n t 3  1…  I  i+1…  j b j+1… b n t 4  1…  I b i+1… b j  j+1…  n

63. 6.6.1 Multivalued Dependencies Example: Relvar R-schema={C,T,H,R,S,G} C: course name T: teacher H: time R: classroom S: student G: grade time classroom C→→HR T→→HR C T H R S G C1 T1 H1 R1 S1 G1 C1 T1 H2 R2 S1 G1 C1 T1 H1 R1 S2 G2 C1 T1 H2 R2 S2 G2

64. 6.6.2 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. 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. The following list of inference rules for functional and multivalued dependencies is sound and complete.

65. 6.6.2 Theory of Multivalued Dependencies 3) Transitivity rule: if    holds and    holds, then    holds. 4) Complementation: if    holds, then   R-  -  holds. 5) Multivalued augmentation rule: if    holds and   R and    then    holds. 6) Multivalued Transitivity rule: if    holds and    then    -  holds. 7) Replication rule: if    holds then    holds.

66. 6.6.2 Theory of Multivalued Dependencies 8) Coalescence rule: if    holds and  , and there is a  such that  R, and  ∩  = , and    then    holds. Multivalued union rule: if    holds and    then    holds. Intersection rule: if    holds and    then    ∩  holds. Difference rule: if    holds and    then    -  holds and    -  holds.

67. 6.6.2 Theory of Multivalued Dependencies Example: Let R={A,B,C,G,H,I} with the following set of dependencies D given: A  B B  HI CG  H R+R+ A  HI : A  B B  HI A  HI-B (HI) A  HI (multivalued transitivity rule) A  CGHI : A  B A  R-B-A (CGHI) A  CGHI (complementation rule)

68. 6.6.2 Theory of Multivalued Dependencies B  H : B  HI H  HI and CG∩HI=  B  H B  H (coalescence rule) A  CG : A  BCGHI A  HI A  CGHI-HI (CG) A  CG (difference rule)

69. 6.6.3 Fourth Normal Form Definition: A relation schema R is in 4NF with respect to a set D of functional and multivalued dependencies if, for all multivalued dependencies in D + of the form   , where  R and  R, at least one of the following holds    is a trivial multivalued dependency  is a superkey for schema R a database design is in 4NF if each member of the set of relation schemas that constitutes the design is in 4NF

70. 6.6.3 4NF decomposition Algorithm: result:={R}; done:=false; compute D + ; while (not done) do if (there is a schema R i in result that is not in 4NF) then begin let    be a nontrivial functional dependency that result:=(result-R i ) ∪ (R i -  ) ∪ ( ,  ); end else done:=true; holds on R i such that   R i is not in D + and  ∩  =  ;

71. 6.6.3 4NF decomposition Example: customer-name  loan-number BC-schema={loan-number,customer-name,customer- street,customer-city} customer-name is not a superkey for BC-schema customer-name  {loan-number,customer- name,customer-street,customer-city} not exist in D + customer-name∩loan-number= 

72. 6.6.3 4NF decomposition R 2 ={loan-number,customer-name,customer- street,customer-city}- loan-number Customer-schema={customer-name,customer- street,customer-city} Borrower-schema={customer-name,loan-number} R 1 =customer-name ∪ loan-number

73. 6.6.3 4NF decomposition This algorithm generates only lossless-join decompositions: let R be a relation schema, and let D be a set of functional and multivalued dependencies of R. Let R 1 and R 2 form a decomposition of R. This decomposition is a lossless-join decomposition of R if and only if at least one of the following multivalued dependencies is in D +: R 1 ∩R 2  R 1 R 1 ∩R 2  R 2

74. 6.6.3 4NF decomposition consider a set of D of both functional and multivalued dependencies. The restriction of D to R i is the set D i, consisting of All functional dependencies in D + that include only attributes of R i. All multivalued dependencies of the form    ∩R i Where  R i and    is in D +

75. 6.6.3 4NF decomposition If we are given a set of multivalued and functional dependencies, it is advantageous to find a database design that meets the three criteria of ③ Dependency preservation ② Lossless join ① 4NF (all we have are functional dependencies, BCNF) The 4NF decomposition can not ensure dependency preservation. When we can not achieve our three goals, we compromise on 4NF,and accept BCNF or even 3NF, if necessary, to ensure dependency preservation.

76. Exercise: ① Suppose that we decompose the schema R=(U,V,W,X,Y,Z) into  1 ={WZ,VY,WXY,UVY};  2 ={UVY,WXYZ} determine which decomposition is a lossless-join decomposition if the following set F of functional dependencies holds F={U→V, W →Z, Y →U, WY →X} ② Suppose that we decompose the schema  ={R 1 (A 1 A 4 ), R 2 (A 1 A 2 ), R 3 (A 2 A 3 ), R 4 (A 3 A 4 A 5 ),R 5 (A 1 A 5 )} determine whether this decomposition is a lossless-join decomposition. If the following set F of functional dependencies holds F={A 1 →A 3, A 3 →A 4, A 2 →A 3, A 4 A 5 →A 3, A 3 A 5 →A 1 }

77. Exercise: ③ Relvar R=(A,B,C,D,E) satisfies the following FDs: F={A→C,C →D,B →C,DE →C,CE →A} ⅰ Find an irreducible equivalent for this set of FDs ⅱ Find all candidate keys of the schema R. ⅲ Determine whether the decomposition  ={AD,AB,BC,CDE,AE} is a lossless-join decomposition or not. ⅳ Give a lossless-join decomposition into BCNF of the schema R. ⅴ Give a lossless-join, dependency-preserving decomposition into 3NF of the schema R.