An Entity Relationship Diagram (ERD) shows the data behind a system — what things are stored, what details are kept about each, and how they relate to one another. If a flowchart is the map of a process, an ERD is the map of the information.
The three building blocks
- Entity — a thing the business needs to keep information about. Customer, Order, Product, Invoice. Drawn as a box.
- Attribute — a detail about an entity. A Customer has a name, an email, a phone number. These live inside the entity box.
- Relationship — how entities connect. A Customer places an Order. An Order contains Products. Drawn as a line between boxes.
Cardinality — the most important idea
Cardinality describes how many of one entity relate to how many of another. It is the part of an ERD that carries the real business rules:
- One-to-one (1:1) — one passport belongs to one person.
- One-to-many (1:N) — one customer places many orders, but each order belongs to one customer. This is the most common.
- Many-to-many (M:N) — a student takes many courses and each course has many students.
Cardinality encodes business rules. When an ERD says a customer can have many addresses, that is a business decision someone made. As a BA, reading cardinality lets you spot rules that were never written down anywhere else — and question them. "Can a customer really have only one phone number? What about a work and a personal number?"
Why a BA needs ERDs even without being technical
You do not need to design databases. But you do need to understand the data, because:
- It reveals hidden requirements. "What happens to a customer's orders if we delete the customer?" is a question an ERD forces you to answer.
- It validates your requirements. If you specified a report grouping sales by region, but the data model has no concept of region, you have found a gap before it became expensive.
- It exposes assumptions. The structure shows what the business believes about its own information.
A small ERD in words
CUSTOMER (one) ——places——> ORDER (many). ORDER (one) ——contains——> ORDER_LINE (many). Each ORDER_LINE refers to one PRODUCT. From this, you can read the rule: an order can have many lines, but each line is for exactly one product — and to order two products, you need two lines.Practice pointer: for any system you work on, sketch the three or four main entities and the relationships between them. Even a rough ERD surfaces questions that requirements documents miss.