How to Make an Entity Relationship Diagram (ERD): A Step-by-Step Guide

An entity relationship diagram, or ERD, is a map of the things your system stores and how they connect. Each entity becomes a box, each attribute a field inside it, and each relationship a line between boxes annotated with how many of one thing relate to how many of another. Done well, an ERD is the single clearest artifact for understanding a database: a new engineer can read it in minutes and know what a customer, an order, and a line item are, and how they hang together. Done poorly, it is a tangle of boxes and lines that obscures more than it reveals.

This guide walks through making an ERD from a blank page: how to find the entities, choose primary and foreign keys, draw relationships with the right cardinality, and resolve the many-to-many relationships that trip up most first drafts. You can build every diagram here in Atlas Diagram Studio at /diagrams, and the purpose-built ERD tool at /diagram-tools/erd-tool gives you entity shapes, key markers, and crow's foot connectors so you are not hand-drawing rectangles. The goal is a diagram that is both correct and readable.

Start by finding the entities

An entity is a thing your system needs to remember - a customer, an order, a product, an invoice. The reliable way to find them is to look for the nouns in how people describe the system. When a stakeholder says a customer places an order that contains several products, you already have three candidate entities: customer, order, and product. Write each as a box and resist the urge to add detail yet; getting the full list of entities right first prevents the far more painful rework of restructuring relationships later.

Not every noun is an entity. Some are attributes - a customer's email is not its own box, it is a field on the customer. The test is whether the thing has its own identity and its own attributes worth storing separately. A customer has a name, an address, and many orders, so it is an entity; an email is a single value belonging to one customer, so it is an attribute. Getting this distinction right is the core judgment of data modeling, and it is easier to see once the candidates are laid out as boxes in the editor at /diagrams.

Add attributes and choose keys

Once the entities are placed, fill each with its attributes - the individual facts you store about it. A customer entity might hold a name, an email, and a created date; an order might hold an order number, a status, and a total. Keep attributes atomic: store a first name and last name rather than a single full name if you will ever need them apart, and never cram a list of values into one field. This discipline pays off when you normalize the design later.

Every entity needs a primary key - one attribute, or a combination, that uniquely identifies each row. Most of the time this is a surrogate key, a system-generated id like an auto-incrementing integer or a UUID, which is stable and never changes. Mark it clearly on the diagram, since the ERD tool at /diagram-tools/erd-tool shows a key marker for it. Relationships are then built with foreign keys: an order carries the customer's primary key as a customerId field, which is the foreign key pointing back to the customer that owns it. That single mechanism - a foreign key referencing a primary key - is how every relationship in a relational database is physically made.

Draw the relationships with crow's foot notation

Relationships are the lines between entities, and crow's foot notation is the standard way to annotate them. The symbols at each end of the line encode two things: cardinality (how many) and modality (whether it is optional or mandatory). A single bar means one, a crow's foot - the three-pronged splay that gives the notation its name - means many, a circle means zero or optional, and the combination at each end tells you the full rule. Reading a line from both ends gives you a precise sentence about the relationship.

• One-to-many is the workhorse: one customer has many orders, drawn with a single bar on the customer end and a crow's foot on the order end.
• One-to-one puts a single bar on both ends, used when two entities share a strict pairing, like a user and their profile.
• Many-to-many puts a crow's foot on both ends, like students and courses, and always needs resolving with a junction entity.
• A circle plus a crow's foot means zero-or-many, marking the relationship as optional on that side - a customer may have no orders yet.
• A bar plus a crow's foot means one-or-many, marking it mandatory - an order must contain at least one line item.
• Read every relationship aloud from both ends to check it: one customer places zero or many orders, and each order is placed by exactly one customer.

Resolve many-to-many with a junction table

A raw many-to-many relationship cannot be stored directly in a relational database, because a foreign key holds one value, not a list. When an order contains many products and a product appears on many orders, you resolve the relationship by introducing a junction entity - often called an associative or join table - that sits between them. An OrderItem entity carries a foreign key to the order and a foreign key to the product, and each row records that one specific product is on one specific order. The single many-to-many line becomes two one-to-many lines meeting at the junction.

The junction table is also the natural home for attributes that belong to the relationship rather than to either entity. The quantity of a product on an order, and the price at the time of purchase, live on OrderItem, not on the product or the order alone. Spotting where a relationship needs its own attributes is a sign you have found a junction entity you might otherwise have missed. Once your ERD is complete, keep learning with the companion guides on database design at /guides/database-design and the Mermaid ER diagram tutorial at /guides/mermaid-er-diagram-tutorial, and see the database-design use case at /diagram-tools/use-cases/database-design for worked examples.