The Entity-Relationship Model

Chapter 2

CENG351

1
 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).
– We can map an ER diagram into a relational schema.
Ø Schema Refinement: (Normalization)
– Check relational schema for redundancies and anomalies.
Ø Physical Database Design and Tuning:
– Consider typical workloads and further refine the db design.
2
 DB Requirements example
A company database needs to store information about
• employees (identifyied by ssn, with salary and phone as
attributes);
• departments (identified by dno, with dname and budget as
attributes); and
• children of employees (with name and age as attributes).
• Employees work in departments;
• each department is managed by an employee;
• a child must be identified uniquely by name when the
parent (who is an employee; assume that only one parent
works for the company) is known. We are not interested in
information about a child once the parent leaves the
company.
3
 ER Model Basics – Entity Set
Ø 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.
– Each entity set has a key.
– Each attribute has a domain.

Employees Entity Set:

name
ssn lot

Employees

4
Logical DB Design: ER to Relational Model
• Entity sets to tables:
name
ssn lot

Employees

CREATE TABLE Employees(

ssn CHAR(11),
name CHAR(20),
lot INTEGER,
PRIMARY KEY (ssn))
5
Logical DB Design: ER to Relational Model
• Entity sets to tables:
dname
did budget

Departments

CREATE TABLE Departments(

did INTEGER,
dname CHAR(20),
budget REAL,
PRIMARY KEY (did))

6
 ER Model Basics- Relationship set
Ø Relationship: Association among two or more entities.
– e.g., Fred 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 Î E1, ..., en Î En

Works_In relationship set:

since
name dname
ssn lot did budget

Employees Works_In Departments

7
 Relationship Sets to Tables
• In translating a relationship set CREATE TABLE Works_In(
to a relation, attributes of the ssn CHAR(11),
relation must include: did INTEGER,
– Keys for each participating since DATE,
entity set (as foreign keys). PRIMARY KEY (ssn, did),
FOREIGN KEY (ssn)
• This set of attributes
REFERENCES Employees,
forms a superkey for the
FOREIGN KEY (did)
relation.
REFERENCES Departments)
– All descriptive attributes.

since
name dname
ssn lot did budget

Employees Works_In Departments

8
 Relationship set (contd.)
Ø Same entity set could participate in different relationship sets.

Works_In and Has Relationship sets:

since
name dname
ssn lot did budget

Employees Works_In Departments

Has Address

street city zipcode

9
 Relationship set (contd.)
Ø Same entity set could participate in different “roles” in same
relationship set.

Reports_To relationship set:

name

ssn lot

Employees

supervisor subordinate

Reports_To

10
 Relationship Types
Ø Consider Works_In: An employee can work in many departments;
a department can have many employees:
many-to-many relationship.
Ø In contrast, each department has at most one employee as manager,
but a manager can manage many departments:
one-to-many relationship.
– Similarly we can think of examples of many-to-one or one-to-one
relationships.

1-to-1 1-to Many Many-to-1 Many-to-Many

11
 Key Constraints
Ø The restriction that each department has at most one manager is
an example of a key constraint.
Ø It implies that each department entity appears in at most one
Manages relationship.

since
name dname
ssn lot did budget

Employees Manages Departments

1-to Many

12
 Translating Relationships with Key
Constraints
• How do we translate Manages into a table?
There are two alternative designs:
EITHER:
We could map Manages relationship to a separate table (like we did in the
previous slide).
OR
Since each department has a unique manager, we could instead combine
Manages and Departments.

since
name dname
ssn lot did budget

Employees Manages Departments

1-to Many

13
 Alternative 1: Separate Table for Manages
• Map Manages relationship to a table:
– Note that did is the key now!
– There are separate tables for Employees and Departments.

CREATE TABLE Manages(

ssn CHAR(11),
did INTEGER,
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (ssn) REFERENCES Employees,
FOREIGN KEY (did) REFERENCES Departments)

14
 Alternative 2: Embed Manages relationship
into Departments table
• Since each department has a unique manager, we could instead
combine Manages and Departments in one table.

CREATE TABLE Department(

did INTEGER,
dname CHAR(20),
budget REAL,
ssn CHAR(11),
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (ssn) REFERENCES Employees)

15
 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!)
since
name dname
ssn lot did budget

Employees Manages Departments

Works_In

since
16
 Participation Constraints in SQL
• We can capture participation constraints involving one entity
set in a binary relationship, but little else (without resorting to
CHECK constraints).

CREATE TABLE Department(

did INTEGER,
dname CHAR(20),
budget REAL,
ssn CHAR(11) NOT NULL,
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (ssn) REFERENCES Employees
ON DELETE NO ACTION)

17
 name since dname
ssn lot did budget

Employees Works_In Departments

Manages

CREATE TABLE Employees(

CREATE TABLE Departments(
ssn CHAR(11),
did INTEGER,
name CHAR(20),
dname CHAR(20),
lot INTEGER,
budget REAL,
PRIMARY KEY (ssn))
PRIMARY KEY (did))

18
 name since dname
ssn lot did budget

Employees Works_In Departments

Manages

CREATE TABLE Employees(

CREATE TABLE Departments(
ssn CHAR(11),
did INTEGER,
name CHAR(20),
dname CHAR(20),
lot INTEGER,
budget REAL,
PRIMARY KEY (ssn))
PRIMARY KEY (did))
CREATE TABLE Works_In(
ssn CHAR(11),
did INTEGER,
since DATE,
PRIMARY KEY (ssn, did),
FOREIGN KEY (ssn) REFERENCES Employees, 19
FOREIGN KEY (did) REFERENCES Departments)
 name since dname
ssn lot did budget

Employees Works_In Departments

Bold: total participation
at least one manager
Manages
Arrow: key constraint
CREATE TABLE Employees( (1-M relationship); at most one manager
ssn CHAR(11), CREATE TABLE Dept_Mans(
name CHAR(20), did INTEGER,
lot INTEGER, dname CHAR(20),
PRIMARY KEY (ssn)) budget REAL,
ssn CHAR(11) NOT NULL,
CREATE TABLE Works_In( since DATE,
ssn CHAR(11), PRIMARY KEY (did),
did INTEGER, FOREIGN KEY (ssn) REFERENCES Employees)
since DATE,
PRIMARY KEY (ssn, did),
FOREIGN KEY (ssn) REFERENCES Employees, 20
FOREIGN KEY (did) REFERENCES Departments)
 A binary relationship with roles
name

ssn lot

Employees

supervisor subordinate

What if each employee (subordinate)

Reports_To
reports to at most one employee (supervisor)?
CREATE TABLE Reports_To (
supervisor_ssn CHAR(11),
subordinate_ssn CHAR(11),
PRIMARY KEY (supervisor_ssn, subordinate_ssn ),
FOREIGN KEY (supervisor_ssn) REFERENCES Employees(ssn),
FOREIGN KEY (subordinate_ssn) REFERENCES Employees(ssn))
21
 Translating a ternary relationship

pname quantity vname

pid vid

Selling_
Part Parts Vendor

address

Shop
Branch

Selling_parts( pid, vid, address, quantity)

22
 Translating a ternary relationship
• Assume each employee works in at most one
department and at a single location (but:
– each dept can be associated with several locations and
employees, and
– each location can be associated with several departments
and employees,
since WorksIn
name dname
ssn did location
ssn lot did budget
100 1 Ankara
Employees Works_In Departments
200 1 Ankara
300 2 Ankara
400 2 İstanbul
address
500 3 İstanbul
23
Locations
 Translating a ternary relationship
CREATE TABLE Works_In(
ssn CHAR(11),
did INTEGER,
address CHAR(20),
since DATE,
PRIMARY KEY (ssn),
FOREIGN KEY (ssn) REFERENCES Employees,
FOREIGN KEY (did) REFERENCES Departments
FOREIGN KEY (address) REFERENCES Locations )
since WorksIn
name dname
ssn did location
ssn lot did budget
100 1 Ankara
Employees Works_In Departments
200 1 Ankara
300 2 Ankara
400 2 İstanbul
address
500 3 İstanbul
24
Locations
 Weak Entities
Ø A weak entity can be identified uniquely only by considering the
primary key of another (owner) entity.
Ø identified by its discriminator attributes (partial key) + PK of another
(owner) entity
Ø Suppose our employees have pets, each pet has a name!
rambo 100

pname age

Pets rambo 200

25
 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 pname age
ssn lot

Employees Has Pets

26
 Translating Weak Entity Sets
• Weak entity set and identifying relationship set are
translated into a single table.
– When the owner entity is deleted, all owned weak
entities must also be deleted.
Do I need this?
CREATE TABLE Has_Pets (
pname CHAR(20),
age INTEGER,
cost REAL,
ssn CHAR(11) NOT NULL,
PRIMARY KEY (pname, ssn),
FOREIGN KEY (ssn) REFERENCES Employees,
ON DELETE CASCADE)
27
ISA (`is a´) Hierarchies
ØAs in object-oriented programming languages, attributes are inherited.
• If we declare A ISA B, every A entity is also considered to be a B entity.
ØReasons for using ISA:
– To add descriptive attributes specific to a subclass.
– To identify entities that participate in a relationship.

name
ssn lot

Employees

hourly_wages hours_worked
ISA
contractid

Hourly_Emps Contract_Emps

28
 ISA (`is a´) Hierarchies
Ø 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)

29
 Translating ISA Hierarchies to Relations
• General approach:
– 3 relations: Employees, Hourly_Emps and Contract_Emps.
• Hourly_Emps: Every employee is recorded in Employees.
For hourly emps, extra info recorded in Hourly_Emps
(hourly_wages, hours_worked, ssn); must delete
Hourly_Emps tuple if referenced Employees tuple is deleted).
• Queries involving all employees easy, those involving just
Hourly_Emps require a join to get some attributes.
• Alternative: Just Hourly_Emps and Contract_Emps.
– Hourly_Emps: ssn, name, lot, hourly_wages, hours_worked.
– Each employee must be in one of these two subclasses.

30
 Translating ISA Hierarchies to Relations
name
ssn lot

Employees

hourly_wages hours_worked
ISA
contractid
• First approach:
– 3 relations. Hourly_Emps Contract_Emps

• Employees(ssn, name, lot)

• Hourly_Emps(ssn, hourly_wages, hours_worked)
• Contract_Emps(ssn, contractid)
– In Hourly_Emps & Contract_Emps tables:
• FOREIGN KEY (ssn) REFERENCES Employees ON
31
DELETE CASCADE
 Translating ISA Hierarchies to Relations
name
ssn lot

Employees

hourly_wages hours_worked
ISA
contractid

Hourly_Emps Contract_Emps

• Second approach:
– 2 relations.
• Hourly_Emps(ssn, name, lot, hourly_wages, hours_worked)
• Contract_Emps(ssn, name, lot, contractid)
– Not applicable if not "covering" 32
 name
ssn lot

Aggregation Employees
Suppose:
Øentity set Projects
Øeach Projects is sponsored by
at least one Departments
Øeach Departments that
sponsors a Projects might since
started_on
assign employees to monitor dname
sponsorship pid pbudget did budget

Projects Sponsors Departments

Intuitively…
ØMonitors should be a
relationship set that
associates a Sponsors
relation (versus a Projects
or Departments) with an
Employees entity.
33
 name
ssn lot

Aggregation Employees

Ø Aggregation is used
when we have to model Monitors until
a relationship involving
(entity sets and) a
since
relation: a relationship started_on
dname
set. pid pbudget did budget

Ø Aggregation allows us Projects Sponsors Departments

to treat a relationship
set as an entity set for
purposes of
participation in (other)
relationships.

34
 name
ssn lot

Aggregation Employees

Monitors until

started_on since
dname
pid pbudget did budget

Projects Sponsors Departments

Ø Mapping to Relational Model:

Employees(ssn, name, lot)
Projects(pid, started_on, pbudget)
Departments(did, dname, budget)
Sponsors(pid, did, since)
Monitors(ssn, pid, did, until)
35
 name
Aggregation vs. ssn lot

Ternary relation Employees

Suppose:
Ø No need to record until
attribute of Monitors
started_on since
ØThen… dname
pid pbudget did budget
ØCan use ternary
relationship Sponsors2 Sponsors2
Projects Departments

But suppose we have constraint that:

Each sponsorship (of a project by a department) be monitored
by at most one employee?
Then…
Can’t do it with Sponsors2 à Need aggregated relationship Sponsors
36
 name
Aggregation vs. ssn lot

Ternary relation Employees

(Contd.)
Monitors until

Ø Monitors is a
distinct relationship, started_on since
dname
with a descriptive pid pbudget did budget
attribute (until).
Projects Sponsors Departments
Ø Also, can say that
each sponsorship
is monitored by at
most one employee.

37
 name
Aggregation vs. ssn lot

Ternary relation Employees

(Contd.)
Monitors until

