Chapter 5

Understanding Entity Relationship

Diagrams

McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.
Outline
 Notation basics
 Understanding relationships
 Generalization hierarchies
 Business rule representation
 Diagram rules
 Alternative notations

5-2
Basic Symbols

Entity Type Entity Type

symbol Relationship name
symbol

Course Offering
Primary Key CourseNo OfferNo
Has
CrsDesc OffLocation
CrsUnits OffTime
Attributes
Relationship
name

5-3
Terminology
 Entity Type
 A collection of entities (noun eg persons,
places, events, or things) of interest
represented by a rectangle in an ERD
 Relationship
 A named (verb eg has, teaches, registers)
association among entity types, usually two-
way or bidirectional

5-4
Terminology
 Attribute
 A property of an entity type or relationship.
Each attribute has a data type that defines the
kind of values and permissible operations on
the attribute
 Reading ERD
 Use active verb rather than passive verb eg
“course has offerings” rather than “offering is
given for a course”

5-5
Terminology
 Cardinality
 A constraint on the number of entities that
participate in a relationship. Has min and
max cardinality for both directions of a
relationship
Course Offering
Course1 Offering1

Course2 Offering2

Course3 Offering3

Offering4

5-6
Cardinality Notation

Perpendicular line: Crow's foot: many

one cardinality cardinality
Inside symbol:
minimum cardinality

Course Offering
CourseNo Has OfferNo
CrsDesc OffLocation
CrsUnits OffTime

Circle: zero
Outside symbol: cardinality
maximum cardinality

5-7
Classification of Cardinalities
 Minimum cardinality based
 A min cardinality of 1>= (one or more) indicates a
mandatory relationship which creates an existence
dependent
 A min cardinality of 0 indicates an optional
relationship
 Maximum cardinality based
 A max cardinality of 1 means the relationship is
single-valued or functional (in math, value 1)
 1-1 (less common), 1-M (common), M-N
(common). Give eg.

5-8
Summary of Cardinalities
Classification Cardinality Restrictions
Mandatory Minimum cardinality  1
Optional Minimum cardinality = 0
Functional or single- Maximum cardinality = 1
valued
1-M Maximum cardinality = 1 in
one direction and maximum
cardinality > 1 in the other
direction.
M-N Maximum cardinality is > 1
in both directions.
1-1 Maximum cardinality = 1 in
both directions.

5-9
More Relationship Examples
 How do you read this ERD? Faculty is a
Lecturer while Offering is like Class
Faculty
Office Offering
FacSSN
OfficeNo WorksIn FacSalary TeamTeaches OfferNo
OffPhone FacRank OffLocation
OffType FacHireDate OffTime

5-10
Comparison to Access Notation
Course ERD (Crow's Foot) Offering
CourseNo Has OfferNo
CrsDesc OffLocation
CrsUnits OffTime

Access Relationship Diagram

Offering
Course OfferNo
Courseno 1 CourseNo
CrsDesc 8 OffLocation
CrsUnits OffTime
...

5-11
Understanding Relationships
 Identification dependency
 M-N relationships with attributes
 Self identifying relationships
 M-way relationships
 Equivalence between M-N and 1-M
relationships

5-12
Identification Dependency
 Strong Entity Type:
 has its own primary key (PK) eg. STUDENT
has matric#
 Weak Entity Type
 does not have its own PK but borrows part
(or all) PK from other strong entity types eg
PK for STATE is (StateID, CountryID), PK for
DEPENDENT is (DependentIC, StaffID) used
in UiTM Panel Clinic System

5-13
Identification Dependency
 Identifying Relationship
 The relationship(s) that provides components of the
PK for weak entity type eg contains in BUILDING and
ROOM or holds in COUNTRY and STATE
 Identifying Dependency
 Involves a weak entity type and one or more
identifying relationships
 Because of the existence dependency and the PK
borrowing, the min and max cardinalities of a weak
entity are always 1

5-14
Identification Dependency
Identification Dependency Symbols:
 Solid relationship line for identifying
relationships
 Diagonal lines in the corners denote
weak entities.

Building
Room
BldgID
BldgName Contains RoomNo
BldgLocation RoomCapacity

5-15
M-N Relationships with Attributes
 Relationships can have attributes especially M:N
relationships eg EnrGrade
 EnrGrade must be associated with the
combination of STUDENT enrolls in OFFERING
Offering
Student
OfferNo
StdSSN EnrollsIn OffLocation
StdName OffTime
EnrGrade
attribute of relationship

5-16
M-N Relationships with Attributes
b) Writes relationship

