data flow diagram
TRANSCRIPT
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