For exclusive use with:

CHAPTER 2 - Database Requirements and ER

Modeling
Copyright (c) 2020 Nenad Jukic and Prospect Press
 INTRODUCTION

 Entity-relationship (ER) modeling - conceptual database

modeling technique
• Enables the structuring and organizing of the requirements collection
process
• Provides a way to graphically represent the requirements
 ER diagram (ERD) - the result of ER modeling
• Serves as a blueprint for the database

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 2
DATA MODELS
 Data Model:
 A set of concepts to describe the structure of a database, the
operations for manipulating these structures, and certain constraints
that the database should obey.

 Data Model Structure and Constraints:

 Constructs are used to define the database structure
 Constructs typically include elements (and their data types) as well
as groups of elements (e.g. entity, record, table), and relationships
among such groups
 Constraints specify some restrictions on valid data; these constraints
must be enforced at all times

Copyright (c) 2020 Nenad Jukic and Prospect Press

DATA MODELS (CONTINUED)
 Data Model Operations:
 These operations are used for specifying database retrievals and updates by
referring to the constructs of the data model.

 Operations on the data model may include basic model operations (e.g.
generic insert, delete, update) and user-defined operations (e.g.
compute_student_gpa, update_inventory)

Copyright (c) 2020 Nenad Jukic and Prospect Press

 ENTITIES

 Entities - constructs that represent what the database keeps track

of
• The basic building blocks of an ER diagram
• Represent various real world notions, such as people, places, objects,
events, items, and other concepts
• Within one ERD each entity must have a different name

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 5
 ENTITIES

Two entities

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 6
 ENTITIES

 Entity instances (entity members) - occurrences of an entity

• Entities themselves are depicted in the ER diagrams while entity instances
are not
• Entity instances are eventually recorded in the database that is created
based on the ER diagram

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 7
 ATTRIBUTES

 Attribute - depiction of a characteristic of an entity

• Represents the details that will be recorded for each entity instance
• Within one entity, each attribute must have a different name
 Unique Attribute - attribute whose value is different for each
entity instance
• Every regular entity must have at least one unique attribute

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 8
 ATTRIBUTES

An entity with attributes

• For entity CUSTOMER, we may decide to keep track of the following
attributes: CustID (customer’s identification number), CustName
(customer’s name), CustBdate (customer’s birth date), and CustGender
(customer’s gender)."

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 9
 RELATIONSHIPS

 Relationship - ER modeling construct depicting how entities are

related
• Within an ER diagram, each entity must be related to at least one other
entity via a relationship

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 10
 RELATIONSHIPS

 Cardinality constraints - depict how many instances of one

entity can be associated with instances of another entity
• Maximum cardinality
o One (represented by a straight bar: I)

o Many (represented by a crow’s foot symbol)

• Minimum cardinality (participation)

o Optional (represented by a circular symbol: 0)
o Mandatory (represented by a straight bar: I)

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 11
 RELATIONSHIPS
A relationship between two entities
 The database will keep track of employees and departments.
• For each employee, we will keep track of his or her name and unique
employee ID.
• For each department, we will keep track of the unique department ID and
the location.
• Each employee reports to exactly one department. A department has
between zero and many employees reporting to it.

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 12
 RELATIONSHIPS

Four possible cardinality constraints

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 13
 RELATIONSHIPS
Several possible versions of the relationship ReportsTo

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 14
 RELATIONSHIPS
Several possible versions of the relationship ReportsTo

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 15
 RELATIONSHIPS

 Types of Relationships (maximum cardinality-wise)

• One-to-one relationship (1:1)
• One-to-many relationship (1:M)
• Many-to-many relationship (M:N)

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 16
 RELATIONSHIPS

Three types of relationships (maximum cardinality-wise)

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 17
 RELATIONSHIPS
A 1:M Relationship

A M:N Relationship

A 1:1 Relationship

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 18
 RELATIONSHIPS

 Relationship instances - occurrences of a relationship

• Occur when an instance of one entity is related to an instance of another
entity via a relationship
• Relationship themselves are depicted in the ER diagrams while relationship
instances are not
• Relationship instances are eventually recorded in the database that is
created based on the ER diagram

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 19
 RELATIONSHIPS
