The Relational Data Model

1. The Relational Data Model Tables Schemas Conversion from E/R to Relations Functional Dependencies

2. Attributes (column headers) Tuples (rows) A Relation is a Table name manf Winterbrew Pete’s Bud Lite Anheuser-Busch Beers

3. Schemas • Relation schema = relation name and attribute list. • Optionally: types of attributes. • Example: Beers(name, manf) or Beers(name: string, manf: string) • Database = collection of relations. • Database schema = set of all relation schemas in the database.

4. Why Relations? • Very simple model. • Often matches how we think about data. • Abstract model that underlies SQL, the most important database language today.

5. From E/R Diagrams to Relations Simplest approach (not always best): convert each E.S. to a relation and each relationship to a relation. Entity Set  Relation E.S. attributes become relational attributes. Becomes: Beers(name, manf) name manf Beers

6. Keys in Relations An attribute or set of attributes K is a key for a relation R if we expect that in no instance of R will two different tuples agree on all the attributes of K. • Indicate a key by underlining the key attributes. • Example: If name is a key for Beers: Beers(name, manf)

7. E/R Relationships  Relations Relation has attribute for key attributes of each E.S. that participates in the relationship. • Add any attributes that belong to the relationship itself. • Renaming attributes OK. • Essential if multiple roles for an E.S.

8. Likes husband 2 1 Favorite Buddies Likes(drinker, beer) Favorite(drinker, beer) wife Buddies(name1, name2) Married Married(husband, wife) Relationship -> Relation name name addr manf Drinkers Beers • For one-one relation Married, we can choose either husband or wife as key.

9. Combining Relations • OK to combine into one relation: • The relation for an entity-set E • The relations for many-one relationships of which E is the “many.” • Example: Drinkers(name, addr) and Favorite(drinker, beer) combine to make Drinker1(name, addr, favBeer).

10. Redundancy Risk with Many-Many Relationships • Combining Drinkers with Likes would be a mistake. It leads to redundancy, as: name addr beer Sally 123 Maple Bud Sally 123 Maple Miller

11. Handling Weak Entity Sets • Relation for a weak E.S. must include its full key (i.e., attributes of related entity sets) as well as its own attributes. • A supporting (double-diamond) relationship yields a relation that is actually redundant and should be deleted from the database schema.

12. Must be the same At becomes part of Logins Example name name Logins At Hosts location billTo Hosts(hostName, location) Logins(loginName, hostName, billTo) At(loginName, hostName, hostName2)

13. Subclasses: Three Approaches • Object-oriented: One relation per subset of subclasses, with all relevant attributes. • Use nulls: One relation; entities have NULL in attributes that don’t belong to them. • E/R style: One relation for each subclass: • Key attribute(s). • Attributes of that subclass.

14. Example Beers name manf isa Ales color

15. Object-Oriented name manf Bud Anheuser-Busch Beers name manf color Summerbrew Pete’s dark Ales Good for queries like “find the color of ales made by Pete’s.”

16. E/R Style name manf Bud Anheuser-Busch Summerbrew Pete’s Beers name color Summerbrew dark Ales Good for queries like “find all beers (including ales) made by Pete’s.”

17. Using Nulls name manf color Bud Anheuser-Busch NULL Summerbrew Pete’s dark Beers Saves space unless there are lots of attributes that are usually NULL.

18. Functional Dependencies Meaning of FD’s Keys and Superkeys Inferring FD’s

19. Functional Dependencies • X -> 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. • Say “X -> A holds in R.” • Convention: …, X, Y, Z represent sets of attributes; A, B, C,… represent single attributes. • Convention: no set formers in sets of attributes, just ABC, rather than {A,B,C }.

20. Example Drinkers(name, addr, beersLiked, manf, favBeer) • Reasonable FD’s to assert: • name -> addr • name -> favBeer • beersLiked -> manf

21. Because name -> favBeer Because name -> addr Because beersLiked -> manf Example Data name addr beersLiked manf favBeer Janeway Voyager Bud A.B. WickedAle Janeway Voyager WickedAle Pete’s WickedAle Spock Enterprise Bud A.B. Bud

22. FD’s With Multiple Attributes • No need for FD’s with > 1 attribute on right. • But sometimes convenient to combine FD’s as a shorthand. • Example: name -> addr and name -> favBeer become name -> addr favBeer • > 1 attribute on left may be essential. • Example: bar beer -> price

23. Keys of Relations • K is a superkey for relation R if K functionally determines all of R. • K is a key for R if K is a superkey, but no proper subset of K is a superkey (Minimality)

24. Example Drinkers(name, addr, beersLiked, manf, favBeer) • {name, beersLiked} is a superkey because together these attributes determine all the other attributes. • name -> addr favBeer • beersLiked -> manf

