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

1.0

CheckStatus

2.0

IssueStatus

Messages

3.0

GenerateShipping

Order

ACCOUNTING

CUSTOMER WAREHOUSE

4.0

Manage Accounts

Receivable5.0

ProduceReports

Order In-Stock Request

Status Data

Status Message

PendingOrdersD1

Order Data

Order Data

Shipping Order

Shipping Confirmation

Invoice

Payment

Accounts ReceivableD2

Accounting Data Accounts Receivable Data

Order Data

Inventory Reports

DFD Symbols (Gane & Sarson)

Process

Data Flow

Data Store

Source/Sink (External Entity)

Process

Work or actions performed on data (inside the system)

Labels should be verb phrases Receives input data and produces output

1.0

ProduceGradeReport

Grade Detail Grade Report

Rule 1: Process

Can have more than one outgoing data flow or more than one incoming data flow

1.0

GradeStudent Work

Submitted WorkGraded Work

Student Grade

3.0

Calculated Gross Pay

Hours Worked

Pay RateGross Pay

Rule 2: Process

Can connect to any other symbol (including another process symbol)

1.0

VerifyOrder

2.0

Assemble Order

Order Accepted OrderInventory Change

Process: Correct/Incorrect?5.0

Create Invoice

Services Perfomed Invoice

Apply InsurancePremium

Payment AmountPolicy Number

2.1

Calculate Gross Pay

Hours Worked Pay Rate

Data Flow

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

Deposit

2.1

Post Payment

Accounts Receivable

D1

Payment Detail

Invoice Detail

Data Flow: Correct/Incorrect?

Courses

Students

ClassList

5.0

PostPayment

Customer Payment

D2 Daily Payments

6.0

Prepare Deposit

DailyPayment

Data Store

Is used in a DFD to represent data that the system stores

Labels should be noun phrases

StudentsD1

Rule: Data Store

Must have at least one incoming and one outgoing data flow

Daily Payments

D1

Customer Payment

Daily Payment

Data Store: Correct/Incorrect?

2.0

BookFlight

Passengers

FightRequest

D2 AccountsReceivable

PaymentDetail

3.0

PostPayment

InvoiceDetail

Source/Sink (External Entity)

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

CUSTOMER

1.0

VerifyOrder

Order

Invoice

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

2.0

Prepare Deposit

BankDeposit

Source/Sink: Correct/Incorrect?

PAYROLLDEPARTMENT

EMPLOYEE

Paycheck

3.0

ApplyPayment

CUSTOMER

Payment

CUSTOMER

AccountsReceivable

Payment

Rules for Using DFD Symbols

Data Flow That ConnectsYES 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

E1

E1

P2

P1

1.0

2.0

DS1

DF2

DF2

DF6

DF4

DF3

DF1

DF5

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

0

Order System

SALESREP

CUSTOMER WAREHOUSE

BANKACCOUNTING

Order

OrderReject Notice

PickingList

CompletedOrder

Payment Invoice

Commission Bank Deposit

CashReceiptsEntry

Context Diagram of Order System

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.

0

Order System

SALESREP

CUSTOMER WAREHOUSE

BANKACCOUNTING

Order

OrderReject Notice

PickingList

CompletedOrder

Payment Invoice

Commission Bank Deposit

CashReceiptsEntry

Context Diagram of Order System

1.0

Fill Order

2.0

CreateInvoice

3.0

ApplyPayment

SALESREP

BANK ACCOUNTING

CUSTOMER WAREHOUSE

Order

Order RejectNotice

Picking List

AccountsReceivableD1

Invoice

Invoice

Invoice DetailPayment

Detail

Payment

Commission Bank Deposit Cash Receipts Entry

Completed Order