Author Book
AuthNo Writes ISBN
AuthName Title
AuthOrder
a) Provides relationship

Supplier Part
SuppNo Provides PartNo
SuppName PartName
Qty
5-17
Self-Referencing Relationships
 Also called unary or reflexive relationship, involves
connections among members of the same
set/entity type

(a) Supervises (b) PreReqTo

Faculty1 IS300

IS320
Faculty2 Faculty3

IS480 IS460
Faculty4 Faculty5

IS461

5-18
ERD Notation for
Self-Referencing Relationships
 How do you read the following ERDs?
a) manager-subordinate b) course prerequisites

Faculty Supervises Course PrereqTo

FacSSN CourseNo
FacName CrsDesc

5-19
 Associative Entity Types for
M-way (Multiway) Relationships
 Associative Entity Type
A weak entity that depends on two or more
entity types for its PK eg Uses. What is the PK?
Part Supplier Project
PartNo SuppNo ProjNo
PartName SuppName ProjName

Supp-Uses

Part-Uses Uses Proj-Uses

Associative
entity type

5-20
Relationship Equivalence
 Replace M-N relationship
 An associative entity type
 Two identifying 1-M relationships
 M-N relationship versus associative entity
type
 Largely preference
 Associative entity type is more flexible in
some situations eg related to other entities eg
Attendence
5-21
Generalization Hierarchies
 Is a collection of entity types arranged in a
hierarchical structure to show similarity in
attributes, hence reduced null values in
Employee
 Each subtype (child entity type) contains a
subset of entities of its supertype (parent entity
type)
 Each subtype entity IS A supertype entity,
therefore it is not shown on the diagram,
replaced by thick line with arrow up or down
5-22
Generalization Hierarchies
 EmpNo will also be PK for SalaryEmp and
HourlyEmp

Employee
EmpNo
EmpName supertype
generalization hierarchy
symbol
EmpHireDate
...

SalaryEmp HourlyEmp
EmpSalary subtypes EmpRate

5-23
Inheritance
 Subtypes inherit attributes of supertypes
(direct-EmpNo and indirect-EmpName,
EmpHireDate) eg
Employee (EmpNo, EmpName,
EmpHireDate)
SalaryEmp (EmpNo, EmpSalary) *
HourlyEmp (EmpNo, EmpRate) *
* EmpNo is both PK and FK

5-24
Generalization Constraints
 Disjointness constraint means that subtypes in a
generalization hierarchy do not have any entities
in common eg Security cannot be both a Stock
and a Bond
 Completeness constraint means that every entity
of a supertype must be an entity in one of the
subtypes eg every Security must be either a
Stock or a Bond
 Some generalization hierarchies lack both one
or both constraints (no symbol D,C)
5-25
Generalization Constraints
 Eg Every Security entity must be either a
Stock entity or a Bond entity
Security
Symbol
SecName
Disjointness LastClose
Completeness
Constraint Constraint

D,C
Stock Bond
OutShares Rate
IssuedShares FaceValue

5-26
Multiple Levels of Generalization
 Both Comon and Preferred entity types inherit the
attributes of Stock (immediate parent) and Security
(direct parent)
Security
Symbol
SecName
LastClose

D,C
Stock Bond
OutShares Rate
IssuedShares FaceValue

D,C
Common Preferred
PERatio CallPrice
Dividend Arrears

5-27
Comprehensive Example
UnivPerson
SSN
Name
City
State
Zip

C
Student Offering Faculty
StdClass OfferNo Teaches FacSalary
StdMajor OffLocation FacRank
StdGPA OffTime FacHireHate
Has

