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

2. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 2 Admin Textbooks?

3. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 3 Agenda Last time: (nearly) 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: Weak Entity Sets Intro to relational model Converting E/Rs to relations Functional dependencies  Keys and superkeys in terms of FDs  Finding keys for relations

4. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 4 Weak entity sets Example: Hierarchy – species & genus Idea: species name unique per genus only Species name Belongs-to Genus name 

5. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 5 Video store connecting entity sets e.g. was a weak entity set Key: date, MID,SID, CID Weak entity sets    MID SID CID Rental StoreOf MovieOf BuyerOf date Product Store Customer

6. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 6 E/R design summary Subject/design choices:  Should a concept be modeled as an ES or an att?  Should a concept be modeled as an ES or a relship?  Identifying relationships: binary or multiway? Constraints in the ER Model:  Important in determining the best design.  Much data semantics can (and should) be captured  Normalization improves further – later

7. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 7 Review: E/R example Exercise: email addresses & logins  address = username @ host  mjohnson @ stern.nyu.edu  Password table stores just username  Draw E/R diagram with weak entity set Username supported by entity set Host Could we design this differently?  Why/why not?

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

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

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

11. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 11 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 relation:  (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

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

13. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 13 Updates/modifications 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/table Modifications to the data are frequent Updates to the schema are rare, painful (Why?)

14. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 14 E/R models to relations  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

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

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

17. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 17 Entity Sets Course CourseID CourseName

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

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

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

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

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

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

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

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

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

27. M.P. Johnson, DBMS, Stern/NYU, Spring 2005 27 For next week Tuesday’s reading is online Proj1 is due Thursday, start of class