--------------------------------------- 1

The Entity-Relationship Model

(ER model)
Chapter 2
Raghu Ramakrishnan & Johanes Ghorke
Modified by
Arber Hajra
See University
a.hajra@seeu.edu.mk

--------------------------------------- 2
Overview of Database Design
Conceptual design: (ER Model is used at this stage.)
±What are the entities and relationships in the
enterprise?
Students sign up for classes
±What information about these entities and relationships
should we store in the database?
Student number and phone number of each student
±What are the integrity constraints or business rules that
hold?
No student takes more than seven courses per semester
±  R [RERMv
represented pictorially (ER diagrams).
±Can map an ER diagram into a relational schema.

--------------------------------------- 3
Entity-Relationship Model (E-R Model)
Entity-Relationship model is a set of concepts
and graphical symbols that can be used to
create conceptual schemas
An E-R Model consists of:
± Entities
± Attributes
± Identifiers
± Relationships
3

--------------------------------------- 4
Entity & Entity Set
Entity: Real-world object distinguishable
from other objects. An entity is described (in
database) 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!) Attribute
Each attribute has a
Key
domain.
name
Each entity set has a key
ssn lot
t uniquely identifies an
entity in the set
Entity set
Employees

--------------------------------------- 5
Attributes
An attribute describes a characteristic of an
entity
For example
An entity: Student
Has attributes:
± StudentNumber
± StudentName
± StudentYear
5

--------------------------------------- 6
Attributes
All instances of a given entity class have the same attributes
Attributes could be
± Single-value attribute: attribute with one value
± Composite attribute: attribute consisting of the group of attributes
Example Address: Street, Number, Town, Zip
± Multi-value attributes: attribute with more than one possible value
Example Phone-numbers: several phone in office
± Stored v.s. Derived: Derived from other attributes values
Average mark, given marks; age, given date of birth
6

--------------------------------------- 7
Type of Key(s)
Super key, Key Attribute(s) Unique identifier of an entity set
± Example, StudentNumber;
± Name, Birth date, Birth Place
Candidate key, Minimal super key (no attribute could be
taken from identifier, it to remain identifier)
± Tax number for company,
± Unique number of a person (EMBG)
± Discuss: Last Name, First Name, Birth date and Birth Place is an
candidate key?
Primary key, one of the candidate keys chosen to uniquely
identifies the entity set
Students
sid name login age gpa
53831 Zhang zhang@ee 19 3.2
53650 Smith smith@cs 21 3.9
53666 Jones jones@cs 20 3.5
7

--------------------------------------- 8
Some notations

--------------------------------------- 9
Relationship
since
name dname
ssn
lot did budget
Employees Works_In
Departments
Relationship: Association among two or
u} v ] ]  UXSJ]Á} l ] v
PR    u v X_

--------------------------------------- 10
Relationship Set
since
name dname
ssn
lot did budget
Employees Works_In
Departments
Relationship
Relationship Set: Collection of set
similar relationships.
EMPLOYEES DEPARTMENTS
WORKS_IN
±An n-ary relationship set R
relates n entity sets E ... E;
1n
each relationship in R involves
entities e in E, ..., e in E
11nn
--------------------------------------- 11
A Ternary Relationship Example
since
name
dname
ssn lot budget did
Employees Works_In Departments
Each department has
offices in several
Locations locations
We want to record the
address capacity
locations at which
each employee works
Employees Works_Ins
Departments

Works at
Locations
two
locations

--------------------------------------- 12
Relationship Participation
Same entity set could participate
in different relationship sets, or in
](( vS }o _ R X
name
ssn lot
SEu o}Ç _
Employees participates in two
super-different roles
subor-visor
dinate
Reports_To

--------------------------------------- 13
Mapping to Tables
since
name dname
ssn
lot did budget
Works_In
Employees Departments
Employees Works_In Departments
ssn name lot ssn did did dname budget
1234 8 8 DB 1,000,000
1234 Jenny A456

--------------------------------------- 14
Key Constraints

--------------------------------------- 15
Key Constraints: 1-to-Many
Consider Works_In:
An employee can name dname from to
work in many ssn lot did budget
departments; a dept
can have many
employees (many-to-Employees Works_In Departments
mamy relationship).
In contrast, each since
dept has at most one name dname
manager, according ssn lot did budget
to the key constraint
on Manages (1-to-Employees Manages Departments
many relationship).

--------------------------------------- 16
Key Constraints
since
name dname
ssn lot did budget
Employees Manages Departments
EMPLOYEES MANAGES DEPARTMENTS
Given a Departments entity,
we can uniquely determine
the Manages relationship in
which it appears
1-to Many

