Entity-Relationship Model

Chapter 2
Contents

1 Overview of Database Design Process

2 A Sample Database Application
3 What is ER Model? And Why?
4 ER Model Concepts
5 ER Diagram and Naming Conventions
6 Alternative Diagrammatic Notations
7 Problems with ER Models

2
Contents

1 Overview of Database Design Process

2 A Sample Database Application
3 What is ER Model? And Why?
4 ER Model Concepts
5 ER Diagram and Naming Conventions
6 Alternative Diagrammatic Notations
7 Problems with ER Models

3
Contents

1 Overview of Database Design Process

2 A Sample Database Application
3 What is ER Model? And Why?
4 ER Model Concepts
5 ER Diagram and Naming Conventions
6 Alternative Diagrammatic Notations
7 Problems with ER Models

4
Overview of Database Design Process
 Database design
 To design the conceptual schema for a database
application
 Applications design
 Focus on the programs and interfaces that access the
database
 Generally considered part of software engineering

5
Overview of Database Miniworld
Design Process
REQUIREMENTS - COLLECTION & ANALYSIS

Functional requirements Data requirements

DBMS–independent

FUNCTIONAL ANALYSIS
CONCEPTUAL DESIGN

High-level transaction Conceptual schema

specification
LOGICAL DESIGN
(DATA MODEL MAPPING)
DBMS–specific

APPLICATION PROGRAM Database schema

DESIGN
PHYSICAL DESIGN

TRANSACTION
Internal schema
IMPLEMENTATION

Application program
6
Application Design Database Design
Overview of Database Miniworld
Design Process
REQUIREMENTS - COLLECTION & ANALYSIS

Data requirements

DBMS–independent
• Interview prospective
database users CONCEPTUAL DESIGN

• Result: Conceptual schema

 Data requirements
 Functional LOGICAL DESIGN
(DATA MODEL MAPPING)
requirements
DBMS–specific Database schema

PHYSICAL DESIGN

Internal schema

7
Database Design
Overview of Database Miniworld
Design Process
REQUIREMENTS - COLLECTION & ANALYSIS

• Create a conceptual Data requirements

DBMS–independent
schema using a high-
CONCEPTUAL DESIGN
level conceptual data
model (Entity- Conceptual schema

Relationship model)
LOGICAL DESIGN
• Descriptions of entity (DATA MODEL MAPPING)
types, relationships,
DBMS–specific Database schema
and constraints
• Independent of
PHYSICAL DESIGN
storage and
implementation details. Internal schema

8
Database Design
Overview of Database Miniworld
Design Process
REQUIREMENTS - COLLECTION & ANALYSIS

• Create a database Data requirements

DBMS–independent
schema in CONCEPTUAL DESIGN
implementation data
Conceptual schema
model of a commercial
DBMS LOGICAL DESIGN
• Data model mapping (DATA MODEL MAPPING)

DBMS–specific
is often automated or Database schema
semi-automated within
the database design PHYSICAL DESIGN
tool.
Internal schema

9
Database Design
Overview of Database Miniworld
Design Process
REQUIREMENTS - COLLECTION & ANALYSIS

Data requirements

DBMS–independent
CONCEPTUAL DESIGN

Conceptual schema

• Specify internal storage LOGICAL DESIGN

structures, file (DATA MODEL MAPPING)

organizations, indexes, DBMS–specific Database schema

access paths, and
physical design PHYSICAL DESIGN
parameters for the
Internal schema
database files.

10
Database Design
Contents

1 Overview of Database Design Process

2 A Sample Database Application
3 What is ER Model? And Why?
4 ER Model Concepts
5 ER Diagram and Naming Conventions
6 Alternative Diagrammatic Notations
7 Problems with ER Models

11
A Sample Database Application
 Design a database for a COMPANY that keeps track of
employees, departments, and projects
 REQUIREMENTS - COLLECTION & ANALYSIS

Data requirements
What data should
be stored?
- Entities
- Attributes
- Relationships
- Constraints

12
A Sample Database Application
 The COMPANY database: keeps track of employees,
departments, and projects.
 The company is organized into DEPARTMENTs. Each
department has a unique name, a unique number, and
a 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.
 A department controls a number of PROJECTs, each of
which has a unique name, a unique number, and a
single location.

13
A Sample Database Application
 We store 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 current
number of hours per week that an employee works on
each project. We also keep track of the direct
supervisor of each employee.
 We want to keep track of the DEPENDENTs of each
