An Entity Relationship (ER) diagram is a picture of a database: its tables, the columns in each one, and how the tables relate. It's the quickest way to understand a schema you didn't design, or to agree on one before you build it.
The parts of an ER diagram
- Entities (tables): the things you store, such as users, orders and products.
- Attributes (columns): what you store about each, such as email or created_at.
- Keys: the primary key that identifies each row, and foreign keys that point to rows in other tables.
- Relationships: lines between tables showing how they connect.
Reading relationship lines
Relationships describe how many rows on one side match the other:
- One to one: each user has one profile.
- One to many: one customer has many orders. This is the most common.
- Many to many: students and courses. In a real database this needs a joining table in the middle, such as enrolments.
Many diagrams draw this with "crow's foot" notation: a single line for "one" and a three-pronged foot for "many".
How to make an ER diagram
1. List the things you store
Start with nouns from the product: users, workspaces, diagrams, comments. Each usually becomes a table.
2. Add the columns that matter
Begin with the primary key and the fields people talk about. You don't need every column to start a useful discussion.
3. Connect the tables
For each foreign key, draw a line to the table it points to. Ask "how many?" in both directions to get the relationship right.
4. Check for missing joins
Any many-to-many relationship needs a table in the middle. Any table with no lines at all deserves a second look.
An example you can type
In Nodeslate, type a table name and press Enter, then its columns. A column like org_id -> orgs.id creates the relationship for you:
users
email text unique
org_id -> orgs.idTab starts a new table, and users > orgs relates two tables directly.
Try it on the canvasNo account needed.
Make an ER diagram from SQL
If the database already exists, don't redraw it by hand. Paste your CREATE TABLE statements into Import and Nodeslate draws every table, key and relationship. Big schemas fold to keys only, so they stay readable. When you're done, download the diagram back out as SQL. See import and export.
Questions
What's the difference between a logical and a physical ER diagram?
A logical diagram shows entities and relationships in business terms. A physical one shows the real tables, column types and keys of a specific database.
Should every column be on the diagram?
Not always. For discussions, keys and the important columns are enough. For documentation, include everything, and fold large tables so the picture stays readable.