Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "M.P. Johnson, DBMS, Stern/NYU, Spring 20081 C20.0046: Database Management Systems Lecture #3 M.P. Johnson Stern School of Business, NYU Spring, 2008."— Presentation transcript:

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

2 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 2 Agenda Last time:  A little on design  (nearly) finished E/R models This time:  Finish E/R  Constraints (some review)  Relational model  Converting E/R to relations Next time: Functional dependencies

3 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 3 Examples

4 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 4 Quick topic: Weak entity sets Def: some or all key attributes belong to another ES Plays role in a connecting relationship The key consists of:  Possibly its own attributes and  All key attributes of entity sets from supporting relationships

5 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 5 Conditions for supporting relationships Supporting relationship R:E  F  R is many-one (or 1-1) E  F  With referential integrity (rounded arrow)  R is binary  E receives key attributes of F F itself may be weak  Another entity set G, and so on recursively…  A1 A2 R E F

6 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 6 For several supporting relships from E to F  Keys of each F role appear as foreign key of E Other, non-supporting many-one relationships are not affected Conditions for weak entity sets Bride Groom Wedding A1 A2 People Witness  

7 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 7 Weak entity set e.g. Example: Hierarchy – species & genus Idea: species name unique per genus only 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 Species Belongs-to Genus 

8 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 8 Examples

9 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 9 Next topic: Constraints Review: programmer-defined rules stating what should always be true about consistent databases Restrictions on data (egs?):  Keys  Single value constraints  Referential Integrity  Domain constraints  General constraints Can’t infer constraints from data  may hold “accidentally”  but they are a part of the schema

10 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 10 E/R keys Uniquely identify entity in ES Attribute or set of attributes  Two entities cannot agree on all key attributes  These attributes determine all others Every ES should have a key  possibly including all attributes Primary key attributes underlined More than one possible key:  Candidate keys, primary key Practical tip: create art key attribute  E.g. SSN, course-id, employee-id, etc.  SSN shorter than (name,address) address namessn Person

11 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 11 Single-valued constraints “at most one” value  Already saw sharp arrows for relationships Attributes have this automatically  could be null or one value  Can think of key atts as (non-null) single-valued TACourse Assists

12 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 12 Referential integrity “Exactly one value”  NOT NULL & foreign keys in SQL Relationships  Non-null value refers to entity that exists  Refer to entity with foreign key  HTML analogy: no broken links  Programming analogy: no dangling pointers  Multiple ways of handling violations… InstructorCourse Taught

13 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 13 Referential integrity – E/R e.g. Insertion – must refer to existing entity Suppose need to add:  course: DBMS  instructor: MPJ Q: Which order? Q: What if relship were exactly-exactly, say, M(Hs,Ws)?  i.e., referential integrity in both directions? A: Put both inserts in one xact – later StudentsCourses Enrolls Instructor Taught

14 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 14 Other kinds of constraints Domain constraints  E.g. date: must be after 1980  Enumerated type: grades A through F, no E  No special E/R notation just write near line General constraints:  A class may have no more than 100 students; a student may not have more than 6 courses: StudentsCourses Enroll <=6<=100

15 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 15 Next topic: the Relational Data Model Invented by Ted Codd  Researcher at IBM  We’ll see his name again… Related work at Berkeley Introduced in a paper a paper published in June, 1970

16 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 16 DB development path the World E/R design Relational schema Relational DB

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

18 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 18 Relational terminology Relation is composed of tuples Tuple = sequence of attribute values  Attribute has atomic types Relation schema: relation name + attribute names + attribute types Database schema: set of relation schemas

19 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 19 Relations as sets Recall: 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  Product(gizmo, $19.99, gadgets, GizmoWorks) Usual updates: add/delete/change a tuple in this set Updates to the schema are rare, painful (why?)

20 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 20 From E/R models to relations Recall justification:  design is easier in E/R  but implementation is easier/faster in R Analogy 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

21 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 21 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 also not one-one Special treatment:  Weak entity sets  Isa relations & subclasses

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

23 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 23 Key: keys of both entities Binary many-to-many relationships 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

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

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

26 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 26 Many-to-many relationships again NB: 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

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

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

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

30 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 30 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 are omitted (why?)

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

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

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

34 M.P. Johnson, DBMS, Stern/NYU, Spring 2008 34 Next week For next week:  Review/skim Ch.3 section 5 (from today)  Read Ch.19 sections 1-3


Download ppt "M.P. Johnson, DBMS, Stern/NYU, Spring 20081 C20.0046: Database Management Systems Lecture #3 M.P. Johnson Stern School of Business, NYU Spring, 2008."

Similar presentations


Ads by Google