1. 1 Lecture 3: Database Modeling (continued) April 5, 2002

2. 2 Q: what do these arrow mean ? A: store, person, invoice determines movie and store, invoice, movie determines person Rental VideoStore Person Movie Invoice Arrows in Multiway Relationships: Correction

3. 3 Roles in Relationships Purchase What if we need an entity set twice in one relationship? Product Person Store salesperson buyer

4. 4 Attributes on Relationships Purchase Product Person Store date

5. 5 Converting Multi-way Relationships to Binary Purchase Person Store Product StoreOf ProductOf BuyerOf date

6. 6 Design Principles Purchase Product Person What’s wrong? President PersonCountry Moral: be faithful!

7. 7 Design Principles: What’s Wrong? Purchase Product Store date personName personAddr Moral: pick the right kind of entities.

8. 8 Design Principles: What’s Wrong? Purchase Product Person Store date Dates Moral: don’t complicate life more than it already is.

9. 9 Next Attactions Subclasses (2.4) Constraints: (2.5) Weak entity sets (2.6)

10. 10 Modeling Subclasses Some objects in a class may be special define a new class better: define a subclass Products Software products Educational products So --- we define subclasses (in ODL and in E/R).

11. 11 Subclasses in ODL interface SoftwareProduct: Product{ attribute string platform; attribute integer requiredMemory; } interface EducationalProduct: Product{ attribute struct Interval {integer begin, integer end} ageGroup; attribute string topic; } interface SoftwareProduct: Product{ attribute string platform; attribute integer requiredMemory; } interface EducationalProduct: Product{ attribute struct Interval {integer begin, integer end} ageGroup; attribute string topic; } The two classes inherit all the properties of Product.

12. 12 Understanding Subclasses Think in terms of records: –Product –SoftwareProduct –EducationalProduct field1 field2 field1 field2 field1 field2 field3 field4 field5

13. 13 Multiple Inheritance in ODL Product Educational Product Educ-software Product Software Product ageGroup topic Platforms required memory Educational-method

14. 14 interface EducSoftwareProduct: SoftwareProduct, EducationalProduct { attribute string educational-method; } interface EducSoftwareProduct: SoftwareProduct, EducationalProduct { attribute string educational-method; }

15. 15 Understanding Multiple Inheritance Think in terms of records: –EducSoftwareProduct field1 field2 field3 field4 field5

16. 16 How do we resolve conflicts? Product Educational Product Educ-software Product Software Product ageGroup topic Platforms required memory Educational-method Rating (ATA) Rating (ASA) Rating?

17. 17 Product namecategory price isa Educational ProductSoftware Product Age Groupplatforms Subclasses in E/R Diagrams

18. 18 ODL: classes are disjoint p1 p2 p3 sp1 sp2 ep1 ep2 ep3 Difference between ODL and E/R inheritance Product SoftwareProduct EducationalProduct

19. 19 E/R: entity sets overlap Difference between ODL and E/R inheritance SoftwareProduct EducationalProduct p1 p2 p3 sp1 sp2 ep1 ep2 ep3 Product

20. 20 No need for multiple inheritance in E/R we have three entity sets, but four different kinds of objects SoftwareProduct EducationalProduct p1 p2 p3 sp1 sp2 ep1 ep2 ep3 Product esp1 esp2

21. 21 Constraints A constraint = an assertion about the database that must be true at all times part of the db schema types in programming languages do not have anything similar correspond to invariants in programming languages

22. 22 Modeling Constraints Finding constraints is part of the modeling process. Commonly used constraints: Keys: social security number uniquely identifies a person. Single-value constraints: a person can have only one father. Referential integrity constraints: if you work for a company, it must exist in the database. Domain constraints: peoples’ ages are between 0 and 150. General constraints: all others (at most 50 students enroll in a class)

23. 23 Keys A set of attributes that uniquely identify an object or entity: Person: social-security-number name name + address name + address + age Perfect keys are often hard to find, so organizations usually invent something.

24. 24 Keys Multi-attribute keys: –E.g. name + address Multiple keys: –E.g social-security-number, name + address

25. 25 Keys in ODL Defining multiple keys: (key ssn employeID (name address age)) interface Person (key ssn) { attribute string ssn; attribute string name;... }

26. 26 Keys in E/R Diagrams address namessn Person Product namecategory price No formal way to specify multiple keys in E/R diagrams Underline:

27. 27 Single Value Constraints Sometimes we can choose to allow one or more values ODL: –attributes are always single value –relationships have single or multiple values relationship person president; relationship set presidents;

28. 28 Single Value Constraints E/R: offers

29. 29 Single Value Constraints Single Value Constraint: we explicitly require one value two flavors: –allow nulls –do not allow nulls

30. 30 Referential Integrity Constraints In some formalisms we may refer to other object but get garbage instead –e.g. a dangling pointer in C/C++ the Referential Integrity Constraint explicitly requires a reference to exists

31. 31 Referential Integrity Constraints In ODL: – means that a relationship cannot be NULL In E/R: CompanyProduct makes CompanyProduct makes

32. 32 Weak Entity Sets Entity sets are weak when their key attributes come from other classes to which they are related. This happens if: - part-of hierarchies - splitting n-ary relations to binary. UniversityTeam affiliation numbersportname