1. Instructor: Elke Rundensteiner
Database Management Systems CS Spring 2017
Modeling Your Data
Chapter 2.
Instructor: Elke Rundensteiner

2. Overview of Database Design
What are the entities and relationships in your application?
What information store in database?
What integrity constraints or business rules hold? 2

3. ER Model : Database Design
A database `schema’ in the ER Model represented pictorially 2

4. ER Model Basics Entity: Real-world object
described by a set of attributes.
Entity Set: A collection of similar entities. E.g., all employees.
All entities in entity set have same set of attributes.
Each entity set has a key.
Each attribute has a domain.
Employees
ssn
name
lot
The slides for this text are organized into several modules. Each lecture contains about enough material for a 1.25 hour class period. (The time estimate is very approximate--it will vary with the instructor, and lectures also differ in length; so use this as a rough guideline.) This covers Lectures 1 and 2 (of 6) in Module (5).
Module (1): Introduction (DBMS, Relational Model)
Module (2): Storage and File Organizations (Disks, Buffering, Indexes)
Module (3): Database Concepts (Relational Queries, DDL/ICs, Views and Security)
Module (4): Relational Implementation (Query Evaluation, Optimization)
Module (5): Database Design (ER Model, Normalization, Physical Design, Tuning)
Module (6): Transaction Processing (Concurrency Control, Recovery)
Module (7): Advanced Topics 3

5. ER Model Basics (Contd.)
Relationship: Association among two or more entities.
E.g., Attishoo works in Pharmacy department
Relationship Set: Collection of similar relationships.
An n-ary relationship set R relates n entities e1 from E1, ..., en from En 4

6. ER Model Basics Relationship: Association among two or more entities.
lot
dname
budget
did
since
name
Works_In
Departments
Employees
ssn
Relationship: Association among two or more entities. 4

7. ER Model Basics Relationship:
Same entity set can participate in different relationship sets (“roles”) in same set.
name
ssn
lot
Employees
super-visor
subordinate
Reports_To 4

8. Key Constraints
Many-to-Many
1-to-1
1-to Many
Many-to-1 6

9. An employee can work in many departments, and
since
name
dname
ssn
lot
did
budget
Employees
Works_In
Departments
Works_In:
An employee can work in many departments, and
a dept can have many employees. 4

10. Which key constraint ? 1-to-1 1-to Many Many-to-1 Many-to-Many since
name
dname
ssn
lot
did
budget
Employees
Works_In
Departments
1-to-1
1-to Many
Many-to-1
Many-to-Many 4

11. Which Key Constraint Case ??
Consider Manager Relation- ship?
since
lot
name
ssn
dname
did
budget
Manages
Employees
Departments 6

12. Which Key Constraint Case ??
since
Consider Manager Relation- ship :
“Each dept has at most one manager.”
lot
name
ssn
dname
did
budget
Manages
Employees
Departments
Many-to-Many
1-to-1
1-to Many
Many-to-1 6

13. Key Constraint: 1 - to - Many
since
Each dept has at most one manager as per key constraint on Manages.
lot
name
ssn
dname
did
budget
Manages
Employees
Departments
dname
budget
did
since
lot
name
ssn
Manages
Employees
Departments
[0:1]
[0:n] 6

14. Participation Constraints
Must every department have a manager?
lot
dname
did
name
budget
since
Manages
Departments
Employees
ssn ? 8

15. Participation Constraints
If every department must have a manager, that is,
the participation of Departments in Manages is
said to be total (vs. partial).
lot
name
dname
budget
did
since
Manages
Departments
Employees
ssn ? 8

16. Participation Constraints
Every department must have a manager (exactly one)!
lot
name
dname
budget
did
since
Manages
Departments
Employees
ssn 8

17. Participation Constraints ?
lot
dname
budget
did
since
name
Works_In
Departments
Employees
ssn 8

18. Participation Constraints
lot
name
dname
budget
did
since
Manages
Departments
Employees
ssn
Works_In
every department has a manager
every employee works in at least one dept.
every dept has at least one employee 8

19. Weak Entities
Weak entity can be identified uniquely only by considering the primary key of another (owner) entity.
lot
name
age
pname
Dependents
Employees
ssn
Policy
cost 10

20. Weak Entities
Owner entity set and weak entity set must participate in a one-to-many relationship set (one owner and many weak entities).
Weak entity set must have total participation in this identifying relationship set.
lot
name
age
pname
Dependents
Employees
ssn
Policy
cost 10

21. ISA (`is a’) Hierarchies
1. As in C++, or other PLs, attributes are inherited.
2. If we declare A ISA B, every A entity is also considered to be a B entity.
Contract_Emps
name
ssn
Employees
lot
hourly_wages
ISA
Hourly_Emps
contractid
hours_worked 12

22. ISA (`is a’) Hierarchies
name
Implicit
Relationship
Between
Super-
And
Subentity?
1-1 ?
ssn
lot
Employees
hourly_wages
hours_worked
ISA
contractid
Hourly_Emps
Contract_Emps
Reasons for using ISA:
To add descriptive attributes specific to a subclass.
To identify entities that participate in a relationship. 12

23. ISA (`is a’) Hierarchies
Contract_Emps
name
ssn
Employees
lot
hourly_wages
ISA
Hourly_Emps
contractid
hours_worked
Overlap constraints: Can Joe be Hourly_Emps as well as Contract_Emps entity? (Allowed/disallowed)
Covering constraints: Does every Employee entity have to be Hourly_Emps or Contract_Emps entity? (Yes/no) 12

24. Aggregation
Used when we have to model a relationship involving entity sets and a relationship set. 2

25. Aggregation
Aggregation allows us to treat a relationship set as an entity set for purposes of participation in (other) relationships
name
ssn
lot
Employees
Monitors
until
started_on
since
dname
pid
pbudget
did
budget
Projects
Sponsors
Departments 2

26. Aggregation Aggregation vs. ternary relationship:
name
ssn
lot
Employees
Monitors
until
started_on
since
dname
pid
pbudget
did
budget
Projects
Sponsors
Departments
Aggregation vs. ternary relationship:
Monitors is a distinct relationship, with a descriptive attribute.
Or, say each sponsorship is monitored by at most one employee. 2

27. Summary of Conceptual Design
Conceptual design follows requirements analysis:
Yields a high-level description of data to be stored
ER model popular for conceptual design
Constructs are expressive - the way people think about their applications.
Basic constructs: entities, relationships, and attributes
Some additional constructs: weak entities, ISA hierarchies, and aggregation.
Note: There are many variations on ER model. 11

28. Summary of ER Modeling
Constraints play important role in determining the best database design for an enterprise.
Integrity constraints expressed in ER model:
key constraints,
participation constraints,
overlap/covering constraints for ISA hierarchies.
Some foreign key constraints also implicit in definition of a relationship set.
Others cannot be expressed :
Some constraints (notably, functional dependencies) cannot be expressed in ER model. 12