employee, including first name, sex, birth date, and
relationship to the employee.

14
Entity-Relationship
Diagram (ERD) for
COMPANY Database
15
Contents

1 Overview of Database Design Process

2 A Sample Database Application
3 What is ER Model? And Why?
4 ER Model Concepts
5 ER Diagram and Naming Conventions
6 Alternative Diagrammatic Notations
7 Problems with ER Models

16
What is ER Model?
 Entity-Relationship (ER) model
 Popular high-level conceptual data model
 A logical organisation of data within a database system
 ER Diagrams (ERD):
 Diagrammatic notation associated with the ER model
 Conceptual Design:
Data requirements  Conceptual Schema (ERD)

17
Why use ER data modelling?
 User requirements can be specified formally &
unambiguously
 It can be easily understood by ordinary users.
 It provides an effective bridge between user
requirements and logical database design and
implementation
 The conceptual data model is independent of any
particular DBMS
 It does not involve any physical or implemental details

18
Contents

1 Overview of Database Design Process

2 A Sample Database Application
3 What is ER Model? And Why?
4 ER Model Concepts
5 ER Diagram and Naming Conventions
6 Alternative Diagrammatic Notations
7 Problems with ER Models

19
ER Model Concepts
 ER model describes data as:
 Entities
 Attributes
 Relationships

20
ERD for
COMPANY Database
21
Entity
 Entity is a thing in the real world with an independent
existence.
 An entity may be an object with a physical existence (a
person, a car, a house, or an employee) or an object
with a conceptual existence (a company, a job, or a
university course)
 Examples: In a COMPANY:
 the EMPLOYEE John Smith
 the Research DEPARTMENT
 the ProductX PROJECT

22
Attribute
 Attributes are properties described an entity.
 Ex: an EMPLOYEE entity may have Name, SSN, Address,
Sex, BirthDate
 A specific entity will have a value for each of its
attributes.
 Each attribute has a value set (or data type)
associated with it.

23
Types of Attributes
 Simple attribute has a single atomic value.
 SSN, Sex
 Composite attribute may be composed of several
components.
 Name (First name, Middle name, Last name)
 Multi-valued attribute has multiple values.
 Colors of a Car {Color}, Phones of a Person {Phone}
 Derived attribute has a value that is derivable from
values of related attributes.
 Number of students in a class
 Complex attribute is a combination of composite and
multivalued attributes.
24
Entities and Attributes

Two entities, EMPLOYEE e1, and COMPANY c1, and

their attributes.
25
Entity Types
 Collection (or set) of entities that have the same
attributes

26
Keys
 Key or uniqueness constraint
 Attributes whose values are distinct for each individual
entity in entity set
 Uniqueness property must hold for every entity set of the
entity type
 Ex: SSN of EMPLOYEE
 An entity type may have more than one key.
 Ex: the STUDENT entity type may have two keys (in
university context):
 Citizen ID and
 Student ID

27
Notations of Entity type, Attributes, Key
 Entity type

 Simple attribute

 Composite attribute

 Multi-valued attribute

 Complex attribute

 Derived attribute

 Key Key
28
Entity Type CAR with two keys and a
corresponding Entity Set

29
Identify Entity Types and Attributes
The COMPANY database:
 The company is organized into departments.
DEPARTMENTs. EachEach
department has a unique
unique name,
name,aaunique
uniquenumber,
number,and
aand
particular employee
a particular who who
employee manages the department.
manages the
We keep track
department. Weofkeep
the start
trackdate when
of the that
start employee
date when that
began managing
employee the department.
began managing A department
the department. A may
have severalmay
department locations.
have several locations.
 A department
department controls
controlsaanumber
numberofofprojects,
PROJECTs,eacheach
of
which
of whichhashas
a unique name,
a unique a unique
name, number,
a unique and aand a
number,
single location.
single location.

30
Identify Entity Types, Attributes
 We store EMPLOYEE’s
employee’s name,name,social
Social
security
Security
number,
number,
address, salary,
address, salary,sex,
sex,and
andbirth
birthdate.
date.
AnAnemployee
employee is is
assigned to
assigned toone
onedepartment,
department,but butmay
maywork
work onon
several
projects,projects,
several which are which
not necessarily
are not necessarily
controlledcontrolled
by the
same
by thedepartment.
same department.
We keep Wetrack
keepoftrack
the current
of the current
number of
number ofhours
hoursper
perweek
weekthat
thatan
anemployee
employeeworks
workson on
each project. We also keep track of the direct
direct
supervisor of
supervisor ofeach
eachemployee.
employee.
 We want to keep track of the dependents
