MODULE: 3 FUNCTIONAL DEPENDENCIES

Transcription

1 MODULE: 3 (13 hours) Database design: functional dependencies - Inference Rules for Functional Dependencies - Closure -- Minimal Cover -Normal forms First-second and third normal forms Boyce- Codd normal form - Properties of Relational Decompositions -Algorithms for Relational database design- Multi valued dependencies and fourth normal form(general definitions) - join dependencies and fifth normal form(general definitions) inclusion - Dependencies (general definitions) FUNCTIONAL DEPENDENCIES Functional dependencies (FDs) are used to specify formal measures of the "goodness" of relational designs. FDs and keys are used to define normal forms for relations.fds are constraints that are derived from the meaning andinterrelationships of the data attributes.a set of attributes X functionally determines a set of attributes Y if the value of X determines a unique value for Y X -> Y holds if whenever two tuples have the same value for X, they must have the same value for Y.For any two tuples t1 and t2 in any relation instance r(r): Ift1[X]=t2[X], then t1[y]=t2[y]. X -> Y in R specifies a constraint on all relation instances r(r).written as X -> Y; can be displayed graphically on a relation schema as in Figures. (denoted by the arrow ).FDs are derived from the real-world constraints on the attributes Eg. Social Security Number (SSN) determines Employee Name (ENAME) SSN -> ENAME Project Number (PNUMBER) determines Project Name (PNAME) and Project Location (PLOCATION) 1

2 PNUMBER -> {PNAME, PLOCATION} Employee SSN and PNUMBER determines the hours per week that the employee works on the project {SSN, PNUMBER} -> HOURS An FD is a property of the attributes in the schema R.The constraint must hold on every relation instance r(r).if K is a key of R, then K functionally determines all attributes in R (since we never have two distinct tuples with t1[k]=t2[k]) 5 mark question 2014 April (2009 scheme) 2.5 mark question 2012 May (2009 scheme) Figure 3.1 Two relation schemas suffering from update anomalies. (a) EMP_DEPT and (b) EMP_PROJ. Inference Rules for FDs Given a set of FDs F, we can inferadditional FDs that hold whenever the FDs in F hold Armstrong's inference rules: IR1. (Reflexive) If Y subset-of X, then X -> Y IR2. (Augmentation) If X -> Y, then XZ -> YZ (Notation: XZ stands for X U Z) IR3. (Transitive) If X -> Y and Y -> Z, then X -> Z IR1, IR2, IR3 form a sound and complete set of inference rules 2

3 Some additional inference rules that are useful: (Decomposition) If X -> YZ, then X -> Y and X -> Z (Union) If X -> Y and X -> Z, then X -> YZ (Psuedotransitivity) If X -> Y and WY -> Z, then WX -> Z Definition: Closure of a set F of FDs is the set F + of all FDs that can be inferred from F. Equivalence of Sets of FDs: 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 + F covers Gif every FD in G can be inferred from F (i.e., if G + subset-of F + ) F and G are equivalent if F covers G and G covers F Minimal Sets of FDs:A set of FDs is minimal if it satisfies the following conditions: (1) Every dependency in F has a single attribute for its RHS. (2) We cannot remove any dependency from F and have a set of dependencies that is equivalent to F. (3) We cannot replace any dependency X -> A in F with a dependency Y -> A, where Y proper-subset-of X ( Y subset-of X) and still have a set of dependencies that is equivalent to F. Every set of FDs has an equivalent minimal set.there can be several equivalent minimal sets 3

4 NORMALIZATION OF RELATIONS Normalization: The process of decomposing unsatisfactory "bad" relations by breaking up their attributes into smaller relations. It is the process of efficiently organizing the data in database. it can also be defined as a process of analyzing the given relation schema based on their FDs and primary key to achieve the desirable properties of Minimizing redundancy of data in database Minimizing insertion, deletion and update anomalies Ensure data dependencies make sense. The process is done in top-down fashion by evaluating each relation against the criteria for Normal Form. It will decomposes the relation if needed. Normalization can be considered as series of test on relation to determine whether it satisfies or violate the requirements of a normal form Normal form: Condition using keys and FDs of a relation to certify whether a relation schema is in a particular normal form. Normal form of a relation is the highest normal form condition that it meet and indicate the degree to which it can be normalized. Normalization is carried out in practice so that the resulting designs are of high quality and meet the desirable properties. Lossless join or non-additive join property: guaranties that the spurious tuple generation problem does not occur w.r.t the relation schema created after decomposition Dependency preservation property: ensure that each FD is represented in same individual relation resulting after decomposition The practical utility of these normal forms becomes questionable when the constraints on which they are based are hard to understand or to detect Denormalization: The process of storing the join of higher normal form relations as a base relation which is in a lower normal form. 4