--------------------------------------- 17
Different Kinds of Relationships
1-to Many Many-to-1
Many-to-Many 1-to-1
--------------------------------------- 18
Participation Constraints

--------------------------------------- 19
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 row of the Manages
table (with a non-null ssn value! - more details later in this course)
sincesince
namnamee dndnameame
ssn lot diddid budgetbudget
Employees Manages Departments
Works_In
Total participation
(a participation constraint)
Can NOT be department without
Partial participation since
can be employee without department employee (must have at least one)

--------------------------------------- 20
Total vs. Partial Participation
Does every department have a manager ?
Employees Manages Departments
Employees Manages Departments Employees Manages Departments
Employees Manages Departments

Partial Participation
Has no
manager Total Participation Everyone
has a
manager

--------------------------------------- 21
a).
b).
c).
--------------------------------------- 22
Weak Entity, Hierarchies, Aggregation

--------------------------------------- 23
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.
Partial key
name
cost dpname
age
ssn lot
Policy Dependents Employees
A weak entity set
The owner entity set t is a strong entity
Draw both with dark lines
Need both ssn and dpname to
to indicate that Policy is the
identify a SDv entity v  _
identifying relationship

--------------------------------------- 24
name
IS~í] H ]  Z ] ssn lot
Employees
As in C++, or other PLs,
hourly_wages hours_worked
attributes are inherited.
ISA
contractid
If we declare A ISA B, every A
entity is also considered to be a
Hourly_Emps Contract_Emps
B entity.
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)

--------------------------------------- 25
name
ssn lot
ISR H R
Employees
hourly_wages hours_worked
ISA
contractid
Contract_Emps
Hourly_Emps Reasons for using ISA
To add descriptive attributes specific to a subclass
± Example: We only need to track hours worked for
hourly employees
To identify entities that participate in a relationship
± Example: Only contract employees can be managers
(i.e., participating in the Manages relationship)

--------------------------------------- 26
name
ssn lot
Aggregation
Employees
Used when we have to
model a relationship
involving (entity sets and) Monitors until
a relationship set.
Aggregation allows
us to treat a started_on since
dname
relationship set as
pid pbudget did budget
an entity set for
purpose of
Sponsors
Projects Departments
participation in
(other) relationships
Aggregation vs. ternary relationship:
Monitors is a distinct relationship, with a descriptive attribute.
Also, can say that each sponsorship is monitored by at most one
employee.

--------------------------------------- 27
Discussion
Conceptual Model using ER

--------------------------------------- 28
Conceptual Design Using the 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,
e.g., functional dependencies (discussed later in this course)
--------------------------------------- 29
Entity vs. Attribute
Should address be an attribute of Employees or an entity
(connected to Employees by a relationship)?
Answer: Depends upon the use we want to make of
address information, and the semantics of the data.
Can retrieve employees
Employees can have
in a given city
name address multiple addresses
lot
ssn
name City
Employees
ssn lot Street State
Employees live_at Address

--------------------------------------- 30
Entity vs. Attribute
Should address be an attribute of Employees or
an entity (connected to Employees by a
relationship)?
Depends upon the use we want to make of
address information, and the semantics of the
data:
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).

--------------------------------------- 31
Entity vs. Attribute (Contd.)
from to
name
dname
ssn lot did
budget
Employees Works_In4 Departments
Works_In4 does
not allow an
employee to work
in a department
ssn did from to for two or more
periods
1234 9 1998 2002
Same
key
value
1234 9 2006 2009
 same instance

--------------------------------------- 32
Entity vs. Attribute (Contd.)
Similar to the problem name dname
ssn lot did
budget
of wanting to record
several addresses for
Works_In5 Departments
Employees
an employee:
from Duration to
We want to record several values
of the descriptive attributes for Works_In5
each instance of this relationship.
ssn did from to
Accomplished by introducing new
1234 9 1998 2002
entity set, Duration.
1234 9 2006 2009

--------------------------------------- 33
Entity vs. Relationship
First ER diagram OK if a ssn
since dbudget
manager gets a
name
dname
separate discretionary
lot did budget
budget for each dept.
Employees Manages2
Departments

name
What if a manager gets
ssn lot
a discretionary
since dname
budget that covers
Employees did budget
all managed depts?
±Redundancy: dbudget
Manages2 Departments
stored for each dept ISA
managed by manager.
±Misleading: Suggests
Managers dbudget This fixes the
dbudget associated with
problem !
department-mgr
combination.

