Data Flow Diagrams

(DFDs)

Data Flow Diagrams (DFDs)

Data flow diagram

(DFD) is a picture of
the movement of
data between
external entities and
the processes and
data stores within a
system

Order

In-Stock Request

CUSTOMER
1.0

Status
Message

Check
Status

Status Data

Order
Data

2.0
Shipping
Confirmation

D1

Issue
Status
Messages

Pending
Orders

Order Data
Payment

4.0
Order Data

Invoice

Manage
Accounts
Receivable
Accounts Receivable Data

Accounting Data

D2

Accounts
Receivable
Inventory
Reports

DFD Symbols (Gane & Sarson)

Process
Data Flow
Data Store
Source/Sink (External Entity)

Process
1.0
Grade Detail

Grade Report

Produce
Grade
Report

Work or actions performed on data (inside the system)

Labels should be verb phrases
Receives input data and produces output

Rule 1: Process

Can have more than one outgoing data flow

or more than one incoming data flow
1.0

Submitted Work

Hours Worked
Pay Rate

Grade
Student
Work

Graded Work
Student Grade

3.0

Gross Pay
Calculated
Gross
Pay

Rule 2: Process

Can connect to any other symbol (including another

process symbol)

Order

1.0
Verify
Order

Accepted Order

2.0
Assemble
Order

Inventory
Change

Process: Correct/Incorrect?
Services Perfomed

5.0

Invoice

Create
Invoice

Policy Number

Payment Amount
Apply
Insurance
Premium

Hours Worked

2.1

Pay Rate
Calculate
Gross
Pay

Data Flow
Deposit

Is a path for data to move from one part of the IS

to another
Arrows depicting movement of data
Can represent flow between process and data
store by two separate arrows
2.1

Payment Detail
Invoice Detail

Post
Payment

D1

Accounts
Receivable

Data Flow: Correct/Incorrect?

5.0
Post
Payment

Courses
Customer
Payment

Class
List

Students

D2

Daily Payments

Daily
Payment

6.0
Prepare
Deposit

Data Store
D1

Students

Is used in a DFD to represent data that the

system stores
Labels should be noun phrases

Rule: Data Store

Must have at least one incoming and one

outgoing data flow
Customer Payment

D1

Daily
Payments

Daily Payment

Data Store: Correct/Incorrect?

2.0
Book
Flight

D2

Accounts
Receivable

Invoice
Detail

Payment
Detail

Fight
Request
3.0

Passengers

Post
Payment

Source/Sink (External Entity)

Order
CUSTOMER

1.0

Invoice

Verify
Order

External entity that is origin or destination of data (outside the system)

Is the singular form of a department, outside organisation, other IS, or person
Labels should be noun phrases

Source Entity that supplies data to the

system
Sink Entity that receives data from the
system

Rule: Source/Sink

Must be connected to a process by a data flow

BANK

Bank
Deposit

2.0
Prepare
Deposit

Source/Sink: Correct/Incorrect?
PAYROLL
DEPARTMENT

Paycheck

EMPLOYEE

CUSTOMER

Payment

3.0
Apply
Payment

CUSTOMER

Payment

Accounts
Receivable

Rules for Using DFD Symbols

Data Flow That Connects

YES

A process to another process

A process to an external entity
A process to a data store
An external entity to another external entity
An external entity to a data store
A data store to another data store

NO

List the errors of this DFD

DF 2
E1

1.0
P2

DF 5

DF 1

DS 1

D
DF 6

2.0

DF 4
DF 2

P1

Context Diagram

Top-level view of IS
Shows the system boundaries, external entities that
interact with the system, and major information flows
between entities and the system.
Example: Order system that a company uses to
enter orders and apply payments against a
customers balance

Context Diagram of
Order System

Order
CUSTOMER

WAREHOUSE

Order
Reject
Notice
Payment

Picking
List

Invoice
0

Completed
Order

