1. Modeling Your Data Chapter 2 cs542
The slides for this text are organized into chapters. This lecture covers Chapter 2.
Chapter 1: Introduction to Database Systems
Chapter 2: The Entity-Relationship Model
Chapter 3: The Relational Model
Chapter 4 (Part A): Relational Algebra
Chapter 4 (Part B): Relational Calculus
Chapter 5: SQL: Queries, Programming, Triggers
Chapter 6: Query-by-Example (QBE)
Chapter 7: Storing Data: Disks and Files
Chapter 8: File Organizations and Indexing
Chapter 9: Tree-Structured Indexing
Chapter 10: Hash-Based Indexing
Chapter 11: External Sorting
Chapter 12 (Part A): Evaluation of Relational Operators
Chapter 12 (Part B): Evaluation of Relational Operators: Other Techniques
Chapter 13: Introduction to Query Optimization
Chapter 14: A Typical Relational Optimizer
Chapter 15: Schema Refinement and Normal Forms
Chapter 16 (Part A): Physical Database Design
Chapter 16 (Part B): Database Tuning
Chapter 17: Security
Chapter 18: Transaction Management Overview
Chapter 19: Concurrency Control
Chapter 20: Crash Recovery
Chapter 21: Parallel and Distributed Databases
Chapter 22: Internet Databases
Chapter 23: Decision Support
Chapter 24: Data Mining
Chapter 25: Object-Database Systems
Chapter 26: Spatial Data Management
Chapter 27: Deductive Databases
Chapter 28: Additional Topics
cs542 1

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

3. Design : The Obvious
Use meaningful and descriptive names (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 lot of data semantics can (and should) be captured.
Some constraints cannot be captured in ER diagrams.
cs542 3

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

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

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

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

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

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
name
Employees
ssn
lot
dname
did
budget
Works_In
Departments
cs542 5

11. Entity vs. Attribute (Contd.)
Works_In4 does not allow an employee to work in a department for two or more periods.
from to
name
Employees
ssn
lot
dname
did
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 5

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

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

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

15. Entity vs. Relationship
since
dbudget
name
dname
ssn
lot
did
budget
Employees
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 6

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

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

18. Binary vs. Ternary Relationships
name
Employees
ssn
lot
pname
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 7

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

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

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

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

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 9

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 13