CHAPTER 3:
Entity Relationship (ER) Modeling
BCI2023 – DATABASE SYSTEMS
Learning Outcomes
• Student should be able to:
– Describe the main characteristics of entity relationship
components
– Describe business rules and how they influence database design
– Describe relationships between entities - defined, refined, and
incorporated into the database design process
– Describe how ERD components affect database design and
implementation
– Describe that real-world database design often requires the
reconciliation of conflicting goals
Database Systems, 8th Edition 2
The Entity Relationship (ER)
Model
• What is ER Model ?
– Represents the conceptual database as viewed by
the end user
– Depicted the database’s main components –
entities, attributes, relationships
Database Systems, 8th Edition 3
HeadDept Club
MemberOf
0..* 1..1
1 1..1
MemberOf
Lead
1 0..*
Department Hire Lecturer Declare Property
1 * 1..1 0..*
1 1..1
Sample of E-R Diagram for University
Has Teach of Engineering & Technology
(Attributes Not Shown)
* 0..3
Student Register Course Become
0..* 2..5 0..*
Prerequisite
0..2
Require
The Entity Relationship (ER)
Model
• Main components:
– Entities
– Attributes
– Relationships
Database Systems, 8th Edition 5
Entities
• An object of interest to the end user
• Refers to entity set and not to single entity
occurrence
• Often corresponds to table and not to row in
relational environment
• In Chen and Crow’s Foot models, entity
represented by rectangle with entity’s name
• Entity name : a noun, written in capital letters
Database Systems, 8th Edition 6
Example of entities
Entity Set symbol in E-R diagram
What should be an ENTITY?
• SHOULD BE:
– An object that will have many instances in the database
– An object that will be composed of multiple attributes
– An object that we are trying to model
• SHOULD NOT BE:
– A user of the database system
– An output of the database system (e.g., a report)
Example of inappropriate entities
System System
user output
Appropriate
entities
Entity Type
• Strong Entity Type
– Entity type that is not existence-dependent on some other
entity type
– Referred as parent, owner, or dominant entities
– has its own unique identifier
– identifier underlined with single-line
• Weak Entity Type
– Entity type that is existence-dependent on some other entity
type (cannot exist on its own)
– does not have a unique identifier (only a partial identifier)
– Referred to as child, dependent, or subordinate
10
© Pearson Education Limited 1995, 2005
Weak Entities
• Weak entity meets two conditions
– Existence-dependent
• Cannot exist without the entity with which it has a
relationship
– Primary key partially or totally derived from parent
entity in relationship (strong/identifying relationship)
• Database designer determines whether an entity
is weak based on business rules
Database Systems, 8th Edition 11
Weak Entities
• Example:
– A company insurance policy insures an employee and
his/her dependents
– EMPLOYEE might or might not have a dependent, but
the DEPENDENT must be associated with an
EMPLOYEE
– the DEPENDENT cannot exist without the
EMPLOYEE; a person cannot get insurance coverage
as a dependent unless s(he) happens to be a
dependent of an employee
– EMPLOYEE has DEPENDENT
Strong entity type called Client and
weak entity type called Preference
13
© Pearson Education Limited 1995, 2005
Relationship called Advertises
with attributes
14
© Pearson Education Limited 1995, 2005
Attributes
• Characteristics of entities
• Property of an entity or a relationship type
• Chen notation: attributes represented by ovals
connected to entity rectangle with a line
– Each oval contains the name of attribute it represents
• Crow’s Foot notation: attributes written in attribute
box below entity rectangle
Database Systems, 8th Edition 15
Attributes (2)
Database Systems, 8th Edition 16
Attributes (3)
Student
studentID(PK)
name
birthDate
address
homeNo
street
city
department
telNo [1..3]
/age
The Attributes in E-R Model
Attributes (4)
• Required attribute: must have a value
• Optional attribute: may be left empty
• Domain: set of possible values for an attribute
– Attributes may share a domain
– E.g.: CGPA (0,4), Gender (F, M)
Database Systems, 8th Edition 18
Attributes (5)
STU_LNAME Required
STU_FNAME Attribute
Optional
Attribute
Database Systems, 8th Edition 19
Attributes (6)
Student
Required
studentID(PK)
name Attribute
birthDate
address
homeNo
street
city
department
telNo [1..3]
/age
Optional
Attribute The Attributes in E-R Model (UML
Notation)
Attributes (7)
• Identifiers (Primary Key): one or more attributes
that uniquely identify each entity instance
• Composite identifier: primary key composed of
more than one attribute
Attributes (8)
Identifier
Composite identifier
Database Systems, 8th Edition 22
Attributes (9)
• Composite attribute :: can be subdivided
– E.g.: address can be subdivided into street, city, state,
zip code
• Simple attribute :: cannot be subdivided
– E.g.: age, gender
• Single-value attribute :: can have only a single
value
– E.g.: IC Number
• Multivalued attributes :: can have many values
– E.g.: phone number
Database Systems, 8th Edition 23
ER diagram of Staff and Branch entities and their attributes
Attributes (9)
Primary Key
Multivalued attribute
Database Systems, 8th Edition 25
Attributes (10)
• M:N relationships and multivalued attributes should
not be implemented in RDBMS
– Create several new attributes for each of the original
multivalued attributes components
– Create new entity composed of original multivalued
attributes components
• Derived attribute: value may be calculated from
other attributes
– Need not be physically stored within database
Database Systems, 8th Edition 26
ER diagram of Staff and Branch entities and their attributes
28
Database Systems, 8th Edition
Relationships
• Association between entities
• Participants :: entities that participate in a
relationship
• Relationships between entities always operate in
both directions
• Relationship name: active or passive verb
(takes, teaches, employs, is managed by, is flown
by)
• Relationship classification is difficult to establish if
only one side of the relationship is known
Database Systems, 8th Edition 29
Semantic net of Has relationship type
ER diagram of Branch Has Staff relationship
30
© Pearson Education Limited 1995, 2005
Relationship Degree
• Indicates number of entities or participants
associated with a relationship
– Unary relationship / recursive relationship
• Association is maintained within single entity
– Binary relationship
• Two entities are associated
– Ternary relationship
• Three entities are associated
– Quaternary relationship
• Four entities are associated
Database Systems, 8th Edition 31
Relationship Degree
Course
require becomes
NeedPrerequisite
Recursive Relationship in E-R diagram
Binary relationship called POwns
Relationship Degree
Lecturer supervise Student
Project
Ternary relationship called supervise
Quaternary relationship called Arranges
Relationship Degree
Entities of
One entity two different
related to types related
another of to each other Entities of three
the same different types
entity type related to each 34
other
Relationship constraints
• Cardinality
– Expresses minimum and maximum number of entity
occurrences associated with one occurrence of related
entity
• Multiplicity
– The cardinality of one entity that can relate to another
entity’s cardinality via a set of relationship
• Established by very concise statements known as
business rules
Database Systems, 8th Edition 35
Relationship constraints
Multiplicity Description
1 (or 1..1) One and only one
* (or 0..*) Many (any number between zero and infinity)
0..1 Whether zero or one
1..* One or many (any positive integer)
n..m Minimum n and maximum m
Semantic net of Staff Manages Branch relationship type
Multiplicity of Staff Manages Branch (1:1) relationship
37
© Pearson Education Limited 1995, 2005
Semantic net of Staff Oversees PropertyForRent relationship type
Multiplicity of Staff Oversees PropertyForRent (1:*) relationship
type
38
© Pearson Education Limited 1995, 2005
Semantic net of Newspaper Advertises PropertyForRent relationship type
Multiplicity of Newspaper Advertises PropertyForRent (*:*) relationship
39
© Pearson Education Limited 1995, 2005
Cardinality Constraints
• Cardinality binary relationship between entity set
X and Y:
– One-to-One (1:1)
– One-to Many (1:*)
– Many-to-one (*:1)
– Many-to-Many (*:*)
Cardinality Constraints
x1 y1 x1 y1
x2 y2 x2 y2
x3 y3 x3 y3
y4
One to One (1:1) One to Many (1:M)
Cardinality Constraints
x1 x1 y1
y1
x2 y2
x2
x3 x3 y3
x4 y2 x4 y4
Many to One (M:1) Many to Many (M:M)
Relationship Participation
• Optional participation
– One entity occurrence does not require corresponding
entity occurrence in particular relationship
• Mandatory participation
– One entity occurrence requires corresponding entity
occurrence in particular relationship
Database Systems, 8th Edition 43
Cardinality Multiplicity as cardinality &
Constraints participation constraints
• Minimum
Cardinality
– If zero,
then
optional
– If one or
more, then
mandatory
• Maximum
Cardinality
– The
maximum
number
44
© Pearson Education Limited 1995, 2005
Relationship Participation
Staff is mandatory to Branch
Branch is optional to Staff
Descriptive Attributes
• Also known as bridge/associative entities
• Used to implement M:N relationships
• Composed of primary keys of each of the entities
to be connected
• May also contain additional attributes that play no
role in connective process
Database Systems, 8th Edition 46
The M*M relationship between Student and Course
Student Course
Register
studentID (PK) 1..* 1..* courseCode
name (PK)
unit
department
The Composite entity in an ERD
Student Register Course
studentID (PK) 1..* 1..* courseCode (PK)
name unit
department
date
Chapter 3:
Business Rules
BCI2023 – DATABASE SYSTEMS
Business Rules
• Descriptions of policies, procedures, or
principles within a specific organization
– Apply to any organization that stores and uses
data to generate information
• Description of operations to create/enforce
actions within an organization’s environment
• Used to define:
– Entities
– Attributes
– Relationships
– Constraints
Business Rules (2) – A good
business rules is…
• Must be in writing and kept up to date
• Widely disseminated
• Describe characteristics of data as viewed by the company
• Declarative–what, not how
• Precise–clear, agreed-upon meaning
• Atomic–one statement
• Consistent–internally and externally
• Expressible–structured, natural language
• Distinct–non-redundant
• Business-oriented–understood by business people
Business Rules (3)
• Example of business rules:
– A customer may generate many invoices
– An invoice is generated by only one customer
– A training session cannot be scheduled for fewer than
10 employees or more than 30 employees
Business Rules (5)
Teach
Lecturer Course
1..1 0..1
A Lecturer may teaches one Course
A Course is taught by only one Lecturer
Business Rules (5)
• Sources of business rules:
– Company managers
– Policy makers
– Department managers
– Written documentation
• Procedures
• Standards
• Operations manuals
– Direct interviews with end users
Database Systems, 8th Edition
Discovering Business Rules
(continued)
• Standardize company’s view of data
• Communications tool between users and
designers
• Allow designer to understand the nature, role, and
scope of data
• Allow designer to understand business processes
• Allow designer to develop appropriate relationship
participation rules and constraints
Database Systems, 8th Edition
Developing an ER Diagram
• Database design is an iterative process
– Create detailed narrative of organization’s
description of operations
– Identify business rules based on description of
operations
– Identify main entities and relationships from
business rules
– Develop initial ERD
– Identify attributes and primary keys that adequately
describe entities
– Revise and review ERD
Database Systems, 8th Edition 55
Example: University of
Engineering & Technology
Example: UET
• Business Rule 1:
– UET consists of a few departments that are lead by
their own heads of department. Each department
consists of few lecturers to teach certain
courses. All courses offered are centralized by
the university.
HeadDept Lead Department Hire Lecturer
1 1 1 *
Example: UET
• Business Rule 2:
– Every lecturer is required to teach up to 3 courses every
semester but exception may be given to lecturers that
have been assigned to other tasks. Each course can only
be taught by one lecturer only but can be taken by many
students. There are courses that require 2 pre-
requisites but most courses do not require any pre-
requisite.
Example: UET
• Business Rule 2
Prerequisite
Become Require
Student 0..* Course 0..2 Lecturer
Register Teach
0..* 2..5 0..3 1..1
Example: UET
• Business Rule 3:
– It is compulsory for every lecturer to declare their
properties so that it can be stored in the database.
Lecturer Declare Property
1..1 0..*
Example: UET
• Business Rule 4:
– All head of departments and lecturers are encouraged to
become the member of the university welfare club.
HeadDept MemberOf Club MemberOf Lecturer
0..* 1..1 1..1 0..*
HeadDept MemberOf Club
0..* 1..1
1 1..1
MemberOf
Lead
1 0..*
Department Hire Lecturer Declare Property
1 * 1..1 0..*
1 1..1
Has Teach
* 0..3
Student Register Course Become
0..* 2..5 0..* Prerequisite
0..2
Require
Summary
• Entity relationship (ER) model
– Uses ERD to represent conceptual database as viewed
by end user
– ERM’s main components:
• Entities
• Relationships
• Attributes
– Includes connectivity and cardinality notations
Database Systems, 8th Edition 63
Summary (continued)
• Connectivities and cardinalities are based on
business rules
• M:N relationship is valid at conceptual level
– Must be mapped to a set of 1:M relationships
• ERDs may be based on many different ERMs
• Database designers are often forced to make
design compromises
Database Systems, 8th Edition 64
