DATA FLOW DIAGRAM

Also known as DFD, Data flow diagrams are used to graphically represent the flow of data in a
business information system. DFD describes the processes that are involved in a system to transfer data
from the input to the file storage and reports generation. As its name indicates its focus is on the flow of
information, where data comes from, where it goes and how it gets stored.

Data flow diagrams visually represent systems and processes that would be hard to describe in a
chunk of text. You can use these diagrams to map out an existing system and make it better or to plan
out a new system for implementation. Visualizing each element makes it easy to identify inefficiencies
and produce the best possible system.

Data flow diagrams can be divided into logical and physical. The logical data flow diagram
describes flow of data through a system to perform certain functionality of a business. The physical data
flow diagram describes the implementation of the logical data flow.

Logical data flow diagrams focus on what happens in a particular information flow: what information is
being transmitted, what entities are receiving that info, what general processes occur, etc. The
processes described in a logical DFD are business activities—a logical DFD doesn’t delve into the
technical aspects of a process or system. Non-technical employees should be able to understand these
diagrams.

Physical data flow diagrams focus on how things happen in an information flow. These diagrams specify
the software, hardware, files, and people involved in an information flow. A detailed physical data flow
diagram can facilitate the development of the code needed to implement a data system.

Design
Logical Physical
Feature

What the model How the How the system will be implemented
depicts business (or how the current system
operates. operates).

What the Business Programs, program modules, and

processes activities. manual procedures.
represent

What the data Collections of Physical files and databases,

data regardless
Design
Logical Physical
Feature

stores represent of how the data manual files.

are stored.

Type of data Show data stores Master files, transition files. Any
stores representing processes that operate at two
permanent data different times must be connected
collections. by a data store.

System controls Show business Show controls for validating input

controls. data, for obtaining a record (record
found status), for ensuring
successful completion of a process,
and for system security (example:
journal records).

Ideally, systems are developed by analyzing the current system (the current logical
DFD) and then adding features that the new system should include (the proposed
logical DFD). Finally, the best methods for implementing the new system should be
developed (the physical DFD). This progression is shown in the figure illustrated below.

The progression of models from logical to physical

Benefits of Logical Data Flow Diagram
 A logical diagram is drawn present business information and centered
on business activities, which makes it an ideal communication tool
when use in communicating with project users.
 Logical DFD is based on business events and independent of particular
technology or physical arrangement, which makes the resulting system
more stable.
 Logical DFD allows analyst to understand the business being studied
and to identify the reason behind implementation plans.
 Systems implemented based on logical DFD will be easier to maintain
because business functions are not subject to frequent change.
 Very often, logical DFD does not contain data stores other than files
or a database, making less complex than physical DFD and is easier to
develop.
 Physical DFD can be easily formed by modifying a logical DFD.

Benefits of Physical Data Flow Diagram

 Clarifying which processes are manual and which are automated: Manual
processes require detailed documentation and automated process require
computer programs to be developed.
 Describing processes in more detail than do logical DFDs: Describes
all steps for processing of data.
 Sequencing processes that have to be done in a particular order:
Sequence of activities that lead to a meaningful result are described.
For example, update must be performed before a producing a summary
report.
 Identifying temporary data storage: Temporary storage such as a sales
transaction file for a customer receipt (report) in a grocery store,
are described.
 Specifying actual names of files and printouts: Logical data flow
diagrams describes actual filenames and reports, so that the
programmers can relate those with the data dictionary during the
developmental phase of the system.
 Adding controls to ensure the processes are done properly: These are
conditions or validations of data that are to be met during input,
update, delete, and other processing of data.

Refining Physical DFD for Logical DFD

The example below shows a logical DFD and a physical DFD for a grocery store
cashier:
 The CUSTOMER brings the ITEMS to the register;
 PRICES for all ITEMS are LOOKED UP, and then totaled;
 Next, PAYMENT is given to the cashier finally, the CUSTOMER is given a
receipt.

Logical DFD Example - Grocery Store

The logical DFD illustrates the processes involved without going into detail
about the physical implementation of activities.

Physical DFD Example - Grocery Store

 The physical DFD shows that a bar code-the UPC PRICE code found on
most grocery store items is used
 In addition, the physical DFD mentions manual processes such as