--------------------------------------- 34
Binary vs. Ternary Relationships (1)
name
1. An employee can own ssn lot pname age
several policies
2. Each policy can be owned Employees Covers
Dependents
by several employee
3. Each dependent can be
covered by several policies Policies
policyid cost
If each policy is Joint
policy
owned by just one Employees Covers
employee, and each
Policy
dependent is tied to
the covering policy,
we need some
Dependents
constraints
Owns 2
Covered by
policies
2 policies

--------------------------------------- 35
Binary vs. Ternary Relationships (2)
Constraints: Each policy is owned by just one employee, and each
dependent is tied to the covering policy.
pname
age
name
ssn
lot
Dependents
Employees
Purchaser Beneficiary
Weak entity set t Each
dependent is uniquely
Key constraint t A identified by a policy
Policies
policy cannot be owned (i.e., policyid and pname)
jointly by two or more
policyid cost
employees
Total participation t
Every policy must be
owned by some
employee
--------------------------------------- 36
When to use N-ary Relationships ?
qty
Suppliers Contracts
Departments
Parts
No combination of binary relationships is an
adequate substitute for the above ternary
relationship:
±The binary relationships S S- µ   oÇvP, D S_P, 
and D So -RS do not imply that D has agreed to
buy P from S.
±How do we record qty in the binary relationships ?

--------------------------------------- 37
Examples

--------------------------------------- 38
Example 2.2
Exercise 2.2 A university database contains information about professors
(identified by social security number, or SSN) and courses (identified by
courseid). Professors teach courses; each of the following situations concerns
the Teaches relationship set. For each situation, draw an ER diagram that
describes it (assuming no further constraints hold).
1. Professors can teach the same course in several semesters, and each offering
must be
recorded.
2. Professors can teach the same course in several semesters, and only the most
recent
such offering needs to be recorded. (Assume this condition applies in all subseq
uent
questions. )
3. Every professor must teach some course.
4. Every professor teaches exactly one course (no more, no less).
5. Every professor teaches exactly one course (no more, no less), and every cour
se must
be taught by some professor.
6. Now suppose that certain courses can be taught by a team of professors jointl
y, but it
is possible that no one professor in a team can teach the course. Model this sit
uation,
introducing additional entity sets and relationship sets if necessary.

--------------------------------------- 39
1. Professors can teach the same course in several
semesters, and each offering must be recorded.
Semester

--------------------------------------- 40
2. Professors can teach the same course in several semesters,
and only the most recent such offering needs to be recorded.
(Assume this condition applies in all subsequent questions. )

--------------------------------------- 41
3. Every professor must teach some course.

--------------------------------------- 42
4. Every professor teaches exactly one course
(no more, no less).

--------------------------------------- 43
5. Every professor teaches exactly one course (no more, no less),
and every course must be taught by some professor.

--------------------------------------- 44
6. Now suppose that certain courses can be taught by a team of professors
jointly, but it is possible that no one professor in a team can teach the course
.
Model this situation, introducing additional entity sets and relationship sets i
f
necessary.

--------------------------------------- 45
University Database t Ex. 2.3
Professors have an SSN, a name, an age, a rank, and a research specialty.
Projects have a project number, a sponsor name (e.g., NSF), a starting date, an
ending date,
and a budget.
Graduate students have an SSN, a name, an age, and a degree program (e.g., M.S.
or Ph.D.).
Each project is managed by one professor (known as the project's principal inves
tigator).
Each project is worked on by one or more professors (known as the project's co-
investigators).
 Professors can manage and/or work on multiple projects.
Each project is worked on by one or more graduate students (known as the project
's
research assistants).
When graduate students >'lark on a project, a professor must supervise their wor
k on the
project. Graduate students can work on multiple projects, in which case they wil
l have a
(potentially different) supervisor for each one.
Departments have a department number, a department name, and a main office.
Departments have a professor (known as the chairman) who runs the department.
Professors work in one or more departments, and for each department that they wo
rk in, a
time percentage is associated with their job.
Graduate students have one major department in which they are working on their d
egree.
Each graduate student has another, more senior graduate student (known as a stud
ent
advisor) who advises him or her on what courses to take.
Design and draw an ER diagram. Be sure to indicate any key and participation con
straints.

--------------------------------------- 46
Example: University Database
We have four entity sets: Professor, Project, Graduate, Department
rank
pid
age sponsor
Specialty
ssn start-date
end_date
Professor Project
budget
Dept Graduate
ssn name
dno office
age deg_prog
dname

