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 CUSTOMER Status Message Status Data 2.0 Shipping Confirmation Issue Status Messages D1

In-Stock Request

1.0 Check Status Order Data Pending Orders

Order Data Payment Invoice 4.0 Order Data Manage Accounts Receivable Accounts Receivable Data Accounts Receivable Inventory Reports

Accounting Data

D2

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

Graded Work Student Grade

Grade Student Work

Hours Worked Pay Rate

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 Create Invoice

Invoice

Policy Number
Apply Insurance Premium

Payment Amount

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 Post Payment
Payment Detail Invoice Detail

D1

Accounts Receivable

Data Flow: Correct/Incorrect?

5.0 Post Payment

Courses
Customer Payment

Class List

D2

Daily Payments

Students

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 Verify Order

Invoice

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
CUSTOMER CUSTOMER

Paycheck

Payment

Payment

EMPLOYEE

3.0 Apply Payment

Accounts Receivable

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 DF 5 1.0 P2

DF 1

DS 1

D DF 6 DF 4 DF 2

2.0

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 Invoice

0 Order System

Picking List

Completed Order

Commission

Bank Deposit

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 Invoice

0 Order System

Picking List

Completed Order

Commission

Bank Deposit

SALES REP

ACCOUNTING

BANK

Order

Level-0 DFD of Order System

Picking List W AREHOUSE 1.0 Fill Order

CUSTOMER

Order Reject Notice Invoice

2.0 Payment Invoice D1 Accounts Receivable Invoice Detail Create Invoice Completed Order

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 the low-level diagrams, then higherlevel diagrams

Bottom-up strategy
Create

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

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 D1 Pending Orders D2 Accounts Receivable

Data Flows

Processes

Data Stores

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 Payment In-Stock Request

WAR

Status Message Invoice

0 Order System Inventory Reports

Shipping Order

Shipping Conf

Context Diagram of Order System

ACCOUNTING

Order CUSTOMER Status Message Status Data 2.0 Shipping Confirmation Issue Status Messages D1

In-Stock Request

WAREHOUS 1.0 Check Status Order Data Pending Orders 3.0 Generate Shipping Order

Shipp Order

Order Data Payment Invoice 4.0 Order Data Manage Accounts Receivable 5.0 Accounts Receivable Data Accounts Receivable Inventory

Level-0 of Order System

Accounting Data

D2

Produce Reports

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 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 alsonew outlet. The uncertainty is maintain thethe economy quo! This wouldcontinuesoutcome of opening a the option to do nothing and the state of current status if the economy have an to grow 0. Economic growthoption is estimated to yield profits of 300,000. However, if the economy fails to grow as healthily the rises: 0.7 x 300,000 = 210,000 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) Expected outcome -500,000

The Process
Economic growth rises 0.5 Expected outcome 300,000 Expand by opening new outlet Economic growth declines 0.5 Maintain current status 0 Expected outcome -500,000

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 Specify which actions are to be followed for a given set of conditions

Rules

Modeling Logic with Decision Tables

Indifferent Condition

Condition whose value does not affect which action is taken for two or more rules 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

Standard procedure for creating decision tables

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 students tuition. What factors are important? E.g. What are they for each factor identified above? E.g. What types of calculations would be necessary?

Identify the range of values for each condition or criteria.

Identify all possible actions that can occur.

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. 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. In the lower right quadrant, determine what, if any, appropriate actions should be taken for each rule.

List all possible rules.

Enter actions 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 Part time (1 to 7 hrs.): 520.00/per hour Full time (>= 8 hrs.): 520.00/per hour

Graduate:

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 Entity, or Entity Type

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

52

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

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 City State Zip Phone

This Customer entity has eight attributes

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 PHYSICIAN name address Admits 0

pt-num PATIENTS

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

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
Customer_Number Last_Name First_Name Address City State Zip Phone

66

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

A patient must have recorded at least one history, and can have many

Optional relationships 0 0 none or one none or more

Mandatory relationships one and only one one 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
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

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 links strong entities to weak entities represented with double line diamond

Weak entity

Identifying relationship

77

Associative Entities

Associative entities provide details of a many-to-many association. Its an entity it has attributes AND its a it links entities together When should a relationship with attributes instead be an associative entity? Guidelines:

relationship

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. 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 A named property or characteristic of an entity that is of interest to an organization

Attribute

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. A better design that is scalable and easier to maintain

Result

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-tomany 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