

Chapter 7
Data Modeling Using the EntityRelationship (ER) Model

1



Entity Relationship Model (ER)

ER model was proposed by Peter Chen in
1976

ER model has become the standard tool for
conceptual schema design

ER model consists of three basic constructs:
entities, attributes and relationships.
2




What is an entity ?

An entity is a “thing” in the real world with an
independent existence.

It may be an object with physical existence
(e.g. person, car, house, employee), or it may
be an object with conceptual existence
(company, job, university, course).
3




Entity and Entity Set

Two types of entities:
 Strong entity: can exist independently (or
can uniquely identify itself)
 Weak entity: existence depends on the
existence of other (strong) entity or
entities

Examples:
 An employee is a strong entity but the
dependents of the employee could be
weak entities
 An account in a bank is a strong entity but
a transaction could be a week entity
4




Entity and Entity Set

An entity type defines a set of entities that
have the same attributes.
 STUDENT is an entity type (Schema)

An entity set is a collection of entities of the
same entity type

Examples:
 Rema, Ali, Amal, Samer, Rana are entity
set of an entity type STUDENT
5




Attributes

An entity has a set of attributes that describes it.
 Person(SSN, Name, Address, Job-description,
Salary).

An entity will have a value for each of its attributes
 (999-010-201, John Smith, ‘20 Alebany Rd,
Cardiff, UK’, ‘Manager’, 2500)

The properties of an entity set are called attributes of
the entity set.
 Students: SSN, Name, Address, GPA, Status, ...
 Books: Title, ISBN, Authors, Publisher, Year, ...
6



Types of Attributes


Simple (or atomic) attribute is a one which
cannot be divided into smaller parts.
 Examples:
 SSN, GPA, Salary.

Composite attribute is an attribute which can
be divided into smaller subparts, these subparts
represent more basic attributes with
independent meanings of their own
 Examples:
 Name: First_Name, Middle_Name, Last_Name
 Address: Street_Address, City, State, Zip code

7



An Example of a composite attribute
Address
Street-Address
City
State Post Code
House No. Street Name

8



Types of Attributes


A single-valued attribute is a one which has one
(single) value for a particular entity.
 Example: Age, BirthDate

A multi-valued attribute is a one which may
have one or more values for the same entity.
 College Degrees for Person: 0, 1, 2, 3, …
 Color for a Car: 1, 2, …..
 Authors of Books
 Phone Number
9



Types of Attributes

A stored attribute is a one whose value is
explicitly stored in the database.
 e.g. name, birth-date.

Derived-attributes: whose values are
computed from other attributes.
 Age from Birthdate
 Annual Salary from Monthly Salary
 NoOfEmployees ==> Count number of
employees in the Employee table.
10



Relationship Types



A relationship type is represented as diamondshaped box which is connected by straight lines
11


Relationship Degree

Degree of a relationship type is the number
of participating entity types: binary
relationships, ternary relationships, ….
EMPLOYEE
Works-for
COMPANY
Binary Relationships

12


Ternary Relationships
SUPPLIER
supplies

PROJECT
PART

13


Ternary Relationships
COMPANY
Sells

PRODUCT
COUNTRY

14


Binary
Recursive Relationships
EMPLOYEE
Supervises
PERSON


Marry
15


Relationships

The role name signifies the role that a
participating entity from the entity type
plays in each relationship instance

entity e1 plays the role of a supervisor, while
entity e2 plays the role of a supervisee

supervisee
e2
EMPLOYEE
Supervises
e1
supervisor

16



Cardinality Ratio

Specifies the number of relationship instances
that an entity can participate in

Common cardinality ratios for binary
relationship types are
 1:1,
 1:N, and
 M:N
17




1:N
EMPLOYEE
N
Works_for
1
COMPANY
An employee works for one company,
and a company has many employees
working for it

18



1:1
DEPARTMENT
1
Has
1
MANAGER
A department has one manager and a
manager manages one department

19



M:N
EMPLOYEE
M
Works-on
N
PROJECT
An employee works on many projects,
and a project has many employees
working on it

20



Participation Constraints

Specifies whether the existence of an
entity depends on its being related to
another entity via the relationship type

There is total and partial participation
21




Total participation
EMPLOYEE
N
Works-for
1
DEPARTMENT
Total participation.
Every employee must be related to a department
via WORKS-FOR relationship. A department
must have at least one employee.

22



Partial participation
PERSON
1
N
Buys
CAR
A person may buy a car and car
may be bought by a person

23


Total & Partial participation
1
PROFESSOR

1
Manages
DEPARTMENT
A professor may manage a department
(partial participation), but a department
must be managed by a professor (total
participation).

24


Attributes of Relationship Types
N
EMPLOYEE

