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

2. M.P. Johnson, DBMS, Stern/NYU, Sp2004 2 Agenda Last time: finished E/R models per se Announcement: may have occasional pop quizzes  at start of class  On reading  Counting toward participation/attendance grade This time: Intro to relational model Converting E/Rs to relations Functional dependencies  Keys and superkeys in terms of FDs  Finding keys for relations

3. M.P. Johnson, DBMS, Stern/NYU, Sp2004 3 Review: E/R example Exercise 2.4.1  Students enroll in courses and get grades  Enrollments as a connecting entity set Represent students taking the course Grade of a student for a course  Draw E/R diagram Indicate weak entity sets & their keys Is the grade part of the key for enrollments?

4. M.P. Johnson, DBMS, Stern/NYU, Sp2004 4 Next topic: the Relational Data Model (3.1) Database Model (E/R, other) Relational Schema Physical storage Diagrams (E/R) Tables: column names: attributes rows: tuples Complex file organization and index structures.

5. M.P. Johnson, DBMS, Stern/NYU, Sp2004 5 Relations as tables Name Price Category Manufacturer gizmo $19.99 gadgets GizmoWorks Power gizmo $29.99 gadgets GizmoWorks SingleTouch $149.99 photography Canon MultiTouch $203.99 household Hitachi tuples/rows/records/entities Attribute names Product table/relation

6. M.P. Johnson, DBMS, Stern/NYU, Sp2004 6 Relational terminology Relation is composed of tuples Tuples composed of attribute values  Attribute has atomic types Relation schema: relation name + attribute names + attribute types Relation instance: set of tuples  order doesn’t matter Database schema: set of relation schemas Database instance: relation instance for every relation in the schema

7. M.P. Johnson, DBMS, Stern/NYU, Sp2004 7 Relations as sets Remember: math relation is a subset of the cross-product of the attribute value sets  R subset-of S x T  Product subset-of Name x Price x Cat x Mft One member of Product:  (gizmo, $19.99, gadgets, GizmoWorks) in Product DB Relation instance = math relation Q: If relations are sets, why call “instances”? A: R is a member of the powerset P(SxT)  powerset = set of all subsets

8. M.P. Johnson, DBMS, Stern/NYU, Sp2004 8 More on tuples Formally, can also be a mapping  from attribute names to (correctly typed) values: name  gizmo price  $19.99 category  gadgets manufacturer  GizmoWorks NB: ordered tuple is equiv to mapping Sometimes we refer to a tuple by itself (note order of attributes)  (gizmo, $19.99, gadgets, GizmoWorks) or  Product(gizmo, $19.99, gadgets, GizmoWorks).

9. M.P. Johnson, DBMS, Stern/NYU, Sp2004 9 Updates The database maintains a current database state Modifications of data:  add a tuple  delete a tuple  update an attribute value in a tuple DB Relation instance = math relation Idea: we saw partic. Product DB instance  add, delete rows  different DB rel. instances  technically, different math relations  to DBMS, still the same relation Modifications to the data are frequent Updates to the schema are rare, painful (Why?)

10. M.P. Johnson, DBMS, Stern/NYU, Sp2004 10 E/R models to relations (3.2)  Recall justification:  design is easier in E/R  implementation is easier/faster in R  Parallel to program compilation:  design is easier in C/Java/whatever  implemen. is easier/faster in machine/byte code  Strategy 1. apply semi-mechanical conversion rules 2. improve by combining some relations 3. improve by normalization involves finding functional dependencies

11. M.P. Johnson, DBMS, Stern/NYU, Sp2004 11 E/R conversion rules Relationship  relation  attributes: keys of entity-sets/roles  key: depends on multiplicity Entity set  … relation  attributes: attributes of entity set  key: key of ES NB: mapping of types is not one-one  We’ll see: mapping one tokens is not one-one Special treatment:  Weak entity sets  Isa relations & subclasses

12. M.P. Johnson, DBMS, Stern/NYU, Sp2004 12 Entity Sets Entity set Students ssn name address Students John Howard Name South Carolina444-555-6666 Park Avenue111-222-3333 AddressSSN Rel: Students

13. M.P. Johnson, DBMS, Stern/NYU, Sp2004 13 Entity Sets Course CourseID CourseName

