MICT713

Advanced Database
Management Systems
SNO Devine
Department of ICT & Mathematics
Presbyterian University, Ghana
Entity Relationship (ER)
Modelling
Conceptual modelling concepts, Chen Model, Crow’s Foot Model,
Degree of Abstraction, Entity Types, Types of Attributes, Degree of
relationships, ERD levels, challenges of DB design
In this chapter, you will learn:
• What a conceptual model is and what its
purpose is
• The difference between internal and external
models
• How internal and external models serve the
database design process
• How relationships between entities are defined
and refined, and how such relationships are
incorporated into the database design process
• Understand the types of attributes, types of
entities and degrees of relationships

3
In this chapter, you will learn:
• How ERD components affect database design
and implementation
• How to interpret the modelling symbols for
the two most popular E-R modelling
tools/techniques
• How to construct ER Models from Context,
Key-based to Fully Attributed levels
• That real-world database design often
requires you to reconcile conflicting goals

4
Basic Modelling Concepts

• Art and science

• Good judgment coupled with powerful
design tools
• Models
• “Description or analogy used to visualize
something that cannot be directly observed”
Webster’s Dictionary

5
Basic Modelling Concepts
• Data Model
• Relatively simple representation of complex real-
world data structures
• Basic tools for database design
• Abstraction: idea/logic for implementation
• Good database design starts with a good design of
data model.
• Different views of data and different concerns
• Communication is needed.
• Impacts on overall management system and policy,
as well as decision making.
• Blueprint, architecture, framework

6
 Data Models: Degrees of Data
Abstraction
• American National Standard Institute (ANSI)/
Standard Planning And Requirements Committee
(SPARC):
• The models/architecture
• is an abstract design standard for a database management
system (DBMS), first proposed in 1975.
• aims to separate each user's view of the database from
the way the database is physically represented.
• Three different models (according to the degree of
abstraction)
• Conceptual model
• External model
• Internal model
• Physical model: address DBMS-specific implementation issues of
internal model 7
8
Degrees of Abstraction

• Conceptual
• Focuses on generally how data can be logically
represented
• Considers the Global view of data
• Basis for identification and description of main data
items
• ERD used to represent conceptual data model
• Hardware and software independent
• Example: Tiny College Database (main objects:
students, professors, courses, classes, and
classrooms)

9
10
11
Degrees of Abstraction
• Conceptual
• Focuses on generally how data can be
logically represented independent of
Hardware and Software to implement the
intended database

• Hardware independent: means the model does

not depend on (specific) hardware used to
implement the model
• Software independent: means the model does
not depend on (specific) DBMS software used
to implement the model
12
Degrees of Abstraction
• Internal
• Focuses mainly on the representation of database
as seen by DBMS
• Adapts conceptual model to specific DBMS
• Software dependent
• DBMS changes affects the internal data model
• Matters with HDBM and NDBM (as long as
database system requires to specify detailed path
to storage)
• Not much with RDBM
• Still hardware independent
• Implement internal data model by creating
database and its tables
13
14
Degrees of Abstraction (con’t.)
• External
• Based on internal data model
• Focuses mainly on Users’(data entry clerks,
programmers, etc) views of data environment
• Provides subsets of internal view (as in
business units/view such as sales, marketing,
etc.)
• Programmer’s assignment on application
development requires modelling set of
requirements and constraints into functional
related modules
15
Degrees of Abstraction (con’t.)
• External data model’s advantages (easy)
• Makes application program development
easier
• Facilitates designers’ tasks of identifying
specific data required for business operations
• Ensures adequacy of conceptual model
• Ensures security constraints in design

16
17
18
19
Degrees of Abstraction (con’t.)
• Physical
• Lowest level of abstraction
• Describe the ways data being stored
• Software and hardware dependent
• Requires definition of physical storage devices
and access methods
• Less emphasized in relational model in RDBM

20
Comparison of E-R Modelling Symbols
• Popular Alternate styles developed to enable
easier use of CASE tools
• Chen
• Provides symbols for different concepts
• Moved conceptual design into practical database
design arena
• Can be a bit clustered in representation of concepts
• Crow’s Foot
• Fewer symbols
• Easier and more presentable to represent concepts
• Cannot detail all cardinalities
21
Comparison of E-R Modelling Symbols

23
The Entity Relationship (E-R) Model

• Represents conceptual view

• Main Components
• Entities
• Corresponds to entire table (entity set), not row
(entity occurrence or entity instance)
• Represented by rectangle
• Attributes
• Relationships

24
Attributes
• Characteristics of entities
• Domain is set of possible values
• Primary keys underlined
• shorthand - CLASS: (CLASS_CODE, CRS_CODE, HOURS)

Figure 3.6
25
• Simple
• Cannot be subdivided
• Multi-valued (avoid)
• Age, sex, marital status
in RDBMS
• Can have many values
• Person may have
• Composite (avoided) several college degrees
• Can be subdivided into • How to avoid? (see
additional attributes next slide)
• Address into street, city,
zip • Derived
• Can be derived with
algorithm (Age can be
• Single-valued derived from date of
• Can have only a single birth)
value • Need to be stored
• Person has one social
security number , Product
one serial number 26
27
 Attributes
• MultiValued attributes indicated in Chen model by
double lines connecting to the attribute
• No indication in the Crow Foot model
• Accepted by Conceptual model but not in relational
DBMS
• Either: create several new attributes in original entity
• Or : create new entity composed of original multivalued
attribute

28
29
30
31
32
Relationships
• Association between entities
• Connected entities are called participants
• Operate in both directions
• e.g. A CUSTOMER may generate many INVOICES
Each INVOICE is generated by one CUSTOMER