DEPENDENTs of each
of each
employee, including
includingfirst
firstname,
name,sex,
sex,birth
birth
date,
date,
andand
relationship to
relationship tothe
theemployee.
employee.

31
Initial Conceptual Design of COMPANY Database

32
ERD for
COMPANY Database
33
Relationships and Relationship Types
 Relationship type R among n entity types E1, E2, ..., En
 Defines a set of associations among entities from these
entity types
 Ex: Relationship type WORKS_FOR between EMPLOYEEs
and DEPARTMENTs
 Relationship instances ri
 Each ri associates n individual entities (e1, e2, ..., en). Each
entity ej in ri is a member of entity set Ej
 Ex: EMPLOYEE John Smith works on the PROJECT
ProductX

34
Relationships and Relationship Types
 Degree of a relationship type
 Number of participating entity types
 Binary (degree 2), ternary (degree 3), and n-ary (degree
n)
 More than one relationship type can exist with the
same participating entity types.
 EMPLOYEE – Works-for – DEPARTMENT
 EMPLOYEE - Manages – DEPARTMENT

35
Example relationship instances

A binary relationship
36
Example relationship instances

A ternary relationship
37
Relationships and Relationship Types
 Recursive relationships
 Same entity type participates more than once in a
relationship type in different roles
 Must specify role that a participating entity plays in each
relationship instance
 Ex: SUPERVISION relationships between EMPLOYEE (in
role of supervisor or boss) and (another) EMPLOYEE (in
role of subordinate or worker)

38
A Recursive Relationship SUPERVISION

1: supervisor
39 2: supervisee
Constraints on Binary Relationship Type
 Structural constraints: one way to express semantics
of relationship: cardinality ratio and participation
constraint.
 Cardinality ratio: specifies maximum number of
relationship instances that entity can participate in a
binary relationship.
 one-to-one (1:1)
 one-to-many (1:M) or many-to-one (M:1)
 many-to-many (M:N)

40
One-to-one (1:1) RELATIONSHIP

41
Many-to-many (M:N) RELATIONSHIP

42
Constraints on Binary Relationship Type
 Participation constraint (or membership class):
specifies whether existence of entity depends on its
being related to another entity
 Mandatory (total participation) - every instance of a
participating entity type must participate in the
relationship. (double line)
 Optional (partial participation) - not every instance of a
participating entity type must participate in the
relationship. (single line)

43
 Notations of Relationship type
 Relationship type

Cardinality An EMPLOYEE works for one DEPARTMENT.

ratio A DEPARTMENT has many EMPLOYEEs.

N Works- 1
EMPLOYEE DEPARTMENT
for

An EMPLOYEE must works for a DEPARTMENT. Participation

A DEPARTMENT may have no EMPLOYEE. constraint

44
Attributes of Relationship Types
 A relationship type can have attributes.
 HoursPerWeek of WORKS_ON
 1:1 relationship type: relationship attributes can be
migrated to any participating entity type.
 1:N relationship type: relationship attributes can be
migrated only to entity type on N-side of relationship.
 M:N relationship types: relationship attributes cannot
be migrated to any entity type.

45
ERD for
COMPANY Database
46
Weak Entity Types
 Do not have key attributes of their own
 Identified by being related to specific entities from
another entity type
 Identifying relationship: Relates a weak entity type
to its owner
 Always has a total participation constraint
 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
entity type

47
Notations of Relationship type
 Weak entity type

 Identifying relationship type

 Partial key

Name SSN

N 1
DEPENDENT Of EMPLOYEE

Identifying/Parent/
Owner entity type
48
Identify Entity Types, Attributes, Relationships
The COMPANY database:
 The company is organized into departments.
DEPARTMENTs. Each
Each
department has a unique
unique name,
name,aaunique
uniquenumber,
number, and
aand
particular employee
a particular whowho
employee manages the department.
manages the
We keep track
department. Weofkeep
the start
trackdate when
of the that
start employee
date when that
began managing
employee the department.
began managing A department
the department. A may
have severalmay
department locations.
have several locations.
 A department controls a number of projects,
PROJECTs, each of of
each
which has a unique
uniquename,
name,aaunique
uniquenumber,
number,and a a
and
single location.
single location.

49
Identify Entity Types, Attributes, Relationships
 We store EMPLOYEE’s