5 Definitions of Keys and Attributes Participating in Key A super keyof a relation schema R = {A1, A2,..., An} is a set of attributes S subset-of R with the property that no two tuples t1 and t2 in any legal relation state r of R will have t1[s] = t2[s] OR Super keyis combination of one or more column in a table which is used to identify a record in a table uniquely. A table can have any no. of super key AkeyK is a superkey with the additional property that removal of any attribute from K will cause K not to be a superkeyanymore. *Difference between key and super key A key has to be minimal ie if we have k ={A1, A2,.AK} of R the k-{ai} is not a key in R for any Ai where 1<i<k. Eg. If {ssn} is a key in EMP where {ssn}, {ssn,ename}, {ssn, ename, bdate} and any set of attributes that include ssn is a superkey. If a relation schema has more than one key, each key is called a candidate key. One of the candidate keys is arbitrarily designated to be the primary key, and the others are called secondary keys. A Prime attribute must bea member of some candidate key A Nonprime attribute is not a prime attribute that is, it is not a member of any candidate key. Composite key: It is primary key of two or more attribute that uniquely identify the row 5

6 PROCESS OF NORMALIZATION Unnormalizedform(UNF): A table that contain one or more repeating group. 2 mark question 2010 Dec (2004 scheme) Repeating Group: an attribute or group of attribute within a table that occur with multiple values for a single occurrence of nominated key attribute of that table First Normal Form: A relation is said to be in 1NF if a relation in which the intersection of each row and column contain one and only one value. 1NF disallow o Multivalued attribute o Composite attribute o Combination of both o Relations within relations Relational schema R is in first normal formif the domains of all attributes of R are atomic.nonatomicvalues complicate storage and encourage redundant (repeated) storage of data. 6

7 Figure 3.2 Normalization into 1NF. (a) A relation schema that is not in 1NF. (b) Sample state of relation DEPARTMENT. (c) 1NF version of the same relation with redundancy. Here the department Research is in three location i.e. multivalued attribute. So decompose the values and make Department Number(DNUMBER) and Department Location (DLOCATION) as primary key thus convert it into 1NF METHODS TO ACHIVE 1NF : 1. Remove the attribute DLOCATION the violate 1NF and place it in separate relation 2. Expand the key so that there will be separate tuple in original DEPARTMENT relation or each DLOCATION of DEPARTMENT-(Disadv- cause redundancy) 3. If maximum no.of value is known, here DLOCATION have maxi of 3 location, then replace it with DLOC1, DLOC2, DLOC3-(may cause null values) 7

8 Second Normal Form Definitions: Uses the concepts of full functional dependency, primary key Prime attribute - attribute that is member of the primary key K Full functional dependency(ffd) - a FD Y -> Z where removal of any attribute from Y means the FD does not hold any more Examples: {SSN, PNUMBER} -> HOURS is a FFD since neither SSN -> HOURS nor PNUMBER -> HOURS hold {SSN, PNUMBER} -> ENAME is not a FFD (it is called a partial dependency ) since SSN -> ENAME also holds A relation schema R is in second normal form (2NF) if every non-prime attribute A in R is fully functionally dependent on the primary key R can be decomposed into 2NF relations via the process of 2NF normalization 8

9 Figure 3.3 Normalizing into 2NF and 3NF. (a) Normalizing EMP_PROJ into 2NF relations. (b) Normalizing EMP_DEPT into 3NF relations. Based on transitive dependency Third Normal Form Transitive functional dependency- a FD X -> Z in a relation schema R is transitive dependency if there is a set of attributes Z in neither candidate key nor a subset of any key R and both X -> Y and Y -> Z hold Examples: - SSN -> DMGRSSN is a transitive FD since SSN -> DNUMBER and DNUMBER -> DMGRSSN hold - SSN -> ENAME is non-transitive since there is no set of attributes X where SSN -> X and X -> ENAME 5 mark question 2014 April (2009 scheme) 2.5 mark question 2012 May (2009 scheme) 9

