Modeling Your Data. Chapter 2. cs542 1

Transcription

1 Modeling Your Data Chapter 2 cs542 1

2 Part II Discussion of the Model: Good Design/ Bad Design cs542 2

3 Design : The Obvious Use meaningful and descriptive s (it s for the human after all) Keep as simple as possible Avoid redundant constructs Express all constraints, if possible, as then DBMS will help enforce them cs542 3

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 of data semantics can (and should) be captured. Some constraints cannot be captured in ER diagrams. cs542 4

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

6 Entity vs. Attribute Should address be an attribute of 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). cs542 6

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

8 Entity vs. Attribute from to did d budget Works_In4 Departments cs542 8

9 Entity vs. Attribute Does Works_In allow an employee to work in a department for two or more periods??? from to did d budget Works_In Departments cs542 9

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! from to did d budget Works_In Departments cs542 10

11 Entity vs. Attribute (Contd.) Works_In4 does not allow an employee to work in a department for two or more periods. from to did d budget Works_In4 Departments What do? 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. cs542 11

12 Entity vs. Attribute from to did d budget Works_In4 Departments did d budget Works_In4 Departments from Duration to cs542 12

13 Entity vs. Relationship? since dbudget did d budget Manages2 Departments cs542 13

14 Entity vs. Relationship since dbudget did d budget Manages2 Departments What if a manager gets a separate discretionary budget for each dept? OK! cs542 14

15 Entity vs. Relationship since dbudget did d budget Manages2 Departments 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. cs542 15

16 Entity vs. Relationship since dbudget did d budget Discretionary Manages2 Departments budget of manager that covers all managed depts? ISA since Manages2 did d budget Departments Managers dbudget cs542 16

17 Binary vs. Ternary Relationships p age Covers Dependents Policies policyid cost cs542 17

18 Binary vs. Ternary Relationships p age Covers Dependents 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? cs542 18

19 Binary vs. Ternary Relationships Bad design! p age Covers Dependents Policies policyid cost What additional constraints in 2nd diagram? Purchaser Better design? p age Dependents Beneficiary Policies cs policyid cost

20 Binary vs. Ternary Relationships p age Bad design Covers Policies Dependents policyid cost p age Dependents Purchaser Beneficiary Even Better Design Policies cs542 policyid cost 20

21 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).

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

23 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? cs542 24

24 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. cs542 25