1. MODELS OF DATABASE AND DATABASE DESIGN
INTRODUCTION TO ENTITY RELATIONSHIP DIAGRAMS
26/03/2013 T.G.ZHOU

2. The Entity-Relationship Model- Lecture Overview
The Entity - Relationship Model (E-R Model) is a high-level conceptual data model developed by Chen in 1976 to facilitate database design. Conceptual Modeling is an important phase in designing a successful database. A conceptual data model is a set of concepts that describe the structure of a database and associated retrieval and updation transactions on the database. A high level model is chosen so that all the technical aspects are also covered.
The E-R model is shown diagrammatically using Entity-Relationship (E-R) diagrams which represent the elements of the conceptual model that show the meanings and the relationships between those elements independent of any particular DBMS and implementation details
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 1

3. LECTURE OBJECTIVES
By the end of the lecture students should be able to:
Learn about the components that make up an Entity Relationship Diagram (ERD) using the Chen’s notation

4. Describe the relationship between entity sets and relationship sets
Identify the participation and key constraints in a given scenario
Describe the parent/child concept

5. Overview of Database Design
Conceptual design: (ER Model is used at this stage.)
What are the entities and relationships in the enterprise?
What information about these entities and relationships should we store in the database?
What are the integrity constraints or business rules that hold?
A database `schema’ in the ER Model can be represented pictorially (ER diagrams).
Can map an ER diagram into a relational schema. 2

6. ER Model Basics
Employees
ssn
name
lot
Entity: Real-world object distinguishable from other objects. An entity is described (in DB) using a set of attributes.
Entity Set: A collection of similar entities. E.g., all employees.
All entities in an entity set have the same set of attributes. (Until we consider ISA hierarchies, anyway!)
Each entity set has a key.
Each attribute has a domain.
A key can be a (minimal) set of attributes 3

7. ER Model Basics (Contd.)
name
ssn
lot
Employees
since
name
dname
super-visor
subor-dinate
ssn
lot
did
budget
Reports_To
Employees
Works_In
Departments
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 entity sets E1 ... En; each relationship in R involves entities e1, ..., en.
Same entity set could participate in different relationship sets, or in different “roles” in same set. 4

8. Key Constraints
since
lot
name
ssn
dname
did
budget
Manages
Consider Works_In: An employee can work in many departments; a dept can have many employees.
In contrast, each dept has at most one manager, according to the key constraint on Manages.
Employees
Departments
Examples: 1-1 -> Dep, Manager
1-many -> Dep, Employees
Many-1 -> Employees, Dep Many-Many -> Customers, Items
1-to-1
1-to Many
Many-to-1
Many-to-Many 6

9. Participation Constraints
Does every department have a manager?
If so, this is a participation constraint: the participation of Departments in Manages is said to be total (vs. partial).
Every did value in Departments table must appear in a tuple of the Manages relation.
since
since
name
name
dname
dname
ssn
lot
did
did
budget
budget
Employees
Manages
Departments
Works_In
since 8

10. Weak Entities
A weak entity can be identified uniquely only by considering the primary key of another (owner) entity.
Owner entity set and weak entity set must participate in a one-to-many relationship set (one owner, many weak entities).
Weak entity set must have total participation in this identifying relationship set.
name
cost
ssn
pname
lot
age
Employees
Policy
Dependents 10

11. ISA (`is a’) Hierarchies
name
ISA (`is a’) Hierarchies
ssn
lot
Employees
As in C++, or other PLs, attributes are inherited.
If we declare A ISA B, every A entity is also considered to be a B entity.
hourly_wages
hours_worked
ISA
contractid
Hourly_Emps
Contract_Emps
Overlap constraints: Can Joe be an Hourly_Emps as well as a Contract_Emps entity? (Allowed/disallowed)
Covering constraints: Does every Employees entity also have to be an Hourly_Emps or a Contract_Emps entity? (Yes/no)
Reasons for using ISA:
To add descriptive attributes specific to a subclass.
To identify entities that participate in a relationship.
Examples: hourly wages are specific to hourly employees
“motor vehicles” participates in “licenses” relationship; see also managers in slide “entity vs. relationship” 12

12. Aggregation Aggregation vs. ternary relationship:
name
Aggregation
ssn
lot
Employees
Used when we have to model a relationship involving (entity sets and) a relationship set.
Aggregation allows us to treat a relationship set as an entity set for purposes of participation in (other) relationships.
Monitors
until
started_on
since
dname
pid
pbudget
did
budget
Projects
Sponsors
Departments
For the second point, need to be able to draw an arrow from Monitors to Employees -> key constraint.
Aggregation vs. ternary relationship:
Monitors is a distinct relationship,
with a descriptive attribute. (i.e., until)
Also, can say that each sponsorship
is monitored by at most one employee. 2