Entity Relationship Diagram: The Complete Guide

An entity relationship diagram (ERD) is a visual map of the data in a system: the things you store, the facts you keep about each one, and how they connect. It turns a database schema into a picture that both engineers and non-technical stakeholders can read. This guide covers the components, symbols, notation styles, the three levels of ERDs, and a real example you can copy straight into your product documentation.

An ERD sits alongside other modeling tools like the data flow diagram and the C4 model, but it answers a different question. A data flow diagram shows how information moves. An entity relationship diagram shows how information is structured and related at rest. If you have ever sketched boxes and lines on a whiteboard to plan a database, you have already drawn a rough ERD.

By the end, you will know how to read any ER diagram, draw your own, and keep it living inside your docs instead of rotting in a slide deck.

What Is an Entity Relationship Diagram?

An entity relationship diagram is a model of the data in a system, shown as a set of entities connected by relationships. It was introduced by Peter Chen in 1976 and remains the standard way to design and communicate a database schema before any tables get built.

Each box in the diagram is an entity, something you store data about, like a Customer or an Order. Lines between boxes show relationships, like "a customer places orders." The result is a blueprint of your database that reads far faster than a wall of CREATE TABLE statements.

Teams reach for an ER diagram in three moments: designing a new schema, onboarding an engineer to an existing one, and reviewing a change before it ships. In every case, the diagram compresses a complex structure into something you can point at during a conversation.

ERD Components: Entities, Attributes, and Relationships

Every entity relationship diagram is built from three core pieces, plus one property that ties them together. Understanding these four ideas is enough to read almost any ERD example you will meet.

• Entities. A thing you store data about. Customers, orders, products, invoices. Drawn as a rectangle. An entity usually becomes a table in the finished database.
• Attributes. The facts you keep about an entity. A Customer has a name, an email, and a signup date. Attributes become columns. One attribute is the primary key, the value that uniquely identifies each row.
• Relationships. How two entities connect. A customer places an order; an order contains products. Drawn as a line, sometimes with a diamond in older notation.
• Cardinality. The rule for how many. One customer can place many orders, but each order belongs to one customer. Cardinality is the number that turns a vague line into a precise constraint.

Cardinality is where most of the meaning lives. The common patterns are one-to-one (one user has one profile), one-to-many (one customer, many orders), and many-to-many (students enroll in many courses, courses hold many students). A one-to-many relationship is by far the most frequent in real schemas.

ERD Symbols and Notation: Chen vs Crow's Foot

Entity relationship diagram symbols are not universal. Two notation styles dominate, and knowing both means you can read any diagram you inherit. Chen notation, the original, uses shapes for everything. Crow's foot notation, now the default in most database tools, encodes cardinality in the shape of the line's endpoint.

Crow's foot is the more common choice today because it is compact and reads well for large schemas. The name comes from the three-pronged symbol that marks the "many" end of a relationship, which looks like a bird's footprint.

In crow's foot notation, the endpoint symbols carry the cardinality. A single bar means "exactly one." A circle means "zero" (optional). The crow's foot means "many." Combine them: a circle plus a crow's foot reads "zero or many," while a bar plus a crow's foot reads "one or many." Once you learn these four marks, every crow's foot ERD becomes readable at a glance.

The 3 Levels of ERD: Conceptual, Logical, Physical

The same database can be drawn at three levels of detail, and the level tells you who the diagram is for. Moving from conceptual to physical is the natural path of a database design project, from a whiteboard sketch to a build-ready spec.

A conceptual ERD is the highest level. It shows entities and how they relate, with no attributes or keys. Customer, Order, Product, and the lines between them. This is the version you draw in a kickoff meeting to agree on scope.

A logical ERD fills in the detail: attributes, primary and foreign keys, and precise cardinality. It stays independent of any specific database, so no data types yet. This is the working document for design reviews.

A physical ERD maps directly to a real database. Table names, column data types, indexes, and constraints all appear. This is what a developer builds from and what a tool like Supabase generates when you introspect an existing schema.

How to Draw an Entity Relationship Diagram

Drawing an ERD is mostly deciding what belongs in it before you place a single box. The mechanical part is quick once the thinking is done. Follow these steps in order.

1. Identify the entities. List the nouns your system stores data about. Customer, order, product, payment. Each becomes a rectangle. If a noun is really just a fact about another entity, it is an attribute, not an entity.
2. Add the attributes. For each entity, list what you know about it. Mark the primary key that uniquely identifies each record. Keep attributes atomic; a single "address" field often wants to be street, city, and postcode.
3. Define the relationships. Draw a line between any two entities that connect. Label it with a verb: a customer "places" an order, an order "contains" products.
4. Set the cardinality. For each relationship, decide the numbers on both ends. Can one customer have many orders? Must every order belong to a customer? These rules become your foreign keys and constraints.
5. Resolve many-to-many relationships. A direct many-to-many cannot exist in a relational database. Break it with a junction entity. Students and courses become Student, Course, and Enrollment.
6. Review and refine. Walk the diagram with someone who knows the domain. Missing entities and wrong cardinality surface fast when a second person reads the model aloud.