10 A relation schema R is in third normal form (3NF) if it is in 2NF and no non-prime attribute A in R is transitively dependent on the primary key R can be decomposed into 3NF relations via the process of 3NF normalization NOTE: InX -> Y and Y -> Z, with X as the primary key, we consider this a problem only if Y is not a candidate key. When Y is a candidate key, there is no problem with the transitive dependency. E.g., Consider EMP (SSN, Emp#, Salary ). Here, SSN ->Emp# -> Salary and Emp# is a candidate key General Normal Form Definitions A relation schema R is in second normal form (2NF) if every non-prime attribute A in R is fully functionally dependent on every key of R A relation schema R is in third normal form (3NF) if whenever a FD X -> A holds in R, then either: (a) X is a superkey of R, or (b) A is a prime attribute of R NOTE: Boyce-Codd normal form disallows condition (b) above 5 mark question 2016 April (2009 scheme) 10

11 Table 3.1 Summary of Normal Forms Based on Primary Keys and Corresponding Normalization Boyce-Codd Normal Form (BCNF) A relation schema R is in Boyce-Codd Normal Form (BCNF) if whenever an FD X -> A holds in R, then X is a superkey of R Each normal form is strictly stronger than the previous one Every 2NF relation is in 1NF Every 3NF relation is in 2NF Every BCNF relation is in 3NF There exist relations that are in 3NF but not in BCNF 11

12 Figure 3.4 Boyce-Codd normal form. (a) BCNF normalization of LOTS1A with the functional dependency FD2 being lost in the decomposition. (b) A schematic relation with FDs; it is in 3NF, but not in BCNF. 10 mark question 2016 April (2009 scheme) 10 mark question 2013 May (2009 scheme) 5 mark question 2013 May (2009 scheme) 15 mark question 2010 Dec (2004 scheme) 15 mark question 2008 June (2004 scheme) 5 mark question 2011 June (2004 scheme) 15 mark question 2008 Dec (2004 scheme) 12

13 Properties of Relational Decompositions Design a good relation design rather than a set of relations that together form the relational database schema Must possess certain additional properties toensure a good design. Relation Decomposition and Insufficiency of Normal Forms Universal relation schema R = {A1, A2,...,An} includes all the attributes of the database. Assumption- every attribute name is unique. Using the functional dependencies, the algorithms decompose the universal relation schema R into a set of relation schemas D = {R1, R2,...,Rm} that will become the relational database schema; D is called a decomposition of R. each attribute in R will appear in at least one relation schema Ri in the decomposition so that no attributes are lost- attribute preservation condition of a decomposition. each individual relation Ri in the decomposition D be in BCNF or 3NF. Additional conditions that should hold on a decomposition D as a whole. Dependency Preservation Property of Decomposition Definition: Given a set of dependencies F on R, the projection of F on Ri, denoted by π Ri(F) where Ri 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 Ri. Hence, the projection of F on each relation schema Ri in the decomposition D is the set of functional dependencies in F+, the closure of F, such that all their left- and right-handside attributes are in Ri. 13

14 We say that a decomposition D = {R1, R2,..., Rm} of R is dependency-preserving with respect to F if the union of the projections of F on each Ri in D is equivalent to F; that is, ((πr1(f)) (πrm(f)))+ = F+. Non additive (Lossless) Join Property of a Decomposition Definition: Formally, a decomposition D = {R1, R2,..., Rm} 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. The word loss in lossless refers to loss of information, not to loss of tuples. The non additive join property ensures that no spurious tuples result after the application of PROJECT and JOIN operations. 10 mark question 2013 May (2009 scheme) Algorithm: Testing for Nonadditive Join Property Input: A universal relation R, a decomposition D = {R1, R2,..., Rm} of R, and a set F of functional dependencies. Note: Explanatory comments are given at the end of some of the steps. They follow the format: (* comment *). 14

15 1. Create an initial matrix S with one row i for each relation Ri in D, and one column j for each attribute Aj in R. 2. Set S(i, j):= bij for all matrix entries. (* each bij is a distinct symbol associated with indices (i, j) *). 3. For each row i representing relation schema Ri {for each column j representing attribute Aj {if (relation Ri includes attribute Aj) then set S(i, j):= aj;};}; (* each aj is a distinct symbol associated with index ( j) *). 4. Repeat the following loop until a complete loop execution results in no changes to S {for each functional dependency X -> Y in F {for all rows in S that 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. If no a symbol exists for the attribute in any of the rows, choose one of the b symbols that appears 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 Non additive join property; otherwise, it does not. Given a relation R that is decomposed into a number of relations R1, R2,..., Rm,. Algorithm begins the matrix S that we consider to be some relation state r of R. Row i in S represents a tuple ti (corresponding to relation Ri) that has a symbols in the columns that correspond to the attributes of Ri and b symbols in the remaining columns. Then transforms the rows of this matrix (during the loop in step 4) so that they represent tuples that satisfy all the functional dependencies in F. Any two rows in S which represent two tuples in r that agree in their values for the lefthand-side attributes X of a functional dependency X -> Y in F will also agree in their values for the right-hand-side attributes Y. 15

16 Applying the loop of step 4, if any row in S ends up with all a symbols, then the decomposition D has the nonadditive join property with respect to F. Figure

17 Testing Binary Decompositions for the Nonadditive Join Property Algorithm allows us to test whether a particular decomposition D into n relations obeys the non additive join property with respect to a set of functional dependencies F. There is a special case of a decomposition called a binary decomposition decomposition of a relation R into two relations. Property NJB (Nonadditive Join Test for Binary Decompositions). A decomposition D = {R1, R2} of R has the lossless (nonadditive) join property with respect to a set of functional dependencies F on R if and only if either The FD ((R1 R2) (R1 R2)) is in F+, or The FD ((R1 R2) (R2 R1)) is in F+ Successive Nonadditive Join Decompositions To verify the succuessive decompositions of 2NF and 3NF are nonadditive, we need to ensure another property, Preservation of Nonadditivity in Successive Decompositions Definition: If a decomposition D = {R1, R2,..., Rm} of R has the nonadditive (lossless) join property with respect to a set of functional dependencies F on R, and if a decomposition Di = {Q1, Q2,..., Qk} of Ri has the nonadditive join property with respect to the projection of F on Ri, then the decomposition D2 = {R1, R2,..., Ri 1, Q1, Q2,..., Qk, Ri+1,..., Rm} of R has the nonadditive join property with respect to F. 17

18 Algorithms for Relational Database Schema Design Three algorithms for creating a relational decomposition from a universal Relation 1. Dependency-Preserving Decomposition into 3NF Schemas 2. Nonadditive Join Decomposition into BCNF Schemas 3. Dependency-Preserving and Nonadditive (Lossless) Join Decomposition into 3NF Schemas 1. Dependency-Preserving Decomposition into 3NF Schemas Algorithm creates a dependency-preserving decomposition D = {R1, R2,..., Rm} of a universal relation R based on a set of functional dependencies F, such that each Ri in D is in 3NF. It guarantees only the dependency-preserving property; it does not guarantee the nonadditive join property. o The first step is to find a minimal cover G for F; (Note that multiple minimal covers may exist for a given set ). Algorithm 1 : 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 2. For each left-hand-side X of a functional dependency that appears in G, create a relation schema in D with attributes {X U A1} U{A2}... U Ak} }, where X -> A1, X -> A2,..., X -> Ak are the only dependencies in G with X as the 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. 18

19 2. Nonadditive Join Decomposition into BCNF Schemas The algorithm decomposes a universal relation schema R = {A1, A2,..., An} into a decomposition D = {R1, R2,..., Rm} such that each Ri is in BCNF and the decomposition D has the lossless join property with respect to F. Algorithm utilizes Property NJB to create a nonadditive join decomposition D = {R1, R2,..., Rm} of a universal relation R based on a set of functional dependencies F, such that each Ri in D is in BCNF. Algorithm 2 : Relational Decomposition into BCNF with Nonadditive 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 functional dependency X Y in Q that violates BCNF; replace Q in D by two relation schemas (Q Y) and (X Y); } ; Each time through the loop in Algorithm decompose one relation schema Q that is not in BCNF into two relation schemas. Step 2 of Algorithm determines whether a relation schema Q is in BCNF or not. One method for doing this is to test, for each functional dependency X->Y in Q, whether X+ fails to include all the attributes in Q, thereby determining whether or not X is a (super)key in Q. 3. Dependency-Preserving and Nonadditive (Lossless) Join Decomposition into 3NF Schemas By the above one and two algorithm we know that it is not possible to have all three of the following: (1) guaranteed nonlossy design 19