25. Example, Cont. • {name, beersLiked} is a key because neither {name} nor {beersLiked} is a superkey. • name doesn’t -> manf; beersLiked doesn’t -> addr. • There are no other keys, but lots of superkeys. • Any superset of {name, beersLiked}.

26. E/R and Relational Keys • Keys in E/R concern entities. • Keys in relations concern tuples. • Usually, one tuple corresponds to one entity, so the ideas are the same. • But --- in poor relational designs, one entity can become several tuples, so E/R keys and Relational keys are different.

27. Example Data name addr beersLiked manf favBeer Janeway Voyager Bud A.B. WickedAle Janeway Voyager WickedAle Pete’s WickedAle Spock Enterprise 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.

28. Where Do Keys Come From? • Just assert a key K. • The only FD’s are K -> A for all attributes A. • Assert FD’s and deduce the keys by systematic exploration. • E/R model gives us FD’s from entity-set keys and from many-one relationships.

29. More FD’s From “Physics” or Organization Policy • Example: “no two courses can meet in the same room at the same time” tells us: hour room -> course.

30. Inferring FD’s • We are given FD’s X1 -> A1, X2 -> A2,…, Xn -> An, and we want to know whether an FD Y -> B must hold in any relation that satisfies the given FD’s. • Example: If A -> B and B -> C hold, surely A -> C holds, even if we don’t say so. • Important for design of good relation schemas.

31. Inference Test this is important because … • When we talk about improving relational designs, we often need to ask “does this FD hold in this relation?” • Given FD’s X1A1, X2A2,…, XnAn, does FD YB necessarily hold in the same relation? • Start by assuming two tuples agree in Y. • Use given FD’s to infer other attributes on which they must agree. • If B is among them, then yes, else no.

32. Closure Test • An easier way to test is to compute the closure of Y, denoted Y +. • Basis: Y+ = Y. • Induction: 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+.

33. X A new Y+ Y+

34. Closure Test -- Example AB, BCD. • A+ = AB. • C+=C. • (AC)+ = ABCD.

35. Given Versus Implied FD’s Typically, we state a few FD’s that are known to hold for a relation R. • Other FD’s may follow logically from the given FD’s; these are implied FD’s. • We are free to choose any basis for the FD’s of R – a set of FD’s that imply all the FD’s that hold for R.

36. Finding All Implied FD’s • Motivation: “normalization,” the process where we break a relation schema into two or more schemas. • Suppose we have a relation ABCD with some FD’s F. If we decide to decompose ABCD into ABCand AD, what are the FD’s for ABC, AD? • Example: F = ABC, CD, DA. • It looks like just ABC holds in ABC, but in fact CA follows from F and applies to relation ABC.

37. Basic Idea • Start with given FD’s and find all nontrivial FD’s that follow from the given FD’s. • trivial = right side member of left side. • A -> A or AB ->A • Restrict to those FD’s that involve only attributes of the projected schema.

38. Simple, Exponential Algorithm • For each set of attributes X, compute X+. • Add X ->A for all A in X + - X. • However, drop XY ->A if X ->A holds. • Because XY ->A follows from X ->A . • Finally, use only FD’s involving projected attributes.

39. A Few Tricks • No need to compute the closure of the empty set or of the set of all attributes. • If we find X + = all attributes, so is the closure of any superset of X.

40. Example • ABC with FD’s A ->B and B ->C. Project onto AC. • A +=ABC ; yields A ->B, A ->C. • We do not need to compute AB + or AC +. • B +=BC ; yields B ->C. • C +=C ; yields nothing. • BC +=BC ; yields nothing.

41. Example --- Continued • Resulting FD’s: A ->B, A ->C, and B ->C. • Projection onto AC : A ->C. • Only FD that involves a subset of {A,C }.

42. Example Relation ABCD FDs: F = ABC, CD, DA. What FD’s follow? • A+ = A; B+=B (nothing). • C+=ACD (add CA). • D+=AD (nothing new). • (AB)+=ABCD (add ABD; skip all supersets of AB). • (BC)+=ABCD (nothing new; skip all supersets of BC). • (BD)+=ABCD (add BDC; skip all supersets of BD). • (AC)+=ACD; (AD)+=AD; (CD)+=ACD (nothing new). • (ACD)+=ACD (nothing new). • All other sets contain AB, BC, or BD, so skip. • Thus, the only interesting FD’s that follow from F are:CA, ABD, BDC.

43. Example 2 • Set of FD’s in ABCGHI: ABACCGHCGIBH • Compute (CG)+, (BG)+, (AG)+

44. Example 3 In ABC with FD’s A B, B C, project onto AC. • A+ = ABC; yields A B, A C. • B+ = BC; yields B C. • AB+ = ABC; yields AB C; drop in favor of A C. • AC+ = ABC yields AC B; drop in favor of A B. • C+ = C and BC+ = BC; adds nothing. • Resulting FD’s: A B, A C, B C. • Projection onto AC: A C.