Entity-Relationship Diagram
Truong Tuan Anh
CSE-HCMUT
1
Contents
Database design process
ER Model
2
Database Design Process
Two main activities:
Database design
Applications design
Database design
To design the conceptual schema for a database
application
Applications design
Programs and interfaces that access the database
Generally considered part of software engineering
3
Database Design Process
4
Database Design Process
Collect and Analyze requirements
Database designers interview prospective
database users to understand and document
data requirements
Outputs:
Data requirements
Functional requirements
5
Database Design Process
Conceptual design
Create a conceptual schema for the
database.
Description of data requirements
Uses the concepts provided by the high-level data
model
Includes detailed descriptions of the entity types,
relationships, and constraints
Independent of storage and implementation
details.
6
Database Design Process
Logical design or data model mapping
Output is a database schema in
implementation data model of DBMS
Physical design phase
Internal storage structures, file organizations,
indexes, access paths, and physical design
parameters for the database files specified
7
ER Model
8
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:
Diagrammatic notation associated with the ER
model
9
Why ER Model?
User requirements can be specified formally &
unambiguously
The conceptual data model is independent of any
particular DBMS
It does not involve any physical or implemental
details
It can be easily understood by ordinary users.
It provides an effective bridge between user
requirements and logical database design and
implementation
10
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.
11
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.
12
COMPANY Database
13
ER Model Concepts
14
ER Model Concepts
ER model describes data as:
Entities
Relationships
Attributes
15
ER Diagram: Summary
Summary of the
Notation for ER
Diagrams
16
Entities and Attributes
Entity is a thing in the real world with an
independent existence.
Ex: the EMPLOYEE John Smith, the Research
DEPARTMENT, the ProductX PROJECT
Attributes are properties describing 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.
17
Entities and Attributes
Types of Attributes
Simple attributes: each entity has a single atomic
value for the attribute.
Composite attributes: attribute may be composed of
several components.
Multi-valued attributes: an entity may have multiple
values for that attribute.
Derived: attribute represents a value that is derivable
from value of a related attribute, set of attributes, or
relationships.
Complex attributes: composite and multivalued
attributes can be nested arbitrarily
18
COMPANY Database
19
Entities and Attributes
Two entities, EMPLOYEE e1, and COMPANY
c1, and their attributes.
20
Entity Types and Keys
Entity type
Collection (or set) of entities that have the same
attributes
21
Entity Types and 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
22
Entity Types and Keys
Super key: A set of attributes (one or more) that
together define an entity in an entity set
Candidate key: A minimal super key, meaning it
has the least possible number of attributes to still
be a super key. An entity set may have more than
one candidate key
Primary key: A candidate key chosen by the
database designer to uniquely identify the entity
set
23
ERD: Entity
24
Entity Type: Example
25
Example: COMPANY Database
26
Relationships
Relationship type R among n entity types E1,
E2, ..., En
Defines a set of associations among entities from
these entity types
Ex: the WORKS_FOR relationship type 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 ProductX
PROJECT
27
Relationships
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
Ex: MANAGES and WORKS_FOR are distinct
relationships between EMPLOYEE and
DEPARTMENT, but with different meanings and
different relationship instances
28
Relationship Instances: Example
A binary relationship
29
Relationship Instances: Example
A ternary relationship
30
COMPANY Database
31
Relationships
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)
32
Recursive Relationship: Example
33
Constraints on Binary Relationship Type
Structural constraints: one way to express
semantics of relationship: cardinality ratio and
membership class
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)
34
One-to-one (1:1) Relationship
35
Many-to-many (M:N) Relationship
36
Constraints on Binary Relationship Type
Membership class (or participation constraint):
specifies if 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)
37
COMPANY Database
38
Attributes of Relationship Types
A relationship type can have attributes.
Ex: HoursPerWeek of WORKS_ON
Attributes of 1:1 or 1:N relationship types can
be migrated to one entity type
For a 1:N relationship type: relationship attribute
can be migrated only to entity type on N-side of
relationship
For M:N relationship types: must be specified as
relationship attributes
39
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
40
COMPANY Database
41
ER Diagram and Naming
Conventions
42
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
43
ER Diagram: Summary
Summary of the
Notation for ER
Diagrams
44
COMPANY Database
45
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
46
(min, max) Notation
47
48
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
49
50
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
51
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
52
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
53
Alternative Diagrammatic Notations
Symbols for entity type / class, Displaying attributes
attribute and relationship
Notations for displaying
Various (min, Displaying
specialization / generalization
max) notations cardinality ratios
54
Higher Degree
Relationship Types
55
Binary vs. Ternary Relationships
Some database design tools permit only binary
relationships
Ternary relationship must be represented as a
weak entity type
No partial key and three identifying relationships
Represent ternary relationship as a regular
entity type
By introducing an artificial or surrogate key
56
Binary vs. Ternary Relationships
57
Constraints on Higher-Degree Relationships
Notations for specifying structural
constraints on n-ary relationships
Should both be used if it is important to fully
specify structural constraints
58
ER Models: Problems
59
Problems with ER Models
Problems may arise when designing a
conceptual data model called 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
60
Problems with ER Models
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
61
An Example of a Fan Trap
At which branch office does staff number SG37 work?
62
Restructuring ER Model to Remove Fan Trap
SG37 works at branch B003
63
An Example of a Chasm Trap
At which branch office is property PA14 available?
64
ER Model Restructured to Remove Chasm Trap
Adding the Offers relationship resolves
the chasm trap
65
ER Model Restructured to Remove Chasm Trap
66
Summary
1 Overview of Database Design Process
2 What is ER Model? And Why?
3 A Sample Database Application
4 ER Model Concepts
5 ER Diagram and Naming Conventions
6 Alternative Diagrammatic Notations
7 Relationship Types of Degree Higher than Two
8 Problems with ER Models
67