Order
System

Bank
Deposit

Commission

SALES
REP

ACCOUNTING

BANK

Level-0 DFD

Shows the systems major processes, data flows,

and data stores at a high level of abstraction
When the Context Diagram is expanded into DFD
level-0, all the connections that flow into and out of
process 0 needs to be retained.

Context Diagram of
Order System

Order
CUSTOMER

WAREHOUSE

Order
Reject
Notice
Payment

Picking
List

Invoice
0

Completed
Order

Order
System

Bank
Deposit

Commission

SALES
REP

ACCOUNTING

BANK

Order

Level-0 DFD of
Order System

Picking List

CUSTOMER

WAREHOUSE
1.0

Order
Reject
Notice

Fill
Order

Invoice
2.0
Payment
Create
Invoice

Invoice
D1

Completed
Order

Accounts
Receivable
Invoice
Detail

Payment
Detail

3.0
Apply
Payment

Commission

Bank Deposit

Cash Rece

Lower-Level Diagrams

Functional Decomposition
An

iterative process of breaking a system description

down into finer and finer detail
Uses a series of increasingly detailed DFDs to
describe an IS

Balancing
The

conservation of inputs and outputs to a data flow

process when that process is decomposed to a lower
level
Ensures that the input and output data flows of the
parent DFD are maintained on the child DFD

Strategies for Developing DFDs

Top-down strategy
Create

the high-level diagrams (Context

Diagram), then low-level diagrams (Level-0
diagram), and so on

Bottom-up strategy
Create

the low-level diagrams, then higherlevel diagrams

Exercise:
Precision Tools sells a line of high-quality woodworking
tools. When customers place orders on the companys
Web site, the system checks to see if the items are in
stock, issues a status message to the customer, and
generates a shipping order to the warehouse, which fills the
order. When the order is shipped, the customer is billed.
The system also produces various reports.
Draw a context diagram for the order system
Draw DFD diagram 0 for the order system

Identify Entities,Process,Data Stores & Data Flow

Entities

Processes

Customer
Warehouse
Accounting
1.0 Check Status
2.0 Issue Status Messages
3.0 Generate Shipping Order
4.0 Manage Accounts Receivable
5.0 Produce Reports

Data Stores

D1 Pending Orders
D2 Accounts Receivable

Data Flows

Order
In-Stock Request
1.0
Order Data
Status Data
2.0
Status Message
Shipping Order
3.0
Order Data
Invoice
Shipping Confirmation
4.0
Payment
Accounting Data
Accounts Receivable Data
5.0
Order Data
Inventory Reports

Order
CUSTOMER

In-Stock
Request

Payment

Status
Message
Invoice

0
Order
System
Inventory
Reports

Context
Diagram of
Order
System

ACCOUNTING

WAR

Shipping
Order

Shipping Conf

Order

In-Stock Request

CUSTOMER

WAREHOUS
1.0

Status
Message
Status Data

Order
Data

2.0
Shipping
Confirmation

Shipp
Order

Check
Status

D1

Issue
Status
Messages

3.0

Pending
Orders

Generate
Shipping
Order

Order Data
Payment

4.0
Order Data

Invoice

Manage
Accounts
Receivable
5.0

Level-0 of
Order System

Accounts Receivable Data

Accounting Data

D2

Produce
Reports

Accounts
Receivable
Inventory

Decision Trees

Decision Trees

Planning Tool

Decision Trees
Enable a business to quantify decision
making
Useful when the outcomes are uncertain
Places a numerical value on likely or
potential outcomes
Allows comparison of different possible
decisions to be made

Decision Trees

Limitations:
How

accurate is the data used

in the construction of the tree?
How reliable are the estimates
of the probabilities?
Data may be historical does this data relate to real
time?
Necessity of factoring in the qualitative factors
human resources, motivation, reaction, relations with
suppliers and other stakeholders

Process

