What a data flow diagram shows
A data flow diagram (DFD) is a visual model of how data moves through a system — where it originates, which processes transform it, where it is held at rest, and where it ultimately goes. DFDs were formalized in two parallel notations: Gane-Sarson (1979), which uses rectangles for external entities, rounded rectangles for processes, and open-ended rectangles for data stores; and Yourdon-DeMarco (1978), which uses rectangles for external entities, circles or "bubbles" for processes, and parallel lines for data stores. Both notations share the same four conceptual elements and the same decomposition discipline.
A DFD is distinct from an entity-relationship diagram (ERD) and from a flowchart. An ERD models the static structure of data — how tables or entities relate to one another — without showing how data moves. A flowchart models the sequence of decisions and actions in a process — control flow — without specifying what data is consumed or produced at each step. A DFD focuses exclusively on data in motion: what enters the system, what transforms it, and what leaves or is stored.
DFD symbols
| Symbol | Element | Meaning |
|---|---|---|
| Rectangle (▭) | External entity | A person, organization, or system that lies outside the system boundary. External entities are sources (they send data in) or sinks (they receive data out). They are not decomposed further in the diagram. |
| Circle / bubble (○) | Process | A function that transforms incoming data into outgoing data. In Yourdon-DeMarco notation this is a circle; in Gane-Sarson it is a rounded rectangle. Each process is labeled with a verb phrase describing the transformation (e.g., "Validate order", "Aggregate daily totals"). |
| Parallel lines (═) | Data store | Data at rest — a database table, file system, cache, or message queue. Data stores receive data from processes and supply data to processes. They do not initiate data movement on their own. |
| Arrow (→) | Data flow | A named, directed arrow showing data moving between any two elements. The label names the data being transferred (e.g., "Order record", "Customer ID"). Arrows must always connect compatible element pairs — external entity to process, process to data store, process to process. |
DFD levels: context, level 0, level 1
DFDs are organized by decomposition level. Each level zooms into a single process bubble from the level above, replacing it with a more detailed sub-diagram. This hierarchy lets you communicate at the right level of detail for each audience.
Context diagram (level 0). The entire system is represented as a single process bubble. All external entities appear around it, and every data flow crossing the system boundary is shown. The context diagram answers one question: what data enters and exits this system, and who sends or receives it? It is used for stakeholder alignment and scope definition. There are no data stores and no internal processes visible.
Level 1 DFD. The single context-diagram bubble is decomposed into the system's major sub-processes (typically three to seven). Internal data stores appear for the first time, and internal data flows between sub-processes become visible. The data flows crossing the system boundary must exactly match those shown in the context diagram — this consistency rule is called "balancing." Level 1 is the most common artifact for requirements analysis and system design reviews.
Level 2 and beyond. Individual sub-processes from level 1 are each decomposed into their own sub-diagrams. Decomposition continues until each process is simple enough to implement directly — typically a single function or module. Deep decomposition is used for detailed design specifications and for generating implementation tasks from a systems analysis model.
ETL vs DFD — choosing the right diagram
ETL pipeline diagrams and DFDs both show data movement, but they answer different questions and serve different audiences.
A DFD shows the logical movement of data across system and organizational boundaries. It abstracts away implementation details — there is no notion of scheduling, retry logic, or infrastructure. DFDs are used in systems analysis, requirements documentation, and architectural communication with non-technical stakeholders. The audience is a business analyst, product manager, or architect.
An ETL pipeline diagram shows the technical stages of a specific data pipeline: the source systems being extracted from (a Postgres replica, an S3 bucket, a Kafka topic), the transformation steps (dbt models, Spark jobs, SQL views), and the load targets (a Snowflake schema, a BigQuery dataset, an Elasticsearch index). ETL diagrams include infrastructure, scheduling, volume estimates, and error-handling paths. The audience is a data engineer or platform team.
Use a DFD when you need to document what data the system handles and where it logically flows. Use an ETL diagram when you need to design or communicate the technical implementation of a specific pipeline. flow-chart.io generates both from a plain-language description — specify the notation or domain in your prompt and the AI selects the appropriate element types.
How to generate a data flow diagram with flow-chart.io
- Create a free account — 40 AI credits/month, no credit card required.
- Select the data flow domain from the domain picker, or type your prompt directly.
- Describe your diagram — for example: "Level 1 DFD for an e-commerce order management system with external entities for Customer, Payment Gateway, and Warehouse; processes for Validate Order, Process Payment, and Fulfill Order; and data stores for Order Database and Inventory Database."
- Edit and export — click any element to rename, reposition, or restyle it. Export as SVG, PNG, PDF, or JSON.
Frequently asked questions
- What is a data flow diagram?
- A data flow diagram (DFD) is a visual model that shows how data moves through a system — where it comes from, which processes transform it, where it is stored, and where it goes. DFDs use four elements: external entities (sources and destinations outside the system boundary), processes (functions that transform data), data stores (where data is held at rest), and data flows (the arrows showing movement between elements). Two common notations are Gane-Sarson (rectangles, rounded rectangles, open-ended rectangles) and Yourdon-DeMarco (rectangles, circles, parallel lines).
- What are the four elements of a DFD?
- The four elements are: (1) External entity — a rectangle representing a person, system, or organization that sends data into or receives data from the system; (2) Process — a circle or rounded rectangle representing a function that transforms incoming data into outgoing data; (3) Data store — parallel lines or an open-ended rectangle representing data at rest, such as a database table, file, or cache; (4) Data flow — an arrow showing data moving between any two elements, labeled with the name of the data being transferred.
- What is the difference between a context diagram and a level 0 DFD?
- A context diagram (sometimes called a level 0 DFD) shows the entire system as a single process bubble with all external entities around it and the data flows crossing the system boundary. It answers: what goes in and what comes out? A level 1 DFD decomposes that single process into its major sub-processes, revealing internal data flows and data stores. Level 2 and beyond decompose individual sub-processes further. The context diagram is used for stakeholder alignment; level 1 is used for design and requirements analysis.
- How is a DFD different from a flowchart?
- A flowchart models control flow — the sequence of decisions and actions a process executes over time. A DFD models data flow — where data originates, how it is transformed, and where it ends up, without implying a time sequence or branching logic. A flowchart asks "what happens next?"; a DFD asks "where does this data go?" DFDs are used in systems analysis and data architecture; flowcharts are used in process design and procedure documentation.
- What is an ETL pipeline diagram?
- An ETL (Extract, Transform, Load) pipeline diagram shows the technical stages that move data from source systems into a target data warehouse or data lake. It typically shows: source systems (databases, APIs, files), extraction steps, transformation logic (cleaning, joining, aggregating), and load targets (warehouse tables, data marts). ETL diagrams are more technically detailed than DFDs — they show specific technologies, scheduling, error handling, and volume — while DFDs show the logical data movement at the system level. flow-chart.io can generate both styles from a plain-language description.
- Does flow-chart.io support data lineage diagrams?
- Yes. Data lineage diagrams trace how a specific data element moves and transforms across systems — from its origin (a source database, an event stream, a file upload) through every intermediate transformation to its final destination (a report, an API response, a data warehouse table). flow-chart.io generates lineage maps as editable diagrams: each node is a real object you can rename, reposition, and annotate. Describe the data element and the systems it passes through, and the AI produces the lineage map.
- What export formats does flow-chart.io support for data diagrams?
- flow-chart.io exports data flow diagrams as SVG (scalable vector, ideal for documentation and presentations), PNG (raster image for embedding in reports), and JSON (the structured scene graph, which captures every node and connection as typed objects for re-import and programmatic use). PDF export is also available. Every element in the exported diagram was generated as a real typed object — not a flattened image — so the structure is preserved across formats.