Supervises
Grants
Registers Course
Enrollment
CourseNo
EnrGrade CrsDesc
CrsUnits

5-28
Business Rules
 Enforce organizational policies
 Promote efficient communication
 Formal representation in ERD
 Informal representation in documentation
associated with an ERD
 Use rules language to formally represent
in relational database after conversion

5-29
Formal Representation
 Primary key constraints: entity identification
 Named relationships: direct connections among
business entities
 Identification dependency: knowledge of other
entities for identification
 Cardinalities: restrict number of related entities
in a business situation
 Generalization hierarchies: classification of
business entities and organizational policies

5-30
Informal Representation
 Specify as documentation associated elements
of an ERD
 Candidate key constraints: alternate ways to
identify business entities
 Reasonable values: fixed collection of values or
consistent with another attribute
 Null value constraints: data collection
completeness
 Default values: simplify data entry and provide
value when unknown
5-31
Diagram Rules
 Ensure that ERD notation is correctly used
 Similar to syntax rules for a computer
language
 Completeness rules: no missing
specifications
 Consistency rules: no conflicts among
specifications
 Supported by the ER Assistant (software)

5-32
Completeness Rules
 Primary Key Rule: all entity types have a PK
(direct, indirect, or inherited)
 Naming Rule: all entity types, relationships, and
attributes have a name
 Cardinality Rule: cardinality is specified in both
directions for each relationship
 Entity Participation Rule: all entity types
participate in an at least one relationship except
for entity types in a generalization hierarchy
 Generalization Hierarchy Participation Rule: at
least one entity type in a generalization
hierarchy participates in a relationship
5-33
Primary Key Rule Issue
 Primary key rule is simple in most cases
 For some weak entities, the PK rule is
subtle
 Weak entity with only one 1-M identifying
relationship
 Weak entity must have a local key to augment
the borrowed PK from the parent entity type
 Violation of PK rule if local key is missing

5-34
PK Rule Violation Example

PK rule violation
 A single 1-M identifying relationship
 Room does not have a local key.
Building
Room
BldgID
BldgName Contains RoomNo
BldgLocation RoomCapacity

5-35
Naming Consistency Rules
 Entity Name Rule: entity type names must
be unique
 Attribute Name Rule: attribute names must
be unique within each entity type and
relationship
 Inherited Attribute Rule: attribute names in
a subtype do not match inherited (direct or
indirect) attribute names.
5-36
Relationship Names
 No uniqueness requirement
 Participating entities provide a context for
relationship names
 Use unique names as much as possible to
distinguish relationships
 Must provide unique names for multiple
relationships between the same entity
types
5-37
Connection Consistency Rules
 Relationship/Entity Connection Rule:
relationships connect two entity types (not
necessarily distinct)
 Relationship/Relationship Connection
Rule: relationships are not connected to
other relationships
 Redundant Foreign Key Rule: foreign keys
are not used.
5-38
Identification Dependency Rules
 Weak entity rule: weak entities have at
least one identifying relationship
 Identifying relationship rule: at least one
participating entity type must be weak for
each identifying relationship
 Identification dependency cardinality rule:
the minimum and maximum cardinality
must equal 1 for a weak entity in all
identifying relationships

5-39
Example of Diagram Errors
UnivPerson
SSN
Name
City
State
Zip

Rule 6 Violation
(Weak Entity)
Student C Offering Faculty
StdClass OfferNo Teaches FacSalary
StdMajor OffLocation FacRank
StdGPA Rule 9 Violation OffTime FacHireHate
Has
(Redundant FK) CourseNo

Rule 7 Violation
Rule 8 Violation (Identifying Relationship)
(Id Dependency Cardinality)
Supervises
Registers Grants Course
Enrollment
CourseNo
EnrGrade CrsDesc
CrsUnits

5-40
Corrected ERD
UnivPerson
SSN
Name
City
State
Zip

C
Student Offering Faculty
StdClass OfferNo Teaches FacSalary
StdMajor OffLocation FacRank
StdGPA OffTime FacHireHate
Has

Supervises
Grants
Registers Course
Enrollment
CourseNo
EnrGrade CrsDesc
CrsUnits

