October 25, 2016
Hot Topics:

Understanding Process Modeling

  • March 16, 2001
  • By Developer.com Staff
  • Send Email »
  • More Articles »

The Data Flow Diagram

The third method for presenting process models is the traditional data flow diagram (DFD). The DFD shows processes and data flows like the process modeler, but it also assigns a numeric ID number to each process. Using the generic process model example discussed earlier, the high-level processes would be DFD level 0, each with its own unique identifying number to the left of the decimal place with a zero to the right.







Human resources 


Research and development 


To further decompose accounting, you would use the accounting processes "1" on the left and a unique number as the first digit on the right. This would be a level-1 DFD.



Accounts payable 


Accounts receivable 




These processes can then be further decomposed. To further decompose accounts payable, you would use the accounting process's "1" to the left of the decimal place and the accounts payable process's "1" as the first digit on the right. You would then add another decimal point and a unique number for each process beneath accounts payable as the second digit on the right of the decimal place. This would be a level-2 DFD with two numerals to the right of the first decimal place.



Receive invoice 


Verify receipt of product 


Send payment 


These processes can yet again be decomposed. You could decompose send payment 1.1.3 by adding a decimal place and unique number for each process beneath send payment. This would be a level-3 DFD, and its decomposition is shown in the following example.



Receive disbursal approval

Print check

Prepare envelope

DFD is the oldest method for processing modeling. Extensive rules are defined for the creation of DFDs that are derived from years of experience using them. The logical organization brought with the numbering system also can be valuable.
The DFD is the traditional method for process modeling, and it assigns a numeric ID to each process based on its parent process and its sequence as related to other processes on the same level.
Figure 5 illustrates a data flow diagram based on the process that has been discussed so far this chapter. The main process shown in this DFD is "manage accounts payable" (1.1.1). Notice that the step number is annotated in the upper-left corner of each function. Functions are represented by rounded boxes. Data stores (entities) are represented by open-ended rounded boxes. Process and data flows are represented by arrows. This diagram contains much of the same information found in the process model. The focus here is to define data access (data usage) by associating functions and entities.

Figure 5: Data flow diagram.

A data flow diagram can be created to illustrate the functions, flows of data, and data stores associated with a database system being designed. A data flow diagram is used to show how information moves through an organization.

What Does One Gain from the Process Model?

The business process model is an invaluable tool in communicating process requirements between developers and users and in capturing them once communicated. Users, the people who truly understand the current processes, can look at the description of processes from the model to see if you, as a developer, really have captured the processes the new system needs to accomplish. As with the ERD, a picture is worth a thousand words. User feedback sessions utilizing the process model as the starting point for discussions are invaluable as you develop the model. Once you've completed the model, it will hold the process requirements agreed to by developers and users as analysis turns to design and then to implementation.

A good developer/consultant will get to know the nature of the business and really understand the business itself before beginning to use the process model or asking questions of the user.

The process of creating the model will help the design team develop a better understanding of the business. The great depth of detail that must be captured as you decompose each process will show the designer exactly how the processes are working and, on occasion, how they're not. It will also often show opportunities for getting rid of duplicated efforts and gaining economies of scale by combining duplicate processes on an enterprise level or establishing new processes that combine several of the old processes more efficiently and effectively. The process model graphically illustrates the flow of data within the system. Often, this will be helpful in identifying ways to make those flows more effective. Unused weekly reports may disappear. Entire applications may be found that are making no real contributions.


You might be able to design a database without producing process models, but you can't design a database without considering the business processes that take place. A database exists for the end user. The end user has a job to perform that, with or without the use of an automated database system, always requires at least one process. The database must be designed to fit the mold of the requirements implied by these processes. Therefore, business processes drive the need for a database.

In this article, you learned about the three basic models used to visually represent business processes. These are the process model, the function hierarchy diagram, and the data flow diagram. The process model shows processes (starting with a root process), organizational units that perform processes, flows between processes, and data stores. Data stores refer to entities that have been defined. The functional hierarchy diagram shows all processes, also called functions, that have been defined in a hierarchical format so that it is easy to determine the relationship between processes. The data flow diagram also shows processes, their flows, and their associated data stores. The DFD is used primarily to show how data flows within an organization. Data usages can be defined that determine how processes may access entities and attributes (data).

This article is derived from the book Database Design (ISBN: 0-672-31758-3), which is available by clicking on the title.

About the Authors

Ryan K. Stephens and Ronald R. Plew are the authors of Database Design (ISBN: 0-672-31758-3), a book by Sams Publishing. Ryan is president and CEO of Perpetual Technologies, Inc. a database company specializing in Oracle consulting and training. Ron is vice president and CIO of Perpetual Technologies, Inc. Both have numerous years of experience training and consulting at the DBA level.

© Copyright Sams Publishing, All Rights Reserved

Page 2 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel