CHAPTER 3

Data Modeling Using the

Entity-Relationship (ER) Model

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 1- 1

NOTATION for ER diagrams

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 2

Example COMPANY Database
◼ We need to create a database schema design
based on the following (simplified) requirements
of the COMPANY Database:
◼ The company is organized into DEPARTMENTs.
Each department has a name, number and an
employee who manages the department. We keep
track of the start date of the department manager.
A department may have several locations.
◼ Each department controls a number of
PROJECTs. Each project has a unique name,
unique number and is located at a single location.

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 3

Example COMPANY Database
(Continued)
◼ The database will store each EMPLOYEE’s social
security number, address, salary, sex, and
birthdate.
◼ Each employee works for one department but may
work on several projects.
◼ The DB will keep track of the number of hours per
week that an employee currently works on each
project.
◼ It is required to keep track of the direct supervisor of
each employee.
◼ Each employee may have a number of
DEPENDENTs.
◼ For each dependent, the DB keeps a record of name,
sex, birthdate, and relationship to the employee. Slide 3- 4
Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei
Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 5

Refining the initial design by introducing
relationships

◼ The initial design is typically not complete

◼ Some aspects in the requirements will be
represented as relationships
◼ ER model has three main concepts:
◼ Entities (and their entity types and entity sets)
◼ Attributes (simple, composite, multivalued)
◼ Relationships (and their relationship types and
relationship sets)
◼ We introduce relationship concepts next

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 6

Relationships and Relationship Types (1)
◼ A relationship relates two or more distinct entities with a
specific meaning.
◼ For example, EMPLOYEE John Smith works on the ProductX
PROJECT, or EMPLOYEE Franklin Wong works for the
Research DEPARTMENT.
◼ Relationships of the same type are grouped or typed into
a relationship type.
◼ For example, the WORKS_ON relationship type in which
EMPLOYEEs and PROJECTs participate, or the MANAGES
relationship type in which EMPLOYEEs and DEPARTMENTs
participate.
◼ The degree of a relationship type is the number of
participating entity types.
◼ Both MANAGES and WORKS_ON are binary relationships.

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 7

Relationship instances of the WORKS_FOR N:1
relationship between EMPLOYEE and DEPARTMENT

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 8

Relationship instances of the M:N WORKS_ON
relationship between EMPLOYEE and PROJECT

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 9

Relationship type vs. relationship set (1)

◼ Relationship Type:
◼ Is the schema description of a relationship
◼ Identifies the relationship name and the
participating entity types
◼ Also identifies certain relationship constraints
◼ Relationship Set:
◼ The current set of relationship instances
represented in the database
◼ The current state of a relationship type

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 10

Relationship type vs. relationship set (2)
◼ Previous figures displayed the relationship sets
◼ Each instance in the set relates individual participating
entities – one from each participating entity type
◼ In ER diagrams, we represent the relationship type as
follows:
◼ Diamond-shaped box is used to display a relationship

type
◼ Connected to the participating entity types via straight

lines
◼ Note that the relationship type is not shown with an

arrow. The name should be typically be readable from

left to right and top to bottom.
Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 11
Refining the COMPANY database
schema by introducing relationships
◼ By examining the requirements, six relationship types are
identified
◼ All are binary relationships( degree 2)
◼ Listed below with their participating entity types:
◼ WORKS_FOR (between EMPLOYEE, DEPARTMENT)
◼ MANAGES (also between EMPLOYEE, DEPARTMENT)
◼ CONTROLS (between DEPARTMENT, PROJECT)
◼ WORKS_ON (between EMPLOYEE, PROJECT)
◼ SUPERVISION (between EMPLOYEE (as subordinate),
EMPLOYEE (as supervisor))
◼ DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 12

ER DIAGRAM – Relationship Types are:
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 13

Discussion on Relationship Types
◼ In the refined design, some attributes from the initial entity
types are refined into relationships:
◼ Manager of DEPARTMENT -> MANAGES
◼ Works_on of EMPLOYEE -> WORKS_ON
◼ Department of EMPLOYEE -> WORKS_FOR
◼ etc
◼ In general, more than one relationship type can exist
between the same participating entity types
◼ MANAGES and WORKS_FOR are distinct relationship
types between EMPLOYEE and DEPARTMENT
◼ Different meanings and different relationship instances.

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 14

Constraints on Relationships
◼ Constraints on Relationship Types
◼ (Also known as ratio constraints)
◼ Cardinality Ratio / Cardinality Mapping

- mapping of one entity set to another entity set in a

relationship set

Four types of cardinality mapping in DBMS

◼ One-to-one (1:1) • 1 student can have only 1 student ID
◼ One-to-many (1:N)
• 1 university can have many (N) students
• Many (N) students can have 1 teacher
◼ Many-to-one (N:1)
• Many (M) students can work on a single
◼ Many-to-many (M:N)
project and a single student can work on
many (N) projects

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 15

Many-to-one (N:1) Relationship

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 16

Many-to-many (M:N) Relationship

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 17

Recursive Relationship Type
◼ A relationship type between the same participating entity
type in distinct roles
◼ Also called a self-referencing relationship type.
◼ Example: the SUPERVISION relationship
◼ EMPLOYEE participates twice in two distinct roles:
◼ supervisor (or boss) role
◼ supervisee (or subordinate) role
◼ Each relationship instance relates two distinct
EMPLOYEE entities:
◼ One employee in supervisor role
◼ One employee in supervisee role

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 18

Displaying a recursive
relationship
◼ In a recursive relationship type.
◼ Both participations are same entity type in
different roles.
◼ For example, SUPERVISION relationships
between EMPLOYEE (in role of supervisor)
and (another) EMPLOYEE (in role of
subordinate).
◼ We create a relationship between the same entity
type.
◼ In following figure, first role participation labeled
with 1 and second role participation labeled with
2.

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 19

A Recursive Relationship Supervision`

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 20

Recursive Relationship Type is: SUPERVISION
(participation role names are shown)

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 21

Weak Entity Types
◼ An entity that does not have a key attribute and that is identification-
dependent on another entity type.
◼ A weak entity must participate in an identifying relationship type with
an owner or identifying entity type
◼ Entities are identified by the combination of:
◼ A partial key of the weak entity type

◼ The particular entity they are related to in the identifying

relationship type
◼ Example:
◼ A DEPENDENT entity is identified by the dependent’s first name,
and the specific EMPLOYEE with whom the dependent is related
◼ Name of DEPENDENT is the partial key

◼ DEPENDENT is a weak entity type

◼ EMPLOYEE is its identifying entity type via the identifying

relationship type DEPENDENT_OF

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 22

Attributes of Relationship types
◼ A relationship type can have attributes:
◼ For example, HoursPerWeek of WORKS_ON
◼ Its value for each relationship instance describes
the number of hours per week that an EMPLOYEE
works on a PROJECT.
◼ A value of HoursPerWeek depends on a particular
(employee, project) combination
◼ Most relationship attributes are used with M:N
relationships
◼ In 1:N relationships, they can be transferred to the
entity type on the N-side of the relationship

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 23

Example Attribute of a Relationship Type:
Hours of WORKS_ON

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 24

Notation for Constraints on
Relationships
◼ Cardinality ratio (of a binary relationship): 1:1,
1:N, N:1, or M:N
◼ Shown by placing appropriate numbers on the
relationship edges.

◼ Participation constraint (rules that determine the

minimum and maximum participation of entities or
relationships in a given relationship set)
◼ Total participation
◼ Partial participation
◼ Total shown by double line, partial by single line.

Copyright © 2016 Ramez Elmasr and Shamkant B. Navathei Slide 3- 25