How to Create an ER Diagram: Entities, Relationships and Examples

By the Diagramium team · 2026-08-13 · 8 min read

To create an ER diagram, list the things your system stores as entities, give each one a primary key and its columns, then draw a line between two entities wherever a fact in one refers to a fact in the other. Mark each line's cardinality — one-to-one, one-to-many or many-to-many — and resolve every many-to-many into a join table before you call the model finished.

Live interactive diagramUse the player controls to follow the steps

E-commerce database schemaPlaying silently in this guideWatch with narration Open in editor

This compact player stays quiet while you read. Open the full presentation when you want narration and the complete walkthrough.

When an ER diagram is the right choice

An entity-relationship diagram answers one question: what does this database hold, and how do the pieces refer to each other? It is the artefact to draw when a schema is about to be built and several people need to agree on it, or when a schema already exists and nobody can remember why a table is shaped the way it is.

It is the wrong tool for showing what the application does. An ER diagram has no notion of time, order or behaviour — if your question involves a sequence of events, you want a sequence diagram; if it involves where data travels, a data flow diagram.

An ER diagram describes what is true at rest. Nothing in it happens.

Entities, attributes, keys and cardinality

Entity. A thing worth storing, drawn as a table box: Customer, Order, Product. Name it in the singular — one row is one customer.
Attribute. A column on that entity. Give it a type where the type carries meaning; skip the ones nobody will argue about.
Primary key (PK). The column that identifies a row uniquely. Every entity needs exactly one, even if it is a surrogate id.
Foreign key (FK). A column holding another entity's primary key. This is what a relationship line actually is — the line is the drawing of the FK.
Relationship. The line between two entities, read as a sentence: "a customer places many orders."
Cardinality. The crow's-foot notation at each end. A three-pronged "crow's foot" means many; a single bar means one; a circle means zero is allowed.

Read cardinality from both ends, always. "One customer has many orders" is only half the model; the other half — "each order belongs to exactly one customer" — is the half that decides whether the FK is nullable.

The many-to-many rule

A relational database cannot store a many-to-many relationship directly, so a line with a crow's foot at both ends is a note-to-self, not a design. Resolve it with a join table that holds one FK to each side:

Students and courses become Student, Course and Enrolment.
Posts and tags become Post, Tag and PostTag.

The join table is frequently where the interesting columns live — an enrolment has a grade and a date, which belong to neither the student nor the course. Missing this is the most common modelling error in a first draft.

How to create an ER diagram, step by step

Write the nouns down. Read a description of the system and list every noun that has to be remembered between sessions. Those are your candidate entities.
Discard the ones that are attributes. "Email address" is a column on Customer, not an entity. A thing is an entity when it has its own identity and its own life.
Give each entity a primary key. Do this before the columns; it forces you to answer "what makes a row unique?"
Draw the relationships as sentences. Connect two entities only if you can say a sentence out loud: "a supplier provides many products."
Mark cardinality at both ends. Ask "at most one, or many?" and "can it be zero?" for each side separately.
Resolve every many-to-many. Add the join table and move any columns that describe the pairing onto it.
Add the columns that matter. Every FK, plus the attributes someone would query or dispute. A model with forty columns per box is a schema dump, not a diagram.

Worked examples you can open and edit

Real, editable schemas — open one and change a relationship to see the cardinality follow.

ER diagramE-commerce database schemaThe reference design: a customer places many orders, each order has many order-items.View example Use template
ER diagramBlog database schemaPosts and tags — a many-to-many resolved with a join table, which is the move most people miss.View example Use template
ER diagramLibrary database schemaTitles versus physical copies: the distinction that decides whether loans can work at all.View example Use template
ER diagramHospital appointments schemaPatients, doctors, appointments and prescriptions — one entity produced by a relationship.View example Use template
ER diagramSaaS billing schemaAn account, one subscription, a plan and the invoices it generates over time.View example Use template
ER diagramSchool enrolment schemaStudents and courses through an enrolments table, narrated table by table.View example Use template

