Data Modelling

Entity Relationship Diagrams

Lecture Outline

Data Modelling
Entity-Relationship Diagrams

Basic Concepts

Notation

Examples
Entity Relationship Diagramming

To determine the file structures of the IS the data must be

examined more closely and modeled appropriately.

Two approaches may be adopted for data modelling:-

Entity Relationship Diagram (top-down)
Normalisation (bottom-up)
Entity Relationship Diagramming

The data view of a system may be modelled by an

Entity-Relationship Diagram (E-R Diagram).
Provides a high-level, conceptual view of a DB structure.

Student database
Marks

Link
(relationship
Student File
type) Details
 Entity Relationship Diagramming

The aim of an ERD is to model the data within the IS.

Provides a CONCEPTUAL DATA MODEL.

i.e. a concept of the system, independent of implementation

What data should be stored?

What relationships exist between items of data?

Four basic components associated with E-R diagrams:

entities, attributes, relationships, existence conditions
Entities

An actual, real thing or person about which data

might be stored is referred to as an entity.

An entity can be uniquely identified.

Organisations collect and store data about entities:

if a bank stores data about you - you are an entity
if a business stores a piece of paper called an invoice - the
invoice is an entity
a library stores data about a particular book - the book is
an entity
Entity Types

Organisations store data about collections of entities,

which bear the same relation to the organisation.

These collections of data about entities are

called ENTITY TYPES.

A bank will store data about all the people (entities) who
do business with them and refer to them generically as
CUSTOMER.

CUSTOMER is an entity type with characteristics shared

by all people who do business with the bank.
 Attributes

These are the characteristics shared by all entities of a

given entity type.

An attribute is a data element associated with an entity.

The entity type SUPPLIER is likely to have attributes such as:

- supplier_name
- supplier_address etc.
Selecting entities

Deciding upon entities is not always an easy process.

The danger is in identifying attributes as entities and vice versa.

Try and identify nouns in the narrative and decide whether or

not data is likely to be stored about them.
Selecting Entities - Example 1

Each engineer is allocated one van (which is driven up

to a certain mileage and then replaced). Each member
has only one address but perhaps many vehicles. Each
visit is to deal with only one vehicle. A member can be
visited more than once on any given date and there may
be many visits to a member on different dates. A
member may only be covered for some of the vehicles
they own and not for others.

From the above what are likely entities and attributes?

Selecting Entities - Example 1

The nouns are:

engineer, van, mileage, member, address, vehicle,
visit and date.
Entities:
engineer, van, member, vehicle, visit.
Attributes
mileage (van)
address (member)
date (visit)
Relationships

Entities are associated with each other via relationships.

A relationship is a named association between two or more

entity types:

the relationship PLAY-FOR between the entity types

PLAYER and TEAM.

the relationship CITIZEN-OF between the entity types

PERSON and COUNTRY.
Relationships - Example 2

A sale always starts with a customer receiving an

estimate. The estimate then becomes an order. An
order can be for one or more stock items. Each stock
item belongs to a certain stock category (e.g. taps,
sinks, cupboards etc.).

What are likely entities?

What are their relationships or named associations?
Relationships - Example 2

Entities:
Estimate, Order, Customer, Stock Item, Stock Category

Relationships
An Estimate becomes an Order
An Estimate is issued to a particular Customer
An Order refers to Stock Item
A Stock Item belongs to a particular Stock Category
Degree of Relationship

The degree of a relationship may be:

one-to-one (1:1)
one-to-many (1:N)
many-to-many (N:M)

(1:1)
The relationship HEAD-OF between entity types
MANAGER and DEPARTMENT.
This means that a department has at most one head and
that a manager is head of at most one department.
Relationships

(1:N)
The relationship SUPERVISES between the entity types
MANAGER and EMPLOYEE.
This assumes that a manager may supervise any number
of different employees but a given employee is supervised
by at most one manager.
(N:M)
The relationship ASSIGNED-TO between the entity types
EMPLOYEE and PROJECT.
An employee may be assigned to many different projects
and each project may have many employees assigned to it.
Existence Conditions

Existence conditions detail whether an occurrence of a

relationship type,
must exist for all occurrences (records) of an entity type
an occurrence of the relationship type might be optional

Terminologies
mandatory
optional
A form has allocated to it a form teacher (mandatory)
A teacher can be allocated to zero or one form (optional)
Notation

INVOICE A plain rectangle is used to

represent the entity type.

is sent by A labeled line to represent the

relationship.

A B 1:1

A B 1:N
Examples

has enrolled
COURSE STUDENT

ONE course has enrolled on it ONE or MORE students.

ONE student is enrolled on ONE course.

refers to
LOAN BOOK

ONE loan refers to ONE book.

ONE book is referred to ONE loan.
Many-to-Many Relationship Example

Relational databases cannot support this relationship type.

These relationships imply a missing or link entity.

Suppose investigation and analysis has shown that:

any one supplier might supply more than one kind of part.

any one kind of part might be bought in from a number of

different suppliers.

supplies
SUPPLIER PART
N:M Example Contd

The many-to-many relationship type is removed as

follows:

SUPPLIER PART

X
N:M Example Contd

Thinking of an appropriate name for entity X can be

difficult.

In such cases it is acceptable to form it from the names of

the original two entities.

SUPPLIER PART

SUPPLIER_
PART
Guidelines for Drawing an E-R Diagram

Select likely entities.

Select an identifier for each of the entities.

Identify relationships between the selected entities.

Sketch an E-R Diagram based on the above.

Decompose any N:M relationships. (If N:M relationships are

present, 2 ERDs will be required.)
Example

Simple Hospital System

In a hospital system, each ward has many patients who are

cared for by nurses assigned to the ward. Patients may
require treatment by more than one specialist doctor. Draw
an ERD for the simple hospital system.

Draw the ERD.

ERD Example - Simple Hospital System

Ward has many patients (1:N)

Patients are cared for by nurses (N:M)
Ward has assigned many nurses (1:N)
Patients require treatment by one or more doctor (N:M)
ERD Example - Simple Hospital System

WARD DOCTOR

has accommodates
assigned treats

NURSE PATIENT
cares
for
Example

Small College Database

A small college database has the following structure.

A department has many lecturers. A lecturer belongs to only one

department. The department offers many different courses, and
many lecturers can teach on a single course. Lecturers can also
teach on more than one course. Many students enrol for many
courses.

Draw an ERD for this system.

Small College Database

DEPARTMENT
is_in
offers

COURSE LECTURER
teaches_on

enrols

STUDENT
Examples

Draw the ERD for the following scenarios:

A player plays for a team.

Each patient has one or more patient histories; each
instance of patient history belongs to one patient.
An employee may be recorded as having many jobs; a
particular job may be recorded as having been held by
many employees.
A person is a citizen of a country.
A customer may place many orders; an order is specific to
one customer.
Examples

Produce narrative statements for the following:

is associated
Customer Property

can place
Customer Order

teach
Teachers Students