1. M.P. Johnson, DBMS, Stern/NYU, Spring 20081 C20.0046: Database Management Systems Lecture #4 M.P. Johnson Stern School of Business, NYU Spring, 2008

2. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 2 Agenda Last time: relational model This time: 1. Functional dependencies  Keys and superkeys in terms of FDs  Finding keys for relations 2. Extended E/R example 3. Rules for combining FDs Next time: anomalies & normalization Pick groups

3. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 3 Where are we going, where have we been? Goal: manage large amounts of data effectively  Use a DBMS  must define a schema DBMSs use the relational model  But initial design is easier in E/R  Must design an E/R diagram  Must then convert it to rel. model

4. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 4 Where are we going, where have we been? At this pt, often find problems – redundancy  How to fix?  Convert the tables to a special “normal” form  How to do this?  First step is: check which FDs there are  The reason we looked at FDs last time  Will have to look at all true FDs of the table  Then well do decompositions

5. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 5 Next topic: Functional dependencies FDs are constraints  Logically part of the schema  can’t tell from particular relation instances  FD may hold for some instances “accidentally” Finding all FDs is part of DB design  Used in normalization

6. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 6 Functional dependencies Definition: Notation: Read as: A i functionally determines B j If two tuples agree on the attributes A 1, A 2, …, A n then they must also agree on the attributes B 1, B 2, …, B m A 1, A 2, …, A n  B 1, B 2, …, B m

7. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 7 Typical Examples of FDs Product  name  price, manufacturer Person  ssn  name, age  father’s/husband’s-name  last-name  zipcode  state  phone  state (notwithstanding inter-state area codes?) Company  name  stockprice, president  symbol  name  name  symbol

8. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 8 Functional dependencies To check A  B, erase all other columns; for all rows t1, t2 i.e., check if remaining relation is many-one  no “divergences”  i.e., if A  B is a well-defined function  thus, functional dependency BmBm...B1B1 AmAm A1A1 t1t1 t2t2 if t 1, t 2 agree here then t 1, t 2 agree here

9. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 9 FD example Product(name, category, color, department, price) name  color category  department color, category  price name  color category  department color, category  price Consider these FDs: What do they say?

10. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 10 FD example FDs as properties: On some instances they hold On others they don’t namecategorycolordepartmentprice GizmoGadgetGreenToys49 TweakerGadgetGreenToys99 Does this instance satisfy all the FDs? name  color category  department color, category  price name  color category  department color, category  price

11. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 11 FD example namecategorycolordepartmentprice GizmoGadgetGreenToys49 TweakerGadgetBlackToys99 GizmoStationaryGreen Office- supp. 59 What about this one? name  color category  department color, category  price name  color category  department color, category  price

12. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 12 Q: Is Position  Phone an FD here? A: It is for this instance, but no, presumably not in general Others FDs? EmpID  Name, Phone, Position but Phone  Position Recognizing FDs EmpIDNamePhonePosition E0045Smith1234Clerk E1847John9876Salesrep E1111Smith9876Salesrep E9999Mary1234Lawyer

13. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 13 Keys of relations {A 1 A 2 A 3 …A n } is a key for relation R if  A 1 A 2 A 3 …A n functionally determine all other atts Usual notation: A 1 A 2 A 3 …A n  B 1 B 2 …B k rels = sets  distinct rows can’t agree on all A i  A 1 A 2 A 3 …A n is minimal No proper subset of A 1 A 2 A 3 …A n functionally determines all other attributes of R Primary key: chosen if there are several possible keys

14. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 14 Keys example Relation: Student(ssn,Name, Address, DoB, Email, Credits) Which (/why) of the following are keys?  SSN  Name, Address (on reasonable assumptions)  Name, SSN  Email, SSN  Email NB: minimal != smallest

15. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 15 Superkeys Df: A set of attributes that contains a key Satisfies first condition: determination Might not satisfy the second: minimality  Some superkey attributes may be superfluous  keys are superkeys key are special case of superkey  superkey set is superset of key set name;ssn is a superkey but not a key

16. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 16 Discovering keys for relations Relation  entity set  Key of relation = (minimized) key of entity set Relation  binary relationship  Many-many: union of keys of both entity sets  Many(M)-one(O): only key of M (why?)  One-one: key of either entity set (but not both!)

17. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 17 Review: entity sets Key of entity set = key of relation Student(Name, Address, DoB, SSN, Email, Credits) Student Name Address DoB SSN Email Credits

18. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 18 Review: many-many Many-many key: union of both ES keys StudentEnrolls Course SSNCredits CourseID Name Enrolls(SSN,CourseID)

19. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 19 Review: many-one Key of the many ES but not of the one ES  keys from both would be non-minimal CourseMeetsIn Room CourseIDName RoomNo Capacity MeetsIn(CourseID,RoomNo)

20. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 20 Review: one-one Keys of both ESs included in relation Key is key of either ES (but not both!) HusbandsMarriedWives SSNName SSN Name Married(HSSN, WSSN) or Married(HSSN, WSSN)

21. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 21 Review: multiway relships Multiple ways – may not be obvious R:F,G,H  E is many-one  E’s key is included  but not part of key  Recall that relship atts are implicitly many-one CourseEnrolls Student CourseID Name SSN NameSection RoomNo Capacity Enrolls(CourseID,SSN,RoomNo)

22. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 22 Extended E/R example: Exercise 2.3 Profs have: ssn, name, age, rank, specialty Projs have: proj#, sponsor name (e.g. NSF), start date, end date, budget Grad students have: ssn, name, age, degree program Each proj: managed by one prof Each proj: worked on by one or more profs Each proj: worked on by one or more grad students When grad students work on a proj, a prof must supervise their work. Grad students may have different supervisors for each proj. Depts have: dept#, dept name, main office Profs work in one or more departments, and a percent-worked in each dept Grad students have one major dept in which they work Then convert to relations…

23. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 23 Extended E/R example: Exercise 2.7 Patients are ID’ed by ssn, and they have names, addresses, and ages Doctors are ID’ed by ssn. For each doctor, record name, specialty, years of experience Each pharm. company is ID’ed by name and has a phone number For each drug, the trade name and foruma are recorded. Each is sold by a given pharm. company, and the trade name ID’s a drug uniquely from the products of that company. If a pharm. company is deleted, you need not keep track of its products any longer. Each pharmacy has: name, address, phone number Every patient has a primary physician. Doctors can have multiple patients. Each pharmacy can sell several drugs and has a price of each. A drug price could vary between pharmacies. Doctors prescribe drugs for patients. A doctor could prescribe multiple drugs for multiple patients, and a patient could obtain prescriptions from multiple doctors. Each prescription has a date and quantity. Assume that if a doctor prescribes the same drug for the same patient multiple times, we only record the last prescription. A pharm. company can contract with several pharmacies, and vice versa. For each contract, store the text and start and end dates. Pharmacies appoint a unique supervisor for each contract. How would this change if each drug had a single price?

24. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 24 Next topic: Combining FDs If some FDs are satisfied, then others are satisfied too If all these FDs are true: name  color category  department color, category  price name  color category  department color, category  price Then this FD also holds: name, category  price Why?

25. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 25 Rules for FDs (quickly) Reasoning about FDs: given a set of FDs, infer other FDs – useful  E.g. A  B, B  C  A  C Definitions: for FD-sets S and T  T follows from S if all relation-instances satisfying S also satisfy T.  S and T are equivalent if the sets of relation- instances satisfying S and T are the same.  I.e., S and T are equivalent if S follows from T, and T follows from S.

26. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 26 Splitting & combining FDs (quickly) Splitting rule: Combining rule: Note: doesn’t apply to the left side Q: Can you split and combine the A’s, too? A 1 A 2 …A n  B 1 B 2 …B m A 1, A 2, …, A n  B 1 A 1, A 2, …, A n  B 2..... A 1, A 2, …, A n  B m A 1, A 2, …, A n  B 1 A 1, A 2, …, A n  B 2..... A 1, A 2, …, A n  B m Bm...B1Am...A1 t1 t2

27. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 27 Reflexive rule: trivial FDs (quickly) FD A 1 A 2 …A n  B 1 B 2 …B k may be  Trivial: Bs are a subset of As  Nontrivial: >=1 of the Bs is not among the As  Completely nontrivial: none of the Bs is among the As Trivial elimination rule:  Eliminate common attributes from Bs, to get an equivalent completely nontrivial FD A 1, A 2, …, A n  A i with i in 1..n is a trivial FD A1A1 …AnAn t t’

28. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 28 Transitive rule (quickly) If and then A 1, A 2, …, A n  B 1, B 2, …, B m B 1, B 2, …, B m  C 1, C 2, …, C p A 1, A 2, …, A n  C 1, C 2, …, C p A1A1 …AmAm B1B1 …BmBm C1C1...CpCp t t’

29. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 29 Augmentation rule (quickly) If then A 1, A 2, …, A n  B A 1, A 2, …, A n, C  B, C, for any C A1A1 …AmAm B1B1 …BmBm C1C1...CpCp t t’

30. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 30 Rules summary (quickly) 1. A  B  AC  B (by definition) 2. Separation/Combination 3. Reflexive 4. Augmentation 5. Transitivity Last 3 called Armstrong’s Axioms  Complete: entire closure follows from these  Sound: no other FDs follow from these Don’t need to memorize details…

31. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 31 Inferring FDs example (quickly) Start from the following FDs: Infer the following FDs: 1. name  color 2. category  department 3. color, category  price 1. name  color 2. category  department 3. color, category  price Inferred FD Which Rule did we apply? 4. name, category  name 5. name, category  color 6. name, category  category 7. name, category  color, category 8. name, category  price Reflexive rule Transitivity(4,1) Reflexive rule combine(5,6) or Aug(1) Transitivity(3,7)

32. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 32 Problem: infer all FDs Given a set of FDs, infer all possible FDs How to proceed? Try all possible FDs, apply all rules  E.g. R(A, B, C, D): how many FDs are possible? Drop trivial FDs, drop augmented FDs  Still way too many Better: use the Closure Algorithm…

33. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 33 Closure of a set of Attributes Given a set of attributes A 1, …, A n The closure, {A 1, …, A n } + = {B in Atts: A 1, …, A n  B} Given a set of attributes A 1, …, A n The closure, {A 1, …, A n } + = {B in Atts: A 1, …, A n  B} name  color category  department color, category  price name  color category  department color, category  price Example: Closures: {name} + = {name, color} {name, category} + = {name, category, color, department, price} {color} + = {color}

34. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 34 Closure Algorithm Start with X={A 1, …, A n }. Repeat: if B 1, …, B n  C is a FD and B 1, …, B n are all in X then add C to X. until X doesn’t change Start with X={A 1, …, A n }. Repeat: if B 1, …, B n  C is a FD and B 1, …, B n are all in X then add C to X. until X doesn’t change {name, category} + = {name, category, color, department, price} name  color category  department color, category  price name  color category  department color, category  price Example:

35. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 35 Example Compute {A,B} + X = {A, B, } Compute {A, F} + X = {A, F, } R(A,B,C,D,E,F) A, B  C A, D  E B  D A, F  B A, B  C A, D  E B  D A, F  B In class:

36. M.P. Johnson, DBMS, Stern/NYU, Spring 2008 36 Next time Read ch.19, sections 4-5