Lecture 2 & 3

Introduction to Data ModellingEntity Relationship Modelling

IMS1002/CSE1205Systems Analysis and Design

2

Data Modelling

Focus on the information aspects of the organisation

In a database environment many applications share the same data

The database is a common asset and corporate resource

Corporate and application level data modelling

3

A conceptual data model is a representation of organisational data

Captures the structure, meaning and interrelationships amongst the data

Independent of any data storage and access method, DBMS, platform issues

Occurs in parallel with other systems analysis activities

Conceptual Data Modelling

4

Identification of information requirements

Allows integration of data across the organisation and across applications

Allows sharing of data across organisation

Helps eliminate problems of data inconsistency and duplication across the organisation

Conceptual Data Modelling

5

Techniques– Entity Relationship (ER) modelling– Data Gathering - attributes– Normalisation– Data Structure Diagrams (DSD)

Good modelling techniques are supported by rigorous standards and conventions to remove ambiguity and aid understanding

Conceptual Data Modelling

6

Used for conceptual data modelling– has become a de facto industry standard especially for

relational databases

Diagrammatic technique used to represent– things of importance in an organisation

• entities– the properties of those things

• attributes– how they are related to each other

• relationships

Entity Relationship (ER) Modelling

7

Entity relationship (ER) models can be readily transformed into a variety of technical architectures

All information about the system’s data identified during conceptual data modelling must be entered into the data dictionary or repository

This assists in checking the consistency of data and process models

Entity Relationship (ER) Modelling

8

Data “objects” or entities are things about which we wish to store information– things of interest to the organisation

ER models show the major data objects and the associations between them– business rules, constraints

ER models are useful in the initiation, analysis and design phases

Entity Relationship (ER) Modelling

9

Something of interest about which we store information– EMPLOYEE– SALES ORDER– SUPPLIER

Often identified from nouns used within the business application

Should be LOGICAL (not physical)– capture the essential nature of the data

Entity

10

Entities are subjective (i.e. they reflect the needs and viewpoint of the system) and can be– Real VEHICLE– Abstract QUOTA– Event remembered LOAN– Role played CUSTOMER– Organisation DEPARTMENT– Geographical LOCATION

Identifying Entities

11

We represent an entity by a named rectangle

Use a singular noun, or adjective + noun

Refer to one instance in naming convention

PART-TIMEEMPLOYEE

CUSTOMER

Representing Entities

12

An entity type is a classification of entity instances– BN Holdings– ABC Engineering– Acme Corp. Ltd.

…are all instances of a Supplier – they share common characteristics

SUPPLIER

Entity Types and Instances

13

For example, in a sales and inventory system there might be 3 physical forms of data– a stock file – product brochures sent to customers enquiring about

products – a product range book used by salespeople when calling

on customers to take orders

These could all be represented by one logical entity - PRODUCT

Entity Types are Logical

14

In a Student Records System there might be an entity type STUDENT which represents some of the data used in several physical forms of data– student re-enrolment forms– subject class lists– student results file

The ER model identifies the minimum set of data objects necessary to construct the data used within the system in its various physical forms

Entity Types are Logical

15

Is an association between two entities

We may also wish to store information about the association

Often recognised by a verb– "entity” + verb + “entity“– eg CUSTOMER places ORDER

Relationships capture the structural associations between the data entities– "business rules" of the system

Relationships

16

We represent a relationship as a line between two entities

The relationship is named by a meaningful verb or verb phrase which should indicate the meaning of the association

Relationships are bi-directional so naming each end of the relationship conveys more meaning

SUPPLIER ITEMsupplies

supplied by

Representing Relationships

17

A relationship type is a classification of relationship instances

MIS FinanceMarketing

John SmithBill BrownSue Blackemploys

employsemploys

DEPT EMPLOYEEemploys

Relationship Types and Instances

18

The cardinality of a relationship is the number of instances of one entity type that may be associated with each instance of the other entity type– a CUSTOMER may place many ORDERs– an ORDER is placed by one CUSTOMER– an ITEM can appear on many ORDERs

Cardinalities in Relationships

19

EMPLOYEE CUSTOMER SUPPLIER

PROJECTSALES

ORDERITEM

leads places supplies

One to One One to Many Many to Many

led by placed by

supplied by

Types of Cardinalities

20

Cardinality constraints enable us to precisely identify the nature of the relationship

We can indicate whether relationships are optional or mandatory– a customer MAY place many sales orders– each sales order MUST be placed by one customer

CUSTOMER SALESORDER

places

placed by

Nature of Relationships

21

EMPLOYEE

COURSE

attends

EMPLOYEE

COURSE

attends

is attended by

Notation used in Hoffer et al Notation used in Whitten et al

ER Notations

22

EMPLOYEE

EMPLOYEE

EMPLOYEE

EMPLOYEE

EMPLOYEE

EMPLOYEE

orExactly one

One and only one

Zero or one

One or more

Zero, one or more

More than one

ER Notations

23

The degree of a relationship is the number of entity types that participate in the relationship

The most common relationships in ER modelling in practice are– unary (degree one) – binary (degree two) – ternary (degree three)– n-ary or higher degree

Degree of a Relationship

24

A unary relationship is a relationship between instances of one entity type – an instance of one entity has a relationship with one or

more different instances of the same entity type– also called a recursive relationship

EMPLOYEEITEM

has component manages

reports tois a componentof

Unary Relationships

25

A binary relationship is a relationship between instances of two entity types and is the most common type of relationship encountered in practice– each instance of one entity has a relationship with one or

more instances of a second entity

MOVIE VIDEO TAPE

has copy

is a copy of

Binary Relationships

26

A ternary relationship is a simultaneous relationship between instances of three entity types

