DFD (Data Flow Diagram) Diagrams – why are they needed and what are they
Today I decided to write a basic theory about the use of data flow diagrams as one of the process modeling tools.
The diagram displays data flows between systems, databases. Key elements are input/output data, systems, data storage and collection points.
Why do we need DFD charts?
DFD diagrams, unlike other notations, allow you to visually show all processes in terms of data. This might be helpful:
when developing an information system
when integrating the system
when migrating data and functionality from one system to another
in projects related to Data Management
in the process of building an analytical repository, BI solutions
The diagram allows you to visualize both the movement of data between system objects and data transformations that can be applied at different steps of the process.
Elements of a DFD Chart
Highlight 4 elements in the chart
Processes in which there is a change in the data flow (processing, transformation, and other changes). The process, as in other diagrams, is usually written using a verb, for example: “Submitting a completed form”
An entity (object) that receives or sends data when interacting with the described process.
All data stores or individual files that store source or output data, as well as all intermediate stores.
A data flow that maps the direction and the data itself as it moves between external entities and data stores using processes.
A few charting rules:
The process must have input and output data stream
Data stores must also have input and output data streams
Data from external entities must necessarily go through the process to get into the storage
In DFD diagrams, 2 different notations are also distinguished. Therefore, it is worth paying attention to the conventions of each element, depending on the notation used. Below is a picture of comparing elements of different notations.
DFD Levels Charts
Depending on the purpose of using the diagram, you can display different levels of process detail. For example, in order to talk and present the process to business users and customers, it is important for them to understand the context and logic of the process itself, sometimes it makes no sense to immerse them in the technical aspects of implementation. On the other hand, when talking to the technical team, it is important to focus on the implementation of the solution from a technical point of view.
As in the ER diagram for data models, which includes several layers of display (conceptual, logical, physical), DFD diagrams can also be divided into similar levels:
Shows a general description of the process that is implemented in the data flow. Displays abstractly data streams associated with different external entities
Displays the logic of data transformation in the system in each process, describes. You can see the input, intermediate, output data in each process that flows from the external entity to the data stores. More points to the question “What does the process of data flow and exchange from the business side involve?”
Includes accurate display of data stores, names of data entities. The physical layer diagram should answer the question “How will the process of transfer and data flow be implemented?”
Also often in other sources you can see the division of the chart levels into 0.1, 2, 3 and so on, depending on the level of detail.
If we are talking about the development of a new solution, then it is important to understand “what we have now” (AS-IS) and “what we want to receive” (TO-BE). In other words, we separate our current state from the desired state that we want to achieve with our solution.
Describing the current logic diagram
We describe the desired logic diagram with new logic and requirements from the business. After that, from the desired logical diagram, we describe the physical one with a new technical solution.