employee’s name, name,social
Social
security
Security
number,
number,
address, salary,
address, salary,sex,
sex,and
andbirth
birthdate.
date.
AnAn employee
employee is is
assigned to
assigned toone
onedepartment,
department,but butmay
maywork
workononseveral
several
projects, which are not necessarily controlled by the
same department. We keep track of the current number
number
of hours per
of hours
weekper
thatweek
an employee
that an employee
works onworks
each on
each project.
project. We also
Wekeep
also keep
tracktrack
of theofdirect
the direct
supervisor of
supervisor
each employee.
of each employee.
 We want to keep track of the dependents
DEPENDENTs of each
of each
employee, including
includingfirst
firstname,
name,sex,
sex,birth
birth
date,
date,
andand
relationship to
relationship tothe
theemployee.
employee.

50
ERD for
COMPANY Database
51
Contents

1 Overview of Database Design Process

2 A Sample Database Application
3 What is ER Model? And Why?
4 ER Model Concepts
5 ER Diagram and Naming Conventions
6 Alternative Diagrammatic Notations
7 Problems with ER Models

52
ER Diagram and Naming Conventions
 An ER model can be expressed in the form of the ER
diagram.
 Proper Naming of Schema Constructs:
 Choose names that convey meanings attached to different
constructs in schema
 Nouns give rise to entity type names
 Verbs indicate names of relationship types
 Choose binary relationship names to make ER diagram
readable from left to right and from top to bottom

53
Summary of the
Notation for ER
Diagrams

54
Draw Entity-Relationship Diagram
The COMPANY database:
 The company is organized into departments.
DEPARTMENTs. Each
Each
department has a unique
unique name,
name,aaunique
uniquenumber,
number, and
aand
particular employee
a particular whowho
employee manages the department.
manages the
We keep track
department. Weofkeep
the start
trackdate when
of the that
start employee
date when that
began managing
employee the department.
began managing A department
the department. A may
have severalmay
department locations.
have several locations.
 A department controls a number of projects,
PROJECTs, each of of
each
which has a unique
uniquename,
name,aaunique
uniquenumber,
number,and a a
and
single location.
single location.

55
Draw Entity-Relationship Diagram
 We store EMPLOYEE’s
employee’s name, name,social
Social
security
Security
number,
number,
address, salary,
address, salary,sex,
sex,and
andbirth
birthdate.
date.
AnAn employee
employee is is
assigned to
assigned toone
onedepartment,
department,but butmay
maywork
workononseveral
several
projects, which are not necessarily controlled by the
same department. We keep track of the current number
number
of hours per
of hours
weekper
thatweek
an employee
that an employee
works onworks
each on
each project.
project. We also
Wekeep
also keep
tracktrack
of theofdirect
the direct
supervisor of
supervisor
each employee.
of each employee.
 We want to keep track of the dependents
DEPENDENTs of each
of each
employee, including
includingfirst
firstname,
name,sex,
sex,birth
birth
date,
date,
andand
relationship to
relationship tothe
theemployee.
employee.

56
ERD for
COMPANY Database
57
Case study: Draw ERD

GROUP A GROUP B
A system for course An order management
registration of HCMUT system for a shop

58
Case study: Draw ERD

GROUP A GROUP B
A system for course A system for a Library of a
registration of HCMUT University

59
Contents

1 Overview of Database Design Process

2 A Sample Database Application
3 What is ER Model? And Why?
4 ER Model Concepts
5 ER Diagram and Naming Conventions
6 Alternative Diagrammatic Notations
7 Problems with ER Models

60
Alternative Diagrammatic Notations
 (Min-max) notation for relationships
 Specify structural constraints on relationships
 Replaces cardinality ratio (1:1, 1:N, M:N) and
single/double line notation for participation constraints
 Associate a pair of integer numbers (min, max) with each
participation of an entity type E in a relationship type R,
where 0 ≤ min ≤ max and max ≥ 1

61
(min, max) notation

(1,1) Works- (4,N)

EMPLOYEE DEPARTMENT
for

(0,1) (1,1)
EMPLOYEE Manages DEPARTMENT

62
63
Alternative Diagrammatic Notations
 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

64
65
Alternative Diagrammatic Notations
 UML class diagrams
 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
 Associations: relationship types
 Relationship instances: links

66
Alternative Diagrammatic Notations
 UML class diagrams
 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

67
Alternative Diagrammatic Notations
 UML class diagrams
 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

68
 Alternative Diagrammatic Notations