• Identified by a descriptive name; either active or

passive verb

33
Connectivity and Cardinality
• Connectivity describes relationship classification
• 1:1, 1:M, M:N
• Cardinality
• Expresses specific number of entity occurrences
associated with one occurrence of related entity
• Indicated in Chen model as (x,y) ;
x – minimum value , y – maximum value
• Both established by very concise business rules

34
Connectivity and Cardinality in an ERD

35
Figure 3.12
Developing an E-R Diagram (ERD)
• Iterative Process
• Step1: General narrative of organizational operations
developed
• Step2: Basic E-R Model graphically depicted and
reviewed
• Step3: Modifications made to incorporate newly
discovered E-R components
• Repeat process until designers and users agree E-R
Diagram complete

37
Developing an E-R Diagram (ERD)
• Developing the ERD presented in 3 stages or levels
• Context-Data Model
• Discover entities
• Establish relationships (association between entities)
• Identify cardinalities (number of occurrences of an entity in
another

• Key-based Model - Resolve many to many relationship

• Identification and allocation of keys (Primary Keys and Foreign
Keys)
• Resolve any many-to-many relationships or associations.

• Fully Attributed Model

• List all attributes for/in each entity

38
Identifying Entities, Attributes and
Relationships
• From a typical case study, entities and attributes
together with their relationships can be identified
from the data collected.
• 3 approaches may be used to perform such a task.
• Identify Based on Role
• Identify Based on Action Performed
• Identify Based on Association

39
Identifying Entities, Attributes and
Relationships
• Entity Discovery Process
• Entity – is often a Noun
• Attributes – are Adjectives (description)
• Relationship – seen as a Verb (action)
• Cardinality - adverb or Number of occurrence of
each entity in connection with the other

40
SUPERMARKET Case:
Modelling at the Context ERD Level
• i. A product belongs to one category only, but a
Category can have zero or more Products under it.

• ii. A supplier may provide several Products. But a

Product is provided by one Supplier.

• iii. A product may be bought and recorded in many

or no receipt. For every receipt generated, it must
capture one or more products purchased.

41
SUPERMARKET Case:
Modelling at the Key-Based ERD and
Fully-Attributed ERD
• i. A Product belongs to one Category only, but a
Category can have zero or more Products under it. All
products are captured with their unique serial
numbers, description, quantity, expiry date, and
supplier. Categories are captured by code, and name.

• ii. A Supplier may provide several Products. But a

Product is provided by one Supplier. Suppliers are also
are recorded based on their company name, contact
person, telephone number and location.
42
SUPERMARKET Case:
Modelling at the Key-Based ERD and
Fully-Attributed ERD
• iii. A product may be bought and recorded in many
or no receipt. For every receipt generated, it must
capture one or more products purchased. The
receipt often has details such as recorded when a
purchase is made.

43
Relationship Strength
• Existence dependence
• Entity’s existence depends on existence of related
entities
• Existence-independent entities can exist apart from
related entities
• Example: EMPLOYEE claims DEPENDENT

44
Relationship Strength
• Weak (non-identifying)
• One entity is existence-independent on another
• PK of related entity doesn’t contain PK component
of parent entity
• Strong (identifying)
• One entity is existence-dependent on another
• PK of related entity contains PK component of
parent entity

45
46
47
48
Relationship Participation
• Optional
• Entity occurrence does not require a corresponding
occurrence in related entity
• Shown by drawing a small circle on side of optional
entity on ERD

49
Relationship Participation
• Mandatory
• Entity occurrence requires corresponding occurrence in
related entity
• If no optionality symbol is shown on ERD, it is
mandatory

50
51
52
53
Weak Entity
• Existence-dependent on another entity
• Has primary key that is partially or totally
derived from parent entity

Figure 3.19
54
Relationship Degree
• Indicates number of associated entities
• Unary
• Single entity
• Recursive
• Exists between occurrences of same entity set
• Binary
• Exists when TWO entities are associated
• Ternary
• Exists when THREE entities are associated

55
Three Types of Relationships

Figure 3.21

56
57
Recursive Relationships
• Relationship exits between occurrences
of the same entity set

58
Recursive Relationships

59
60
61
Composite Entities
• Used to ‘bridge’ between M:N relationships
• Bridge entities composed of primary keys of each
entity needing connection

Figure 3.30

62
Composite Entities (con’t.)

Figure 3.31

63
Challenge of Database Design:
Conflicting Goals

• Database must be designed to conform to design

standards
• High-speed processing may require design
compromises
• Quest for timely information may be the focus of
database design

64
Challenge of Database Design:
Conflicting Goals

• Other concerns
• Security
• Performance
• Shared access
• Integrity

65
Entity Supertypes and Subtypes
• Generalization hierarchy
• Depicts relationships between higher-level supertype
and lower-level subtype entities
• Supertype has shared attributes
• Subtypes have unique attributes
• Disjoint relationships
• Unique subtypes
• Non-overlapping
• Indicated with a ‘G’
• Overlapping subtypes use ‘Gs’ Symbol

66
67
68
69
Generalization Hierarchy with
Overlapping Subtypes

Figure 3.35

70
71
72
Supertype/Subtype Relationship in
an ERD

73
74
75
First ERD Segment Established

Figure 3.43

76
Second and Third ERD
Segments Established

77
Fourth and Fifth ERD
Segments Established

78
Sixth and Seventh ERD
Segments Established

79
Eighth ERD
Segment Established

80
Ninth ERD
Segment Established

Figures 3.51

81
Components of E-R Model

Table 3.2
82
Completed ERD

Figure 3.52

83