1
Works-for
DEPARTMENT
Start-Date
We may keep a start date attribute to record for each
employee the date he/she started work for a certain
department.

25


A weak entity type is an entity which 
does not have any key attributes
EMPLOYEE
Works-for
1
DEPARTMENT
identifying relationship
Dependents
Fname
N
Sex
DEPENDENT
Birthdate

Relationship
26



Weak Entity Types
•
A weak entity type always has a total
participation with its identifying entity type
•
A Weak entity type has a partial key, i.e. this
key is enough to identify its extension within
the scope of its identifying entity type
•
In the previous example, the first name is
enough to identify kids within a single family,
but is not enough to identify entities as stand
alone entities (two families may use identical
names for their kids)
27



ER Notations
Entity Type
<Name>
Attribute
<Name>


<Name>
Key Attribute
<Name>
Multi-valued
attribute
28


ER Diagram Notations
<Name>
Weak Entity Type
<Name>
Relationship Type
<Name>


Identifying Relationship Type
29


ER Notations
<Name>
<Name>
Composite Attribute
<Name>
Derived Attribute
<Name>
<Name>


partial key attribute
30


Notations







Entity Types
 singular name, capital letters
Relationship Types
 usually singular verbs, capital letters
Attribute
 nouns, capitalized
Role names
 are in lowercase letters
ER diagrams are drawn such that they are
readable from left to right and top to bottom
(Except weak entity types)
31



Relationships

Several relationships may exist among the
same set of entity sets.
Works_in
EMPLOYEE
DEPARTMENT
Manages

32



Degree of a Relationship (1)

Definition:
 The degree of a relationship is the number of
entity sets participating the relationship.

Recursive relationship
Examples:
Supervises on Employees
is_prerequisite_of on Courses
is_classmate_of on Students
33



Degree of a Relationship (2)


Binary relationship (degree = 2)
 Examples:
 takes between Students and Courses
 owns between Persons and Cars

Ternary relationship (degree = 3)
 Examples:
 orders among Customers, Parts and
Suppliers
 skill_used among Engineers, Skills and
Projects

34


Cardinality (1)


One-to-one (1-to-1) relationship between E1 and E2:
 for each entity in E1, there is at most one
associated entity in E2, and vice versa.

Examples of 1-to-1 relationships:
 Binary 1-to-1 relationship
 manages between Employees and Departments

recursive 1-to-1 relationship
 is_married_to on Persons

35


Cardinality (2)



One-to-many (1-to-m) relationship from E1 to E2:
for each entity of E1, there are zero or more
associated entities of E2, but for each entity of E2,
there is at most one associated entity of E1
Examples of 1-to-m relationships:
 binary 1-to-m relationship
 advises between Professors and Students

recursive 1-to-m relationship
 is_mother_of on Persons


Many-to-one (m-to-1) relationship from E1 to E2:
same as 1-to-m relationship from E2 to E1
36


Cardinality (3)


Many-to-many (m-to-m) relationship between E1
and E2: for each entity in E1, there are zero or more
associated entities in E2, and vice versa

Examples of m-to-m relationships:
 binary m-to-m relationship
 takes between Students and Courses

recursive m-to-m relationship
 is_component_of on Parts

37


ER Diagram (1)

Recursive relationship
is_married_to
1
1
PERSON
SSN

Name
38
Age



ER Diagram (2)
binary relationship
PROFESSOR
SSN

Name
1
m
advises
Age
STUDENT
SSN
39
Name
Age



ER Diagram (3)
ternary relationship
ENGINEER
Skill_used
SKILL

PROJECT
40


Role of an Entity Set (1)

Definition: The role of an entity set in a relationship is the
function it performs in the relationship.
Case 1: Role can be determined from properly chosen
names.
m
takes
n
STUDENT
COURSE
1

is_TA_of
41
1



Role of an Entity Set (2)
Case 2: Roles need to be explicitly given.
is_married_to
supervises
1
1
wife
husband
PERSON

1
m
supervisor
supervisee
EMPLOYEE
42


Attribute of Relationship (1)

Where to keep the grade information?
STUDENT
m
takes
n
COURSE
grade

43


Attribute of Relationship (2)

Another example:
SUPPLIER
m
n
orders
PART

Quantity
r
PROJECT
44


Cardinality Constraint
min/max (1)



One in ER model means zero or one
Many in ER model means zero or more
Cardinality constraints make them more precise
STUDENT


(1, 5)
takes
45
(15, 60)
COURSE


Cardinality Constraint
min/max (2)

General format:

0  min_card  max_card
 Interpretation:

 Each entity in E may involve between min_card
and max_card relationships in R.
E

(min_card, max_card)
46
R