A relationship and its instances

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 20
 RELATIONSHIPS
 Relationship attributes
• In some cases M:N relationships can actually have attributes of their own

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 21
 RELATIONSHIPS
A 1:M relationship with and without an attribute

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 22
 RELATIONSHIPS
A 1:M relationship with and without an attribute

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 23
 ER diagram example: ZAGI Retail Company Sales Department Database

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 24
 ZAGI RETAIL COMPANY SALES DEPARTMENT DATABASE

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 25
 ATTRIBUTES

 Composite attribute – attribute that is composed of several

attributes
• Not an additional attribute of an entity
• Its purpose is to indicate a situation in which a collection of attributes has
an additional meaning, besides the individual meanings of each attribute

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 26
 ATTRIBUTES

An entity with a composite attribute

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 27
 ATTRIBUTES

Another entity with a composite attribute

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 28
 ATTRIBUTES

Composite attributes sharing components

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 29
 ATTRIBUTES
 Composite unique attribute – attribute that is composed of several attributes
and whose value is different for each entity instance.
 An entity with a unique composite attribute

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 30
 ATTRIBUTES

 Multiple unique attributes (candidate keys) - when an entity

has more than one unique attribute each unique attribute is also
called a candidate key.
 An entity with multiple unique attributes (candidate keys)

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 31
 ATTRIBUTES

An entity with a regular and composite candidate key

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 32
 ATTRIBUTES

 Multivalued attribute - attribute for which instances of an entity

can have multiple values for the same attribute.
 A multivalued attribute

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 33
 ATTRIBUTES

A scenario that does not use multivalued attributes

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 34
 ATTRIBUTES

 Derived attribute - attribute whose values are calculated and not

permanently stored in a database.
 A derived attribute example

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 35
 ATTRIBUTES
Another derived attribute example

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 36
 ATTRIBUTES

 Optional attribute - attribute that is allowed to not have a value.

 An optional attribute example

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 37
 ATTRIBUTES
EXAMPLE: An entity with various types of attributes

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 38
 ATTRIBUTES
EXAMPLE: An entity with various types of attributes

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 39
 RELATIONSHIPS
 Exact minimum and maximum cardinality in relationships
• In some cases the exact minimum and/or maximum cardinality in relationships is
known in advance
• Exact minimum/and or maximum cardinalities can be depicted in ER diagrams.
 A relationship with specific minimum and maximum cardinalities

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 40
 RELATIONSHIPS

A relationship with a mixture of specific and non-specific

cardinalities

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 41
 RELATIONSHIPS

 Degree of a relationship - reflects how many entities are

involved in the relationship
 Binary relationship - relationship between two entities
(degree 2 relationship)
 Unary relationship (recursive relationship) - occurs when an
entity is involved in a relationship with itself
(degree 1 relationship)

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 42
 RELATIONSHIPS
Unary relationship examples

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 43
 RELATIONSHIPS

 Relationship roles - additional syntax that can be used in ER

diagrams at the discretion of a data modeler to clarify the role of
each entity in a relationship

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 44
 RELATIONSHIPS
Unary relationships with role names

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 45
 RELATIONSHIPS

A binary relationship with role names

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 46
 RELATIONSHIPS
 Multiple relationships between same entities
• Same entities in an ER diagram can be related via more than one relationship .
 Multiple relationships between the same entities

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 47
 WEAK ENTITY

 Weak entity - ER diagram construct depicting an entity that does

not have a unique attribute of its own
 Owner entity - entity whose unique attribute provides a
mechanism for identifying instances of a weak entity
 Identifying relationship - relationship between a weak entity and
its owner entity in which each instance of a weak entity is
associated with exactly one instance of an owner entity
• Each weak entity must be associated with its owner entity via an identifying
relationship
• Unique attribute from the owner entity uniquely identifies every instance of
the weak entity via an identifying relationship

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 48
 WEAK ENTITY

 Partial key - attribute of a weak entity that combined with the

unique attribute of the owner entity uniquely identifies the weak
entity's instances
• Combination of the partial key and the unique attribute from the owner
entity uniquely identifies every instance of the weak entity

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 49
 WEAK ENTITY
