Systems Analysis and Design

Data Modelling

Session Outline

Session Objectives
Enable students to:
l draw Entity-Relationship Diagrams for manufacturing
systems
Relevant course objectives
l use systems analysis and design tools for information
systems development

Section 1 - Purpose of Data Modelling

Purpose of data modelling

Entity-relationship modelling

Techniques
l

entity-relationship modelling
a top-down approach that starts with data groups

Identification of the DATA OBJECTS, or ENTITIES, in

the system.
Construction of a model of data storage requirements that
is INDEPENDENT of specific processing requirements.
Construction of a ROBUST model (tends to be a
MINIMAL model) of system data.
Achieve a LOGICAL model of system data, independent
from storage implementation issues.

Terminology
l
l
l
l
l
l
l

Data modelling describes data in terms of:

ENTITIES,
OCCURRENCES of entities,
ATTRIBUTES of entities,
VALUES of attributes,
entity KEYS, and
RELATIONSHIPS between entities.

Entities and Occurrences

Attributes and Values

An entity is an object about which the system must hold data,

e.g.
l customer
l machine
l purchase order
An occurrence of an entity is one particular example of it,
e.g.
l Fred Bloggs
l Machining Centre B
l Purchase Order P00158

ATTRIBUTES of entity are the data elements that describe it

In the case of the machine entity, these might include:
l Model,
l Manufacturer,
l Value, etc.
Note: not ALL are stored, only those REQUIRED.
VALUE ... is its specific value for one occurrence of an entity
e.g.
l Manufacturer: CINCINATTI

Keys

Keys (cont.)

A key is one or more attributes whose values UNIQUELY

identify an occurrence.
Each occurrence of an entity must be DISTINGUISHABLE from
the other occurrences.
Single attributes are sometimes inadequate, e.g.
l the NAME attribute for the SUPPLIER entity
If two parts of a large company supply different items, two
occurrences might be required.
There are two options here:
l use additional attribute(s), e.g. Division
l create a unique attribute, e.g. Supplier Code

Relationships
l

l
l

All options for the key are called CANDIDATE keys

The key that is chosen as the identifier is called the PRIMARY
key, these must:
l be unique for each occurrence of an entity,
l always have a value,
l not be liable to change (unlike Surname or Phone Number),
l be under control of the developers, not other individuals.
An entity attribute that is the primary key of another entity is
called a FOREIGN key;
l e.g. the Supplier Code attribute of a Purchase Order.

Degree of Relationships

A relationship is a link between entities that is significant

for the system, e.g. between Customer and Order
These can be represented as:
l simple relationships or

Four options:
One to one

One to many
CUSTOMER

WIFE

DOCTOR

PATIENT

MUSICIAN

PERFORMANCE

ORDER

Many to many

HUSBAND

NAMED relationships:
Reflexive

Places
CUSTOMER

ORDER

CUSTOMER

Types of Relationship
l

Summary of Notation

In addition, relationships can be of 2 types:

l MANDATORY, e.g. daughter to mother
l OPTIONAL,
e.g. mother to daughter

Entity

One to one

One to many
MOTHER

DAUGHTER

Many to many

Mandatory - optional

Section 2 - Entity-relationship modelling

Is a TOP-DOWN approach that starts with data groups
Characteristics of a good model are:
l data items grouped LOGICALLY,
l each data group has a key that uniquely identifies individual
occurrences,
l the data model is MINIMAL (there is no REDUNDANT
data).

Checking Data Model is Good

l
l

Are data items grouped LOGICALLY?

Is there enough information to identify each occurrence of
a data group?
Does each data item NEED to be stored?
(Can it be DERIVED instead?)
Is each data item stored only ONCE?

Redundant Data
Data is redundant if:
l
l
l

it is NEVER USED by the system, or

the same data is STORED ELSEWHERE in the system, or
it can be DERIVED from other data in the system.

The first of these just wastes space, the other two can
cause major problems.

How to build an E-R model

1. Identify entities (or objects) about which the system needs
to store data
2. List the attributes of each entity
3. Check the attributes satisfy the requirements for a good
data model
4. Investigate and record the relationships between entities
5. Check that the model includes all of the data described in
the Data Flow Diagrams
(for the various processes that the system should
support)
To demonstrate the process it will now be applied to the Just a Line case
study from Britton and Doakes book.

Just a Line - Step 1

Just a Line - Step 2

Identify entities/objects about which system

needs to store data:

List the attributes of each entity:

CUSTOMER

ORDER

PRODUCT

CUSTOMER
CustomerName
CustomerAddress
(CustomerPhone)
LastOrderDate
PRODUCT
ProductDescription
PacketSize
CostPerPacket

Just a Line - Step 3

Just a Line - Step 4

Check attributes satisfy requirements for a good data model:

CUSTOMER
CustomerNumber
CustomerName
CustomerAddress
(CustomerPhone)

ORDER
CustomerName
(CustomerPhone)
CustomerAddress
DateRequired
{ProductDescription
PacketSize
NumberOfPackets}

ORDER
CustomerNumber
DateRequired
ProductCode
NumberOfPackets

Investigate and record the relationships between entities:

CUSTOMER

PRODUCT

Initial model

ORDER

PRODUCT
ProductCode
ProductDescription
PacketSize
CostPerPacket

CUSTOMER

PRODUCT

Revised model

ORDER

Just a Line - Step 4 (cont.)

CUSTOMER
CustomerNumber
CustomerName
CustomerAddress
(CustomerPhone)

ORDER
CustomerNumber
DateRequired

PRODUCT
ProductCode
ProductDescription
PacketSize
CostPerPacket

ORDER LINE
CustomerNumber
DateRequired
ProductCode
NumberOfPackets

ORDERLINE

Summary
Entity-relationship modelling is a topdown approach;

starts with identifying entities (or objects),

then their attributes & finally examines
relationships between entities