DFD and ER Diagram for a Project Report: Symbols, Levels and Rules

By Vivek Singh · 11 October 2026 · 4 min read

In short

A data flow diagram (DFD) shows how data moves through a system: where it comes from, which processes change it, and where it is stored. An ER diagram shows what data the system stores: the entities, their attributes and how they relate. A project report usually has a context diagram, a level 1 DFD and one ER diagram.

Key takeaway

A DFD answers "how does data move through the system?" An ER diagram answers "what data does the system store?" A blackbook's system design chapter usually has a context diagram, a level 1 DFD and one ER diagram, and all three must agree with each other and with your actual database.

DFD symbols

There are four, in two common notations:

Element	Meaning	Yourdon and DeMarco	Gane and Sarson
External entity	A person or system outside yours that sends or receives data	Rectangle	Square
Process	Something that transforms data	Circle	Rounded rectangle
Data store	Where data rests: a table or file	Two parallel lines	Open-ended rectangle
Data flow	Data moving from one place to another	Labelled arrow	Labelled arrow

Use one notation for every diagram in the report.

The levels of a DFD

Level 0, the context diagram. The whole system is one process in the centre. Around it are the external entities, with arrows labelled with the data that passes each way. No data stores.

Level 1. The single process is broken into the main processes of the system, usually four to seven, numbered 1.0, 2.0, 3.0. Data stores appear here, named D1, D2, D3.

Level 2. One level 1 process is broken down further, with processes numbered 1.1, 1.2. Draw this only for the processes complex enough to need it.

Worked example: library management system

Context diagram

Entities: Member, Librarian
Member to system: search request, issue request, return
System to member: search results, due date, fine notice
Librarian to system: book details, member details
System to librarian: reports

Level 1 processes

1.0 Manage members
2.0 Manage books
3.0 Issue book
4.0 Return book and calculate fine
5.0 Generate reports

Data stores: D1 Members, D2 Books, D3 Issues, D4 Fines

Rules examiners check in a DFD

Every process has at least one input and one output.
Data does not flow directly between two external entities, between two data stores, or between an entity and a data store. It always passes through a process.
Every arrow is labelled with a noun: "issue request", not "sends".
Processes are named with a verb: "Issue book", "Calculate fine".
Levels balance: the flows into and out of a process at level 1 match the flows of its level 2 diagram, and level 1 as a whole matches the context diagram.
A DFD has no decisions or loops. If you are drawing a diamond, you are drawing a flowchart.

ER diagram symbols (Chen notation)

Entity: a rectangle. A thing you store data about: Member, Book.
Attribute: an oval joined to its entity. The primary key is underlined.
Relationship: a diamond between entities: Member borrows Book.
Cardinality: written on the lines as 1:1, 1:N or M:N.

Many colleges now accept crow's foot notation, where each entity is a box listing its attributes and the line ends show one or many. It is closer to how the tables really look.

The same example as an ER diagram

Member (member_id, name, phone, joined_on)
Book (book_id, title, author, category, copies)
Issue (issue_id, member_id, book_id, issue_date, due_date, return_date)
Fine (fine_id, issue_id, amount, paid)

Relationships:

A member can have many issues; an issue belongs to one member (1:N)
A book can appear in many issues; an issue is for one book (1:N)
An issue can have at most one fine (1:1)

Member and Book are really many to many: a member borrows many books, and a book is borrowed by many members over time. A many-to-many relationship becomes a table of its own in the database, which is what Issue is.

Rules examiners check in an ER diagram

Every entity has a primary key
Every relationship has its cardinality marked
Many-to-many relationships are resolved into a linking table
The entities and attributes match the tables in your implementation chapter, name for name

Common mistakes

A context diagram with data stores or more than one process
Arrows with no labels
A DFD drawn as a flowchart, with decisions
An ER diagram copied from the internet that does not match the project's tables
Attributes on the diagram that are missing from the data dictionary

Drawing them

A blackbook written with BlackBook draws the diagrams for your own project, including the ER diagram, from the modules and tables it writes about, and each one can be edited in the editor when your tables change. For use case, class, sequence and activity diagrams, see UML Diagrams for a Project Report.

Frequently asked questions

What is the difference between a DFD and an ER diagram?

A DFD shows movement: the processes of the system and the data flowing between users, processes and stores. An ER diagram shows structure: the things the system keeps data about and the relationships between them. One describes what the system does with data, the other what data it holds.

What is a level 0 DFD?

The context diagram. It shows the whole system as a single process, with the external entities around it and the data that flows between them and the system. It has no data stores.

How many levels of DFD does a project report need?

Usually the context diagram (level 0) and a level 1 diagram. A level 2 diagram is added for one or two complex processes if your college asks for it.

How many entities should an ER diagram have?

As many as your database has main tables, commonly five to ten for a final year project. The diagram must match the real tables, including keys.

Which notation should I use?

For DFDs, either Yourdon and DeMarco (circles for processes) or Gane and Sarson (rounded rectangles). For ER diagrams, Chen notation or crow’s foot. Pick the one your syllabus teaches and use it throughout.

Written by

Vivek Singh

Founder of BlackBook

University of Mumbai graduate and software engineer. He built BlackBook so students can put their time into studies and exams, not months of formatting. More about BlackBook