Level-0 DFD of Order System

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 strategyCreate the high-level diagrams (Context

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

Bottom-up strategyCreate 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

Customer Warehouse Accounting

Processes 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 Order Data Status Data Status Message Shipping Order Order Data Invoice Shipping Confirmation Payment Accounting Data Accounts Receivable Data Order Data Inventory Reports

1.0

2.0

3.0

4.0

5.0

ACCOUNTING

WAREHOUSECUSTOMER

0

Order System

Order

Payment

In-StockRequest

StatusMessage

Invoice Shipping Confirmation

Shipping Order

Inventory Reports

Context Diagram of Order System

1.0

CheckStatus

2.0

IssueStatus

Messages

3.0

GenerateShipping

Order

ACCOUNTING

CUSTOMER WAREHOUSE

4.0

Manage Accounts

Receivable5.0

ProduceReports

Order In-Stock Request

Status Data

Status Message

PendingOrdersD1

Order Data

Order Data

Shipping Order

Shipping Confirmation

Invoice

Payment

Accounts ReceivableD2

Accounting Data Accounts Receivable Data

Order Data

Inventory ReportsLevel-0 of

Order System

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

Expand by opening new outlet

Maintain current status

Economic growth rises

Economic growth declines

0.7

0.3

Expected outcome£300,000

Expected outcome-£500,000

£0

A square denotes the point where a decision is made, In this example, a business is contemplating opening a new outlet. The uncertainty is the state of the economy – if the economy continues to grow healthily the option is estimated to yield profits of £300,000. However, if the economy fails to grow as expected, the potential loss is estimated at £500,000.

There is also the option to do nothing and maintain the current status quo! This would have an outcome of £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 example it is:

Economic growth rises: 0.7 x £300,000 = £210,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

Expand by opening new outlet

Maintain current status

Economic growth rises

Economic growth declines

0.5

0.5

Expected outcome£300,000

Expected outcome-£500,000

£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 withDecision Tables

Consists of three partsCondition stubs

Lists condition relevant to decisionAction stubs

Actions that result from a given set of conditionsRules

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-4Complete decision table for payroll system example

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

489.489.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 ModelEntity

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

0010Scott George56 Neat StreetBoulder, Colorado35882-2799507-293-8749

An Instance of the Customer Entity52

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

Cust_ID Last_Name First_Name Address City ST Zip

0001 Snerd Mortimer General Delivery Tampa FL 336470002 Fogg Bob 567 Fogg Lane Omaha NE 324050003 Amos Famous 2 Cookie Ct. Miami FL 331330004 Targa Maxine 67 Fast Lane Clinton NJ 200820005 George Scott 56 Neat St. Boulder CO 358820006 Guy Nice 290 Pleasant St. Tampa FL 336410007 Smith Bob 76 Quaker Path Wynn NY 211180009 Smith James 234 Bayview Tampa FL 33641

Identifier Attribute

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 businessAn object that will have many instances in

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

Inappropriate entities

System userSystem user System outputSystem output

Appropriate entities

Figure 3-4

59

An Attribute

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

CUSTOMERCustomer_NumberLast_NameFirst_NameStreet_AddressCityStateZipPhone

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

PHYSICIAN PATIENTS Admits 0

emp-id

name address

pt-num

name ward

62

Attributes on ERDs

Multivalued attributes are shown as double ellipses

EMPLOYEE

emp-id

nameskills

f_name

l_name

m_name

Multivalued composite

Composite attributes may be shown broken down into their simple components Simple/Single Valued; Primary Key

63

Textbook’s notation

6464

An attribute broken into component parts

Multivaluedan employee can have more than one skill

Derivedfrom 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 identifiersto simplify design andenhance performance CUSTOMER

Customer_NumberLast_NameFirst_NameAddressCityStateZipPhone66

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

68

Figure 3-10 Relationship types and instances

a) Relationship

b) Relationship instances

Cardinality Constraints

0 Optional relationships

none or one0

0 none or more

Mandatory relationships

one and only one

one or more

69

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

A patient history is recorded for one and only one patient

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

70

Degrees of Relationships: unary and binary

The number of different entities involved in a relationship

EMPLOYEE Manages UNARY

STUDENT DORMITORYIs assigned

BINARY

71

Note: a relationship can have attributes of its own

Degrees of Relationships - ternary

A vendor supplies parts to warehouses. The unit cost and delivery method may differ for every warehouse.

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

Figure 3-21a Employees and departments

Entities can be related to one another in more than one way

76

Strong vs. Weak Entities, andIdentifying 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

Associative entity is depicted as a rectangle with a diamond inside.

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

79

Modeling a ternary relationship as an associative entity

80

Introduction to Entity-Relationship (E-R) Modeling Notation uses three main constructs

Data entitiesRelationshipsAttributes

Entity-Relationship (E-R) DiagramA detailed, logical representation of the

entities, associations and data elements for an organization or business

10.8110.81

Entity-Relationship (E-R) ModelingKey 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.8210.82

Entity-Relationship (E-R) ModelingKey Terms

Candidate keys and identifiersEach 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 SystemAmazon.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) ModelingKey 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) ModelingKey Terms

RelationshipAn 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

909.909.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.9210.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

EMPLOYEEsupervises

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 INV. ITEMSORDER ITEMS

Example (ER Diagram)

SALES ORDERS

INV. ITEMSORDER ITEMS

CLERKSCUSTOMERS

1059.1059.105