20 (2) guaranteed dependency preservation (3) all relations in BCNF..A simple modification to Algorithm 1, shown as Algorithm 3, yields a decomposition D of R that does the following: Preserves dependencies Has the nonadditive join property Is such that each resulting relation schema in the decomposition is in 3NF Algorithm 3. Nonadditive Join Property Relational Synthesis into 3NF with Dependency Preservation and 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 2. For each left-hand-side X of a functional dependency that appears in G, create a relation schema in D with attributes {X U {A1} U {A2}... U {Ak} }, where X ->A1, X-> A2,..., X -> Ak 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. 4. Eliminate redundant relations from the resulting set of relations in the relational database schema. A relation R is considered redundant if R is a projection of another relation S in the schema; alternately, R is subsumed by S. Step 3 of Algorithm involves identifying a key K of R. Algorithm 2 can be used to identify a key K of R based on the set of given functional dependencies F. 20

21 FOURTH NORMAL FORM Based on Multivalued Dependency(MVD) Figure 3.6 Here in EMP table an employee may work on several projects and may serve for different dependents Multivalued Dependency(MVD): 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 t1 and t2 exist in r such that t1[x] = t2[x], then two tuples t3 and t4 should also exist in r with the following properties, where we use Z to denote (R 2 (XUY)): t3[x] = t4[x] = t1[x] = t2[x]. t3[y] = t1[y] and t4[y] = t2[y]. t3[z] = t2[z] and t4[z] = t1[z]. 2.5 mark question 2012 May (2009 scheme) The EMP relation with two MVDs: ENAME >> PNAME and ENAME >> DNAME. An MVD X >>Y in R is called a trivial MVD if (a) Y is a subset of X, or (b) XUY = R. 21

