 10.1 CS 728 Advanced Database Systems Chapter 11 Relational Database Design Algorithms and Further Dependencies

 11.2 Chapter Outline  0. Designing a Set of Relations  1. Properties of Relational Decompositions  2. Algorithms for Relational Database Schema  3. Multivalued Dependencies and 4 th Normal Form  4. Join Dependencies and 5 th Normal Form  5. Inclusion Dependencies  6. Other Dependencies and Normal Forms

 11.3 Designing a Set of Relations (1)  The 1 st approach is (Chapter 10) a Top-Down Design (Relational Design by Analysis):  1. Designing a conceptual schema in a high-level data model, such as the EER model  2. Mapping the conceptual schema into a set of relations using mapping procedures.  3. Each of the relations is analyzed based on the functional dependencies and assigned primary keys, by applying the normalization procedure to remove partial and transitive dependencies if any remain.

 11.4 Designing a Set of Relations (2)  The 2 nd approach is (Chapter 11) a Bottom-Up Design (Relational Design by Synthesis - التأليف ):  1. First constructs a minimal set of FDs  Assumes that all possible functional dependencies are known.  2. a normalization algorithm is applied to construct a target set of 3NF or BCNF relations.  start by one large relation schema, called the universal relation, which includes all the database attributes.  then repeatedly perform decomposition until it is no longer feasible or no longer desirable, based on the functional and other dependencies specified by the database designer.

 11.5 Designing a Set of Relations (3)  Additional criteria may be needed to ensure the set of relations in a relational database are satisfactory.  Two desirable properties of decompositions:  The dependency preservation property and  The lossless (or nonadditive) join property  Additional normal forms  4NF (based on multi-valued dependencies)  5NF (based on join dependencies)

 11.6 Designing a Set of Relations (4)  When we decompose a relation schema R with a set of functional dependencies F into R 1, R 2, …, R n we want  Dependency preservation:  Otherwise, checking updates for violation of functional dependencies may require computing joins, which is expensive.  Lossless-join decomposition:  Otherwise decomposition would result in information loss.  No redundancy:  The relations R i preferably should be in either Boyce- Codd Normal Form or 3NF.

 11.7 Designing a Set of Relations (5)  Example: R = (A, B, C)F = {A  B, B  C}  Can be decomposed in two different ways:  R 1 = (A, B), R 2 = (B, C)  Lossless-join decomposition: –R 1  R 2 = {B} and B  BC  Dependency preserving  R 1 = (A, B), R 2 = (A, C)  Lossless-join decomposition: –R 1  R 2 = {A} and A  AB  Not dependency preserving –cannot check B  C without computing R 1 R 2

 11.8 Properties of Relational Decompositions (1)  Relation Decomposition and Insufficiency of Normal Forms:  Universal Relation Schema:  a relation schema R = {A 1, A 2, …, A n } that includes all the attributes of the database.  Universal relation assumption:  every attribute name is unique.  Decomposition:  The process of decomposing the universal relation schema R into a set of relation schemas D = {R 1, R 2, …, R m } that will become the relational database schema by using the functional dependencies.

 11.9 Properties of Relational Decompositions (2)  Relation Decomposition and Insufficiency of Normal Forms:  Attribute preservation condition:  Each attribute in R will appear in at least one relation schema R i in the decomposition so that no attributes are “lost”.  Another goal of decomposition is to have each individual relation R i in the decomposition D be in BCNF or 3NF.  Additional properties of decomposition are needed to prevent from generating spurious (المزوّر) tuples.

 Properties of Relational Decompositions (3)  Example of spurious tuples.  Decomposition of R = (A, B)  R 1 = (A)R 2 = (B) AB  A  B 1212 r A(r)A(r) B(r)B(r)  A (r)  B (r) AB 

 Properties of Relational Decompositions (4)  Dependency Preservation Property of a Decomposition:  It would be useful if each functional dependency X  Y specified in F either  appeared directly in one of the relation schemas in the decomposition D or  could be inferred from the dependencies that appear in some R i.  Informally, this is the  dependency preservation condition.

 Properties of Relational Decompositions (5)  Dependency Preservation Property of a Decomposition:  We want to preserve the dependencies because each dependency in F represents a constraint on the database.  If one of the dependencies is not represented in some individual relation of the decomposition, we cannot enforce this constraint by dealing with an individual relation; instead,  we have to join two or more of the relations in the decomposition and then check that the functional dependency holds in the result of the join operation.  This is clearly an inefficient and impractical procedure.

 Properties of Relational Decompositions (6)  Dependency Preservation Property of a Decomposition:  It is not necessary that the exact dependencies specified in F appear themselves in individual relations of the decomposition D.  It is sufficient that the union of the dependencies that hold on the individual relations in D be equivalent to F.  We now define these concepts more formally.

 Properties of Relational Decompositions (7)  Dependency Preservation Property of a Decomposition:  Definition:  Given a set of dependencies F on R, the projection of F on R i, denoted by  Ri (F) where R i is a subset of R, is the set of dependencies X  Y in F + such that the attributes in X  Y are all contained in R i.  Hence, the projection of F on each relation schema R i in the decomposition D is the set of functional dependencies in F +, the closure of F, such that all their left- and right-hand-side attributes are in R i.

 Properties of Relational Decompositions (8)  Dependency Preservation Property of a Decomposition:  A decomposition D = {R 1, R 2,..., R m } of R is dependency-preserving with respect to F if the union of the projections of F on each R i in D is equivalent to F; that is,  ((  R1 (F))  …  (  Rm (F))) + = F +  (See examples in Fig and Fig 10.12a)  Claim 1: It is always possible to find a dependency-preserving decomposition D with respect to F such that each relation R i in D is in 3NF.

 Properties of Relational Decompositions (9)  Consider a decomposition of R = (R, F) into  R 1 = (R 1, F 1 ) and R 2 = (R 2, F 2 )  How to compute the projections F 1 and F 2 ?  F i is the projection of FDs in F + over R i  Example: R=ABC and F = A→B, B→C, C→A  Let R 1 =AB and R 2 =BC  Not enough to let F 1 = A→B and F 2 = B→C  Consider FDs in F + : B→A and C→B  So F 1 = A→B, B→A and F 2 = B→C, C→B  Now F and F 1  F 2 are equivalent

 Properties of Relational Decompositions (10)  Lossless (Non-additive) Join Property of a Decomposition:  This property ensures that no spurious tuples are generated when a NATURAL JOIN operation is applied to the relations in the decomposition.  Lossless join property: a decomposition D = {R 1, R 2,..., R m } of R has the lossless (nonadditive) join property with respect to the set of dependencies F on R if, for every relation state r of R that satisfies F, the following holds, where * is the natural join of all the relations in D:  * (  R1 (r),...,  Rm (r)) = r  r  r 1 * r 2 * … * r m and  r 1 * r 2 * … * r m  r

 Properties of Relational Decompositions (11)  Consider  What happens if we decompose on  (Id#, Name, Address) and  (C#, Description, Grade)?  Spurious tuples will be generated Name Jones Brown Address Phila Boston C# Phil7 Math8 Description Plato Topology Grade A C Id#

 Properties of Relational Decompositions (12)  Lossy Decomposition:  Problem: Name is not a key SSN Name Address SSN Name Name Address 1111 Joe 1 Pine 1111 Joe Joe 1 Pine 2222 Alice 2 Oak 2222 Alice Alice 2 Oak 3333 Alice 3 Pine 3333 Alice Alice 3 Pine r1r1 r2r2 r 

 Properties of Relational Decompositions (13)  Lossless (Non-additive) Join Property of a Decomposition:  Note: The word loss in lossless refers to loss of information, not to loss of tuples. In fact, for “loss of information” a better term is “addition of spurious information”.  Algorithm: Testing for Lossless Join Property Input: A universal relation R, a decomposition D = {R 1, R 2,..., R m } of R, and a set F of functional dependencies.

 Properties of Relational Decompositions (14) 1.Create an initial matrix S with one row i for each relation R i in D, and one column j for each attribute A j in R. 2.Set S(i, j) = b ij for all matrix entries. // each b ij is a symbol associated with indices (i, j) 3.For each row i representing relation schema R i For each column j representing attribute A j if (relation R i includes attribute A j ) then S(i, j) = a j // each a j is a symbol associated with index j

 Properties of Relational Decompositions (15) 4.Repeat until a complete loop execution results in no changes to S for each functional dependency X  Y in F for all rows in S which have the same symbols in the columns corresponding to attributes in X make the symbols in each column that correspond to an attribute in Y be the same in all these rows as follows: If any of the rows has an “a” symbol for the column, set the other rows to that same “a” symbol in the column.

 Properties of Relational Decompositions (16) If no “a” symbol exists for the attribute in any of the rows, choose one of the “b” symbols that appear in one of the rows for the attribute and set the other rows to that same “b” symbol in the column 5.If a row is made up entirely of “a” symbols, then the decomposition has the lossless join property; otherwise it does not.

 Properties of Relational Decompositions (17)  Lossless (non-additive) join test for n-ary decompositions.  (a) Case 1: Decomposition of EMP_PROJ into EMP_PROJ1 and EMP_LOCS fails test.  (b) A decomposition of EMP_PROJ that has the lossless join property.  (c) Case 2: Decomposition of EMP_PROJ into EMP, PROJECT, and WORKS_ON satisfies test.

 Properties of Relational Decompositions (18)

 Properties of Relational Decompositions (19)

 Properties of Relational Decompositions (20)  Binary Decomposition:  decomposition of a relation R into two relations.  Non-additive (Lossless) Join Test for Binary decompositions (NJB):  A decomposition D = {R 1, R 2 } of R has the lossless join property with respect to a set of functional dependencies F on R if and only if either  The FD ((R 1 ∩ R 2 )  (R 1 - R 2 )) is in F +, or  The FD ((R 1 ∩ R 2 )  (R 2 - R 1 )) is in F +.  Check this property using decomposition in Section 10.3 and 10.4

 Properties of Relational Decompositions (21)  Intuition for Test for Losslessness  Suppose R 1  R 2  R 2. Then a row of r 1 can combine with exactly one row of r 2 in the natural join (since in r 2 a particular set of values for the shared attributes defines a unique row), i.e.,  R 1  R 2 is a superkey of R 2 R 1  R 2 R 1  R 2 …………. a a ………... ………… a b …………. ………… b c …………. ………… c r 1 r 2

 Properties of Relational Decompositions (22)  Schema (R, F) where  R = {SSN, Name, Address, Hobby}  F = {SSN  Name, Address}  can be decomposed into  R 1 = {SSN, Name, Address}  F 1 = {SSN  Name, Address}  and  R 2 = {SSN, Hobby}  F 2 = { }  Since R 1  R 2 = SSN and  SSN  R 1 - R 2  SSN  Name, Address is in F +, then  the decomposition is lossless

 Properties of Relational Decompositions (23)  Example: WRT the FD set  Id#  Name, Address  C#  Description  Id#, C#  Grade  Is  (Id#, Name, Address) and  (Id#, C#, Description, Grade)  a lossless decomposition?

 Properties of Relational Decompositions (24)  A relation scheme  {Sname, Sadd, City, Zip, Item, Price}  The FD set  Sname  Sadd, City  Sadd, City  Zip  Sname, Item  Price  Consider the decomposition  {Sname, Sadd, City, Zip} and  {Sname, Item, Price}  Is it lossless?  Is it dependency preserving?  What if we replaced the first FD by  Sname, Sadd  City?

 Properties of Relational Decompositions (25)  The scheme:  {Student, Teacher, Subject}  The FD set:  Teacher  Subject  Student, Subject  Teacher  The decomposition:  {Student, Teacher} and  {Teacher, Subject}  Is it lossless?  Is it dependency preserving?

 Properties of Relational Decompositions (26)  Claim 2 (Preservation of non-additivity in successive decompositions):  If a decomposition D = {R 1, R 2,..., R m } of R has the lossless (non-additive) join property with respect to a set of functional dependencies F on R, and  if a decomposition D i = {Q 1, Q 2,..., Q k } of R i has the lossless (non-additive) join property with respect to the projection of F on R i,  then the decomposition D 2 = {R 1, R 2,..., R i-1, Q 1, Q 2,..., Q k, R i+1,..., R m } of R has the lossless (non- additive) join property with respect to F.

 Algorithms for RDB Schema Design (1) Algorithm 11.2: Relational Synthesis into 3NF with Dependency Preservation Input: A universal relation R and a set of functional dependencies F on the attributes of R. 1. Find a minimal cover G for F (See Algorithm 10.2); 2. For each left-hand-side X of a functional dependency that appears in G, create a relation schema in D with attributes {X  {A 1 }  {A 2 }...  {A k }}, where X  A 1, X  A 2,..., X  A k are the only dependencies in G with X as left- hand-side (X is the key of this relation) ; 3. Place any remaining attributes (that have not been placed in any relation) in a single relation schema to ensure the attribute preservation property.

 Algorithms for RDB Schema Design (2)  A set of FDs F is minimal if it satisfies the following conditions:  Every FD in F is of the form X  A, where A is a single attribute,  We cannot remove any dependency from F and have a set of dependencies that is equivalent to F.  For no X  A in F is F-{X  A} equivalent to F.  We cannot replace any dependency X  A in F with a dependency Y  A, where Y is a proper-subset of X (Y subset-of X) and still have a set of dependencies that is equivalent to F.  For no X  A in F and Y  X is F-{X  A}  {Y  A} equivalent to F.

 Algorithms for RDB Schema Design (3)  Examples  {A  C, A  B} is a minimal cover for {AB  C, A  B}  What about {AB  C, B  AB, D  BC}?  Every set of FDs has an equivalent minimal set  There can be several equivalent minimal sets  There is no simple algorithm for computing a minimal set of FDs that is equivalent to a set F of FDs  To synthesize a set of relations, we assume that we start with a set of dependencies that is a minimal set.

 Algorithms for RDB Schema Design (4)  Two sets of FDs F and G are equivalent if:  Every FD in F can be inferred from G, and  Every FD in G can be inferred from F  Hence, F and G are equivalent if F + = G +  Definition (Covers):  F covers G if every FD in G can be inferred from F  (i.e., if G + is subset-of F + )  F and G are equivalent if F covers G and G covers F  There is an algorithm for checking equivalence of sets of FDs

 Algorithms for RDB Schema Design (5)  Algorithm 10.2 Finding a minimal cover G for F  1.Set G := F.  2.Replace each FD X  {A 1, A 2,..., A k } in G by the n functional dependencies X  A 1, X  A 2, …, X  A k.  3.For each FD X  A in G  For each attribute B that is an element of X  if ((G -{X  A})  {(X-{B})  A}) is equivalent to G,  then replace X  A with (X-{B})  A in G.  4.For each remaining FD X  A in G,  if (G-{X  A}) is equivalent to G, then remove X  A from G.

 Algorithms for RDB Schema Design (6)  Example:  {A→B, ABCD→E, EF→GH, ACDF→EG}  Make RHS a single attribute:  {A→B, ABCD→E, EF→G, EF→H, ACDF→E, ACDF→G}  Minimize LHS: ACD→E instead of ABCD→E  Eliminate redundant FDs  Can ACDF→G be removed?  Can ACDF→E be removed?  Final answer: {A→B, ACD→E, EF→G, EF→H}

 Algorithms for RDB Schema Design (7)  Minimal Cover Exercise  Compute the minimal cover of the following set of functional dependencies:  {ABC  DE, BD  DE, E  CF, EG  F}  ABC  D  ABC  E//  BD  D// reflexive  BD  E  E  C  E  F  EG  F// augmentation  The minimal cover is:  {ABC  D, BD  E, E  C, E  F}

 Algorithms for RDB Schema Design (8)  Example of Algorithm 11.2: (3NF Decomposition)  Consider  the relation R = CSJDPQV  FDs F = C→CSJDPQV, SD→P, JP→C,J→S  Find minimal cover:  {C→J, C→D, C→Q, C→V, SD→P, JP→C, J→S}  New relations:  R 1 =CJDQV, R 2 =JPC,  R 3 =JS, R 4 =SDP

 Algorithms for RDB Schema Design (9) Algorithm 11.3: Relational Decomposition into BCNF with Lossless (non-additive) join property Input: A universal relation R and a set of functional dependencies F on the attributes of R. 1. Set D = {R} 2. While there is a relation schema Q in D that is not in BCNF do { choose a relation schema Q in D that is not in BCNF; find a FD X  Y in Q that violates BCNF; replace Q in D by two relation schemas (Q-Y) & (X  Y) }

 Algorithms for RDB Schema Design (10)  Example of Algorithm 11.3 (BCNF Decomposition)  R = (branch-name, branch-city, assets, customer-name, loan-number, amount)  F = {branch-name  branch-city, assets loan-number  branch-name, amount}  Key = {loan-number, customer-name}  Decomposition  R 1 = (branch-name, branch-city, assets)  R 2 = (branch-name, customer-name, loan-number, amount)  R 3 = (loan-number, branch-name, amount)  R 4 = (loan-number, customer-name)  Final decomposition R 1, R 3, R 4

 Algorithms for RDB Schema Design (11)  Example of Algorithm 11.3 (BCNF Decomposition)  R = (A, B, C) F = {A  B, B  C} Key = {A}  R is not in BCNF  Decomposition R 1 = (A, B), R 2 = (B, C)  R 1 and R 2 in BCNF  Lossless-join decomposition  Dependency preserving

 Algorithms for RDB Schema Design (12) Algorithm 11.4 Relational Synthesis into 3NF with Dependency Preservation and Lossless (Non-Additive) Join Property Input: A universal relation R and a set of functional dependencies F on the attributes of R. 1. Find a minimal cover G for F (Use Algorithm 10.2). 2. For each left-hand-side X of a functional dependency that appears in G, create a relation schema in D with attributes {Xυ{A 1 }υ{A 2 }...υ {A k }}, where X  A 1, X  A 2,..., X  A k are the only dependencies in G with X as left-hand-side (X is the key of this relation). 3. If none of the relation schemas in D contains a key of R, then create one more relation schema in D that contains attributes that form a key of R. (Use Algorithm 11.4a to find the key of R) 4. Eliminate redundant relations from the resulting set of relations. A relation T is considered redundant if T is a projection of another relation S.

 Algorithms for RDB Schema Design (13) Algorithm 11.4a Finding a Key K for R Given a set F of Functional Dependencies Input: A universal relation R and a set of functional dependencies F on the attributes of R. 1. Set K = R 2. For each attribute A in K compute (K - A) + with respect to F; If (K - A) + contains all the attributes in R, then set K = K - {A} See Examples at pages 380 and 381.

 Algorithms for RDB Schema Design (14)  Issues with null-value joins.  (a) Some EMPLOYEE tuples have null for the join attribute DNUM.

 Algorithms for RDB Schema Design (15)  Issues with null-value joins.  (b) Result of applying NATURAL JOIN to the EMPLOYEE and DEPARTMENT relations. (c) Result of applying LEFT OUTER JOIN to EMPLOYEE and DEPARTMENT.

 Algorithms for RDB Schema Design (16)  The “dangling tuple” problem.  (a) The relation EMPLOYEE_1 (includes all attributes of EMPLOYEE from figure 11.2a except DNUM).

 Algorithms for RDB Schema Design (17)  The “dangling tuple” problem.  (b) The relation EMPLOYEE_2 (includes DNUM attribute with null values).  (c) The relation EMPLOYEE_3 (includes DNUM attribute but does not include tuples for which DNUM has null values).

 Algorithms for RDB Schema Design (18)  Discussion of Normalization Algorithms:  Problems:  The database designer must first specify all the relevant functional dependencies among the database attributes.  These algorithms are not deterministic in general.  It is not always possible to find a decomposition into relation schemas that preserves dependencies and allows each relation schema in the decomposition to be in BCNF (instead of 3NF as in Algorithm 11.4).

 Algorithms for RDB Schema Design (19) Algorit hm InputOutputProperties/Purpos e Remarks 11.1A decomposition D of R and a set F of functional dependencies Boolean result: yes or no for lossless join property Testing for non- additive join decomposition See a simpler test in Section for binary decompositions 11.2Set of functional dependencies F A set of relations in 3NF Dependency preservation No guarantee of satisfying lossless join property 11.3Set of functional dependencies F A set of relations in BCNF Lossless join decomposition No guarantee of dependency preservation 11.4Set of functional dependencies F A set of relations in 3NF Lossless join and dependency preserving decomposition May not achieve BCNF 11.4aRelation schema R with a set of functional dependencies F Key K of RTo find a key K (which is a subset of R) The entire relation R is always a default superkey Table 11.1 Summary of some of the algorithms discussed

 Multivalued Dependencies and 4 th Normal Form (1)  Beyond BCNF:  CustService (State, SalesPerson, Delivery) Is this BCNF?

 Multivalued Dependencies and 4 th Normal Form (2)  Everything is in the key -- must be BCNF  Still problems with duplication  Multivalued Dependencies

 Multivalued Dependencies and 4 th Normal Form (3)  At least three attributes (A, B, C)  A  B and A  C  B and C are independent of each other (they really shouldn’t be in the same table)

 Multivalued Dependencies and 4 th Normal Form (4) Definition:  A multivalued dependency (MVD) X —>> Y specified on relation schema R, where X and Y are both subsets of R, specifies the following constraint on any relation state r of R:  If two tuples t 1 and t 2 exist in r such that t 1 [X] = t 2 [X], then two tuples t 3 and t 4 should also exist in r with the following properties, where we use Z to denote (R - (X υ Y)):  t 3 [X] = t 4 [X] = t 1 [X] = t 2 [X]  t 3 [Y] = t 1 [Y] and t 4 [Y] = t 2 [Y].  t 3 [Z] = t 2 [Z] and t 4 [Z] = t 1 [Z].  An MVD X —>> Y in R is called a trivial MVD if  (a) Y is a subset of X, or  (b) X υ Y = R

 Multivalued Dependencies and 4 th Normal Form (5)  4th Normal Form  BCNF with no multivalued dependencies  Create separate tables for each separate functional dependency

 Multivalued Dependencies and 4th Normal Form (6)  (a) The EMP relation with two MVDs: ENAME —>> PNAME and ENAME —>> DNAME. (b) Decomposing the EMP relation into two 4NF relations EMP_PROJECTS and EMP_DEPENDENTS.

 Multivalued Dependencies and 4th Normal Form (7) SalesForce (State, SalesPerson) Delivery (State, Delivery)

 Multivalued Dependencies and 4th Normal Form (8)  Inference Rules for Functional and Multivalued Dependencies:  IR1 (reflexive rule for FDs):  If X  Y, then X –> Y.  IR2 (augmentation rule for FDs):  {X –> Y}  XZ –> YZ.  IR3 (transitive rule for FDs):  {X –> Y, Y –>Z}  X –> Z.  IR4 (complementation rule for MVDs):  {X —>> Y}  X —>> (R – (X  Y)).  IR5 (augmentation rule for MVDs):  If X —>> Y and W  Z then WX —>> YZ.  IR6 (transitive rule for MVDs):  {X —>> Y, Y —>> Z}  X —>> (Z - Y).  IR7 (replication rule for FD to MVD):  {X –> Y}  X —>> Y.  IR8 (coalescence (الإتحاد) rule for FDs and MVDs):  If X —>> Y and there exists W with the properties that (a) W  Y is empty, (b) W –> Z, and (c) Y  Z, then X –> Z.

 Multivalued Dependencies and 4th Normal Form (9)  A relation schema R is in 4NF with respect to a set of dependencies F (that includes functional dependencies and multivalued dependencies), at least one of the following hold:  X —>> Y is trivial (i.e., Y  X or X  Y = R)  X is a superkey for schema R  If a relation is in 4NF it is in BCNF  Note: F + is the (complete) set of all dependencies (functional or multivalued) that will hold in every relation state r of R that satisfies F. It is also called the closure of F.

 Multivalued Dependencies and 4NF (10)  Decomposing a relation state of EMP that is not in 4NF. (a) EMP relation with additional tuples. (b) Two corresponding 4NF relations EMP_PROJECTS and EMP_DEPENDENTS.

 Multivalued Dependencies and 4NF (11) Lossless (Non-additive) Join Decomposition into 4NF Relations:  PROPERTY NJB’ The relation schemas R 1 and R 2 form a lossless (non-additive) join decomposition of R with respect to a set F of functional and multivalued dependencies if and only if (R 1 ∩ R 2 ) —>> (R 1 - R 2 ) or by symmetry, if and only if (R 1 ∩ R 2 ) —>> (R 2 - R 1 )).

 Multivalued Dependencies and 4NF (12) Algorithm 11.5: Relational decomposition into 4NF relations with non-additive join property Input: A universal relation R and a set of functional and multivalued dependencies F. 1. Set D := { R }; 2. While there is a relation schema Q in D that is not in 4NF do {choose a relation schema Q in D that is not in 4NF; find a nontrivial MVD X —>> Y in Q that violates 4NF; replace Q in D by two relation schemas (Q - Y) and (X υ Y); };

 Multivalued Dependencies and 4NF (13)  R =(A, B, C, G, H, I) F ={ A —>> B,B —>> HI,CG —>> H }  R is not in 4NF since A —>> B and A is not a superkey for R  Decomposition  R 1 = (A, B) (R 1 is in 4NF)  R 2 = (A, C, G, H, I) (R 2 is not in 4NF)  R 3 = (C, G, H) (R 3 is in 4NF)  R 4 = (A, C, G, I) (R 4 is not in 4NF)  Since A —>> B and B —>> HI, A —>> HI, A —>> I  R 5 = (A, I) (R 5 is in 4NF)  R 6 = (A, C, G) (R 6 is in 4NF)

 Join Dependencies and Fifth Normal Form (1)  A join dependency (JD), denoted by JD(R 1, R 2,..., R n ), specified on relation schema R, specifies a constraint on the states r of R.  The constraint states that every legal state r of R should have a non-additive join decomposition into R 1, R 2,..., R n ; that is, for every such r we have * (  R1 (r),  R2 (r),...,  Rn (r)) = r  A join dependency JD(R 1, R 2,..., R n ), specified on relation schema R, is a trivial JD if one of the relation schemas R i in JD(R 1, R 2,..., R n ) is equal to R.

 Join Dependencies and Fifth Normal Form (2)  A relation schema R is in fifth normal form (5NF) (or Project-Join Normal Form (PJNF)) with respect to a set F of functional, multivalued, and join dependencies if, for every nontrivial join dependency JD(R 1, R 2,..., R n ) in F + (that is, implied by F),  every R i is a superkey of R.  if and only if R is equal to the join of its projections on R 1, R 2,..., R n  R is in 5NF if and only if every join dependency in R is implied by the candidate keys of R

 Join Dependencies and Fifth Normal Form (3)  (c) The relation SUPPLY with no MVDs is in 4NF but not in 5NF if it has the JD(R1, R2, R3). (d) Decomposing the relation SUPPLY into the 5NF relations R1, R2, and R3.