1 Lecture 7 Design Theory for Relational Databases (part 1) Slides based on CS4416 Database Systems CS5122 Development of IS 2

2 Relational Schema Design uGoal of relational schema design is to avoid anomalies and redundancy. wUpdate anomaly : one occurrence of a fact is changed, but not all occurrences. wDeletion anomaly : valid fact is lost when a tuple is deleted.

3 Functional Dependencies (FD's)

4 Functional Dependencies uX Y 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 all attributes in set Y. wSay X Y holds in R. or X functionally determines Y 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 }.

5 Splitting Right Sides of FDs uX A 1 A 2 …A n holds for R exactly when each of X A 1, X A 2,…, X A n hold for R. uExample: A BC is equivalent to A B and A C. u There is no splitting rule for left sides. uWell generally express FDs with singleton right sides.

6 Example: FD's nameaddr beersLiked manffavBeer JanewayVoyager Bud A.B.WickedAle JanewayVoyager WickedAle PetesWickedAle SpockEnterprise Bud A.B.Bud Because name addr Because name favBeer Because beersLiked manf Drinkers(name, addr, beersLiked, manf, favBeer)

7 Example: FDs (contd.) Drinkers(name, addr, beersLiked, manf, favBeer) uReasonable FDs to assert: 1.name addr favBeer wThis is the same as name addr and name favBeer. 2.beersLiked manf

8 Example of Bad Design Drinkers(name, addr, beersLiked, manf, favBeer) nameaddrbeersLikedmanffavBeer JanewayVoyagerBudA.B.WickedAle Janeway???WickedAlePetes??? SpockEnterpriseBud???Bud Data is redundant, because each of the ???s can be figured out by using the FDs name addr favBeer and beersLiked manf.

9 This Bad Design Also Exhibits Anomalies nameaddrbeersLikedmanffavBeer JanewayVoyagerBudA.B.WickedAle JanewayVoyagerWickedAlePetesWickedAle SpockEnterpriseBudA.B.Bud Update anomaly: if Janeway is transferred to Intrepid, will we remember to change each of her tuples? Deletion anomaly: If nobody likes Bud, we lose track of the fact that Anheuser-Busch manufactures Bud.

10 Keys

11 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.

12 Example: Superkey 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

13 Example: Key u{name, beersLiked} is a key because neither {name} nor {beersLiked} is a superkey. wname doesnt manf; wbeersLiked doesnt addr. uThere are no other keys, but lots of superkeys. wAny superset of {name, beersLiked}.

14 Where Do Keys Come From? 1.Just assert a key K (usually some sort of id). wThe only FDs are K A for all attributes A. 2.Assert FDs and deduce the keys by systematic exploration. wImportant for normalization (see next lecture).

15 Inferring FD's

16 Inferring FDs uWe are given FDs 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 FDs. wExample: If A B and B C hold, surely A C holds, even if we dont say so.

17 Closure Test uAn easier way to test is to compute the closure of Y, denoted Y +, and check if B is an element of in Y +. uStep 1: Start with Y + = Y. uStep 2: Look for an FDs X A whose left side X is in the current Y +. wIf there is no such FD stop. wIf there is such an FD, A to Y + and repeat Step 2.

18 Y+Y+ new Y + XA

19 Finding All Implied FDs Simple, Exponential Algorithm 1.For each set of attributes X, compute X +. 2.Add X A for all A in X + ̶ X. 3.However, drop XY A whenever we discover X A. uBecause XY A follows from X A in any projection.

20 A Few Tricks uNo need to compute the closure of the empty set or of the set of all attributes. uIf we find X + = all attributes, so is the closure of any superset of X.

21 Example uABC with FDs A B and B C. Find all implied FDs. wA + =ABC ; yields A B, A C. We do not need to compute AB + or AC +. wB + =BC ; yields B C. wC + =C ; yields nothing. wBC + =BC ; yields nothing. uResulting FDs: A B, A C, and B C.

22 Visual Representation of FD's (optional material)

23 Visual Representation of FD's uImagine the set of all instances of a particular relation. uThat is, all finite sets of tuples that have the proper number of components. uEach instance is a point in this space.

24 Example: R(A,B,C) {(1,2,3), (3,4,5)} {} {(1,2,3), (3,4,5), (1,3,5)} {(5,1,1)} {(1,2,3), (1,2,4)}

25 An FD is a Subset of Instances uFor each FD X A there is a subset of all instances that satisfy the FD. uWe can represent an FD by a region in the space. uTrivial FD = an FD that is represented by the entire space. wExample: A A.

26 Example: A -> B for R(A,B) A B {(1,2,3), (3,4,5)} {} {(1,2,3), (3,4,5), (1,3,5)} {(5,1,1)} {(1,2,3), (1,2,4)}

27 Representing Sets of FDs uIf each FD is a set of relation instances, then a collection of FDs corresponds to the intersection of those sets. wIntersection = all instances that satisfy all of the FDs.

28 Example A B B C CD A Instances satisfying A B, B C, and CD A

29 Implication of FDs uIf an FD Y B follows from FDs X 1 A 1,…,X n A n, then the region in the space of instances for Y B must include the intersection of the regions for the FDs X i A i. wThat is, every instance satisfying all the FDs X i A i surely satisfies Y B. wBut an instance could satisfy Y B, yet not be in this intersection.

30 Example A->B B->C A->C