5-41
Support in the ER Assistant

 Relationship formation rules are supported

by diagram construction
 Other rules are supported by the Check
Diagram feature
 For the Redundant Foreign Key rule, the
ER Assistant detects FKs that have the
same name as the associated PKs

5-42
ERD Variations
 No standard ERD notation
 Symbol variations
 Placement of cardinality symbols
 Rule variations
 Be prepared to adjust to the ERD notation
in use by each employer

5-43
ERD Rule Variations
 Lack of ERD standards
 M-way relationships
 M-N relationships
 Relationships with attributes
 Self-referencing relationships
 Relationships connected to other
relationships
 Adapt to notations in work environments
5-44
Chen ERD Notation
Maximum Cardinality Maximum Cardinality
for Course for Offering

Offering
Course
(0:N) (1:1) OfferNo
CourseNo
Has OffLocation
CrsDesc
OffTime
CrsUnits
...
Mininum cardinality Mininum cardinality
for Course for Offering

5-45
Unified Modeling Language
 Standard notation for object-oriented
modeling
 Objects
 Object features
 Interactions among objects
 UML supports class diagrams, interface
diagrams, and interaction diagrams
 More complex than ERD notation

5-46
Simple Class Diagram

Object name

Association
Offering
Faculty
OfferNo : Long Teaches 0..1
Attributes FacSSN : String
OffTerm : String
0..n FacFirstName : String
OffYear : Integer TaughtBy
FacLastName : String
OffLocaton : String
FacDOB : Date
Operations EnrollmentCount() : Integer
FacAge() : Integer
OfferingFull() : Boolean

Cardinality Role name

5-47
Association Class in UML

Association Enrollment
class
EnrGrade : Numeric

Offering
Student
OfferNo : Long Takes 0..n StdSSN : String
OffTerm : String
0..n Enrolls StdFirstName : String
OffYear : Integer
StdLastName : String
OffLocaton : String
StdDOB : Date
EnrollmentCount() : Integer
StdAge() : Integer
OfferingFull() : Boolean

5-48
Generalization Relationship in UML

Student

StdSSN : Long
StdFirstName : String
StdLastName : String
Generalization
name
Status
{complete}
Undergraduate Graduate

Major : String ThesisTitle : String

Minor : String ThesisAdvisor : String

Generalization
constraint

5-49
Composition Relationship
 Similar to identification dependency in ERD

Composition symbol
(dark diamond)

Order
OrdLine
1..1
OrdNo : Long
1..n LineNo : Integer
OrdDate : Date
Qty : Integer
OrdAmt : Currency

5-50
Summary
 Data modeling is an important skill
 Crow’s Foot ERD notation is widely used
 Use notation precisely
 Use the diagram rules to ensure structural
consistency and completeness
 Understanding the ERD notation is a
prerequisite to applying the notation on
business problems

5-51
Review Questions
 Final Exam April 2010 – Question 3
Every year Malaysia’s Ministry of Education hold debating contest
among primary and secondary schools throughout each state. The
peak event is to crown the best school in Malay and English language
category debate based on school level and also the best debator.
The ministry wanted an information system and hence a complete
database to record all the information about the debate competition.
 
Participants of the debate come from various schools in Malaysia.
Information required of the schools are school code, name, address,
telephone number and contact person.

 
5-52
Review Questions
 Final Exam April 2010-continue
Each school is allowed to send up to three teams of debators in
each category. Each team comprises of three members. The team
is given a unique code and a name and the members identification
card number, name, and age are recorded. Competition venue, date
and time are also important.
 
Each debate is being judged by three independent judges. Marks
given for each debator are based on content, fluent, presentation
style and voice control. The results determined by the judges are
needed to complete the database.

5-53
Review Questions
 Final Exam April 2010-continue
a) Draw a complete entity relationship diagram (ERD) for the above
information and identify their relationship and connectivity. Underline
the primary keys and understrike (***) the foreign keys (if any) in each
entity. You may state your assumptions to strengthen your
clarifications.
(15 marks)
 
b) Give TWO (2) examples of report that can be produced from this
information system.
(5 marks)

 Answer
5-54