22 If we have a non trival MVD in a relation we may have repeated valued in this. Here in EMP X and Y of PNAME are repeated for each value of DNAME 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 (XY))}. IR5 (augmentation rule for MVDs): If X >> Y and WZ then WX >> YZ. IR6 (transitive rule for MVDs): {X >> Y, Y >> Z} X >> (Z 2 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) WY is empty, (b) W >Z, and (c) YZ, then X >Z. Fourth Normal Form:A relation schema R is in 4NF with respect to a set of dependencies F (that includes functional dependencies and multivalued dependencies) if, for every nontrivial multivalued dependency X >> Y in F +, X is a superkey for R. Eg: EMP is not in 4NF because for the non trivalmvdepencdencyename->> PNAME and ENAME->> DNAME, ENAME is not a superkey. Decomposing a relation state of EMP. Two corresponding 4NF relations EMP_PROJECTS and EMP_DEPENDENTS. 22

23 Figure 3.7 ADVANTAGE: Here in EMP we need to store 16 tuples but by dividing we need only b11 tuples Decomposition save storage space Avoid update anomalies 10 mark question 2016 April (2009 scheme) 5 mark question 2010 Dec (2004 scheme) JOIN DEPENDENCIES AND FIFTH NORMAL FORM A join dependency (JD), denoted by JD(R1, R2,..., Rn), 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 R1, R2,..., Rn; that is, for every such r we have* (πr1(r), πr2(r),..., πrn(r)) = r Note: an MVD is a special case of a JD where n = 2. A join dependency JD(R1, R2,..., Rn), specified on relation schema R, is a trivial JD if one of the relation schemas Ri in JD(R1, R2,..., Rn) is equal to R. 2.5 mark question 2012 May (2009 scheme) 23

24 FIFTH NORMAL FORM (5NF) 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(R1, R2,..., Rn) in F + (that is, implied by F), every Ri is a superkey of R Figure

25 INCLUSION DEPENDENCIES Inclusion dependencies were defined in order to formalize two types of inter relational constraints: The foreign key (or referential integrity) constraint cannot be specified as a functional or multivalued dependency because it relates attributes across relations. The constraint between two relations that represent a class/subclass relationship also has no formal definition in terms of the functional, multivalued, and join dependencies An inclusion dependency R. X<S.Y between two sets of attributes X of relation schema R, and Y of relation schema S specifies the constraint that, at any specific time when r is a relation state of R and s a relation state of S, we must have πx(r(r))πy(s(s)) 25