The Process
Economic growth rises
0.7

Expected outcome
300,000

Expand by opening new outlet

Economic growth declines
0.3

Expected outcome
-500,000

Maintain current status

0
The circle denotes the point where different outcomes could occur. The estimates of the probability and the
knowledge of the expected outcome allow the firm to make a calculation of the likely return. In this
A square
example
it is: denotes the point where a decision is made, In this example, a business is contemplating
There
is also
the outlet.
option The
to douncertainty
nothing and
current
status quo!
wouldcontinues
have an outcome
opening
a new
is maintain
the state the
of the
economy
if theThis
economy
to grow of
0.
Economic
growth
rises: is
0.7
x 300,000
= 210,000
healthily
the option
estimated
to yield
profits of 300,000. However, if the economy fails to grow as
expected, the potential loss is estimated at 500,000.
Economic growth declines: 0.3 x 500,000 = -150,000
The calculation would suggest it is wise to go ahead with the decision ( a net benefit figure of +60,000)

The Process
Economic growth rises
0.5

Expected outcome
300,000

Expand by opening new outlet

Economic growth declines
0.5

Expected outcome
-500,000

Maintain current status

0

Look what happens however if the probabilities change. If the firm is unsure of the potential for growth, it
might estimate it at 50:50. In this case the outcomes will be:
Economic growth rises: 0.5 x 300,000 = 150,000
Economic growth declines: 0.5 x -500,000 = -250,000
In this instance, the net benefit is -100,000 the decision looks less favourable!

Advantages

Disadvantages

Decision Tables

Modeling Logic with

Decision Tables
A matrix representation of the logic of a
decision
Specifies the possible conditions and the
resulting actions
Best used for complicated decision logic

Modeling Logic with

Decision Tables

Consists of three parts

Condition

Lists condition relevant to decision

Action

stubs

stubs

Actions that result from a given set of conditions

Rules

Specify which actions are to be followed for a

given set of conditions

Modeling Logic with

Decision Tables

Indifferent Condition

Condition whose value does not affect which action is

taken for two or more rules

Standard procedure for creating decision tables

Name the condition and values each condition can

assume
Name all possible actions that can occur
List all rules
Define the actions for each rule
Simplify the table

Figure 9-4
Complete decision table for payroll system example

9.43
9.43

Constructing a Decision Table

PART 1. FRAME THE PROBLEM.

Identify the conditions (decision criteria). These are the factors that will influence the
decision.

Identify the range of values for each condition or criteria.

E.g. What are they for each factor identified above?

Identify all possible actions that can occur.

E.g., We want to know the total cost of a students tuition. What factors are important?

E.g. What types of calculations would be necessary?

PART 2. CREATE THE TABLE.

Create a table with 4 quadrants.

List all possible rules.

Alternate values for first condition. Repeat for all values of second condition. Keep
repeating this process for all conditions.
Put the rules in the upper right quadrant.

Enter actions for each rule

Put the conditions in the upper left quadrant. One row per condition.
Put the actions in the lower left quadrant. One row per action.

In the lower right quadrant, determine what, if any, appropriate actions should be taken for
each rule.

Reduce table as necessary.

Example

Calculate the total cost of your tuition this

quarter.
What

do you need to know?

Level. (Undergrad or graduate)

School. (CTI, Law, etc.)
Status. (Full or part time)
Number of hours

Actions?

Actions?

Consider CTI only (to make the problem smaller):

U/G

Graduate:

Part Time (1 to 11 hrs.): 500.00/per hour

Full Time (12 to 18 hrs.): 10000.00
* Credit hours over 18 are charged at the part-time rate
Part time (1 to 7 hrs.): 520.00/per hour
Full time (>= 8 hrs.): 520.00/per hour

Create a decision table for this problem

Entity Relationship
Diagrams
Basic Elements and Rules

9.48
9.48
48

Conceptual Data
Modeling,
E-R Diagrams

