COMP101:

Foundations
of
Information
Systems

Lecture 3: (I)
Entity-Relationship
Data Modelling
Diagrams Stephen
Cranefield
Department of
Information
Science
Paper Structure

Section 1: Databases
(storing and retrieving You are here!
organized information)

Foundations of Section 2: Key Issues in

ICT (networks, security,
AI and machine
learning)
Section 3: Data
COMP 101:

Representations

Section 4: Algorithms
(execution of
instructions)

2
 Information System Components

Focus of the next

seven lectures

[Source: Stair & Reynolds – Principles of Information Systems (2009), page 12] 4
Topics for the next 7 (or 8) lectures

• Databases: organized collections of data

• Lectures:
3 (today) Databases and Data Modelling with Entity
Relationship Diagrams (ERDs)
4 ERDs continued / The Relational Model
5 to 8 Structured Query Language (SQL)
9 Non-relational databases (NoSQL)
10 (Spare overflow lecture – content to be advised)

• The basis for the first blackboard test (20%),

practical test (20%) and five lab assessments
(10%).
5
Today

• Brief introduction to databases

• Data modeling is a way of
capturing and modeling the data
requirements of an organization
• Many different data modeling approaches
• We will use Entity Relationship Diagrams
(ERDs)
4
1. Databases
The underpinnings of all information systems

5
What is a database?

“… a collection of persistent data

that is used by the application
systems of some given enterprise.”
Date (2003), An Introduction to Database Systems (8th Ed.)

6
 Database clients and servers

• Various software
applications access a
central database by
sending queries and
receiving results
• See lecture 5 to 8 on the
database query language
SQL
• Direct human interaction
with a DB is usually only
done by database
administrators
9
 What a
database
administrat
or would
see
Why use a database?

• Uniformity of representation
• More consistent data, reduced duplication
• Easier to manipulate and query

• Data independence
• Application-neutral data persistence

• Contrast with, e.g., “flat” files

(with no predefined structure)

12
 Data duplication

Limitations of flat Data

files Data input error

https://youtu.be/xoTyrdT9SZI
Every database has a schema

• Definition of the database’s structure

• In some language, usually SQL (see lecture 5)

• Processed to create a database

• By a database management system (DBMS)

14
Database management system
(DBMS)
• Software to create and manage databases
(COMP 101 uses the PostgreSQL DBMS)

• Implements a logical data model

(e.g., relational model – next lecture)

• Security
• Concurrent access
• Failure recovery

15
2. Data Modelling
Capturing the requirements for your database scheme

16
Motivation 1
Different organisations have different
information needs

• Compare information needs for:

• University
• Hospital
• Retail store

 Every* database is different

* Well, almost every database

8
Motivation 2
Real-world information has structure
(it’s not just bits)

• Students have names, ID numbers, etc.

• Papers have titles, descriptions,
points, prerequisites, etc.

A database needs to be set up to know this

structure

8
Motivation 3
Information is
connected
• University students enrol in papers that are
offered by departments
• Sales of products are made by customers

These connections (or relationships) must be

recorded in a database

Motivations 2 & 3  You need a way of

modelling the information structure for your
database
8
Data modelling
• To set up a database, you must first define a
model of the data to be stored in it
• A data model:
• models the types of things (entities) of
interest
• specifies the attributes needed to
describe each entity
• models relationships between entities
• is used by analysts to capture requirements
and inform the design of databases
• An entity-relationship diagram (ERD) is a
common type of data model
Goals for today

• Understand the concept of an ERD

• Be able to:
• Explain ERD key concepts
• Read and interpret ERD examples
• Draw an ERD that matches given business rules

11
Example: recording sales

22
 Entity-relationship diagram (ERD)
Entity (may end up as a table in a database)

} Attributes
(may end up as columns
in a database table)

Relationship
Unique identifier
(primary key).
Can be a
combination of two {
attributes as shown
here
Notes
:
1) Th is u s es t h e “ In fo r m a t io n E n gi n e e ri n
• T hi s is In fo r m a tio n E ng i n ee rin g n o t at io n ,
go”n: evaorfiamnatnoy fdEifRfeDrenntoEtaRtDionnotations
2) •DaSsohlieddanadnddassohleidd lliinneess
hfoavreresulabttiloyndsifhfeipresnht amveeasnpinegcsif–icwme
weaillniignngosreththaattwineCwOoMnP’t101 discuss
Entity
• “…a thing or object of significance,
whether real or imagined, about which
information needs to be known or held”
(Barker, 1990)

Employee Product
Customer Location
Transaction Departme
nt

• Shown as a named rectangle in an ERD

• “Our business” usually does not need
to be modelled as an entity
???

17
How do we tell
whether something
is an entity?
1. Is it a specific type of thing we need to
know about?

2. Is it relevant to the problem?

3. Do you need to deal with more than

