What is the difference between DFD and ERD?

A data flow diagram (DFD) shows how data moves through a system, and an entity-relationship diagram (ERD) shows how data is structured when it is stored. A DFD has four parts: processes that transform data, data stores that hold it, external entities that send or receive it, and arrows for the flows between them. An ERD has three parts: entities, which are the things the system stores facts about, attributes, which are the facts, and relationships, which connect entities with a stated cardinality. The DFD answers "what happens to the data". The ERD answers "what does the stored data look like".

What a Data Flow Diagram Shows

A DFD tracks data from the point it enters a system to the point it leaves. A process is any step that changes data, such as "Validate order". A data store is any place data is held, such as an Orders file. An external entity is a person or system outside the boundary, such as a customer or a payment provider. A data flow is a named arrow, such as "order details", between any two of those.

DFDs are drawn in levels. The context diagram, also called level 0, has one process for the whole system and shows only the external entities around it. Level 1 breaks that one process into its main sub-processes. Level 2 expands one level 1 process further. Each level must have the same inputs and outputs as the process it expands, which is called balancing.

Two notations are common. Yourdon-DeMarco draws a process as a circle and a data store as two parallel lines. Gane-Sarson draws a process as a rounded rectangle and a data store as an open-ended rectangle. Both draw external entities as squares and flows as arrows.

Logical DFD Versus Physical DFD

A logical DFD shows what the system does, and a physical DFD shows how it does it. The logical version names processes by business activity, such as "Approve loan", and stores by what they hold. The physical version names the actual programs, files, database tables, and people that carry out each step. Analysts usually draw the logical DFD first, so the design is not tied to the current implementation.

What an Entity-Relationship Diagram Shows

An ERD is the plan for the tables of a relational database. An entity becomes a table. An attribute becomes a column, and one attribute is marked as the primary key, which is the column that identifies each row. A relationship becomes a foreign key, which is a column holding the primary key of a row in another table.

Cardinality states how many rows on each side can take part in a relationship: one-to-one, one-to-many, or many-to-many. A many-to-many relationship cannot be stored directly, so it becomes a third table with two foreign keys.

Two notations are common here too. Chen notation draws entities as rectangles, attributes as ovals, and relationships as diamonds. Crow's foot notation lists the attributes inside the entity rectangle and marks cardinality with symbols on the line ends, where three short lines stand for "many".

The Same Bookstore in Both Diagrams

One system is described by both diagrams, and they do not overlap. For an online bookstore, the level 1 DFD has processes such as "Place order" and "Manage inventory", stores such as Orders and Products, and external entities Customer and Payment provider. A flow named "order details" goes from Customer to "Place order", and a flow named "confirmation" goes back.

The ERD for the same store has entities Customer, Order, Product, and Category. Customer to Order is one-to-many. Order to Product is many-to-many, so an OrderLine table holds the order id, the product id, and a quantity. Product to Category is many-to-one. The DFD never says which columns Order has, and the ERD never says who places an order or when.

When to Use Each

Use a DFD when the question is about process, and an ERD when the question is about storage. A DFD is the right tool for documenting an existing workflow, finding a step where data is copied by hand, or agreeing on the boundary of a new system. An ERD is the right tool for designing a database, reviewing a schema, or explaining to a developer how two tables connect.

In a system design interview, the ERD is the diagram that appears most often, because the data model is a required part of the answer. Most projects draw both. The DFD is written first, because its data stores become the starting list of entities for the ERD.