--------------------------------------- 47
Example: University Database
Each project is managed by one professor (principal investigator)
Professors can manage multiple projects
rank
pid
age sponsor
Specialty
ssn start-date
end_date
Professor Manages Project
budget
Dept Graduate
grad
ssn name
dno office
age deg_prog
dname

--------------------------------------- 48
Example: University Database
Each project is worked on by one or more professors (co-investigators)
Professors can work on multiple projects
rank
pid
age sponsor
Specialty
Work_in
ssn start-date
end_date
Professor Manages Project
budget
Dept Graduate
ssn name
dno office
age deg_prog
dname

--------------------------------------- 49
Example: University Database
Each project is worked on by one or more graduate students (research assistants)
Graduate students can work on multiple projects
rank
pid
age sponsor
Specialty
Work_in
ssn start-date
end_date
Professor Manages Project
budget
Work_proj hours
Dept Graduate
ssn name
dno office
age deg_prog
dname

--------------------------------------- 50
Example: University Database
When graduate students work on multiple projects, they must have a
supervisor (professor) for each one.
rank
pid
age sponsor
Specialty
Work_in
ssn start-date
end_date
Professor Manages Project
budget
Supervises Work_proj hours
Dept Graduate
ssn name
dno office
age deg_prog
dname

--------------------------------------- 51
Example: University Database
Departments have a professor who runs the department
rank
pid
age sponsor
Specialty
Work_in
ssn start-date
end_date
Professor Manages Project
budget
Supervises Work_proj hours
Runs
Dept Graduate
ssn name
dno office
age deg_prog
dname

--------------------------------------- 52
Example: University Database
Professors work in one or more departments
For each department a professor works in, a time percentage is associated with t
heir
job
rank
pid
age sponsor
Specialty
Work_in
ssn start-date
end_date
Professor Manages Project
budget
Supervises Work_proj hours
Work_dept Runs
pc_time
Dept Graduate
ssn name
dno office
age deg_prog
dname

--------------------------------------- 53
Example: University Database
Graduate students have one major department in which they are working
on their degree
rank
pid
age sponsor
Specialty
Work_in
ssn start-date
end_date
Professor Manages Project
budget
Supervises Work_proj hours
Work_dept Runs
pc_time
Dept Major Graduate
ssn name
dno office
age deg_prog
dname

--------------------------------------- 54
Example: University Database
Each graduate student has another, more senior graduate student who
advises him or her on what courses to take
rank
pid
age sponsor
Specialty
Work_in
ssn start-date
end_date
Professor Manages Project
budget
Supervises Work_proj hours
Work_dept Runs
senior
pc_time
Dept Major Graduate Advisor
grad
ssn name
dno office
age deg_prog
dname

--------------------------------------- 55
Example: University Database
rank
pid
age sponsor
Specialty
Work_in
ssn start-date
end_date
Professor Manages Project
budget
Supervises Work_proj hours
Work_dept Runs
senior
pc_time
Dept Major Graduate Advisor
grad
ssn name
dno office
age deg_prog
dname

--------------------------------------- 56
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, close to the way people
think about their applications.
±Basic constructs: entities, relationships, and attributes
(of entities and relationships).
±Some additional constructs: weak entities, ISA
hierarchies, and aggregation.
Note: There are many variations on ER model.

--------------------------------------- 57
Summary of ER (Contd.)
Several kinds of integrity constraints can be
expressed in the ER model:
± key constraints,
± participation constraints, and
± overlap/covering constraints for ISA hierarchies.
± Some foreign key constraints are also implicit in the
definition of a relationship set (more later in the course).
± Some constraints (notably, functional dependencies)
cannot be expressed in the ER model.
± Constraints play an important role in determining the
best database design for an enterprise.

--------------------------------------- 58
Summary of ER (Contd.)
There are often many ways to model a given
scenario! Analyzing alternative ER designs can be
tricky. Common choices include:
± Entity vs. attribute,
± entity vs. relationship,
± binary or n-ary relationship,
± whether or not to use ISA hierarchies, and
± whether or not to use aggregation.
Ensuring good database design: resulting relational
schema should be analyzed and refined further.
± Functional dependency information and normalization
techniques are especially useful (discussed later).

--------------------------------------- 59
Homework #2
Exercises 2.6 in the textbook ± Submit in Libri or Hard Copy
Be sure to know:
Entity, Entity set
Attribute, Types of Attribute
Relationships
Key Constrains (Cardinality)
Participation Constrains
Super Key, Candidate Key, Primary Key, Composite Primary key, Partial Key,
Foreign Key
Weak Entity
Hierarchies
Aggregation, etc.