Entity Relationship Diagram Examples: A Visual Guide for Developers

Entity-Relationship diagrams (ERDs) are the universal language of database design. They let you see the full structure of a database at a glance — every table, every column, every relationship — before writing a single line of SQL. But for many developers, the best way to learn how to create ER diagrams is to study concrete, real-world examples.

In this guide, we walk through five practical ER diagram examples across different domains. For each one, we describe the tables, the key columns, and the relationships between them. By the end, you will be able to read any ER diagram fluently and design your own from scratch.

What Is an ER Diagram?

An ER diagram is a visual map of a relational database. It shows entities (tables), attributes (columns), and relationships (foreign keys). Every box in the diagram represents a table; every line connecting two boxes represents a relationship between them. The symbols at each end of the line describe the cardinality — whether the relationship is one-to-one, one-to-many, or many-to-many.

Notation Types: Chen vs. Crow's Foot

Two notations dominate modern ER diagrams. Chen notation, invented by Peter Chen in 1976, uses rectangles for entities, ovals for attributes, and diamonds for relationships. It is academically rigorous but verbose, making large schemas hard to read.

Crow's Foot notation is used by virtually all modern database design tools, including ER Flow. Entities are rectangles with columns listed inside. Relationships are lines with small symbols at each end: a single vertical bar means "one," a crow's foot (three spread lines) means "many," and a circle means "zero." This compact notation makes it easy to map out large schemas on a single canvas.

Example 1: E-Commerce Platform

An e-commerce schema typically revolves around five core tables. The users table stores customer accounts with columns like id, email, password_hash, name, and created_at. The products table holds the catalog: id, name, description, price, stock_quantity, and category_id. The categories table provides a simple hierarchy with id, name, and a nullable parent_id self-referencing foreign key for subcategories.

The orders table links customers to purchases: id, user_id (FK to users), status, total_amount, and created_at. Finally, the order_items junction table captures the line items of each order: id, order_id (FK to orders), product_id (FK to products), quantity, and unit_price. The relationship reads: one user has many orders; one order has many order items; each order item references one product.

Example 2: Blog Platform

A blog schema is a classic teaching example because it demonstrates several relationship types cleanly. The users table stores authors. The posts table has id, user_id (FK), title, slug, body, published_at, and status. A comments table adds id, post_id (FK), user_id (FK), body, and created_at — a one post has many comments relationship. For tagging, a tags table (id, name, slug) and a post_tags junction table (post_id, tag_id) implement a many-to-many relationship between posts and tags.

Example 3: SaaS User Authentication

Modern SaaS applications need more than a users table. A production-grade auth schema typically includes users (id, email, password_hash, email_verified_at, created_at), personal_access_tokens (id, tokenable_id, tokenable_type, name, token, last_used_at, expires_at) for API tokens, and password_reset_tokens (email, token, created_at). For OAuth login, an oauth_accounts table links external provider IDs to local users: id, user_id (FK), provider, provider_id, access_token, refresh_token.

Example 4: Project Management Tool

A project management schema centers on workspaces, projects, and tasks. The workspaces table (id, name, owner_id) is the top-level container. projects (id, workspace_id FK, name, description, status) belong to workspaces. tasks (id, project_id FK, assignee_id FK to users, title, description, status, due_date, position) belong to projects. A workspace_members junction table (workspace_id, user_id, role) implements the many-to-many relationship between users and workspaces with a role column (owner, admin, member) attached to the join.

Example 5: Hospital Management System

Hospital schemas illustrate more complex relationships. patients (id, name, date_of_birth, blood_type, contact_info) store demographic data. doctors (id, user_id FK, specialty, license_number) extend the users table. appointments (id, patient_id FK, doctor_id FK, scheduled_at, status, notes) create a many-to-many bridge between patients and doctors over time. medical_records (id, patient_id FK, doctor_id FK, diagnosis, treatment, recorded_at) store clinical history. prescriptions (id, record_id FK, medication_name, dosage, instructions) belong to medical records.

How to Read an ER Diagram

Start by scanning the table names to understand the domain. Then look at the relationships — trace each line from one table to another and read the cardinality symbols. A line from users to orders with a single bar at the users end and a crow's foot at the orders end reads: "one user has many orders." Finally, examine the column names and types to understand what data is stored. Foreign key columns (user_id, order_id) make relationship columns immediately obvious.

Building ER Diagrams with ER Flow

ER Flow is purpose-built for creating ER diagrams exactly like the ones described in this article. You can add tables visually, define columns with types and constraints, and draw relationships by connecting tables with a drag. The Crow's Foot notation is rendered automatically. When your design is ready, ER Flow generates SQL migration files — so the diagram and the actual database schema are always in sync. Whether you are designing from scratch or reverse-engineering an existing database, ER Flow makes the process fast and collaborative.