one occurrence?

If yes to all three, then it’s (probably) an

entity.
18
Entities vs. Instances/Data items

Types

Instances
(possibly many instances of a single
entity)

…
Entities vs. Instances/Data items

Entity in an Row in a table

ERD • Individual data item recorded
in a database:
• Describes common features
of a type of thing or object: • e.g., Janet Smith
• e.g., “Person” • Has a value for each attribute

• A set of attributes • e.g. “Janet Smith”, 9/7/1999

need to describe a
person • Actual data used by an IS

• e.g., name, date of birth • ... can have many rows

representing different
instances of the entity
• Part of a data model

• One entity in an ERD ...

Entity vs. data item instance

Type Instances/Data items

Student
ID Surname First Name …
1234567 Shore Cynthia …

1122334 Factor Frederick …

1357246 Groff Gillian …

4673157 Edmundso Edmund

n

21
Attribute

• An individual property of an entity

• Holds a single value of some well-defined type
• A value may be required (indicated using a ●) or
optional
Attribute

• ERDs may omit the attributes (e.g. in the initial

phase of modelling)
Unique identifier
(Special kind of attribute)
• Combination of one or more attributes
whose value uniquely identifies an
instance
• Entire combined value must be unique

• Usually only one per entity type

• Even when it comprises several attributes
• Often referred to as the primary key (Lecture 4)

• Examples:
• A student ID is unique to a specific student
• A sale line needs both the sale number and
product code to identify it uniquely
23
Notation for unique IDs

• Often shown in a
separate compartment
Student ID
• Unique ID
(“primary
key”)
• Then other attributes
Relationship
• Reflects a real-world association
between entities:
• A sale is to a customer
• A sale is made by an employee
• An employee has an assigned office

• Properties of a relationship:
• Cardinality: one to one, one to many, many to many
• Participation: optional or mandatory
 Relationship cardinality

• Denotes “how many” instances

of one entity can be related to
instances of another entity, and Employee
vice versa
• Three types
• 1:1 (one-to-one) — not common
Look
like
“1”s

Note: We are modelling an organisation’s “business logic” here. Some companies

might consider allocating more than one company car to an Company
employee, but not this
one Car
Relationship cardinality

• Denotes “how many” instances

of one entity can be related to
instances of another entity, and Customer
vice versa
• Three types Looks
• 1:1 (one-to-one) — not like
“many”
common branch
• 1:M (one-to-many) — the es
most common
Order
Relationship cardinality

• Denotes “how many” instances

of one entity can be related to
instances of another entity, and Student
vice versa
• Three types
• 1:1 (one-to-one) — not common
• 1:M (one-to-many) — the
most common
• M:N (many-to-many) — Paper
fairly common
The N is deliberately different from M
to suggest that (e.g.) student Sam
may take 7 papers, and paper
COMP101 may have 154 students (7
≠ 38)
 Adding participation symbols
(we now allow 0s)
• The relationship line
There can
now has two symbols be many
at each end movies by
a director It is optional
• At each end: (“O”): to have
any movies for a
• Cardinality symbol given director
(closest symbol to the
entity box) Mandatory:
• Participation The model insists
A movie (“I”) that there
symbol has at most must be a
(innermost symbol) one director for a
director movie
For illustrative purposes, we assume movies have a single director
 Combined meanings of
cardinality and participation

Note: It depends on the drawing tool whether the line is visible

through the O (both versions are OK)
Diagram source: https://www.lucidchart.com/pages/ER-diagram-symbols-and-meaning
How to “read” relationships

Movie Director

• You can read the relationship in two directions

• Read the symbols at the end of the line in the direction you are
reading
• Movie to Director:
A Movie must be directed by one (and only one) Director
(or: a movie is directed by exactly one director)

• Director to Movie:
A Director may direct many Movies
(or: a director directs zero or more movies)
ERD Summary
• Business analysts need to analyse the nature
of the data that the business collects and
generates
• ERDs provide a high level notation for
modelling the structure and relationships
between different types of data
• ERDs can be used to capture database
requirements graphically, discuss with
others, and pass on to database designers
• ERDs are models of the data that needs to be
stored
– they don’t deal with actual data instances.
Exercise 1: understand ERD notation

• Identify the
following in the ERD
at left:
• Entities
• Attributes
• Unique identifiers
• Relationship(s) where
participation is
mandatory on both
sides

• Describe the
relationship between
Customer and Sale
Header in plain
English

40
Exercise 2: interpret an ERD

Direction: Employee to Office:

Every employee is allocated exactly one office

Direction: Office to Employee:

Cardinality: An office may ....
Participation: An office may ...
Combined: An office may ....
Homework exercises

• Identify some real-world entities and

work out what their attributes and
unique identifiers might be.

• How would you model their relationships

with other entities?

39
Thanks!
Questions?