14. M.P. Johnson, DBMS, Stern/NYU, Sp2004 14 Binary many-to-many relationships Key: keys of both entities Why we learned to recognize keys C30.0046444-555-6666 C20.0056111-222-3333 C20.0046111-222-3333 CourseIDssn Relation: Enrolls Enrolls S_addr S_Name Students Course Course-Name CourseID ssn

15. M.P. Johnson, DBMS, Stern/NYU, Sp2004 15 Many-to-one relationships Key: keys of many entitiy MoviesStudiosowns 2003SyliaM202 1999Mr. Ripley.M101 YearTitleMovieID Movies OrlandoDisneyS73 NYCMiramaxS35 AddressNameStudioID Studios S35 S73 StudioID CN22222 CN11111 CopyrightNo M202 M101 MovieID Owns CopyrightNo MovieID Title Year StudioID Name Address

16. M.P. Johnson, DBMS, Stern/NYU, Sp2004 16 Improving on many-one Note rules applied:  Movies Rel.: all atts from Movies ES  Studios Rel: all atts from Studios ES  Owns Rel: att key atts from Movies & Studios ESs But: Owns:Movies  Studios is many-one  for each row in Movies, there’s a(/no) row in Owns   just add the Owns data to Movies

17. M.P. Johnson, DBMS, Stern/NYU, Sp2004 17 Many-to-one: a better design Q: What if a movie’s Owns row were missing? 2003SyliaM202 1999Mr. Ripley.M101 YearTitleMovieID Movies S35 S73 StudioID CN22222 CN11111 CopyrightNo M202 M101 MovieID Owns CN22222 CN11111 CopyrightNo S35 S73 StudioID 2003 1999 Year SyliaM202 Talent Mr. Ripley M101 TitleMovieID Movies’

18. M.P. Johnson, DBMS, Stern/NYU, Sp2004 18 Many-to-many relationships again Won’t work for many-many relationships acts MovieIDTitleYear M101Mr. Ripley1999 M202Sylia2003 M303P.D. Love2002 StarIDNameAddress T400Gwyneth P.Bev.Hills T401P.S. HoffmanHollywood T402Jude LawPalm Springs MovieIDStarID M101T400 M202T400 M101T401 M101T402 M303T401 Movies Stars Acts Movies Stars

19. M.P. Johnson, DBMS, Stern/NYU, Sp2004 19 Many-to-many relationships again MovieIDTitleYearStarID M101Talented Mr. Ripley1999T400 M101Talented Mr. Ripley1999T401 M101Talented Mr. Ripley1999T402 M202Sylia2003T400 M303Punch Drunk Love2003T401 And here’s why:

20. M.P. Johnson, DBMS, Stern/NYU, Sp2004 20 Multiway relationships & roles Different roles treated as different entity sets Key: keys of the many entities StudentsCourses TAs tutorsgraders enrolls TA_SSN Name SSNCourseID Name

21. M.P. Johnson, DBMS, Stern/NYU, Sp2004 21 Multiway relationships & roles Enrolls(S_SSN, Course_ID, Tutor_SSN, Grader_SSN) SSNName 111-11-1111George 222-22-2222Dick TA_SSNName 333-33-3333Wesley 444-44-4444Howard 555-55-5555John StudentsTAs CourseIDName C20.0046Databases C20.0056Software Courses S_SSNCourseIDTutor_SSNGrader_SSN 111-11-1111C20.0046333-33-3333444-44-4444 222-22-2222C20.0046444-44-4444555-55-5555

22. M.P. Johnson, DBMS, Stern/NYU, Sp2004 22 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?)

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

24. M.P. Johnson, DBMS, Stern/NYU, Sp2004 24 Weak entity sets - relationships Non-support 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

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

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

27. M.P. Johnson, DBMS, Stern/NYU, Sp2004 27 Converting inheritance hierarchies (3.3) 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

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

29. M.P. Johnson, DBMS, Stern/NYU, Sp2004 29 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

30. M.P. Johnson, DBMS, Stern/NYU, Sp2004 30 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.

31. M.P. Johnson, DBMS, Stern/NYU, Sp2004 31 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

32. M.P. Johnson, DBMS, Stern/NYU, Sp2004 32 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 medium number  OO: exponentional in #ESs, so very many (how many?) 3. Number/size of rows per entity  nulls: one “long” row per entity non-applicables become null  OO: one (all-relevant) row per entity, so smallest  E/R: several (tho all relevant) rows per entity  Better of E/R and OO depends (on what?)