Chapter 6 Relational Database Design 6.1 Pitfalls in Relational-Database DesignPitfalls in...

77
Chapter 6 Relational Database Design 6.1 Pitfalls in Relational-Database Design 6.2 Decomposition 6.3 Normalization Using Functional Dependence 6.4 BCNF decomposition 6.5 3NF decomposition 6.6 Fourth Normal Form 6.7 Exercise

Transcript of Chapter 6 Relational Database Design 6.1 Pitfalls in Relational-Database DesignPitfalls in...

  • Chapter 6 Relational Database Design6.1 Pitfalls in Relational-Database Design6.2 Decomposition6.3 Normalization Using Functional Dependence6.4 BCNF decomposition6.5 3NF decomposition6.6 Fourth Normal Form6.7 Exercise

  • 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.

  • 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 informationExample: 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)

  • 6.1 Pitfalls in Relational-Database DesignLending Figure A

    branch-namebranch-cityassetscustomer-nameloan-numberamountDowntownBrooklyn9000000JonesL-171000RedwoodPalo Alto2100000SmithL-232000PerryridgeHorseneck1700000HayesL-151500DowntownBrooklyn9000000JacksonL-141500MianusHorseneck400000JonesL-93500Round HillHorseneck8000000TurnerL-11900

  • 6.1 Pitfalls in Relational-Database DesignProblems: 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.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)

  • 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.

  • 6.2 DecompositionExample: 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)

  • 6.2 DecompositionBranch-customer BCustomer-loan C

    branch-namebranch-cityassetscustomer-nameDowntownBrooklyn9000000JonesRedwoodPalo Alto2100000SmithPerryridgeHorseneck1700000HayesDowntownBrooklyn9000000JacksonMianusHorseneck400000JonesRound HillHorseneck8000000Turner

    customer-nameloan-numberamountJonesL-171000SmithL-232000HayesL-151500JacksonL-141500JonesL-93500TurnerL-11900

  • 6.2 Decomposition Suppose that we wish to find all branches that have loans with amount less than $1000. We should write. Figure D

    branch-namebranch-cityassetscustomer-nameloan-numberamountDowntownBrooklyn9000000JonesL-171000DowntownBrooklyn9000000JonesL-93500RedwoodPalo Alto2100000SmithL-232000PerryridgeHorseneck1700000HayesL-151500DowntownBrooklyn9000000JacksonL-141500MianusHorseneck400000JonesL-171000MianusHorseneck400000JonesL-93500Round HillHorseneck8000000TurnerL-11900

  • 6.2 DecompositionProblems: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 HillFigure D Mianus Round Hill Downtown

  • 6.2 Decomposition

  • 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.

  • 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 {R1,R2Rn} 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.

  • 6.3 Normalization Using Functional DependenceLossless-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+. R1R2R1 R1R2R2

  • 6.3 Normalization Using Functional DependenceExample: 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-schemaLoan-info-schema={branch-name}

  • 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-schemaBorrower-schema={loan-number}

  • 6.3 Normalization Using Functional DependenceF={AB,CF,EA,CED}Example: Suppose that we decompose the schema R=(A,B,C,D,E,F) into R1={CF,BE,ECD,AB}; R2={ABE,CDEF}. Determine which decomposition is a lossless-join decomposition if the following set F of functional dependencies holds. {ABE }{ CDEF}= {E}EA AB EBEA EB EAB EABE R2 is a lossless-join decomposition

  • 6.3 Normalization Using Functional DependenceF={AB,CF,EA,CED}b21a6a2Another Algorithm:Lossy-join decomposition

    ABCDEFCFb11b12a3b14 b15a6BEb21a2b23b24a5b26ECDb31b32a3a4a5b36ABa1a2b43b44b45b46

  • 6.3 Normalization Using Functional DependenceF={AB,CF,EA,CED}a1a2Lossless-join decomposition

    ABCDEFABEa1a2b13b14a5b16CDEFb21b22a3a4a5a6

  • 6.3 Normalization Using Functional DependenceDependency 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 R1,R2Rn be a decomposition of R. The restriction of F to Ri is the set Fi of all functional dependencies in F+ that include only attributes of Ri.

  • 6.3 Normalization Using Functional Dependence Let F=F1 F2 Fn. 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.

  • 6.3 Normalization Using Functional DependenceNormal Form: The process of further normalizationhere in after abbreviated to just normalizationis 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.

  • 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-nameCustomer-cityCustomer-streetJones BrooklynRayHayesPalo AltoHeroes

  • 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={BNOTitle, Author, Price, Lo-NoCard Name, DeptBNO,Card Date}

  • 6.3 Normalization Using Functional DependenceCandidate key {BNO,Card}{BNO,Card} TitleBNO TitleFSo, it not in 2NF Redundancy

    BNOTitleCard1AW2BW3CW

  • 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.

  • 6.3 Normalization Using Functional DependenceExample:Relvar student=(SNO, SNAME, SAGE,MASTER,CLASS, SEX)F={SNOSNAME, SNO SAGE, SNO SEX,SNO CLASS,CLASS MASTER}Candidate key {SNO}MASTER transitively dependent on SNO.

  • 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

  • 6.3 Normalization Using Functional DependenceExamples: 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 keycustomer-schema is in BCNFbranch-schema is a candidate keybranch-schema is in BCNF

  • 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 keyloan-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)

  • 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-schemaloan-schema and borrower-schema are both in BCNF

  • 6.4 BCNF decomposition If R is not in BCNF, we can decompose R into a collection of BCNF schemas R1,R2Rn. Which not only a BCNF decomposition, but also a lossless-join decomposition.

  • 6.4 BCNF decompositionAlgorithm:result:={R};done:=false;compute F+;while (not done) doif (there is a schema Ri in result that is not in BCNF)then beginlet be a nontrivial functional dependency thatholds on Ri such that Ri is not in F+ ,and = ;

    result:=(result-Ri) (Ri- ) ( ,);endelse done:=true;

  • 6.4 BCNF decompositionExample: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}

  • 6.4 BCNF decompositionR1=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}= R2={branch-name,branch-city, assets,customer-name,loan-number,amount}-{branch-city,assets}

  • 6.4 BCNF decompositionBranch-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 BCNFDecompose Loan-info-schema

  • 6.4 BCNF decompositionR3= {branch-name,customer-name,loan-number,amount}-{amount,branch-name}R2= 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}=

  • 6.4 BCNF decompositionLoan-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)

  • 6.4 BCNF decompositionAlgorithm: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 Ri is a BCNF decomposition which satisfies Fi=Ri(F)

  • 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 XA and A-X=, X do not include any candidate key of S, S-X-A . Let S={S1,S2}, S1 is XA, S2 is S-A(AX), replace the S with {S1,S2} turn to Stop decomposing and output

  • 6.4 BCNF decompositionCompute 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 FDR: the attributes appear only on the right-hand side of FDLR: the attributes appear both on the left-hand side and left-hand side of FDN: the attributes do not appear on the FD

  • 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!

  • 6.4 BCNF decompositionExample:Relvar R=(O,I,S,Q,B,D) satisfies the following FDs.F={SD, I B, IS Q, B O} Give a lossless-join decomposition into BCNF of the schema RL: S, I R: D, Q, O LR: B(SI)+=SIDBQO=U have only one candidate key.SD ISS not in BCNFSD D-S S do not include ISDecompose: R1=SD R2=OISQB

  • 6.4 BCNF decompositionFR2={IB, IS Q, B O}L: S, I R: Q, O LR: B

    (SI)+=SIBOQ=U have only one candidate key.IB ISI B-I not in BCNFDecompose: R21=IB R22=OISQF R21={IB}F R22 ={IS Q}=(R1, R21, R22)

  • 6.4 BCNF decompositionExample:Relvar R=(A,B,C,D) satisfies the following FDs.F={AD, CD, D B}Give a lossless-join decomposition into BCNF of the schema RL: A,C R: B LR: D(AC)+=ACDB=U have only one candidate key.Decompose: R1=AD R2=ACBFR2={CB, A B}

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

  • 6.4 BCNF decompositionBanker-branch-schema={banker-name,branch-name}Customer-banker-schema={customer-name,banker-name}F1={banker-namebranch-name}F2= {branch-name,customer-name}banker-name in F+ {branch-name,customer-name}banker-name not in {F1F2}+ {F1F2}+F+ and the decomposition is not dependency preserving

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

  • 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.

  • 6.5 3NF decompositionBanker-schema={branch-name,customer-name,banker-name}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.

  • 6.5 3NF decomposition If R is not in 3NF, we can decompose R into a collection of 3NF schemas R1,R2Rn, which is not only a lossless-join decomposition, but also a dependency-preserving decomposition.

  • 6.5 3NF decompositionAlgorithm:let Fc be a canonical cover for F;i:=0;for each functional dependency in Fc doif none of the schemas Rj, j=1,2,i contains then begini:=i+1;Ri:= ;

    endIf none of the schemas Rj, j=1,2,i contains a candidate key for Rthen begini:=i+1;Ri:= any candidate key for R ;

    endReturn(R1,R2,,Ri)

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

  • 6.5 3NF decompositionExample:Banker-info-schema={branch-name,customer-name,banker-name,office-number}Banker-name{branch-name,office-number}{customer-name,branch-name}banker-nameR1= banker-name{branch-name,office-number}R2= {customer-name,branch-name}banker-name3NF decomposition:

  • 6.5 3NF decompositionBanker-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-schemaBanker-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}

  • 6.5 comparison of BCNF and 3NFAdvantage 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.

  • 6.6 Fourth Normal FormConsider 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.

  • 6.6 Fourth Normal FormSolution: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

  • 6.6.1 Multivalued Dependencies Functional dependencies rule out certain tuples from being in a relation. If AB, 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.

  • 6.6.1 Multivalued DependenciesDefinition: 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 t1 and t2 in r such that t1[]=t2[], there exist tuples t3 and t4 in r such thatt1[]=t2[]=t3[]=t4[]t3[]=t1[]t3[R--]=t2[R--]t4[]=t2[]t4[R--]=t1[R--]

  • 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.

  • 6.6.1 Multivalued DependenciesExample:Relvar R-schema={C,T,H,R,S,G}C: course name T: teacher H: time R: classroom S: student G: gradeCHRTHR

  • 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.

  • 6.6.2 Theory of Multivalued Dependencies3) 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.

  • 6.6.2 Theory of Multivalued Dependencies8) 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.

  • 6.6.2 Theory of Multivalued DependenciesExample:Let R={A,B,C,G,H,I} with the following set of dependencies D given:AB BHI CGH R+ AHI : AB BHI AHI-B (HI) AHI (multivalued transitivity rule) ACGHI : AB AR-B-A (CGHI) ACGHI (complementation rule)

  • 6.6.2 Theory of Multivalued DependenciesBH : BHI HHI and CGHI= BH BH (coalescence rule) ACG : ABCGHI AHI ACGHI-HI (CG) ACG (difference rule)

  • 6.6.3 Fourth Normal FormDefinition: 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

  • 6.6.3 4NF decompositionAlgorithm:result:={R};done:=false;compute D+;while (not done) doif (there is a schema Ri in result that is not in 4NF)then beginlet be a nontrivial functional dependency thatresult:=(result-Ri) (Ri- ) ( ,);endelse done:=true;holds on Ri such that Ri is not in D+ and = ;

  • 6.6.3 4NF decompositionExample:customer-nameloan-numberBC-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-nameloan-number=

  • 6.6.3 4NF decompositionR2={loan-number,customer-name,customer-street,customer-city}- loan-numberCustomer-schema={customer-name,customer-street,customer-city}Borrower-schema={customer-name,loan-number}R1=customer-nameloan-number

  • 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 R1 and R2 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+: R1R2 R1R1R2 R2

  • 6.6.3 4NF decomposition consider a set of D of both functional and multivalued dependencies. The restriction of D to Ri is the set Di, consisting of All functional dependencies in D+ that include only attributes of Ri. All multivalued dependencies of the form RiWhere Ri and is in D+

  • 6.6.3 4NF decomposition Dependency preservation 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 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.

  • 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={UV, W Z, Y U, WY X} Suppose that we decompose the schema ={R1(A1A4), R2(A1A2), R3(A2A3), R4(A3A4A5),R5(A1A5)} determine whether this decomposition is a lossless-join decomposition. If the following set F of functional dependencies holds F={A1A3, A3A4, A2A3, A4A5A3, A3A5A1}

  • Exercise: Relvar R=(A,B,C,D,E) satisfies the following FDs:F={AC,C D,B C,DE C,CE A}Find an irreducible equivalent for this set of FDsFind 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.