Page 224 -

chaPter 7 • Using Data Flow Diagrams 191

matrix for an Internet storefront. Notice that some of the processes include more than one activity.
Data entry processes such as keying and verifying are also part of physical data flow diagrams.
Physical data flow diagrams also have intermediate data stores, often a transaction file or
a temporary database table. Intermediate data stores often consist of transaction files used to
store data between processes. Because most processes that require access to a given set of data
are unlikely to execute at the same instant in time, transaction files must hold the data from one
process to the next. An easily understood example of this concept is found in the everyday expe-
riences of grocery shopping, meal preparation, and eating. The activities are:
1. Selecting items from shelves
2. Checking out and paying the bill
3. Transporting the groceries home
4. Preparing a meal
5. Eating the meal
Each of these five activities would be represented by a separate process on a physical data flow
diagram, and each one occurs at a different time. For example, you would not typically trans-
port the groceries home and eat them at the same time. Therefore, a “transaction data store” is
required to link each task. When you are selecting items, the transaction data store is the shop-
ping cart. After the next process (checking out), the cart is unnecessary. The transaction data
store linking checking out and transporting the groceries home is the shopping bag (cheaper than
letting you take the cart home!). Storing the groceries in bags once they are home would be inef-
ficient, so cupboards and a refrigerator are used as a transaction data store between the activity
of transporting the goods home and preparing the meal. Finally, a plate, bowl, and cup constitute
the link between preparing and eating the meal.
Timing information may also be included. For example, a physical DFD may indicate that
an edit program must be run before an update program. Updates must be performed before pro-
ducing a summary report, or an order must be entered on a website before the amount charged
to a credit card may be verified with the financial institution. Note that because of such consider-
ations, a physical data flow diagram may appear more linear than a logical model.
You create the physical data flow diagram for a system by analyzing its output and input.
When creating a physical data flow diagram, input data flow from an external entity is sometimes
called a trigger because it starts the activities of a process, and output data flow to an external
entity is sometimes called a response because it is sent as the result of some activity. You need to
determine which data fields or elements need to be keyed. These fields are called base elements
and must be stored in a file. Elements that are not keyed but are rather the result of a calculation
or logical operation are called derived elements.
Sometimes it is not clear how many processes to place in one diagram and when to create
a child diagram. One suggestion is to examine each process and count the number of data flows
entering and leaving it. If the total is greater than four, the process is a good candidate for a child
diagram. Physical data flow diagrams are illustrated later in this chapter.
EVENT MODELING AND DATA FLOW DIAGRAMS. A practical approach to creating physical
data flow diagrams is to create a simple data flow diagram fragment for each unique system
event. Events cause the system to do something and act as a trigger to the system. Triggers start
activities and processes, which in turn use data or produce output. An example of an event is a
customer reserving a flight on the Web. As each Web form is submitted, processes are activated,
such as validating and storing the data and formatting and displaying the next web page.
Events are usually summarized in an event response table. An example of an event response
table for an Internet storefront business is illustrated in Figure 7.12. A data flow diagram frag-
ment is represented by a row in the table. Each DFD fragment is a single process on a data flow
diagram. All the fragments are then combined to form Diagram 0. The trigger and response
columns become the input and output data flows, and the activity becomes the process. The
analyst must determine the data stores required for the process by examining the input and
output data flows. Figure 7.13 illustrates data flow diagrams for the first three rows of the event
response table.
The advantage of building data flow diagrams based on events is that the users are famil-
iar with the events that take place in their business area and know how the events drive other
activities.