Cardinality Constraint
min/max (3)



Definition:
 If every entity in E involves at least one
relationship in R (i.e., min_card >= 1), E is
said to have total participation in R
 If min_card = 0, E is said to have partial
participation in R
47


Cardinality Constraint
min/max (4)

Employees has a partial participation.
Departments has a total participation.
EMPLOYEE

(0, 1)
manages
48
(1, 1)
DEPARTMENT


one-to-one:
many-to-many:
one-to-many:
(0, 1)
E
(0, m)
E
(0, m)
E
1
E


Representing 1-to-1, 1-to-m, m-to-m
Relationships
49
R
R
R
R
(0, 1)
(0, n)
(0,1)
m
F
F
F
F


An Example Database Application

Company Database

50


An Example Database
Application







The Company database keeps track of a
company’s
 Employees, Departments, Projects
The following are the requirements and
specifications
The company is organized into departments.
Each department has a:
 unique name, unique number
 particular employee who manages the
department
We keep track of the start date when that
employee began managing the department
A department may have several locations
51



An Example Database
Application







A department controls a number of projects,
each of which has a
 unique name, unique number, and single
location
We store each employee’s
 name, social security number, address,
salary, sex, and birth date.
An employee is assigned to one department but
may work on several projects, which are not
necessarily controlled by the same department
We keep track of the number of hours per week
that an employee works on each project
We keep track of the direct supervisor of each
employee
52


An Example Database
Application




We want to keep track of the dependents of
each employee for insurance purposes.
We keep each dependent’s first name, sex, birth
date, and relationship to the employee
53


ER diagram for the company
database

Each department has a unique name, a unique number, particular employee
who manages the department. A department may have several locations.
Name
Number
DEPARTMENT

54
Locations
NumberOfEmployee


ER diagram for the company
database

A department controls a number of projects, each of which has a unique
name, unique number, and single location
Name
Number
Location
PROJECT

55


ER diagram for the company
database

We store each employee’s name, social security number, address, salary, sex,
and birth date.
Fname
Minit
Name
Lname
SSN
Sex
BDate

EMPLOYEE
56
Address
Salary


ER diagram for the company
database

We want to keep track of the dependents of each employee for insurance
purposes. We keep each dependent’s first name, sex, birth date, and
relationship to the employee
Fname
Relationship
Sex
BDate

DEPENDENT
57


ER diagram for the company
database

Each department has a particular employee who manages the department
We keep track of the start date when that employee began managing the
department
(0,1)
EMPLOYEE
manager
(1,1)
DEPARTMENT
Manages
department
managed
StartDate

58


ER diagram for the company
database

An employee is assigned to one department.
(1,1)
EMPLOYEE
employee

(1,N)
DEPARTMENT
Works_for
department
59


ER diagram for the company
database

A department controls a number of projects
DEPARTMENT
(0,N)
(1,1)
controlling
department

PROJECT
Controls
controlled
project
60


ER diagram for the company
database

An employee is assigned to one department but may work on several
projects, which are not necessarily controlled by the same department. We
keep track of the number of hours per week that an employee works on each
project
EMPLOYEE
(0,N)
(1,N)
PROJECT
Works_on
worker
project
Hours

61


ER diagram for the company
database

We keep track of the direct supervisor of each
employee
EMPLOYEE
(0,N)
(0,1)
supervisor
supervisee
Supervises

62


ER diagram for the company
database

We want to keep track of the dependents of each
employee for insurance purposes.
EMPLOYEE
(0,N)
(1,1)
employee

DEPENDENT
has
dependent
63



ER diagram for the company
database
64



Example of Other Notation:
UML Class Diagrams




UML methodology
 Used extensively in software design
 Many types of diagrams for various
software design purposes
UML class diagrams
 Entity in ER corresponds to an object in
UML
65




66


Example of Other Notation:
UML Class Diagrams (cont’d.)



Class includes three sections:
 Top section gives the class name
 Middle section includes the attributes;
 Last section includes operations that can be
applied to individual objects
67


Example of Other Notation:
UML Class Diagrams (cont’d.)






Associations: relationship types
Relationship instances: links
Binary association
 Represented as a line connecting
participating classes
 May optionally have a name
Link attribute
 Placed in a box connected to the
association’s line by a dashed line
68


Example of Other Notation:
UML Class Diagrams (cont’d.)






Multiplicities: min..max, asterisk (*) indicates
no maximum limit on participation
Types of relationships: association and
aggregation
Distinguish between unidirectional and
bidirectional associations
Model weak entities using qualified
association
69


Relationship Types of Degree
Higher than Two





Degree of a relationship type
 Number of participating entity types
Binary
 Relationship type of degree two
Ternary
 Relationship type of degree three
70