The discipline here mirrors any good modeling exercise: name the pieces, connect them, then constrain them. Rushing to a physical schema before the logical relationships are clear is the most common way database designs go wrong.

Entity Relationship Diagram Example: An E-Commerce Schema

Theory clicks once you see a real ERD example. Below is a small e-commerce schema written in Mermaid syntax, the text-based diagram format that renders in GitHub, Docusaurus, and most modern docs platforms. It models customers, orders, order line items, and products, the backbone of any online store.

erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ ORDER_ITEM : contains
    PRODUCT ||--o{ ORDER_ITEM : "appears in"
    CUSTOMER {
        int customer_id PK
        string name
        string email
        date created_at
    }
    ORDER {
        int order_id PK
        int customer_id FK
        date order_date
        string status
    }
    ORDER_ITEM {
        int order_item_id PK
        int order_id FK
        int product_id FK
        int quantity
        decimal unit_price
    }
    PRODUCT {
        int product_id PK
        string name
        decimal price
        int stock_qty
    }

Read the relationship lines from left to right. CUSTOMER ||--o{ ORDER says one customer places zero or many orders: the double bar means "exactly one" on the customer side, and the circle-plus-crow's-foot means "zero or many" on the order side. ORDER ||--|{ ORDER_ITEM says one order contains one or many line items, because an order with no items makes no sense.

The ORDER_ITEM entity is doing quiet but important work. It is a junction entity that resolves the many-to-many relationship between orders and products. One order holds many products, and one product appears in many orders, so a bridge table sits between them, carrying the quantity and price for each line. This is exactly the many-to-many resolution from step five above, shown in practice.

Notice the PK and FK markers. Primary keys uniquely identify each row; foreign keys point at another entity's primary key and are what the relationship lines actually represent in a real database. Every crow's foot in the diagram corresponds to a foreign key in the schema.

When to Use an Entity Relationship Diagram

An ERD is worth drawing whenever the shape of your data matters to more than one person. A few situations call for one almost every time.

• Designing a new database. Model entities and relationships before writing migrations. Fixing a schema on paper costs minutes; fixing it in production costs weeks.
• Onboarding engineers. A new hire understands a database far faster from one ER diagram than from reading dozens of table definitions.
• Reviewing a schema change. Adding a table or relationship? An updated diagram makes the impact obvious in review, especially where it changes cardinality.
• Documenting an existing system. Reverse-engineer an ERD from a live database to give your team a shared reference that the raw SQL never provides.

An ERD is not the right tool for showing process or flow over time. For a sequence of steps across roles, reach for a swimlane diagram instead. For behavior and interactions, the broader family of a UML diagram covers class, state, and sequence models that an ERD does not.

ERDs in Your Documentation

An entity relationship diagram is only useful if the people who need it can find it, and that means it belongs in your documentation, not in a design tool nobody logs into. A diagram exported as a PNG and pasted into a wiki is dead the day your schema changes. The image never updates, and readers quietly start distrusting it.

The fix is to write your ERD as text and render it inside the docs. Because the Mermaid erDiagram example above is plain text, it lives in the same file as the prose that explains it. When the schema changes, you edit a line, and the diagram redraws. It diffs cleanly in code review, so a schema change and its diagram update travel together in one commit.

This is where Docsio fits. Docsio generates a full documentation site from your URL and renders Mermaid natively, so an ERD like the e-commerce example above shows up live on your docs page, not as a stale screenshot. Your data model stays version-controlled next to your API reference and guides, and it updates the moment you edit the code block.

The habit worth building: treat diagrams as code. The same rule that applies to a sequence diagram example applies to your ERD. Text-based, versioned, and rendered in the docs beats a binary image in a folder every time.

Entity Relationship Diagram FAQ

What is an entity relationship diagram?

An entity relationship diagram is a visual model of a database. It shows entities (the things you store data about), their attributes (the facts you keep), and the relationships between them, including cardinality rules like one-to-many. It gives engineers and stakeholders a shared, readable picture of a database schema before any tables are built.

What are the 3 levels of ERD?

The three levels are conceptual, logical, and physical. A conceptual ERD shows only entities and relationships for planning. A logical ERD adds attributes, keys, and cardinality without database-specific detail. A physical ERD adds table names, data types, and constraints, mapping directly to a real database ready for implementation.

How do you draw an ERD diagram?

Identify your entities, list each one's attributes and mark a primary key, then draw labeled relationship lines between connected entities. Set the cardinality on each relationship, resolve any many-to-many links with a junction entity, and review the model with someone who knows the domain to catch missing entities or wrong constraints.

What is an entity relationship diagram for dummies?

Think of an ERD as boxes and lines. Each box is a thing you track, like a customer or an order. Each line shows how two boxes connect, and small symbols on the line say how many, such as one customer having many orders. It is a simple map of what data you store and how it relates.

What is the difference between Chen and crow's foot notation?

Chen notation, the original, uses shapes: rectangles for entities, ovals for attributes, and diamonds for relationships, with numbers marking cardinality. Crow's foot notation puts attributes inside the entity box and encodes cardinality in the line endpoints (bars, circles, and the three-pronged crow's foot). Crow's foot is more compact and preferred for real database design.