Plan of the lecture. G53RDB: Theory of Relational Databases Lecture 13. Join dependencies. Multivalued dependencies. Decomposition (non-loss!

Transcription

1 Plan of the lecture G53RDB: Theory of Relational Databases Lecture 13 Multivalued and join dependencies: example. Informal coursework: normalising a relation. Natasha Alechina School of Computer Science & IT nza@cs.nott.ac.uk Lecture 12 2 Multivalued dependencies A multivalued dependency X Y holds in R if for every two tuples r,s R, if r(x) = s(x) then the sets of Y- values with which r and s occur in R are the same. Formally, I R (r(x,z)) = I R (s(x,z)), where Z is the rest of R s attributes. (Note: definition changed from Lecture 11). In other words, for every b π Y (R): <r(x),b,r(z)> R if, and only if, <s(x),b,s(z)> R (where Z is the rest of R s attributes). Lecture 12 3 Join dependencies Let R be a relation and X 1, X 2,, X n be sets of attributes of R. A join dependency JD*(X 1, X 2,, X n ) holds in R if and only if R is equal to the join of its projections on X 1, X 2,, X n : R = π X1 (R) >< π X2 (R) ><... >< π Xn (R) (join is on common attributes). Multivalued dependency X Y holds for a relation R(X,Y,Z) if, and only if, join dependency JD*(XY,XZ) holds for R. Multivalued dependency is a special case of join dependency where only two attribute sets are involved. Lecture 12 4 Join dependency: example Decomposition (non-loss!): Example from Stanczyk et al: JD*(University, Discipline, Degree) Lecture 12 5 R1 University Discipline Old Town Computing Old Town Mathematics New City Computing Discipline Degree R2 Computing BSc Computing PhD Mathematics PhD R3 University Degree Old Town BSc Old Town PhD New City PhD Lecture

2 Are there any multivalued dependencies in this relation R? Let s check whether University Discipline holds. This means, for every t,s: if t(university) = s(university), I R (t(university,degree) ) = I R (s(university,degree) ). Lecture 12 7 Lecture 12 8 (University) = (University), but I R ((University,Degree) ) = {Computing}, I R ((University,Degree) ) = {Mathematics, Computing}. Let s check whether University Degree holds. Lecture 12 9 Lecture (University) = (University), but I R ((University,Discipline) ) = {BSc,PhD}, I R ((University,Discipline) ) = {PhD}. Similarly for other non-trivial mvds: Discipline Degree, Degree Discipline, Discipline University, Degree University do not hold. Lecture Lecture

3 On the other hand: On the other hand: Café Drinks holds. Cafe Drinks Food I R (Café,Food)(r1) = {Orange juice, Apple juice} Cafe Drinks Food OneCafe Orange juice Salad OneCafe Orange juice Carrot cake OneCafe Apple juice Salad OneCafe Apple juice Carrot cake AnotherCafe Coffee Sandwich AnotherCafe Tea Sandwich r1 r2 r3 r4 r5 r6 OneCafe Orange juice Salad OneCafe Orange juice Carrot cake OneCafe Apple juice Salad OneCafe Apple juice Carrot cake AnotherCafe Coffee Sandwich AnotherCafe Tea Sandwich Lecture Lecture On the other hand: On the other hand: I R (Café,Food)(r1) = I R (C,F)(r2) = I R (C,F)(r3) = I R (C,F)(r4) Cafe Drinks Food I R (Café,Food)(r5) = I R (Cafe,Food)(r6) = {Coffee, Tea} Cafe Drinks Food r1 r2 r3 r4 r5 r6 OneCafe Orange juice Salad OneCafe Orange juice Carrot cake OneCafe Apple juice Salad OneCafe Apple juice Carrot cake AnotherCafe Coffee Sandwich AnotherCafe Tea Sandwich r1 r2 r3 r4 r5 r6 OneCafe Orange juice Salad OneCafe Orange juice Carrot cake OneCafe Apple juice Salad OneCafe Apple juice Carrot cake AnotherCafe Coffee Sandwich AnotherCafe Tea Sandwich Lecture Lecture Informal coursework Informal coursework Consider the following relation PR2 which describes arrangements for a first year programming course. Attributes are: StudentId (e.g. xyz01u), StudentName, TutorId (e.g. gjm), TutorName (e.g. Graham), Date (of the tutorial), Place (of the tutorial, e.g. B53), Assignment (e.g. SimpleGUI), Mark (assuming each student gets a mark for each assignment). Each student has one tutor, tutor may have multiple tutees and give multiple tutorials on different times, there is one tutorial per room, one mark per assignment, one assignment discussed and marked at a tutorial. Determine candidate keys in relation PR2. Normalize to BCNF, 4NF, 5NF. Lecture Lecture

4 Informal coursework Normalising to 2NF Candidate keys: {StudentID, Assignment} {StudentID, Date} (assuming there is one assignment per week) any more? Lecture Functional dependencies: StudentID StudentName, TutorID, TutorName TutorID TutorName Date Assignment (assuming each week there is one assignment) everything else depends on candidate keys any more? I assumed that place of the tutorial may change from week to week so we don t have StudentID Place. Dependencies where determinant is part of a key: StudentID StudentName, TutorID, TutorName Lecture Normalising to 2NF Relation Tutees This means we can separate a relation where everything depends on StudentID - and the rest of PR2 relation. So we have Tutees = π StudentID, StudentName, TutorID, TutorName (PR2) where StudentID is the key Mark = π StudentID, Date, Place, Assignment, Mark (PR2) where candidate keys are {StudentID,Assignment} and {StudentID, Date}. Decomposition is lossless because of Heath s theorem. Lecture Tutees = π StudentID, StudentName, TutorID, TutorName (PR2) Is it in 2NF? The only key is StudentID, so no determinant can be part of a key. Is it in BCNF? Relation Tutees has a functional dependency TutorID TutorName, so it has determinant which is not a key, so it is not in BCNF. Normalisation to BCNF was given as an example in Lecture 10. Tutees is decomposed into Students = π StudentID, StudentName, TutorID, (PR2) Tutors = π TutorID, TutorName (PR2) Lecture Normalising Tutees to BCNF Tutees relation has to be decomposed into Students and Tutors: Students Tutors ST-ID ST-Name Tutor-ID Tutor-ID Tutor-Name 123 John xyz xyz Peter 456 Mary xyz abc Paul 789 Jane abc Mark relation Mark = π StudentID, Date, Place, Assignment, Mark (PR2) where candidate keys are {StudentID,Assignment} and {StudentID, Date}. Is it in 2NF? Is there part of key which is a determinant? No attributes depend on StudentID alone; No attributes depend on Assignment alone; But if there is only one assignment per week, we have a functional dependency Date Assignment! Lecture Lecture

5 Decomposing Mark relation Dates relation We have Dates = π Date, Assignment (Mark) (candidate key: {Date}; there could be several dates during the week when an assignment is discussed, so Assignment is not a key). Marks = π StudentID, Date, Place, Mark (Mark) (candidate key: {StudentID, Date}) Dates = π Date, Assignment (Mark) (candidate key: {Date}) Is it in 2NF? Obviously yes because the only key is a single attribute. Is it in BCNF? Yes, because the only non-trivial functional dependency is on Date. Lecture Lecture Where are we... Marks = π StudentID, Date, Place, Mark (Mark) (candidate key: {StudentID, Date}) Is it in 2NF? Yes, nothing depends on just StudentID or just Date. Is it in BCNF? Yes, Place and Mark don t determine any other attributes. Relation PR2 is decomposed into Students = π StudentID, StudentName, TutorID, (PR2) Tutors = π TutorID, TutorName (PR2) Dates = π Date, Assignment (PR2) Marks = π StudentID, Date, Place, Mark (PR2) All these relations are in BCNF. Lecture Lecture What about mvds? Students relation To have a relation in 4NF, we need to make sure that for every non-trivial mvd X Y, X is a key (or superkey). Non-trivial means that there are other attributes in addition to those in X and Y. So we don t have to check Tutors and Dates relations (which only have two attributes). We also only need to check for mvds where X is not a (super) key. Students = π StudentID, StudentName, TutorID, (PR2) The only non-trivial mvds which we could check where X is not a (super) key are: StudentName TutorID TutorID StudentName. Lecture Lecture

6 StudentName TutorID? TutorID StudentName? Suppose we fix the values for StudentName and StudentID for some tuple s in Students. For example, s = <jxs01u, John Smith, gjm>. The set of TutorID values in its image will be a single id {gjm}. Suppose there is another tuple t which agrees with s on StudentName, but the student is another John Smith with another tutor: t = <jys01u, John Smith, isk> The set of TutorID values is {isk}, different from s. So the mvd does not hold. Lecture Suppose we fix the values for TutorID and StudentID for some tuple s in Students. For example, s = <jxs01u, John Smith, gjm>. The set of StudentName values in its image will be a single name {John Smith}. Suppose there is another tuple t which agrees with s on TutorId, t = <jxb01u, Jane Brown, gjm> The set of StudentName values is {Jane Brown}, different from s. So the mvd does not hold. Lecture Marks = π StudentID, Date, Place, Mark (PR2) Potential bad mvds (20 in total!): StudentID Date StudentID Place StudentID Mark Date StudentID Date Place Date Mark Place StudentID Place Date Place Mark Mark StudentID Mark Date Mark Place {StudentID, Place} Date {StudentID, Place} Mark Lecture Lecture {Date, Place} StudentID {Date, Place} Mark {Place, Mark} StudentID {Place, Mark} Date {Date, Mark} StudentID {Date, Mark} Place Let us show just for one of them that it does not hold: {Date, Place} StudentID Is t possible that there are two tuples s and t from Marks, such that s(date,place) = t(date,place), but I R (s(date,place,mark)) I R (t(date,place,mark)) Consider s = <abc01u, , B53, 60> and t = <xyz01u, , B53, 70>. Clearly, abc01u is in I R (s(date,place,mark)) (and so are ids of all other students who got a mark of 60 on that day) but not in I R (t(date,place,mark)). Lecture Lecture

7 In general, {Date, Place} StudentID does not hold because the missing attribute Mark and StudentID are connected, so Date and Place alone don t determine the set of StudentIDs. The same kind of argument works for all other potential mvds: all four attributes are dependent on each other. Relation Marks has no bad mvds... so it is in 4NF. PR2 is decomposed into Students = π StudentID, StudentName, TutorID, (PR2) Tutors = π TutorID, TutorName (PR2) Dates = π Date, Assignment (PR2) Marks = π StudentID, Date, Place, Mark (PR2) All these relations are in 4NF. Lecture Lecture Fifth normal form (5NF) A relation R is in 5NF if for all non-trivial join dependencies JD*(X 1,,X n ) that hold for R, every X i is a superkey for R. A join dependency is called trivial if one of X i includes all attributes (so projection on X i is R itself). Checking for 5NF We need to check if there are any non-trivial join dependencies in the relations below and if there are, check if each of the projections is on a superkey. Students = π StudentID, StudentName, TutorID, (PR2) Tutors = π TutorID, TutorName (PR2) Dates = π Date, Assignment (PR2) Marks = π StudentID, Date, Place, Mark (PR2) Obviously there cannot be non-trivial join dependencies in Tutors and Dates. Lecture Lecture Checking Students relation for 5NF Students = π StudentID, StudentName, TutorID, (PR2) It can be non-loss decomposed into π StudentID, StudentName (Students) and π StudentID,TutorID, (Students), but both {StudentID, StudentName} and {StudentID, TutorID} are superkeys. It cannot be non-loss decomposed into π StudentID,StudentName (Students) and π StudentName,TutorID, (Students) (we already so this when looking for mvds). Checking Students relation for 5NF π StudentID,StudentName, (Students) >< π StudentName,TutorID, (Students) Students: Students StudentID StudentName TutorID jxs01u John Smith gjm jys01u John Smith isk Lecture Lecture

8 Checking Students relation for 5NF π StudentID,StudentName, (Students) >< π StudentName,TutorID, (Students) Students: π StudentID,StudentName, (Students) >< π StudentName,TutorID (Students) StudentID StudentName TutorID jxs01u John Smith gjm jys01u John Smith isk jys01u John Smith gjm jxs01u John Smith isk Checking Students relation for 5NF Similarly, no other decomposition of Students is lossless, unless each projection involves StudentID. Relation Student is in 5NF. Lecture Lecture Checking for 5NF Marks = π StudentID, Date, Place, Mark (PR2) We already checked for mvds, so the only hope to find a non-loss decomposition is to take three or more projections. Let us check {StudentID, Date}, {Date,Place,Mark}, {StudentID, Mark}. Checking for 5NF π StudentID, Date (Marks) >< π Date, Place, Mark (Marks) >< π (Marks) Marks StudentID,Mark Marks StudentID Date Place Mark abc01u B53 60 xyz01u B53 70 abc01u B53 70 Lecture Lecture Checking for 5NF <abc01u,13.11> π StudentID, Date (Marks) <13.11, B53, 70> π Date, Place, Mark (Marks) <abc01u,70> π StudentID, Date (Marks) <abc01u,13.11, B53, 70> π StudentID, Date (Marks) >< π Date, Place, Mark (Marks) <abc01u,13.11, B53, 70> π StudentID, Date (Marks) >< π Date, Place, Mark (Marks) >< π StudentID,Mark (Marks) But it does not belong to Marks. Summary Really need to check all possible decompositions, but similar argument will show that there are no bad join dependencies in Marks. All our relations are in 5NF. Checking this way whether a relation is in a given normal form an extremely laborious process. Would be nice to know that if one dependency does not hold, then a set of other dependencies also does not hold. Subject of the next lecture. Lecture Lecture