A practical example: e-commerce orders

The e-commerce schema above is the reference design worth internalising, because it contains the one structure people most often get wrong. A customer places many orders — straightforward. But an order contains many products, and a product appears on many orders, which is a many-to-many. The resolution is OrderItem: a join table between order and product that also carries quantity and the price at the time of purchase.

That last column is the point. Price belongs on OrderItem, not on Product, because the price on the order is the price the customer actually paid — and product prices change. A schema that reads the price from Product silently rewrites history every time someone runs a sale. The ER diagram is where that decision becomes visible enough to argue about.

A second example: titles versus copies

The library schema makes a distinction that looks pedantic until you try to build without it: a Book is a title, and a Copy is a physical object on a shelf. Loans attach to copies, not to titles, because two people can borrow the same book only if the library owns two copies. Collapsing the two entities into one produces a system that cannot answer "is it available?" — a modelling failure you can see in the diagram long before it becomes a bug.

Building one in Diagramium

Open the ER diagram editor and work on the canvas.

Drop an entity from the shapes panel and name it.
Add columns in the inspector, marking keys as you go.
Drag from an entity's port to another entity to create a relationship.
Set the crow's-foot ends on the selected connector to state cardinality at each end.
Press Present to introduce the schema one table at a time — the way to walk a new engineer through a model they have never seen.

The ER editor is canvas-based; there is no text syntax for it, and the Text editor tab is hidden in this mode rather than offering syntax that would not apply.

Present reveals one entity at a time, which is how a schema review should go — nobody absorbs eleven tables at once.
Export as PNG, SVG or PDF free and without an account; SVG stays sharp when a wide schema is printed or zoomed. Animated SVG, GIF and video need a free account, no subscription.
Embed a published schema as an interactive player in internal documentation.

Common mistakes

Leaving a many-to-many unresolved. It cannot be built as drawn. Add the join table.
Cardinality on one end only. The unstated end is where the nullable-FK argument hides.
Entities that are really attributes. If it has no identity of its own and nothing points at it, it is a column.
Every column in the box. Show keys and the attributes under discussion. A reader who wants all forty can read the DDL.
Plural entity names. One box is one row's shape. Order, not Orders — mixing the two makes relationship sentences unreadable.
Modelling the UI. A screen that shows customers and orders together is not an entity. Model what is stored, not what is displayed.

A UML class diagram looks similar but describes objects with behaviour — methods as well as data. Use it for code structure, an ER diagram for storage.
A data flow diagram shows how data moves and what transforms it; an ER diagram shows how it is shaped once it lands.
A system architecture diagram shows which service owns which database — the level above this one.
A sequence diagram shows the reads and writes happening in order.

Questions people actually ask

What is the difference between an ER diagram and a UML class diagram?

An ER diagram models data at rest: tables, keys, cardinality. A UML class diagram models objects: attributes and methods, with inheritance. If the output is a database schema, draw an ER diagram; if it is code structure, draw a class diagram.

What does the crow's foot mean?

The three-pronged mark means "many" at that end of the relationship. A single perpendicular bar means "exactly one"; a circle means zero is permitted. Read both ends to get the full rule.

Do I need to show every column?

No. Show the primary key, every foreign key, and the attributes relevant to the discussion. A diagram is for agreeing on structure; the full column list belongs in the schema itself.

How do I model a many-to-many relationship?

Add a join table holding a foreign key to each side, then move any columns that describe the pairing — a grade, a quantity, a date — onto that table.

Should I use surrogate keys or natural keys?

That is a design decision your team should make deliberately; the diagram's job is to record which you chose so it is visible rather than assumed. Whichever you pick, mark exactly one primary key per entity.

Ready to build one? Open the ER diagram editor on a blank canvas, or start from one of the templates above — they are all editable.Open the ER diagram editor Browse all templates