scanning, explains that a temporary file is used to keep a subtotal of
items
 The PAYMENT could be made by CASH, CHECK, or DEBIT CARD
 Finally, it refers to the receipt by its name, CASH REGISTER RECEIPT
Data flow diagram levels

Data flow diagrams are also categorized by level. Starting with the
most basic, level 0, DFDs get increasingly complex as the level
increases. As you build your own data flow diagram, you will need to
decide which level your diagram will be.

Level 0 DFDs, also known as context diagrams, are the most basic
data flow diagrams. They provide a broad view that is easily digestible
but offers little detail. Level 0 data flow diagrams show a single
process node and its connections to external entities.

Level 1 DFDs are still a general overview, but they go into more detail
than a context diagram. In a level 1 data flow diagram, the single
process node from the context diagram is broken down into
subprocesses. As these processes are added, the diagram will need
additional data flows and data stores to link them together.
Level 2+ DFDs simply break processes down into more detailed
subprocesses. In theory, DFDs could go beyond level 3, but they rarely
do. Level 3 data flow diagrams are detailed enough that it doesn’t
usually make sense to break them down further.
Data Flow Diagrams Symbols
There are essentially two different types of notations for data flow diagrams (Yourdon & Coad
or Gane & Sarson) defining different visual representations for processes, data stores, data flow
and external entities.
Yourdon and Coad type data flow diagrams are usually used for system analysis and design,
while Gane and Sarson type DFDs are more common for visualizing information systems.
Visually, the biggest difference between the two ways of drawing data flow diagrams is how
processes look. In the Yourdon and Coad way, processes are depicted as circles, while in the
Gane and Sarson diagram the processes are squares with rounded corners.
Process Notations. A process transforms incoming data flow into outgoing data flow.

Datastore Notations. Datastores are repositories of data in the system. They are sometimes also
referred to as files.

Dataflow Notations. Dataflows are pipelines through which packets of information flow. Label
the arrows with the name of the data that moves through it.

External Entity Notations. External entities are objects outside the system, with which the
system communicates. External entities are sources and destinations of the system's inputs and
outputs.
Data flow diagram symbols and notation

Depending on the methodology (Gane and Sarson vs. Yourdon and

Coad), DFD symbols vary slightly. However, the basic ideas remain the
same. There are four basic elements of a data flow diagram: processes,
data stores, external entities, and data flows. The picture below shows
the standard shapes for both methodologies.
How to create a data flow diagram

Now that you have some background knowledge on data flow

diagrams and how they are categorized, you’re ready to build your
own DFD. The process can be broken down into 5 steps:

1. Identify major inputs and outputs in your system

Nearly every process or system begins with input from an external

entity and ends with the output of data to another entity or database.
Identifying such inputs and outputs gives a macro view of your
system—it shows the broadest tasks the system should achieve. The
rest of your DFD will be built on these elements, so it is crucial to know
them early on.

2. Build a context diagram

Once you’ve identified the major inputs and outputs, building a

context diagram is simple. Draw a single process node and connect it
to related external entities. This node represents the most general
process information undergoes to go from input to output.

The example below shows how information flows between various

entities via an online community. Data flows to and from the external
entities, representing both input and output. The center node, “online
community,” is the general process.

3. Expand the context diagram into a level 1 DFD

The single process node of your context diagram doesn’t provide

much information—you need to break it down into subprocesses. In
your level 1 data flow diagram, you should include several process
nodes, major databases, and all external entities. Walk through the
flow of information: where does the information start and what needs
to happen to it before each data store?

4. Expand to a level 2+ DFD

To enhance the detail of your data flow diagram, follow the same
process as in step 3. The processes in your level 1 DFD can be broken
down into more specific subprocesses. Once again, ensure you add
any necessary data stores and flows—at this point you should have a
fairly detailed breakdown of your system. To progress beyond a level 2
data flow diagram, simply repeat this process. Stop once you’ve
reached a satisfactory level of detail.

5. Confirm the accuracy of your final diagram

When your diagram is completely drawn, walk through it. Pay close
attention to the flow of information: does it make sense? Are all
necessary data stores included? By looking at your final diagram, other
parties should be able to understand the way your system functions.
Before presenting your final diagram, check with co-workers to ensure
your diagram is comprehensible.