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

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

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

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

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

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

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

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

M.P. Johnson, DBMS, Stern/NYU, Spring Inheritance: E/R-style conversion Each ES  relation Root entity set: Movies(title, year, length) Lion King Year 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

M.P. Johnson, DBMS, Stern/NYU, Spring 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 Wars TitleYearlengthMurder-Weapon Scream Knife TitleYearlength Lion King TitleYearlengthMurder-Weapon Roger Rabbit Knife

M.P. Johnson, DBMS, Stern/NYU, Spring 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 Wars NULL Lion King NULL Scream Knife Roger Rabbit Knife

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

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

M.P. Johnson, DBMS, Stern/NYU, Spring Combined isa/weak example Exercise  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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

M.P. Johnson, DBMS, Stern/NYU, Spring Example Exercise 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?

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