Entity-relationship diagram (ERD)
An entity-relationship diagram (ERD) is a visual representation of a database's entities (tables), their attributes, and the relationships between them, used to design and document relational schemas.
Overview
An entity-relationship diagram, introduced by Peter Chen in 1976, models a database as entities (things, which become tables), attributes (properties of an entity, which become columns), and relationships (associations between entities, which become foreign keys or junction tables). ERDs are typically drawn at three levels of increasing detail:
- Conceptual: entities and relationships only, no attributes or keys — a high-level map for discussing scope with stakeholders.
- Logical: adds attributes, primary keys, and cardinality (one-to-one, one-to-many, many-to-many), independent of any specific database technology.
- Physical: adds concrete data types, constraints, and indexes — the blueprint for the actual
CREATE TABLEstatements.
Reading an ERD
Relationships carry cardinality: a customer places many orders (one-to-many), while students and courses relate many-to-many through an enrollments junction table. Crow's-foot notation is the most common way to show this visually, but the underlying idea maps directly to foreign keys in SQL.
Example
A simple logical ERD — one customer places many orders, each order has many order lines, each line references one product — translates directly to:
Copy code
CREATE TABLE customers (
customer_id INTEGER PRIMARY KEY,
name VARCHAR
);
CREATE TABLE orders (
order_id INTEGER PRIMARY KEY,
customer_id INTEGER REFERENCES customers(customer_id),
order_date DATE
);
CREATE TABLE order_lines (
order_id INTEGER REFERENCES orders(order_id),
line_number INTEGER,
product_id INTEGER,
quantity INTEGER,
PRIMARY KEY (order_id, line_number)
);
Each REFERENCES foreign key here is exactly the relationship line an ERD would draw between orders and customers, and between order_lines and orders.
DuckDB angle
DuckDB has no built-in ERD visualizer, but you can inspect a live schema's tables, columns, and foreign keys through information_schema (or DESCRIBE tablename, and duckdb_constraints()), and feed that into any external ERD tool to generate a diagram from an existing DuckDB or MotherDuck database rather than drawing one from scratch.
Related terms
A foreign key links one table to another by referencing its primary key. Learn how foreign keys enforce referential integrity, with SQL syntax, composite key examples, and data warehousing use cases.
data model →A data model is a conceptual representation of how data is structured, organized, and related within a system or database.
relational database →A relational database is a structured collection of data organized into tables with rows and columns.
Cardinality →Cardinality refers to the number of distinct values in a column or dataset, or, in data modeling, the nature of a relationship between two tables (such as one-to-many).
table →A table is a fundamental structure in a relational database that organizes data into rows and columns, similar to a spreadsheet.
Composite key →A composite key is a primary key made up of two or more columns whose combined values uniquely identify a row, used when no single column is unique on its own.
FAQS
A conceptual ERD shows only entities and relationships. A logical ERD adds attributes, keys, and cardinality, independent of any database technology. A physical ERD adds concrete data types and constraints — it's the direct blueprint for CREATE TABLE statements.
A one-to-many relationship becomes a foreign key on the 'many' side pointing to the primary key of the 'one' side. A many-to-many relationship becomes a separate junction (bridge) table with foreign keys to both entities.
