1. Matthew P. Johnson, OCL3, CISDD CUNY, June 20051 OCL3 Oracle 10g: SQL & PL/SQL Session #2 Matthew P. Johnson CISDD, CUNY June, 2005

2. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 2 New topic: Design Principles Faithfulness Avoiding redundancy Simplicity Choice of relationships Picking elements

3. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 3 Faithfulness Is the relationship many-many or many-one? Are the attributes appropriate? Are the relationships applicable to the entities? Examples  Courses & instructors maybe many-one, maybe many-many  Bosses & subordinates maybe one-many, maybe many-many

4. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 4 Simplicity Einstein: Theories as simple as possible, but not simpler. Use as few elements as possible  Minimum required relations  No unnecessary attributes (will you be using this attribute?)  Eliminate “spinning wheels” Example: how can we simplify this? MoviesOwningsStudios Owned-byOwns

5. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 5 Avoiding redundancy Say everything exactly once  Minimize database storage requirements  More important: prevent possible update errors simplest but not only e.g.: modify data one place but not the other – more later Example: Spot the redundancy StudiosMovies Own StudioName Name Length Name Address

6. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 6 Avoiding redundancy Say everything exactly once  Minimize database storage requirements  More important: prevent possible update errors simplest but not only e.g.: modify data one place but not the other – more later Example: Spot the redundancy StudiosMovies Own StudioName Name Length Name Address Redundancy: Movies “knows” the studio two ways Phone

7. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 7 Spot more redundancy Different redundancy: studio info listed for every movie! Movies StudioName Name Length SAddress SPhon e Name Length Studio SAddress SPhone Pulp Fiction… Miramax NYC 212-… Sylvia… Miramax NYC 212-… Jay & Sil. Bob … Miramax NYC 212-… …

8. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 8 Don’t add relships that are implied StudentsCourses TAs Enrolls TA-of Assist Suppose each course again has <=1 TA Q: Is the following good design? A: If TAs other than the course’s TA can help students, then yes; if not, then no: we can connect Students and TAs by going through Courses; redundant!

9. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 9 Correct E/R models may contain loops Person plays multiple roles:  employee of company  buyer of product price address namessn Person buys makes employs Company Product namecategory stockprice name

10. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 10 More design: attribute  entity  Repeating TA names & IDs – redundant  TA is not TAing any course now  lose TA’s data!  TAs should get their own ES StudentsCourses Enrolls Q: What’s wrong with this design? A: TA-NameTA-ID TA-Email Course-ID CName

11. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 11 Opposite problem: entity  attribute Some E/Rs improved by removing entities Can convert Entity E into attributes of F if 1. R:F  E is many-one  one-one counts because special case 2. Attributes for E are independent of each other  knowing one att val doesn’t tell us another att val Then  remove E  add all attributes of E to F

12. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 12 StudentsCourses Enrolls TA-Name Assists TA Entity  attribute CName Room StudentsCourses Enrolls CName Room TA-Name Course-ID

13. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 13 Convert TA entity again? No! Multiple TAs allowed Violates condition (1) Redundant course data StudentsCourses Enrolls Assists TA CName CIDRoom TA-Name DBMS 46 123 Howard DBMS 46 123 Wesley … CName Room Course-ID TA-Name

14. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 14 Convert TA entity again? StudentsCourses Enrolls Assists TA CName Room Course-ID TA-IDTA-Favorite-Color No! TA has dependent fields Violates condition (2)  How can it tell? Redundant TA data CName TA-Name TA-ID TA-Color DBMS Ralph 678 Green C++ Ralph 678 Green … TA-Name

15. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 15 Entity or attributes? Should student address be an entity or an attribute? If student may have multiple addresses, must be entity  campus address, permanent address  attributes cannot be set-valued If we need to examine structure of address, must be entity  find all students from NYS but not NYC If attribute, then it’s probably a simple string  no structure!  NB: this choice is a microcosm of entire miniworld  (much) power of a DB comes from the structure imposed on the data

16. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 16 Larger example DB design Application: library database. Authors have written books about various subjects; different libraries in the system may carry these books. Entities (with attributes in parentheses):  Authors (ssn, name, phone, birthdate)  Books (ISDN, title)  Subjects (sname, sid)  Libraries (lname) Relations [associating entities in square brackets]:  Wrote-on [Authors, Subjects]  Cover [Libraries, Subjects]  On [Books, Subjects]

17. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 17 E/R of DB design Name Author ssnphonebirthdate wrote-on Subject SName Title Carries Library LName On Book ISBN

18. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 18 Poor initial design First design is a poor model of this system Some info not captured:  How many copies does a lib. have of a given book?  What edition of a book does the library have? Design problems:  no direct relship associating authors and books  no direct relship associating libraries and books Common queries complex, difficult, or impossible  What libraries carry books by a given author?  What books has a given author written?  Who is the author of a given book?

19. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 19 Larger example DB design 2 Application: library database as before Entities (with attributes in parentheses):  Authors (ssn, name, phone, birthdate)  Books (ISDN, title)  Subjects (sname, sid)  Libraries (lname) Relations [associating entities in square brackets] (attributes in parentheses):  Wrote [Authors, Books]  Carries [Libraries, Books] (quantity, edition)  On [Books, Subjects]

20. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 20 E/R of improved DB design Rule of thumb: often queried together  make closely connected Name Author ssnphonebirthdate wrote Book ISBN Title Carries Library LName Edition Quantity On Subject SName

21. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 21 Agenda Before: E/R models, design & redundancy Constraints  Identifying & specifying key attributes to an entity set  Recognizing other types of single-valued constraints  Representing referential integrity constraints  Identifying & representing general constraints Weak entity sets

22. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 22 Next topic: Constraints Review: programmer-defined rules stating what should always be true about consistent databases Restrictions on data:  Keys (e.g. SSNs uniquely identify people)  Single value constraints (e.g. everyone has 1 father)  Referential Integrity (e.g. person’s record refers to father  father must exist)  Domain constraints (e.g. gender in M/F, age in 0..150)  General constraints (e.g. no more than 10 customers per sales rep) Can’t infer constraints from data  may hold “accidentally”  they are a part of the schema

23. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 23 E/R keys Uniquely identifies 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 intentional key attribute  E.g. SSN, course-id, employee-id, etc.  SSN likely shorter than (name,address)  Prevents quasi-redundancy address namessn Person

24. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 24 Single-valued constraints “at most one” value  sharp arrows E.g. attributes: could be null or one Many-one relationships: the “one” part is single-valued. Can think of key atts as (non-null) single- valued TACourse Assists

25. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 25 Referential integrity “Exactly one value” NOT NULL attributes 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  Ways of handling deletion: Prevent deletion as long as referrer exist Enforce deletion of all referrers InstructorCourse Taught

26. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 26 Referential integrity – E/R e.g. Insertion – must refer to existing entity Suppose need to add  course: “OCL3”  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

27. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 27 Other kinds of constraints Domain constraints  E.g. date: must be after 1900  Enumerated type: grades A through F, no E  No specific E/R notation: mention with attribute or relationship General constraints:  A class may have no more than 100 students; a student may not have more than 6 courses: StudentsCourses Enroll <=6<=100

28. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 28 Next topic: Weak entity sets Definition:  Some or all key attributes belong to another ES Why:  An entity set is part of a hierarchy (not ISA)  Connecting entity sets The key consists of  0, 1 or more of its own attributes  Key attributes of entity sets from supporting relationships

29. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 29 Conditions of Supporting relationships Supporting relationship R:E  F  R is many-one (E-F) (or one-one)  R is binary  Referential integrity from E to F a rounded arrow  Those atts supplied to E are the key attributes of F  F itself may be weak Another entity set G, and so on recursively  A1 A2 R E F

30. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 30 For several supporting relships from E to F  Keys of each F role appear as foreign key of E Other many-one relationships  Not necessarily supporting Requirements for weak entity sets Buyer Seller Trades A1 A2 A3 People Stores Date  

31. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 31 Weak entity sets Example: Hierarchy – species & genus Idea: species name unique per genus only Species name Belongs-to Genus name 

32. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 32 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

33. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 33 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

34. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 34 Review: E/R example Exercise: email addresses & logins  address = username @ host  mpjohnson @ gmail.com  Password file stores logins, not full addresses  Draw E/R diagram with weak entity set Users supported by entity set Hosts Could we design this differently?  Why/why not?

35. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 35 Agenda Before: finished E/R models per se Now: Intro to relational model Converting ER diagrams to relations Functional dependencies  Keys and superkeys in terms of FDs  Finding keys for relations  Rules of FDs Normalization

36. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 36 Next topic: the Relational Data Model the World E/R design Relational schema Relational DB

37. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 37 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.

38. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 38 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

39. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 39 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

40. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 40 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

41. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 41 More on tuples Formally, can also be a mapping  from attribute names to (correctly typed) values: name  gizmo price  $19.99 category  gadgets manuf.  GizmoWorks NB: ordered tuple is equiv to mapping  Both ways supported in SQL Sometimes we refer to a tuple by itself (note order of attributes)  (gizmo, $19.99, gadgets, GizmoWorks) or  Product(gizmo, $19.99, gadgets, GizmoWorks).

42. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 42 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, expensive (why?)

43. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 43 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

44. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 44 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

45. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 45 Entity Sets Entity set Students ssn name address Students John Howard Name North Carolina444-555-6666 Park Avenue111-222-3333 AddressSSN Rel: Students

46. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 46 Entity Sets Course CourseID CourseName

47. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 47 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

48. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 48 Many-to-one relationships Key: keys of many entity 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

49. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 49 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

50. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 50 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’

51. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 51 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

52. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 52 Many-to-many relationships again MovieIDTitleYearStarID M101Talented Mr. Ripley1999T400 M101Talented Mr. Ripley1999T401 M101Talented Mr. Ripley1999T402 M202Sylia2003T400 M303Punch Drunk Love2003T401 And here’s why:

53. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 53 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

54. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 54 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

55. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 55 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?)

56. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 56 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

57. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 57 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

58. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 58 Conversion example Video store rental example, plus some atts Q: Conversion to relations? Rental VideoStore Customer Movie date year MName address Cname MID

59. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 59 Conversion example, continued Resulting binary-relationship version Q: Conversion to relations? Rental Customer Store Movie StoreOf MovieOf BuyerOf date year MName address Cname MID

60. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 60 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

61. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 61 Converting inheritance hierarchies Movies Cartoons Murder- Mysteries isa Voices Weapon stars length titleyear Lion King Component

62. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 62 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

63. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 63 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 Better: introduce “movie-id” key att

64. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 64 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.

65. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 65 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

66. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 66 Agenda Before: relational model Next: 1. Functional dependencies  Keys and superkeys in terms of FDs  Finding keys for relations 2. Rules for combining FDs And then: anomalies & normalization

67. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 67 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

68. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 68 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

69. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 69 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

70. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 70 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

71. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 71 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?

72. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 72 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

73. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 73 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

74. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 74 Q: Is Position  Phone an FD here? A: It is for this particular instance, but no, presumably not in general Others FDs? EmpID  Name, Phone, Position but Phone  Position Recognizing FDs EmpIDNamePhonePosition E0045Smith1234Clerk E1847John9876Salesrep E1111Smith9876Salesrep E9999Mary1234Lawyer

75. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 75 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

76. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 76 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

77. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 77 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

78. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 78 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!)

79. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 79 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

80. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 80 Example – many-many Many-many key: union of both ES keys StudentEnrolls Course SSNCredits CourseID Name Enrolls(SSN,CourseID)

81. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 81 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)

82. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 82 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)

83. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 83 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)

84. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 84 Rules for FDs Reasoning about FDs: given a set of FDs, infer other FDs – useful E.g. A  B, B  C  A  C Definitions: for FD-sets S and T  T follows from S if all relation-instances satisfying S also satisfy T.  S and T are equivalent if the sets of relation- instances satisfying S and T are the same.  I.e., S and T are equivalent if S follows from T, and T follows from S.

85. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 85 Combining FDs If some FDs are satisfied, then others are satisfied too If all these FDs are true: name  color category  department color, category  price name  color category  department color, category  price Then this FD also holds: name, category  price Why?

86. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 86 Splitting & combining FDs Splitting rule: Combining rule: Note: doesn’t apply to the left side Q: Does it apply to the left side? A 1 A 2 …A n  B 1 B 2 …B m A 1, A 2, …, A n  B 1 A 1, A 2, …, A n  B 2..... A 1, A 2, …, A n  B m A 1, A 2, …, A n  B 1 A 1, A 2, …, A n  B 2..... A 1, A 2, …, A n  B m Bm...B1Am...A1 t1 t2

87. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 87 Reflexive rule: trivial FDs FD A 1 A 2 …A n  B 1 B 2 …B k may be  Trivial: Bs are a subset of As  Nontrivial: >=1 of the Bs is not among the As  Completely nontrivial: none of the Bs is among the As Trivial elimination rule:  Eliminate common attributes from Bs, to get an equivalent completely nontrivial FD A 1, A 2, …, A n  A i with i in 1..n is a trivial FD A1A1 …AnAn t t’

88. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 88 Transitive rule If and then A 1, A 2, …, A n  B 1, B 2, …, B m B 1, B 2, …, B m  C 1, C 2, …, C p A 1, A 2, …, A n  C 1, C 2, …, C p A1A1 …AmAm B1B1 …BmBm C1C1...CpCp t t’

89. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 89 Example R(A,B,C) Each of three determines other two Q: What are the FDs?  Closure of singleton sets  Closure of doubletons Q: What are the keys? Q: What are the minimal bases?

90. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 90 Examples of Keys Product(name, price, category, color) name, category  price category  color Keys are: {name, category} Enrollment(student, address, course, room, time) student  address room, time  course student, course  room, time Keys are: [in class]

91. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 91 Where are we going, where have we been? Goal: manage large amounts of data effectively  Use a DBMS  must define a schema DBMSs use the relational model  But initial design is easier in E/R  Must design an E/R diagram  Must then convert it to rel. model

92. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 92 Where are we going, where have we been? At this pt, often find problems – redundancy  How to fix?  Convert the tables to a special “normal” form  How to do this?  First step is: check which FDs there are  The reason we looked at FDs last time  Will have to look at all true FDs of the table  Then well do decompositions

93. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 93 Next Lab 2 online Readings posted for tomorrow Tomorrow:  Briefly discuss normalization  Install Oracle

94. Matthew P. Johnson, OCL3, CISDD CUNY, June 2005 94 E/R to relational model courses Depts Computer- allocation room number givenBy name chair