49

Importance of Conceptual Data Modeling

Data rather than processes are more complex in many modern

information systems.

Characteristics of data (structure, properties) are more stable,

i.e. less likely to change over time, easier to reach consensus on.

It is shared between many processes, therefore is crucial in the

design of databases, ensuring integrity of the data in an
information system, efficiency of processing.

50

Outline
Purpose and importance of conceptual
data modeling
Entity-Relationship Model

Entity

Attributes

Relationships

51

An Entity

Something of interest in the environment (e.g., person,

place, object, event, concept)
Represented in E-R diagram by a rectangle
An instance is a particular occurrence of an entity

CUSTOMER

52

Entity, or Entity Type

0010
Scott George
56 Neat Street
Boulder, Colorado
35882-2799
507-293-8749

An Instance of the Customer Entity

Entities

Entity Type - a collection of entity instances

that share common properties (also simply called
an Entity)

Entity Instance - an individual occurrence of

an entity type

53

Example Entity & Instances

Identifier Attribute
Cust_ID
0001
0002
0003
0004
0005
0006
0007
0009

54

Last_Name
Snerd
Fogg
Amos
Targa
George
Guy
Smith
Smith

First_Name

Address

City

ST

Zip

Mortimer General Delivery Tampa FL 33647

Bob
567 Fogg Lane Omaha NE 32405
Famous
2 Cookie Ct.
Miami FL 33133
Maxine
67 Fast Lane
Clinton NJ 20082
Scott
56 Neat St.
Boulder CO 35882
Nice
290 Pleasant St. Tampa FL 33641
Bob
76 Quaker Path Wynn NY 21118
James
234 Bayview
Tampa FL 33641

Basic E-R Model Constructs and notation

Entity
Attribute

55

Relationship

Sample E-R Diagram (figure 3-1)

56

What Should an Entity Be?

SHOULD BE:
An

object that is important to business

An object that will have many instances in
the database
An object that will be composed of multiple
attributes

SHOULD NOT BE:

A

user of the database system(unless

system keeps track of users)
An output of the database system (e.g. a
report)
57

Business Rules

Policies and rules about the operation of a business

that a data model represents
Govern how data is stored and handled.
E.g. a section of a course has between 15 and 35
students

58

Must be expressed in terms familiar to end users,

clear and concise.
Not all business rules are related to data

Figure 3-4

System user

Inappropriate entities

System output

Appropriate entities

59

An Attribute
A discrete data element
A characteristic (property) of an entity

CUSTOMER

This Customer entity

has eight attributes

60

Customer_Number
Last_Name
First_Name
Street_Address
City
State
Zip
Phone

Types of Attributes

Simple vs. Composite

Simple - most basic level

Composite decomposable into a group of related attributes
ex: address (street, city, state, zip)

Single Valued vs. Multi Valued

Single - only one value per entity instance (e.g., last name, date of
birth)

Mulitvalued- multiple values per entity instance (e.g., degrees, clubs,

skills)

Stored vs Derived (e.g. DateOfBirth vs Age)

61

Attributes on ERDs
May be shown on ERDs as ellipses

pt-num

emp-id
PHYSICIAN
name

62

address

Admits

name

PATIENTS

ward

Attributes on ERDs
Multivalued attributes are shown as double ellipses
Composite attributes may be shown broken down
into their simple components
Simple/Single Valued; Primary Key

Multivalued

emp-id

composite
f_name

skills
63

EMPLOYEE

name

m_name
l_name

Textbooks notation
An attribute broken
into component
parts

Multivalued
an employee can have
more than one skill
64
64

Derived
from date
employed and
current date

Identifiers/Primary Key

Every instance of an entity must be uniquely identified (to

unambiguously distinguish them)

An identifier can be one or more attributes called a

composite identifier (e.g., first name, middle name, and last name)

Partial identifier (in weak entities) attribute that together

