Data Flow Diagrams

(DFDs)
Data Flow Diagrams (DFDs)
 Data flow diagram CUSTOMER
Order In-Stock Request

(DFD) is a picture of Status

1.0

the movement of Message

Check

data between
Status Data Status

Order
2.0
external entities and Shipping
Data

Pending
Confirmation D1
the processes and
Issue Orders
Status
Messages

data stores within a Order Data

system Payment 4.0

Order Data
Invoice
Manage
Accounts
Receivable

Accounting Data Accounts Receivable Data

Accounts
D2 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 Graded Work

Submitted Work
Grade Student Grade
Student
Work

3.0
Hours Worked
Gross Pay
Pay Rate Calculated
Gross
Pay
Rule 2: Process
 Can connect to any other symbol (including another
process symbol)

1.0 2.0 Inventory

Order Accepted Order Change

Verify Assemble
Order Order
Process: Correct/Incorrect?
5.0
Services Perfomed Invoice

Create
Invoice

Policy Number Payment Amount

Apply
Insurance
Premium

2.1
Hours Worked 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 D1 Accounts

Receivable
Post
Payment
Data Flow: Correct/Incorrect?
5.0

Post
Payment
Courses
Customer
Payment

Class
List D2 Daily Payments

Daily
Payment
Students

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 D2 Accounts
Receivable

Book
Flight
Invoice
Payment
Detail
Detail
Fight
Request

3.0

Passengers Post
Payment
Source/Sink (External Entity)
Order 1.0
Invoice
CUSTOMER
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 CUSTOMER CUSTOMER

DEPARTMENT

Paycheck
Payment Payment

EMPLOYEE 3.0
Accounts
Receivable
Apply
Payment
Rules for Using DFD Symbols
 Data Flow That Connects
YES NO
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

List the errors of this DFD

DF 2
E1 1.0

DF 5 P2

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
customer’s balance
 Order
Context Diagram of
Order System CUSTOMER WAREHOUSE

Order
Picking
Reject
List
Notice
Payment Invoice

Completed
Order Order
System

Commission Bank
Deposit

SALES
ACCOUNTING BANK
REP
Level-0 DFD
 Shows the system’s 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.
 Order
Context Diagram of
Order System CUSTOMER WAREHOUSE

Order
Picking
Reject
List
Notice
Payment Invoice

Completed
Order Order
System

Commission Bank
Deposit

SALES
ACCOUNTING BANK
REP
 Order Picking List
Level-0 DFD of CUSTOMER WAREHOUSE
Order System
1.0

Fill
Order Order
Reject
Notice

Invoice

2.0
Payment
Create Completed
Invoice
Invoice Order

Accounts
D1 Receivable

Invoice
Payment 3.0
Detail
Detail
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 higher-
level diagrams
Exercise:
Precision Tools sells a line of high-quality woodworking
tools. When customers place orders on the company’s
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  Data Flows
 Customer  Order
 Warehouse
 In-Stock Request
 Accounting 1.0
 Order Data
 Processes
 1.0 Check Status
 Status Data
2.0
 2.0 Issue Status Messages  Status Message
 3.0 Generate Shipping Order  Shipping Order
3.0
 4.0 Manage Accounts Receivable  Order Data
 5.0 Produce Reports  Invoice
 Data Stores  Shipping Confirmation
 D1 Pending Orders 4.0
 Payment
 D2 Accounts Receivable
 Accounting Data
 Accounts Receivable Data
 Order Data 5.0
 Inventory Reports
 Order
CUSTOMER In-Stock WAR
Payment Request

Status 0 Shipping
Message Order

Order
Invoice System Shipping Conf

Inventory
Reports

Context
Diagram of
Order
System ACCOUNTING
 Order In-Stock Request
CUSTOMER WAREHOUS

1.0
Status
Message
Check Shipp
Status Data Status Order

Order
2.0 Data
Shipping 3.0
Confirmation Pending
Issue D1 Orders
Status
Messages Generate
Shipping
Order Data Order

Payment 4.0
Order Data
Invoice
Manage
Accounts
Receivable
5.0
Accounting Data Accounts Receivable Data
Level-0 of Produce
Order System Accounts Reports
D2 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 Expected outcome
0.7 £300,000