started_on since
dname
pid pbudget did budget

Projects Sponsors Departments

Ø Mapping:
Projects(pid, started_on, pbudget)
Departments(did, dname, budget)
Sponsors(pid, did, since)
Employees(ssn, name, lot)
Monitors(pid, did, ssn, until) Where does pid and did refer to? 38
 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.

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

40
 Entity vs. Attribute (Cont.)
from to
name dname
Ø Works_In2 does not ssn lot did budget
allow an employee to
Employees Works_In2 Departments
work in a department
for two or more periods.
Ø Similar to the problem of
wanting to record several
addresses for an employee:
name dname
we want to record several ssn lot did budget
values of the descriptive
Employees Works_In3 Departments
attributes for each instance
of this relationship.
from Duration to

41
 Entity vs. Relationship
Ø First ER diagram OK if a since dbudget
manager gets a separate name dname
ssn lot did budget
discretionary budget for
each dept. Employees Manages2 Departments
Ø What if a manager gets a
discretionary budget that
covers all managed depts? name dname
– Redundancy of budget, ssn lot did budget
which is stored for each
dept managed by the Employees Manages3 Departments
manager.
Misleading: suggests dbudget
since
tied to managed dept. apptnum Mgr_Appts
dbudget
42
 Binary vs. Ternary Relationships
name
Suppose that: ssn lot pname age
Ø a policy cannot be
Employees Covers Dependents
owned jointly by two
or more Employee: Bad design Policies

–Key constraint on Policies policyid cost

would mean policy can only
cover 1 dependent!
• Suppose that:
• Every policy must be owned by
some employee
•Acceptable if each policy covers
at least one dependent

43
 Binary vs. Ternary Relationships (Cont.)
Ø What are the additional constraints in this 2nd diagram?
–Policy cannot be owned jointly by two or more employees
–Every policy must be owned by some employee
–Dependent is a weak entity set, and each dependent entity is uniquely
identified by taking pname in conjunction with the policyid of a policy.
–Dependents cannot be beneficiary of more than one policy.
name pname age
ssn lot
Dependents
Employees

Purchaser
Beneficiary

Better design Policies

policyid cost 44
 Binary vs. Ternary Relationships (Contd.)
CREATE TABLE Policies (
• The key constraints policyid INTEGER,
allow us to combine cost REAL,
Purchaser with ssn CHAR(11) NOT NULL,
Policies and PRIMARY KEY (policyid),
Beneficiary with FOREIGN KEY (ssn) REFERENCES Employees
Dependents. ON DELETE CASCADE)
• Participation CREATE TABLE Dependents (
constraints lead to pname CHAR(20),
NOT NULL
constraints. age INTEGER,
policyid INTEGER,
• What if Policies is a PRIMARY KEY (pname, policyid).
weak entity set? FOREIGN KEY (policyid) REFERENCES Policies
ON DELETE CASCADE)
CENG351 45
 Binary vs. Ternary Relationships (Cont.)

Ø Previous example illustrated a case when two binary

relationships were better than one ternary relationship.
Ø An example in the other direction: a ternary relation
Contracts relates entity sets Parts, Departments and
Suppliers, and has descriptive attribute qty.
Ø No combination of binary relationships is an adequate
substitute for at least two reasons:
– S “can-supply” P, D “needs” P, and D “deals-with” S
does not imply that D has agreed to buy P from S.
– How do we record qty?

46
 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.

47
 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.
– 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.

48
 Summary of ER (Contd.)
Ø ER design is subjective. There are often many
ways to model a given scenario! 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,
and whether or not to use aggregation.
Ø Ensuring good database design: resulting relational
schema should be analyzed and refined further. FD
information and normalization techniques are
especially useful.

49
Example
Ø 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 that no
further constraints hold).

50
 Example (cont’)
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 to all
subsequent 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 course must be taught by some professor.
6) Now assume 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 if necessary.
51
 Example (cont’)
1) Professors can teach the same course in several
semesters, and each offering must be recorded.

52
 Example (cont’)
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 to all subsequent questions.)

53
 Example (cont’)
3) Every professor must teach some course

54
 Example (cont’)
4) Every professor teaches exactly one course (no
more, no less).

55
 Example (cont’)
5) Every professor teaches exactly one course (no
more no less), and every course must be taught
by some professor.

56
 Example (cont’)
6) Now assume 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 if necessary.

57
Bank
Example

58