with some attribute from another entity identifies an
instance

Underline identifiers in diagrams

65

Identifiers

Must be unique
Should not change value over time
Guaranteed to have a valid value
No intelligent identifiers (e.g. containing locations or people that might change)
Consider substituting
single-attribute
identifiers for
composite identifiers
to simplify design and
enhance performance

CUSTOMER

66

Customer_Number
Last_Name
First_Name
Address
City
State
Zip
Phone

Relationships

A relationship is an association between one or more

entities

The degree of a relationship indicates the number of entities

involved

The cardinality of a relationship describes the number of

instances of one entity associated with another entity

67

Figure 3-10 Relationship types and instances

a) Relationship

b) Relationship
instances

68

Cardinality Constraints

A patient history is
recorded for one and
only one patient

Optional relationships
0
0

69

none or one
none or more

A patient must have

recorded at least one
history, and can have many

Mandatory relationships
one and only one
one or more

Cardinality Constraints
Cardinality Constraints - the number of
instances of one entity that can or must be
associated with each instance of another entity.
Minimum Cardinality

If

zero, then optional

If one or more, then mandatory

Maximum Cardinality
The

70

maximum number

Degrees of Relationships: unary and binary

The number of different entities involved in a relationship

Manages

EMPLOYEE

UNARY

BINARY
STUDENT
71

Is assigned

DORMITORY

Degrees of Relationships - ternary

A vendor supplies parts to warehouses. The unit cost and

delivery method may differ for every warehouse.

Note: a relationship can have attributes of its own

72

More on Relationships

Relationships (many-to-many or one-to-one) can have attributes

These describe features pertaining to the association between the entities in the
relationship

Two entities can have more than one type of relationship between them
(multiple relationships)
Associative Entity = combination of relationship and entity
Some typical cases

73

Examples of multiple relationships entities can be

related to one another in more than one way
Figure 3-21a Employees and departments

74

Time stamping

75

Entities can be related to one another in more

than one way

Figure 3-21a Employees and departments

76

Strong vs. Weak Entities, and

Identifying Relationships

Strong entities

Weak entity

exist independently of other types of entities

has its own unique identifier
represented with single-line rectangle
dependent on a strong entitycannot exist on its own
Does not have a unique identifier
represented with double-line rectangle

Identifying relationship

77

links strong entities to weak entities

represented with double line diamond

Associative Entities

Associative entities provide details of a many-to-many association.

Its an entity it has attributes

relationship

AND its a
it links entities together
When should a relationship with attributes instead be an associative entity?
Guidelines:

78

All relationships for the associative entity should be many

The associative entity could have meaning independent of the other entities
The associative may be participating in other relationships other than the entities of
the associated relationship
The associative entity preferably has a unique identifier, and should also have other
attributes.
If an associative entity may have a partial identifier.
Ternary relationships should be converted to associative entities

An associative entity (CERTIFICATE) (Fig. 311b)

Associative entity is depicted as a rectangle with a diamond

inside.

79

Modeling a ternary relationship as an

associative entity

80

Introduction to EntityRelationship (E-R) Modeling

Notation uses three main constructs

Data

entities
Relationships
Attributes

Entity-Relationship (E-R) Diagram

A

detailed, logical representation of the

entities, associations and data elements for
an organization or business

10.81
10.81

Entity-Relationship (E-R) Modeling

Key Terms

Entity
A person, place, object, event or concept in the user
environment about which the organization wishes to
maintain data
Represented by a rectangle in E-R diagrams

Entity Type

A collection of entities that share common properties or

characteristics

Attribute

10.82
10.82

A named property or characteristic of an entity that is of

interest to an organization

Entity-Relationship (E-R) Modeling

Key Terms

Candidate keys and identifiers

Each

entity type must have an attribute or set

of attributes that distinguishes one instance
from other instances of the same type
Candidate key

Attribute (or combination of attributes) that

