1. Database Management Systems Chapter 3 The Relational Data Model (II) Instructor: Li Ma Department of Computer Science Texas Southern University, Houston September, 2007

2. Functional Dependencies Meaning of FD’s Keys and Superkeys Rules about FD’s

3. Jeffrey Ullman3 Functional Dependencies uX -> A is an assertion about a relation R that whenever two tuples of R agree on all the attributes of X, then they must also agree on the attribute A. wSay “X -> A holds in R.” wConvention: …, X, Y, Z represent sets of attributes; A, B, C,… represent single attributes. wConvention: no set formers in sets of attributes, just ABC, rather than {A,B,C }.

4. Jeffrey Ullman4 Example Drinkers(name, addr, beersLiked, manf, favBeer) uReasonable FD’s to assert: 1.name -> addr 2.name -> favBeer 3.beersLiked -> manf

5. Jeffrey Ullman5 Example Data nameaddr beersLiked manffavBeer JanewayVoyager Bud A.B.WickedAle JanewayVoyager WickedAle Pete’sWickedAle SpockEnterprise Bud A.B.Bud Because name -> addr Because name -> favBeer Because beersLiked -> manf

6. Jeffrey Ullman6 FD’s With Multiple Attributes uNo need for FD’s with > 1 attribute on right. wBut sometimes convenient to combine FD’s as a shorthand. wExample: name -> addr and name -> favBeer become name -> addr favBeer u > 1 attribute on left may be essential. wExample: bar beer -> price

7. Jeffrey Ullman7 Keys of Relations uK is a superkey for relation R if K functionally determines all of R. uK is a key for R if K is a superkey, but no proper subset of K is a superkey.

8. Jeffrey Ullman8 Example Drinkers(name, addr, beersLiked, manf, favBeer) u {name, beersLiked} is a superkey because together these attributes determine all the other attributes. wname -> addr favBeer wbeersLiked -> manf

9. Jeffrey Ullman9 Example, Cont. u{name, beersLiked} is a key because neither {name} nor {beersLiked} is a superkey. wname doesn’t -> manf; beersLiked doesn’t -> addr. uThere are no other keys, but lots of superkeys. wAny superset of {name, beersLiked}.

10. Jeffrey Ullman10 E/R and Relational Keys uKeys in E/R concern entities. uKeys in relations concern tuples. uUsually, one tuple corresponds to one entity, so the ideas are the same. uBut --- in poor relational designs, one entity can become several tuples, so E/R keys and Relational keys are different.

11. Jeffrey Ullman11 Example Data nameaddr beersLiked manffavBeer JanewayVoyager Bud A.B.WickedAle JanewayVoyager WickedAle Pete’sWickedAle SpockEnterprise Bud A.B.Bud Relational key = {name beersLiked} But in E/R, name is a key for Drinkers, and beersLiked is a key for Beers. Note: 2 tuples for Janeway entity and 2 tuples for Bud entity.

12. Jeffrey Ullman12 Where Do Keys Come From? 1.Just assert a key K. wThe only FD’s are K -> A for all attributes A. 2.Assert FD’s and deduce the keys by systematic exploration. wE/R model gives us FD’s from entity-set keys and from many-one relationships.

13. Jeffrey Ullman13 More FD’s From “Physics” uExample: “no two courses can meet in the same room at the same time” tells us: hour room -> course.

14. Jeffrey Ullman14 Inferring FD’s uWe are given FD’s X 1 -> A 1, X 2 -> A 2,…, X n -> A n, and we want to know whether an FD Y -> B must hold in any relation that satisfies the given FD’s. wExample: If A -> B and B -> C hold, surely A -> C holds, even if we don’t say so. uImportant for design of good relation schemas.

15. Jeffrey Ullman15 About Two FD’s Set uTwo sets of FD’s are equivalent: they are satisfied by exactly the same set of relation instances uIf every relation instance that satisfies all the FD’s in set T also satisfies all the FD’s in set S, then we say S follows from T

16. Jeffrey Ullman16 Splitting/Combining Rule uX -> B 1 B 2...B n is the shorthand for the set of FD’s X -> B 1 X -> B 2 … X -> B n

17. Jeffrey Ullman17 Trivial-Dependency Rule uA FD X -> B is trivial if B is in the attribute set X wExample: AB -> A uWe can always remove from the right side of a FD those attributes that appear on the left wABC –> AD is equivalent to ABC -> D

18. Jeffrey Ullman18 Transitive Rule uIf X -> Y and Y -> Z hold in relation R, then X -> Z also holds in R wSimilar as the transitive rule in Arithmetic uWe can use either inference test or closure test to prove this rule

19. Jeffrey Ullman19 Inference Test uTo test if Y -> B, start by assuming two tuples agree in all attributes of Y. Y B 0000000... 0 000000?... ?

20. Jeffrey Ullman20 Example uGiven a relation R with attributes A, B, and C satisfies the FD’s A -> B and B -> C, test if R also satisfies the FD A -> C wAssume two tuples agree on A: (a,b 1,c 1 ) and (a,b 2,c 2 ) wSince R satisfies A -> B, they also agree on B: (a,b,c 1 ) and (a,b,c 2 ) wSimilarly, since R satisfies B -> C, they also agree on C: (a,b,c) and (a,b,c) wSo we proved any two tuples of R that agree on A also agree on C

21. Jeffrey Ullman21 Closure of Attribute Set uThe closure of an attribute set X under the FD’s in S is the attribute set Y such that every relation that satisfies all the FD’s in S also satisfies X -> Y wX -> Y follows from the FD’s in S wWe denote X + = Y

22. Jeffrey Ullman22 Closure Algorithm uAn easier way to test is to compute the closure of Y, denoted Y +. uBasis: Y + = Y. uInduction: Look for an FD’s left side X that is a subset of the current Y +. If the FD is X -> A, add A to Y +.

23. Jeffrey Ullman23 Y+Y+ new Y + XA

24. Jeffrey Ullman24 Closure Algorithm (2) uRepeat the induction step until no more attribute can be added to Y +. wY + is the closure of Y. uThe closure algorithm claims only true FD’s uThe closure algorithm discovers all true FD’s

25. Jeffrey Ullman25 Closure Test uFor the transitive rule wIf X -> Y and Y -> Z hold in relation R, then X -> Z also holds in R uIf we can compute the closure of X (X + ) and Z is a subset of X +, then the rule is proved wNeed to use the trivial-dependency rule