A ternary relationship is NOT the same as three binary relationships between the same three entity types

Ternary Relationships

27

PROGRAMMER

PROJECT

LANGUAGE

PROGRAMMER

PROJECT

LANGUAGE

Triplets e.g.Mary uses COBOL on HR Project

3 independent sets of pairs e.g.Mary uses COBOL Mary works on HR ProjectCOBOL is used in the HR Project

Ternary Relationships

28

CUSTOMER

ITEM

SALESORDER

EMPLOYEE

employs

made by

places

is on

employed

makes

placed by

is for

DEPARTMENT

Example ER Model

29

A relationship of interest that a data modeller decides to model as an entity type in its own right

As both entities and relationships can have attributes, the associative entity may have attributes in its own right

PRODUCT

CUSTOMER

Is ordered by

orders

PRODUCT

CUSTOMER

SALES ORDER

makes

Is made by

has

Is on

Associative Entities - Gerunds

30

It is common to have two or more relationships between instances of the same entities

They represent different business rules– different structural associations of interest

EMPLOYEE PROJECT

is working on

is eligible for

has working

has eligible

Multiple Relationships

31

Some data values vary over time and it may be important to store a history of data values to understand trends and for forecasting– for accounting purposes we are likely to need a history

of costs of material and labour costs and the time period over which each cost was in effect

– reflect changes in price of retail items

Modelling time-dependent data can result in changes to entities, attributes and relationships

Modelling Time-dependent Data

32

One technique is to store a series of time stamped data values

These values can either be represented as repeating data or as an additional entity called PRICE HISTORY

PRODUCTPRICE

HISTORY

has

belongsto

PRODUCT

PriceEffective date

Modelling Time-dependent Data

33

Relationship cardinality can change

DEPT EMPLOYEEworks for

DEPT EMPLOYEEhas worked for

has working

had working

Modelling Time-dependent Data

34

Some entities can be generalised (or specialised) to form other entities

An entity subtype is made up from some of the instances of the entity

This is useful when one sub-type participates in a specific relationship not shared by other sub-types of the same entity

Entity Types and Sub-types

35

The entity types– Motor Car– Truck– Train

…can be grouped together to form the generalised entity supertype– Transport Vehicle

Entity Types and Sub-types

36

Example entity sub-type and super-type– the entity super-type EMPLOYEE includes the subtype

SALESPERSON

SALESPERSON

EMPLOYEE

Entity Sub-types and Super-types

37

Entity subtypes are included in the ER model only when they are of use - they may participate in relationships and have additional attributes in their own right

SALESPERSON

EMPLOYEE

DEPARTMENT

CUSTOMER

employs

services

employed by

served by

Entity Sub-types

38

Entity types may have multiple subtypes

Entity subtypes may be nested

EMPLOYEE

PART-TIME

FULL-TIME

PROPERTY

RESIDENTIAL

METROPOLITAN

COUNTRY

COMMERCIAL

Multiple Entity Sub-types

39

Multiple entity subtypes should be– non-overlapping (disjoint)– collectively exhaustive

This enables easier translation to a relational design

EMPLOYEE

PART-TIME

SALARIED

RESIDENTIAL

METROPOLITAN

COMMERCIAL

PROPERTY

? ?

Multiple Entity Sub-types

40

Identify and list the major entities in the system

Represent the entities by named rectangles

Identify, draw, name, and quantify relationships

Indicate mandatory/optional nature of relationships

Revise for entity subtypes where appropriate

Building a Basic ER Model

41

Airline ticketing model

FLIGHT

TICKET

PASSENGER

AIRLINEROUTE

AIRLINE

AIRPORT

COUPON

for

made up of

scheduled as arrival

departure

operated by

shown on

See Barker (1989), chap 2.4

Building a Basic ER Model

42

Fact-finding and information gathering techniques

are used to determine the entities and relationships

Identify both existing and new information

Existing documents are particularly useful– forms, paper-based and computer files, reports, listings,

data manuals, data dictionary

Existing and new business rules for information are often difficult to elicit from documents– it is essential to speak directly to the client

Eliciting Information for ER Models

43

Is a given object an entity or relationship ?

Are two similar objects one entity or two ?

Is a given object an entity or an attribute of (data item about) an entity?– EMPLOYEE vs EMPLOYEE SPOUSE

Do we need to store data about the object?

What is the 'best' data model ?

ER Modelling Difficulties

44

Correctness

Completeness

Understandability

Simplicity

Flexibility

Quality Dimensions

45

Do not to confuse entities with sources/sinks or relationships with data flows

TREASURER is the person entering data; there is only one person and hence it is not an entity type

ACCOUNT has many account balance instances

EXPENSE has many expense transactions

EXPENSE REPORT contents are already in ACCOUNT and EXPENSE - it is not an entity type

ER Models and DFDs

EXPENSEREPORT

ACCOUNTTREASURER EXPENSE

46

All data elements represented in a DFD (data flows and data stores) MUST correspond to entities and their attributes in the ER model

ORDER CUSTOMERplaced by

ORDERLINE

PRODUCTfor

made up of

2

Check sales order

3

Produce weekly sales totals

Sales orders

Integrating ER Models and DFDs

47

Hoffer, J.A., George, J.F. and Valacich, J.S., (2002), Modern Systems Analysis and Design, (3rd edn.), Pearson Education Inc., Upper Saddle River, NJ, USA. Chs.1, 2, 3.

Barker, R. (1989) CASE*METHOD Entity Relationship Modelling, Addison-Wesley, Wokingham UK. Chs. 4,5.

Whitten, J.L., Bentley, L.D. and Dittman, K.C., (2004), Systems Analysis and Design Methods, (6th edn.), McGraw-Hill, Boston, MA., USA. Chs. 1, 3, 4.

References