uniquely identifies each instance of an entity type

Examples

Identify a few entity types, instances,

attributes and candidate keys for:
DePaul

Campus Connect Registration System

Illinois Bureau of Motor Vehicles System
Amazon.com Product Information System

Depicting Entities and Attributes

Draw a portion of the ERD for each of these systems:

Campus Connect Registration System
Bureau of Motor Vehicles System
Amazon.com Product Information System

Conceptual Data Modeling and

the E-R Diagram
Goal

Capture as much of the meaning of the data as possible

If you know the rules of normalization, referential integrity,
foreign keys, etc., this is good but not as important now. It
is much more important to get the organizational data
model correct, i.e. to understand the actual data
requirements for the organization.

Result

A better design that is scalable and easier to maintain

Entity-Relationship (E-R) Modeling

Key Terms

Identifier
A candidate key that has been selected as the unique
identifying characteristic for an entity type
Selection rules for an identifier
1. Choose a candidate key that will not change its value
2. Choose a candidate key that will never be null
3. Avoid using intelligent keys
4. Consider substituting single value surrogate keys for
large composite keys

Entity-Relationship (E-R) Modeling

Key Terms

Relationship
An

association between the instances of one

or more entity types that is of interest to the
organization
Association indicates that an event has
occurred or that there is a natural link
between entity types
Relationships are always labeled with verb
phrases

Cardinality

The number of instances of entity B that can be

associated with each instance of entity A
Minimum Cardinality
The minimum number of instances of entity B that
may be associated with each instance of entity A
This is also called modality.

Maximum Cardinality

The maximum number of instances of entity B that

may be associated with each instance of entity A

9.90
9.90
90

Naming and Defining

Relationships

Relationship name is a verb phrase

Avoid vague names
Guidelines for defining relationships
Definition explains what action is being taken and why it is
important
Give examples to clarify the action
Optional participation should be explained
Explain reasons for any explicit maximum cardinality

Naming and Defining

Relationships

Guidelines for defining relationships

Explain

any restrictions on participation in the

relationship
Explain extent of the history that is kept in the
relationship
Explain whether an entity instance involved in
a relationship instance can transfer
participation to another relationship instance

10.92
10.92

Entity

An entity is a business object that

represents a group, or category of data.1

Do we know a similar concept?

1) Stephens, R.K. and Plew. R.R., 2001. Database Design. SAMS, Indianapolis , IN.

Attribute

An attribute is a sub-group of information

within an entity.1

Do we know a similar concept?

1) Stephens, R.K. and Plew. R.R., 2001. Database Design. SAMS, Indianapolis , IN.

Entity Relationship Models

Mandatory Relationships
Optional Relationships
Many-to-Many Relationships
One-to-Many Relationships
One-to-One Relationships
Recursive Relationships

Mandatory, Many-to-Many

INSTRUCTOR

STUDENT

INSTRUCTOR

STUDENT

Optional, Many-to-Many

DEPARTMENT

STUDENT

DEPARTMENT

STUDENT

Optional/Mandatory,
Many-to-Many

INSTRUCTOR

SKILL

INSTRUCTOR

SKILL

Optional/Mandatory,
One-to-Many

PRODUCT

VENDOR

PRODUCT

VENDOR

Mandatory, One-to-One

AUTOMOBILE

ENGINE

AUTOMOBILE

ENGINE

Recursive

EMPLOYEE

is supervised by

supervises

Resolving Many-to-Many
Relationships

Many-to-many relationships should be

avoided. We can resolve a many-to-many
relationship by dividing it into two one-tomany relationships.

Resolving Many-to-Many
Relationships

SALES ORDERS

SALES ORDERS

INV. ITEMS

ORDER ITEMS

INV. ITEMS

Example (ER Diagram)

CUSTOMERS

CLERKS

SALES ORDERS

ORDER ITEMS

INV. ITEMS

9.
9.
105
105

105