Symbols for entity type / class, Displaying attributes
attribute and relationship

Notations for displaying

Various (min, max) Displaying
specialization / generalization
notations cardinality ratios

69
Contents

1 Overview of Database Design Process

2 A Sample Database Application
3 What is ER Model? And Why?
4 ER Model Concepts
5 ER Diagram and Naming Conventions
6 Alternative Diagrammatic Notations
7 Problems with ER Models

70
Problems with ER Models
 Semantic constraints
 Connection traps

71
Semantic constraints
 Constraints that cannot be directly expressed in the ER
diagram
 Must be expressed and enforced by the trigger
mechanism, or application programs or in some other
ways.
 Examples:
 The age of an employee must be greater than 18 years old
 The salary of a department manager must be higher than
the other employees works for that department.
 When increasing salary of employee, the increasing
amount must not more than 20% of current salary.

72
Connection traps
 Often due to a misinterpretation of the meaning of
certain relationships
 Two main types of connection traps are called fan traps
and chasm traps

73
Connection traps
 Fan Trap
 Where a model represents a relationship between entity
types, but pathway between certain entity occurrences is
ambiguous
 Usually: two or more 1:N relationships fan out from the
same entity
 Chasm Trap
 Where a model suggests the existence of a relationship
between entity types, but pathway does not exist
between certain entity occurrences
 Usually: optional participation

74
An Example of a Fan Trap

At which branch office does staff number SG37 work?

75
Restructuring ER model to remove Fan Trap

SG37 works at branch B003

76
An Example of a Chasm Trap

At which branch office is property PA14 available?

77
ER Model restructured to remove Chasm Trap

Property PA14 is at
78
the branch B007
Contents

1 Overview of Database Design Process

2 A Sample Database Application
3 What is ER Model? And Why?
4 ER Model Concepts
5 ER Diagram and Naming Conventions
6 Alternative Diagrammatic Notations
7 Problems with ER Models

79
80
Exercise 1: University Database
The university database maintains records of its departments,
lecturers, course modules, and students. The university
consists of departments. Each department has a unique name
and some other descriptive attributes. A department must
also have a number of lecturers, one of which is the head of
department. All lecturers have different names (we assume so
anyway). They must teach one or more modules. A lecturer
can only belong to one department. Modules are offered by
departments . A module is taught by one lecturer. They must
also be attended by some students. Each module has a unique
module number. Students must enrol for a number of
modules. Each student is given a unique student number

81
Exercise 2: Small LIB Database
You are to design a database for a small library. The
database needs to store data about various branches and
about books the library holds. Each branch has an id
(unique), name (unique) and an address. For each book,
the database should record the book id (unique), title,
publisher and the year of publication. A book may have
several authors, and each author is represented by
his/her name. A book typically has several copies. Each
copy of a book is given a copy number. The availability of
a book should be known, as well as the total number of
copies

82
 1 N

83
 1 1

84
 1 N
E R D

N 1
E R D

1 N
E R D

N 1
E R D

85
a. There are no actors in this database that have been in no
movies.
b. There are some actors who have acted in more than ten
movies.
c. Some actors have done a lead role in multiple movies.
d. A movie can have only a maximum of two lead actors.
86
e. Every director has been an actor in some movie.
f. No producer has ever been an actor.
g. A producer cannot be an actor in some other movie.
h. There are movies with more than a dozen actors.
87
i. Some producers have been a director as well.
j. Most movies have one director and one producer.
k. Some movies have one director but several producers.
l. There are some actors who have done a lead role, directed a movie,
and produced a movie.
88
m. No movie has a director who also acted in that movie.
Case study: Requirements - Collection & Analysis
Data requirements
- Entities
- Attributes
- Relationships
- Constraints

GROUP A GROUP B
A system for course An order management
registration of HCMUT system for a shop

89
Case study: Requirements - Collection & Analysis
Data requirements
- Entities
- Attributes
- Relationships
- Constraints

GROUP A GROUP B
A system for course A system for a Library of a
registration of HCMUT University

90
 Case study: Identify Entity Types and Attributes
GROUP A GROUP B
A system for course An order management
registration of HCMUT system for a shop

Entity type
Composite att.
Simple att.

Key Key Multi-valued Derived

91
attribute attribute
 Case study: Identify Entity Types and Attributes
GROUP A GROUP B
A system for course A system for a Library of a
registration of HCMUT University

Entity type
Composite att.
Simple att.

Key Key Multi-valued Derived

92
attribute attribute