1. Modeling Your Data Chapter 2 cs5421

2. Part II Discussion of the Model: Good Design/ Bad Design? cs5422

3. Design : The Obvious ! – Use meaningful and descriptive names (it’s for the human after all) – Keep as simple as possible, and relevant to the application at hand – Avoid redundant constructs – Express all constraints, if possible, as then the DBMS will help you to enforce them cs5423

4. Conceptual Design Using ER Model Design choices: – Should a concept be modeled as an entity or an attribute? – Should a concept be modeled as an entity or a relationship? – Identifying relationships: Binary or ternary? Aggregation? Constraints in the ER Model: – A lot of data semantics can (and should) be captured. – But some constraints cannot be captured in ER diagrams. cs5424

5. Entity vs. Attribute Should address be an attribute of Employees or an entity (connected to Employees by a relationship)? cs5425

6. Entity vs. Attribute Should address be an attribute of Employees or a related entity ? Answer: Depends upon how we want to use address information and its semantics : If we have several addresses per employee, address must be an entity (since attributes cannot be set-valued). If the structure (city, street, etc.) is important, e.g., we want to retrieve employees in a given city, address must be modeled as an entity (since attribute values are atomic). cs5426

7. Entity vs. Attribute Reminder : Do not introduce un-necessary entities (and complexity) if not needed for your application ! cs5427

8. Entity vs. Attribute name Employees ssn lot Works_In4 from to dname budget did Departments cs5428

9. Entity vs. Attribute Does Works_In allow an employee to work in a department for two or more periods??? name Employees ssn lot Works_In from to dname budget did Departments cs5429

10. Entity vs. Attribute (Contd.) Works_In does not allow an employee to work in a department for two or more periods  no multi-valued attributes in ER ! name Employees ssn lot Works_In from to dname budget did Departments cs54210

11. Entity vs. Attribute (Contd.) Similar to the problem of wanting to record several addresses for an employee: We want to record several values of the descriptive attributes for each instance of this relationship. Accomplished by introducing new entity set, Duration. name Employees ssn lot Works_In4 from to dname budget did Departments Works_In4 does not allow an employee to work in a department for two or more periods. What do ? cs54211

12. Entity vs. Attribute name Employees ssn lot Works_In4 from to dname budget did Departments dname budget did name Departments ssn lot Employees Works_In4 Duration from to cs54212

13. Entity vs. Relationship? Manages2 name dname budget did Employees Departments ssn lot dbudget since cs54213

14. Entity vs. Relationship What if a manager gets a separate discretionary budget for each dept ? OK ! Manages2 name dname budget did Employees Departments ssn lot dbudget since cs54214

15. Entity vs. Relationship What if a manager gets a discretionary budget that covers all managed depts? – Redundancy: dbudget stored for each dept managed by manager. – Misleading: Suggests dbudget associated with department-mgr combination. Manages2 name dname budget did Employees Departments ssn lot dbudget since cs54215

16. Entity vs. Relationship Discretionary budget of manager that covers all managed depts? Manages2 name dname budget did Employees Departments ssn lot dbudget since dname budget did Departments Manages2 Employees name ssn lot since Managersdbudget ISA cs54216

17. Binary vs. Ternary Relationships age pname Dependents Covers name Employees ssn lot Policies policyid cost cs54217

18. Binary vs. Ternary Relationships age pname Dependents Covers name Employees ssn lot Policies policyid cost  What if each policy is owned by just 1 employee?  What if each dependent should be tied to only 1 covering policy? cs54218

19. Binary vs. Ternary Relationships What additional constraints in 2nd diagram? Beneficiary age pname Dependents policyid cost Policies Purchaser name Employees ssn lot age pname Dependents Covers name Employees ssn lot Policies policyid cost Bad design! Better design? cs54219

20. Binary vs. Ternary Relationships age pname Dependents Covers name Employees ssn lot Policies policyid cost Beneficiary age pname Dependents policyid cost Policies Purchaser name Employees ssn lot Bad design Even Better Design cs54220

21. Binary vs. Ternary Relationships If each policy is owned by just 1 employee, and each dependent is tied to the covering policy, first diagram is inaccurate. What are the additional constraints in the 2nd diagram? age pname Dependents Covers name Employees ssn lot Policies policyid cost Beneficiary age pname Dependents policyid cost Policies Purchaser name Employees ssn lot Bad design Better design cs54221

22. Binary vs. Ternary Relationships Previous example illustrated when two binary relationships better than one ternary relationship. New Example: How about we want to model Contracts between the entity sets Parts, Departments and Suppliers, –Where D has agreed to buy parts P from supplier S according to a given contract (i.e. a certain quantity of parts of type P).

23. Binary vs. Ternary Relationships How about ternary relation Contracts : –entity sets Parts, Departments and Suppliers, –and has descriptive attribute qty. pnum Parts contract Suppliers sid Department did qty

24. Binary vs. Ternary Relationships What about following binary relationships : –S “can-supply” P, – D “needs” P, and – D “deals-with” S ? No combination of binary relationships is an adequate substitute: – Together 3 binary relationships don’t imply that D has agreed to buy P from S. – Also, how could we record qty? cs54224

25. Summary of ER There are often many ways to model a given scenario! Not one correct ER design Analyzing alternatives can be tricky, especially for a large enterprise. Common choices include: – Entity vs. attribute, entity vs. relationship, binary or n-ary relationship, whether or not to use ISA hierarchies, aggregation. Ensuring good database design: –Resulting relational schema should be analyzed and refined further. –FD information and normalization techniques useful. cs54225