A weak entity example with entity instances

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 50
 WEAK ENTITY
A weak entity versus a multivalued composite attribute

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 51
 WEAK ENTITY
A weak entity with an identifying and regular relationship

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 52
 WEAK ENTITY

 Identifying relationship is either 1:M or 1:1 relationship

• In case of 1:M identifying relationship, a weak entity must have a partial
key attribute
• In case of 1:1 identifying relationship, a weak entity doesn’t need to have a
partial key attribute

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 53
 WEAK ENTITY

A weak entity with a 1:1 identifying relationship

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 54
 NAMING CONVENTIONS FOR ER DIAGRAMS

 Entities and attributes

• Use singular (rather than plural) nouns

 Relationships
• Use verbs or verb phrases, rather than nouns

 Names should be as brief as possible, without being too

condensed as to obscure the meaning of the construct

 If possible, give all attributes in the entire ER diagram different

names

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 55
 MULTIPLE ER DIAGRAMS

 When depicting multiple ER diagrams, each diagram should be

visualized separately
 Instead of multiple ER diagrams in one schema a better choice is
to present each ER diagram separately

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 56
 MULTIPLE ER DIAGRAMS
A schema with two separate ER diagrams (potentially misleading)

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 57
 MULTIPLE ER DIAGRAMS
Separate ER diagrams in separate schemas

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 58
 MULTIPLE ER DIAGRAMS
Separate ER diagrams in separate schemas

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 59
HAFH Realty Company Property Management Database

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 60
HAFH Realty Company Property Management Database

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 61
 DATABASE REQUIREMENTS AND ER MODEL USAGE
 One of the common mistakes that beginners make when engaging in ER modeling for
the first time is not recognizing the difference between an entity and the ER diagram
itself.
 An ER diagram incorrectly and correctly interpreting requirements

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 62
 DATABASE REQUIREMENTS AND ER MODEL USAGE

An ER diagram incorrectly and correctly interpreting requirements.

In this case, entity COLLEGE would be unnecessary.

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 63
 DATABASE REQUIREMENTS AND ER MODEL USAGE

 Another common database requirements collection and ER

modeling mistake made by novices is not distinguishing between:

Modeling of the data that is wanted and can be kept track of

versus
Modeling of everything that takes place in an organization

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 64
 DATABASE REQUIREMENTS AND ER MODEL USAGE
ER diagrams based on unfeasible vs. proper requirements

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 65
 DATABASE REQUIREMENTS AND ER MODEL USAGE
ER diagrams based on unfeasible vs. proper requirements

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 66
 VARIOUS ER NOTATIONS

 There is no universally adopted ER notation to which all database

projects conform
 Instead, there is a variety of available ER notations in use
 However, if a designer is familiar with one ER notation, other
alternative ER notations are easy to understand and use

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 67
 VARIOUS ER NOTATIONS
Examples of various ER notations

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 68
 TERNARY RELATIONSHIP
 Ternary relationship - relationship involving three entities (degree 3 relationship)

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 69
 TERNARY RELATIONSHIP
Three binary relationships that are insufficient for depicting given requirements.

A ternary relationship

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 70
 TERNARY (AND HIGHER DEGREE) RELATIONSHIPS

 In practice, ternary relationships are relatively rare, and

relationships of degree higher than 3 are rarer still

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 71
 REDUCING THE NUMBER OF ATTRIBUTES

 Reducing the number of attributes by treating some attributes as

attribute values
• In some cases, it may be appropriate to consider whether an originally
designed attribute can be treated as an attribute value instead
• Valid alternative in some circumstances (but not always)

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 72
 REDUCING THE NUMBER OF ATTRIBUTES
 Example of reducing the number of attributes by treating some
attributes as attribute values:

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 73
 REDUCING THE NUMBER OF ATTRIBUTES

 Example of reducing the number of attributes by treating some

attributes as attribute values:

Jukić, Vrbsky, Nestorov, Sharma – Database Systems Copyright (c) 2020 Nenad Jukic and Prospect Press Chapter 2 – Slide 74