1. M.P. Johnson, DBMS, Stern/NYU, Spring 20051 C20.0046: Database Management Systems Lecture #5 Matthew P. Johnson Stern School of Business, NYU Spring, 2005

2. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 2 Converting weak ESs – differences Atts of Crew Rel are:  attributes of Crew  key attributes of supporting ESs CrewUnit-ofStudio StudioName Crew_ID address C2Miramax C1Disney C1Miramax Crew_IDStudioName Crew Supporting relships may be omitted (why?)

3. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 3 Weak entity sets - relationships CrewStudio StudioName Crew_ID address Insurance IName Address 1260 7 th Av.NYBlueCross 1250 6 th Av.NYAetna AddressIName Insurance Subscribes Unit-of

4. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 4 Weak entity sets - relationships Non-supporting relationships for weak ESs are converted  keys include entire weak ES key C21 C22 C21 Crew_ID Aetna BlueCross Aetna Insurer Universal Disney Universal StudioName Subscribes

5. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 5 Conversion example Video store rental example, plus some atts Q: Conversion to relations? Rental VideoStore Customer Movie date year MName address Cname MID

6. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 6 Conversion example, continued Resulting binary-relationship version Q: Conversion to relations? Rental Customer Store Movie StoreOf MovieOf BuyerOf date year MName address Cname MID

7. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 7 Converting inheritance hierarchies No best way Several non-ideal methods:  E/R-style: each ES  relation  OO-style: each possible “object”  relation  nulls-style: each rooted hierarchy  relation non-applicable fields filled in with nulls Pros & cons  for each method, exist situations favoring it

8. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 8 Converting inheritance hierarchies Movies Cartoons Murder- Mysteries isa Voices Weapon stars length titleyear Lion King Component

9. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 9 Inheritance: E/R-style conversion Each ES  relation Root entity set: Movies(title, year, length) 1301993Lion King 1988 1990 1980 Year 110 115 120 length Roger Rabbit Scream Star Wars Title Knife1990R. Rabbit 1988 Year Knife murderWeapon Scream Title Subclass: MurderMysteries(title, year, murderWeapon) Subclass: Cartoons(title, year) 1993Lion King 1990 Year Roger Rabbit Title

10. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 10 Subclasses: object-oriented approach Every possible “subtree” (what’s this?): 1. Movies 2. Movies + Cartoons 3. Movies + Murder-Mysteries 4. Movies + Cartoons + Murder-Mysteries TitleYearlength Star Wars1980120 TitleYearlengthMurder-Weapon Scream1988110Knife TitleYearlength Lion King1990115 TitleYearlengthMurder-Weapon Roger Rabbit1988110Knife 1.3. 2.4.

11. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 11 Subclasses: nulls approach One relation for entire hierarchy Any non-applicable fields are NULL Q: How do we know if a movie is a MM? Q: How do we know if a movie is a cartoon? TitleYearlengthMurder-Weapon Star Wars1980120NULL Lion King1993130NULL Scream1988110Knife Roger Rabbit1990115Knife

12. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 12 Subclasses methods: considerations 1. Query time ~ number of tables accessed in query  nulls: best, since each entity  single row  multi-node questions: “Find 1999 films with length > 150 mins” E/R: just Movies, so fast OO: Movies AND cartoons, so slow  single-node questions: “Find weapons in >150-min. cartoons” E/R: Movies, Cartoons AND MMs, so slow OO: just MoviesCMM, so fast 2. Number of relations per entity set  nulls: just one, so very few  E/R: one per ES, so more  OO: exponential in #ESs, so very many (how many?) 3. Number/size of rows per entity  nulls: one “long” row per entity But all non non-applicables become null  OO: one (all-relevant) row per entity, so smallest  E/R: several (tho all relevant) rows per entity but keys are duplicated

13. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 13 E/R-style & quasi-redundancy Name and year of Roger Rabbit were listed in three different rows (in different tables) Suppose title changes (“Roger”  “Roget”)   must change all three places Q: Is this redundancy? A: No!  name and year are independent  multiple movies may have same name Real redundancy reqs. dependency two rows agree on SSN  must agree on rest  conflicting hair colors in these rows is an error two rows agree on movie title  may still disagree  conflicting years may be correct – or may not be can forbid first case but not second Better: introduce “movie-id” key att

14. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 14 Combined isa/weak example Exercise 3.3.1  Convert from E/R to R, by E/R, OO and nulls courses Lab- courses Depts #machines room cnumber givenBy dname chair isa platform cname

15. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 15 Agenda Last time: relational model This time: 1. Functional dependencies  Keys and superkeys in terms of FDs  Finding keys for relations 2. Rules for combining FDs Next time: anomalies & normalization

16. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 16 Next topic: Functional dependencies FDs are constraints  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

17. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 17 Functional dependencies Definition: Notation: Read: 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

18. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 18 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

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

20. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 20 FDs 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 ?

21. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 21 FDs Example FDs are constraints: 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

22. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 22 FDs 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

23. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 23 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

24. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 24 Keys of relations {A 1 A 2 A 3 …A n } is a key for relation R if 1. A 1 A 2 A 3 …A n functionally determine all other attributes 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 2. 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

25. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 25 Keys example Relation: Student(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

26. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 26 Superkeys A set of attributes that contains a key Satisfies first condition:  functionally determines every other attribute in the relation Might not satisfy the second condition: minimality  may be possible to peel away some attributes from the superkey  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

27. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 27 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!)

28. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 28 Example – entity sets Key of entity set = (minimized) key of relation Student(Name, Address, DoB, SSN, Email, Credits) Student Name Address DoB SSN Email Credits

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

30. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 30 Example – 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)

31. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 31 Example – 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)

32. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 32 Discovering keys: multiway Multiway relationships:  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)

33. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 33 Example Exercise 3.4.2 Relation relating particles in a box to locations and velocities InPosition(id,x,y,z,vx,vy,vz) Q: What FDs hold? Q: What are the keys?

34. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 34 Next time Do reading on web Finish project part 1 Office hours now