How to Draw an Entity Relationship Diagram | Step-by-Step

An entity relationship diagram uses rectangles for entities, ovals for attributes, and crow’s-foot lines to show how data connects.

Whether you’re designing a new database or documenting one that’s already running, understanding how to draw an entity relationship diagram gives you a clear visual map of the data and how it connects. The process follows a repeatable sequence: define scope, identify entities, add attributes, define relationships, mark cardinality, and refine the layout. Each step builds on the last, and the guide below walks you through every one.

What Is an Entity Relationship Diagram?

An entity relationship diagram (ERD) is a visual model of a database that shows entities, their attributes, and the relationships between them. Database designers, software engineers, and business analysts use ERDs to plan new databases or document existing ones before writing any SQL.

The diagram acts as a shared blueprint. A developer can look at an ERD and know which tables to create, what columns each table needs, and how foreign keys connect them. Without one, missing relationships and inconsistent data structures become much more likely.

The Core Components of an ERD

Every ERD is built from four basic building blocks. Understanding these before you start drawing makes the whole process faster.

Drawing an Entity Relationship Diagram: The Step Order That Works

1. Define the scope

Decide what part of the system you’re modeling before you place a single rectangle. A scope that’s too wide produces a cluttered, hard-to-read diagram. Too narrow, and you’ll miss important connections. Write one sentence describing the boundary — for example, “this ERD covers the order-processing subsystem only.”

2. Identify the entities

List every real-world object or concept the database needs to store information about. Common entities include Customer, Product, Order, Invoice, and Employee. Draw each one as a rectangle and label it with a singular noun. Skip vague or redundant entities — if two labels mean the same thing, merge them.

3. Add attributes

For each entity, list its properties. In Chen notation, attributes appear as ovals connected to the entity by a line. In crow’s-foot notation, attributes are usually listed inside the entity rectangle. Either way, include the primary key (underlined) and any foreign keys that link to other entities. Stick to atomic attributes — one piece of data per field.

4. Define the relationships

Connect the entities with lines and label each relationship with a verb that describes how they interact. A Customer places an Order. A Product appears on an Invoice. In crow’s-foot notation, the line itself carries the verb label. In Chen notation, a diamond sits on the line and holds the verb.

5. Mark the cardinality

The cardinality tells you how many instances of one entity relate to another. The three types — one-to-one, one-to-many, and many-to-many — are the backbone of any ERD. Crow’s-foot notation uses fork marks on the line to show “many” and a single line to show “one.” Most ERD tools, including draw.io and Lucidchart, include crow’s-foot connectors as a built-in shape.

For a detailed walkthrough of each cardinality style and how to apply it, refer to Lucidchart’s complete ERD guide.

6. Organize and refine

Arrange the entities so related ones sit near each other and the lines cross as little as possible. Remove any redundant entities or relationships — if a relationship can be inferred through another path, drop the extra line. Add a title and legend so anyone reading the diagram can interpret the notation without guessing.

When you finish, you should be able to trace a path from any entity to any related entity and clearly see the cardinality at each step.

What Notation Style Should You Use?

ERD notation is not fully standardized. Different tools and teams use different visual conventions, and the choice affects how you draw entities, attributes, and relationships. The most common styles are Chen, crow’s foot (IE), and UML, each with strengths for different contexts.

Most database teams use crow’s-foot notation because it maps directly to relational table structures and is supported by the widest range of tools. Mermaid, a popular text-based diagram tool, uses crow’s-foot syntax that is compatible with PlantUML, making it easy to version-control your ERD alongside your code.

Mistakes to Avoid When Drawing an ERD

The most common ERD problems are not technical — they are planning and clarity issues. A missing cardinality mark, a redundant entity, or a cluttered layout can make the diagram harder to read than having no diagram at all.

• Skipping the scope step. Drawing too much or too little wastes time and confuses the team. Define the boundary first.
• Omitting cardinality. A line without “1” or “many” marks tells the reader nothing about how the entities relate. Always include the cardinality on every relationship.
• Adding redundant entities or relationships. If two entities capture the same data, merge them. If a relationship duplicates a path that already exists, drop it.
• Unclear naming. Entity names should be singular nouns. Relationship verbs should describe real actions. “Has” is vague; “assigns” or “contains” is precise.
• Creating a cluttered layout. A diagram with twenty entities crammed into one page and lines running every direction is not useful. Split large models into subject-area diagrams or increase the canvas size.

ERD Drawing Checklist

Finish your diagram by running through this list. If you can tick every box, the ERD is ready for review or implementation.

• Scope defined in one sentence
• All entities named as singular nouns
• Each entity has the correct attributes
• Primary keys marked (underlined)
• Foreign keys present where entities connect
• Relationships labeled with action verbs
• Cardinality shown on every relationship line
• No redundant entities or relationships
• Layout readable with minimal line crossings
• Legend or notation guide included