An entity relationship diagram (ERD) is a picture of the things a system stores and how they relate to each other - customers, orders, invoices, and which ones belong to which. It is the shape of your data, drawn so a room can argue about it before it is built.
How to read one in thirty seconds
Boxes are things you store. Lines are relationships. The markings at the ends of a line tell you how many of each can exist, which is the part that actually matters.
- One-to-many
- One customer has many orders. The commonest relationship, and the one drawn with a "crow's foot" - three prongs - at the many end.
- One-to-one
- One user has one profile. Often a sign that the two could be a single thing.
- Many-to-many
- A project has many people and a person works on many projects. Usually needs a third box in the middle to record the pairing.
- Optional versus required
- Can an order exist with no customer? A circle on the line means yes, a bar means no. This is the marking that catches real product questions.
Why a product person should care
Because the data model quietly decides what your product can do later. If an invoice belongs to exactly one project, then "split this invoice across two projects" is not a feature request, it is a migration. Reading an ERD early is how you find that out during a design conversation rather than during a sprint.
Where ERDs get argued about
The interesting disagreements are almost always about the markings, not the boxes. Can a team member exist without a team? Can a project have two owners? Does deleting a client delete their projects, or is that forbidden? Each of those is a product decision wearing a technical costume, and each is cheaper to settle on a diagram than in code.
Frequently asked questions
Do we need an ERD for every feature?
No. Draw one when a feature introduces new things to store or changes how existing ones relate. For a change that only adds a field, it is overkill.
Who should draw it?
Usually an engineer, but read and challenged by whoever owns the product. The questions worth asking about an ERD are product questions.
How Spectr helps
Keep a requirements doc that is still true next month
Versioned BRDs and PRDs that stay current, and can generate a spec sheet directly
Related terms
Spend less of the week on documents
Spectr drafts the spec, the requirement document and the stories from your meetings. You review and approve.
Free plan available. 30-day free trial on Starter.