Expand by opening new outlet

Economic growth declines Expected outcome
-£500,000
0.3

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
opening the outlet.
a new option The
to douncertainty
nothing andis maintain
the state the current
of the status– quo!
economy if theThis wouldcontinues
economy have an outcome
to grow of
£0.
Economic growth
healthily rises: is
the option 0.7 x £300,000
estimated = £210,000
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 Expected outcome
0.5 £300,000

Expand by opening new outlet

Economic growth declines Expected outcome
-£500,000
0.5

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 stubs
 Lists condition relevant to decision
 Action 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.
 E.g., We want to know the total cost of a student’s tuition. What factors are important?
 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. What types of calculations would be necessary?

 PART 2. CREATE THE TABLE.

 Create a table with 4 quadrants.
 Put the conditions in the upper left quadrant. One row per condition.
 Put the actions in the lower left quadrant. One row per action.
 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
 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
 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
 Graduate:
 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

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

52 Entity, or Entity Type 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 Last_Name First_Name Address City ST Zip

0001 Snerd Mortimer General Delivery Tampa FL 33647

0002 Fogg Bob 567 Fogg Lane Omaha NE 32405
0003 Amos Famous 2 Cookie Ct. Miami FL 33133
0004 Targa Maxine 67 Fast Lane Clinton NJ 20082
0005 George Scott 56 Neat St. Boulder CO 35882
0006 Guy Nice 290 Pleasant St. Tampa FL 33641
0007 Smith Bob 76 Quaker Path Wynn NY 21118
0009 Smith James 234 Bayview Tampa FL 33641

54
Basic E-R Model Constructs and notation

 Entity
 Attribute

 Relationship

55
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”
 Must be expressed in terms familiar to end users,
clear and concise.
 Not all business rules are related to data

58
Figure 3-4 Inappropriate entities

System user System output

Appropriate entities

59
An Attribute

 A discrete data element

 A characteristic (property) of an entity

CUSTOMER
Customer_Number
Last_Name
First_Name
Street_Address
This Customer entity  City
State
has eight attributes
Zip
Phone

60
 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

emp-id pt-num

PHYSICIAN Admits 0 PATIENTS

name address
name ward

62
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 composite
emp-id
f_name

skills EMPLOYEE name m_name

l_name
63
 Textbook’s notation

An attribute broken
into component
parts

Multivalued
an employee can have Derived
more than one skill from date
employed and
current date
64
64
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
Customer_Number
Last_Name
First_Name
Address
City
State
Zip
66 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 A patient must have

recorded for one and recorded at least one
only one patient history, and can have many

0 Optional relationships Mandatory relationships

0 none or one one and only one

one or more
0 none or more

69
 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 maximum number

70
 Degrees of Relationships: unary and binary

The number of different entities involved in a relationship

EMPLOYEE Manages UNARY

BINARY

STUDENT Is assigned DORMITORY

71
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
 exist independently of other types of entities
 has its own unique identifier
 represented with single-line rectangle
 Weak entity
 dependent on a strong entity…cannot exist on its own
 Does not have a unique identifier
 represented with double-line rectangle
 Identifying relationship
 links strong entities to weak entities
 represented with double line diamond

77
Associative Entities
 Associative entities provide details of a many-to-many association.
 It’s an entity – it has attributes

AND it’s a relationship – it links entities together
 When should a relationship with attributes instead be an associative entity?
Guidelines:
 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

78
An associative entity (CERTIFICATE) (Fig. 3-
11b)

Associative entity is depicted as a rectangle with a diamond

inside.

79
Modeling a ternary relationship as an
associative entity

80
 Introduction to Entity-
Relationship (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
 A named property or characteristic of an entity that is of
interest to an organization

10.82
10.82
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
supervises

is supervised by
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-to-
many relationships.
Resolving Many-to-Many
Relationships

SALES ORDERS INV. ITEMS

SALES ORDERS ORDER ITEMS INV. ITEMS

Example (ER Diagram)

CUSTOMERS CLERKS

SALES ORDERS

ORDER ITEMS INV. ITEMS

9.
9.
105
105 105