How to Draw an ER Diagram: Complete Guide | text2diagram
Learn how to draw an ER diagram with the 6 core ingredients, 4 essential symbols, 3 cardinalities, and 9 rules — then let text2diagram's AI turn plain text into a database schema diagram.
1. What is an ER diagram?
Learning how to draw an ER diagram starts with a small vocabulary of shapes and one central idea: describe the real world as things and the relationships between them. An ER diagram (short for entity-relationship diagram) is a conceptual model that captures the data structure of a system — who or what exists, what facts we record about them, and how they connect.
The ER model was formalized by Peter Chen in 1976 and is still the default language for database design half a century later. Before writing a single CREATE TABLE, most teams sketch the ER diagram first — because relational tables, foreign keys, and join queries all follow the shape of the diagram.
Every ER diagram is built from six core ingredients: entities, attributes, entity sets, keys, entity types, and relationships. The rest of this guide unpacks each one, then shows you how to compose them into readable diagrams.
| Entity | A concrete, distinguishable thing in the world you care about — a specific customer, a specific book, a specific order. Drawn as a rectangle. |
| Attribute | A characteristic of an entity — a customer's name, an email address, a birthdate. Drawn as an oval (in Chen notation) or listed inside the entity box (in modern crow's-foot / Mermaid style). |
| Entity set | The collection of all entities of the same kind — all customers, all books. This is what maps to a table in a relational database. |
| Key | The attribute (or combination) that uniquely identifies an entity within its set. Cannot be null; cannot repeat. Marked with an underline (Chen) or the tag PK (Mermaid). |
| Entity type | The schema of an entity — its name plus the list of attributes. Written as EntityName(attr1, attr2, __key__). This is the type; individual entities are instances. |
| Relationship | The meaningful link between two (or more) entities — a customer places an order, a student enrolls in a course. Drawn as a diamond (Chen) or a line with cardinality markers (crow's-foot / Mermaid). |
2. Why draw an ER diagram?
Three core reasons — each addresses a real pain in day-to-day product / engineering work:
- Design the schema before writing code. A well-drawn ER diagram surfaces which tables you need, which columns each carries, and which foreign keys connect them — before you write a single migration. Fixing schema in a diagram costs seconds; fixing it after 200 rows of code costs hours.
- Compare data reality vs mental model. Drawing what data actually flows through your system next to what you thought would flow surfaces missing links and dangling references — this is how you find orphan records and undocumented dependencies.
- Communicate with non-technical stakeholders. Product managers and business owners understand rectangles and lines. They will not read a
schema.prismafile. An ER diagram lets you have the same conversation with the DBA and the CEO — same picture, same language.
On top of the three "why"s, an ER diagram delivers three concrete benefits:
Organize your thinking. A clean ER diagram forces the author to name every entity, every attribute, and every relationship. Fuzzy concepts stop being fuzzy the moment they enter the diagram — is "customer" the same as "user"? Does an "order" have exactly one "shipping address" or many? The rectangle-and-line grammar refuses to hide the answer.
Catch normalization gaps early. When you draw M:N as a straight line, the missing junction entity stands out. When one entity carries 40 attributes, the need to split it becomes obvious. Cheaper to spot here than in a slow SQL query three months later.
Speed up onboarding. One ER diagram replaces a 20-page schema doc. New team member, DBA, and QA all read the same picture and reach the same conclusion — which saves the awkward "wait, what does that column mean" ping every week.
3. ER Diagram Symbols: The 4 Essentials
ER diagrams have a small, standardized visual vocabulary. Master these 4 shapes and you can read (and write) 90% of ER diagrams in the wild:
| Rectangle | Entity. Every ER diagram is fundamentally a collection of rectangles connected by lines. Use singular nouns (Customer, not Customers) and title-case. Double rectangles denote weak entities — see §6. |
| Oval | Attribute. Ovals hang off entities via lines. Primary keys get an underline — this is the visual signal you can never omit. Modern tools (Mermaid, dbdiagram) collapse ovals into a column list inside the rectangle, but the semantics are identical. |
| Diamond | Relationship. Diamonds sit between two entities and carry a verb label (places, enrolls in, owns). Must always have a cardinality annotation (1:1, 1:N, M:N) on the connecting lines — see §4. Mermaid replaces the diamond with the line itself + endpoint markers. |
| Connecting line | The relationship itself. In Chen notation it is annotated with 1, N, or M. In crow's-foot / Mermaid, the ends of the line carry different symbols: || for exactly-one, o| for zero-or-one, }| for one-or-many, }o for zero-or-many. Read from the entity outward. |
4. ER Diagram Cardinalities: The 3 Fundamentals
Every relationship in an ER diagram, no matter how complex, boils down to one of just three cardinality patterns:
One-to-One (1:1). Exactly one entity on each side. Each employee has exactly one office badge; each badge belongs to exactly one employee. Rare in practice — 1:1 usually collapses into "just add columns to one of the entities" unless you have a strong reason to split (privacy, storage optimization, ownership boundary).
One-to-Many (1:N). One entity on the left connects to many on the right (but each on the right connects back to only one on the left). A customer places many orders, but each order belongs to one customer. This is the most common pattern in real schemas — 80%+ of relationships you'll ever draw are 1:N.
Many-to-Many (M:N). Many on both sides. A student enrolls in many courses; each course has many students. In a relational database, M:N cannot be represented directly — you must introduce a junction entity (e.g. Enrollment) that carries two 1:N relationships. Drawing M:N as a direct line is a schema smell that hides real work.
Choose 1:1 only when the two sides genuinely have separate lifecycles or access patterns. Choose 1:N for the default parent-child relationship. Choose M:N (with junction) when both sides truly stand alone and can pair freely — and remember, the junction entity itself often carries its own attributes (enrollment date, grade, role).
5. The 9 Rules of Well-Drawn ER Diagrams
An ER diagram can be technically correct and still be unreadable. Follow these 9 rules and yours will read like a schema doc, not a puzzle:
- Singular, title-case entity names.
Customer, notCustomersorcustomer. The rectangle represents the concept; pluralizing conflates the type with the set. - Every entity has a primary key. No exceptions. If you can't name a key, you don't have an entity yet — you have an attribute of something else. Mark the key with
PK(Mermaid) or an underline (Chen). - Cardinality on every line. Never draw an unlabeled connection.
1:1,1:N, orM:N— even if it feels obvious, write it down. Diagrams are read by strangers. - Verb-labeled relationships. Relationship diamonds (or lines) carry an action verb:
places,owns,belongs to,references.Order → Customeris meaningless;Order belongs to Customeris not. - No direct M:N lines. Every many-to-many becomes a junction entity plus two 1:N lines. If you drew
Student —M:N— Course, redraw it asStudent —1:N— Enrollment —N:1— Course. The junction gets its own PK (usually composite:(student_id, course_id)). - Foreign keys marked. Attributes that reference another entity's PK carry the
FKtag. Skipping this makes joins invisible; a reader has to guess which columns will end up asJOIN ... ON .... - Consistent attribute typing. Every attribute carries a data type (
string,int,datetime,decimal, ...). Mixing typed and untyped attributes across entities looks careless and blocks downstream code generation. - Group related entities visually. Put
Order,OrderItem,Paymentnear each other. PutUser,UserProfile,Sessionnear each other. Distance on the canvas encodes conceptual distance; use it deliberately. - Weak entities double-boxed. An entity that cannot exist without a parent (e.g.
OrderItemwithout anOrder) is a weak entity — draw its box with a double border and mark its identifying relationship. See §6.
6. How to Draw Complex ER Diagrams: Weak Entities and Composite Attributes
Once an ER diagram has more than ~15 entities it starts to feel like a subway map. Two tools handle the complexity without exploding the canvas:
Weak entities. An entity that cannot exist without a parent is weak. Classic example: OrderItem doesn't make sense without an Order — you can't have "line 3, quantity 2" floating in the database without knowing which order line 3 belongs to. Draw a weak entity with a double-bordered rectangle, connect it to its parent with a double-bordered relationship (the identifying relationship), and give it a partial key (unique only within the parent — e.g. line_number unique within one Order).
Composite and multivalued attributes. Some attributes have internal structure: an Address has street, city, postal_code, country. Rather than flatten it into four ovals hanging off Customer, group them into a composite attribute. Similarly, a Product might have multiple tags — draw tags as a multivalued attribute (double-outlined oval in Chen) or, more commonly in modern schemas, promote it to its own entity ProductTag linked by 1:N.
The rule of thumb: promote to a separate entity the moment (a) the attribute grows its own attributes (a tag with a color and a description isn't just a string anymore), or (b) you find yourself querying "all X with attribute Y" — that query needs an index, and an index needs its own row, and that row deserves its own entity.
Everything above still holds — but the way we draw has changed
Traditional tools (MySQL Workbench, dbdiagram, Lucidchart, draw.io) treat you as a schema-drafter: you place every entity, drag every relationship line, pick every crow's-foot marker. A 20-entity ER diagram costs 30 minutes of mousing, and adding one new relationship means realigning three neighbors.
AI-generated ER diagrams flip this: you describe the domain in plain text — "an e-commerce platform where customers place orders containing products" — and the AI produces the diagram. Layout is delegated to a graph engine. You spend your time on the what (which entities exist, what attributes they carry) — the AI handles the how (positions, line routing, cardinality markers).
The catch: naive AI generation ignores every rule in Section 5. Text2diagram's whole design is to fix that.
7. What is text2diagram? AI ER Diagram Generator
text2diagram is an AI ER diagram generator with two modes: Quick (one prompt, one diagram — best for straightforward domains) and Chat (AI asks 2-3 clarifying questions first — best for schemas with more than 5 entities or any M:N relationships). Every diagram is validated against the 9 rules from Section 5:
- Every entity gets a PK. The generator refuses to emit an entity without a primary key — Rule 2, structurally enforced. If the domain description leaves the key ambiguous, Chat mode asks before drawing.
- M:N auto-expanded to junction entity. When the model detects a many-to-many, it introduces the junction entity automatically (e.g.
EnrollmentbetweenStudentandCourse), and asks whether the junction carries its own attributes (grade, role, timestamp) — Rule 5 encoded as an interactive question. - All cardinalities labelled. Every line renders with the correct Mermaid ER crow's-foot markers (
||--o{,}o--o{, etc.) — Rule 3, encoded as a syntactic sanitizer that rejects any unlabeled relationship.
8. How to Draw an ER Diagram with text2diagram: Prompt Template
The trick to a great AI-generated ER diagram is a well-structured prompt. Here's the template we recommend — copy it into text2diagram's chat mode and fill in the blanks:
Please draw an ER diagram for: <the domain>
Entities:
- <EntityName>:
- PK: <primary key field + type>
- <attribute name>: <type>
- <attribute name>: <type>
- <EntityName>:
...
Relationships:
- <EntityA> <verb> <EntityB> (<cardinality>)
e.g. Customer places Order (1:N)
e.g. Student enrolls in Course (M:N — junction: Enrollment, carries: grade, enrolled_at)
Weak entities (optional):
- <WeakEntity> depends on <ParentEntity>, partial key: <field>
Notation: Mermaid ER (crow's-foot)The template mirrors Sections 3-6 of this article. If you spec out those four sections, text2diagram has enough information to produce a diagram that follows all 9 rules in one shot — no back-and-forth needed.
9. ER Diagram Example 1: Simple E-Commerce Schema
Let's walk through a real prompt. Copy this into text2diagram chat mode:
Please draw an ER diagram for a small e-commerce site.
Entities:
- Customer:
- PK: id (uuid)
- email: string
- name: string
- created_at: datetime
- Order:
- PK: id (uuid)
- FK: customer_id (uuid)
- total: decimal
- status: string
- placed_at: datetime
- Product:
- PK: id (uuid)
- name: string
- price: decimal
- stock: int
Relationships:
- Customer places Order (1:N)
- Order contains Product (M:N — junction: OrderItem, carries: quantity, unit_price)
Notation: Mermaid ERWhat happens after you hit Send:
1. text2diagram's Meta Router detects this is an ER diagram (not flowchart, not sequence).
2. The Extractor pulls out 3 declared entities, 2 relationships, and notes the M:N needs a junction — no ambiguity, no clarification needed.
3. The Planner sees all required slots are filled and proceeds directly to generation.
4. The Generator produces Mermaid ER source with:
- Four entity blocks: Customer, Order, Product, and the auto-created junction OrderItem (Rule 5, M:N expansion)
- Every entity's PK explicitly tagged (Rule 2)
- The FK customer_id in Order and both FKs in OrderItem tagged (Rule 6)
- Cardinalities: Customer ||--o{ Order : "places", Order ||--o{ OrderItem : "contains", Product ||--o{ OrderItem : "listed in" (Rule 3 + Rule 4)
5. Semantic Validator may raise one question (e.g. "should OrderItem have a synthetic PK or a composite (order_id, product_id)?") — click YES to accept the recommended default, NO to override.
10. ER Diagram Example 2: Course Registration System with Weak Entities
More complex — a university course registration system that involves M:N enrollment, weak entities for lecture sessions, and a composite key. Prompt:
Please draw an ER diagram for a university course registration system.
Entities:
- Student:
- PK: student_id (string)
- name: string
- major: string
- year: int
- Course:
- PK: course_code (string, e.g. "CS101")
- title: string
- credits: int
- department: string
- Instructor:
- PK: instructor_id (string)
- name: string
- email: string
Relationships:
- Student enrolls in Course (M:N — junction: Enrollment, carries: enrolled_at, grade, status)
- Instructor teaches Course (M:N — junction: TeachingAssignment, carries: semester, section_number)
Weak entities:
- Session depends on Course (partial key: session_number)
A Course has multiple Sessions across a semester (Session 1, 2, 3, ...).
Session attributes: topic (string), scheduled_at (datetime), room (string).
Notation: Mermaid ER (crow's-foot)Highlights of what text2diagram produces:
- The main diagram has ~7 entities (3 core + 2 junctions + 1 weak entity), staying scannable.
- Enrollment and TeachingAssignment appear as junction entities with their own attributes (Rule 5).
- Session is drawn with a double-bordered rectangle and connected to Course via a double-lined identifying relationship (Rule 9).
- All PKs and FKs are explicitly tagged (Rules 2, 6).
- Entity names are singular and title-case (Rule 1); every attribute has a type (Rule 7).
- Related entities cluster visually — Course sits between Enrollment, TeachingAssignment, and Session because all three connect to it (Rule 8).
You'll notice text2diagram's chat mode may ask one clarification: "Should Session's partial key be session_number alone (unique within a Course) or should it include semester?" — because your prompt doesn't specify whether sessions repeat across semesters. That's the whole point of chat mode: catch the ambiguity you didn't realize was there.
11. Wrapping Up: How to Draw an ER Diagram in 2026
To recap, how to draw an ER diagram in 2026 is a two-part skill:
1. Understand the domain — 6 core ingredients (entity / attribute / entity set / key / entity type / relationship), 4 symbols, 3 cardinalities, 9 rules, weak entities. This part hasn't changed since 1976 and won't change tomorrow. 2. Let AI do the layout — describe the domain in a structured prompt, let text2diagram enforce every rule, expand every M:N into a junction, and hand you a Mermaid ER diagram in seconds.
The old skill (visual schema drafting) becomes optional. The new skill (crisp domain specification) becomes the multiplier. Get the prompt right and the schema writes itself.
Try it now on any domain you've been putting off modeling — you'll be surprised how much clarity comes back to you in 60 seconds. And that is how to draw an ER diagram without opening MySQL Workbench.
FAQ
Will AI-generated ER diagrams have errors?
text2diagram has 15 built-in rules and 4 layers of sanitizers that catch the most common issues — missing PKs, unlabeled cardinalities, direct M:N lines that should have junction entities, weak entities drawn as regular ones. A self-healing Repair Loop retries automatically when the Mermaid parser rejects a diagram. In production the syntactic error rate is under 1%. That said, semantic mistakes — the AI misreading which attribute is a key, or missing a domain-specific constraint — do happen; that's what Chat mode is for.
What formats can I export?
SVG (vector, best for embedding in schema docs), PNG (raster, best for slides and Notion), Mermaid ER source (edit in Mermaid Live, or feed to a schema-to-SQL converter), and Markdown (with the diagram embedded as a code block). Everything is one click from the preview pane.
What's the difference between Chat mode and Quick mode?
Quick generates in one shot from a single prompt — fast, great for domains with fewer than 5 entities and no M:N. Chat asks 1-3 clarifying questions before drawing (typically about junction attributes, weak entity partial keys, or ambiguous cardinality) — slower per turn but catches ambiguity. Rule of thumb: if the domain has any M:N relationship or any weak entity, use Chat.
Is it free? Any usage limits?
Yes, free to use. Anonymous users get 20 generations per day. Logged-in users get 500 per day. No paywall on any feature.
How do I modify the generated ER diagram?
Two ways: (1) tweak your prompt and re-generate — the AI keeps state across the conversation, so incremental edits ('actually, also add a Payment entity linked to Order') work naturally. (2) When the AI presents its assumptions in a Confrontation card, click NO to reject and re-draw. For hand-level edits, export as Mermaid ER source and edit directly — the syntax is straightforward enough that most schema tweaks are one line.
What can I draw besides ER diagrams?
Seven core diagram types are supported: flowchart, sequence, class (UML), ERD, state, mindmap, Gantt — plus an architecture-diagram mode for system diagrams (AWS / K8s / microservices). Each type has its own set of rules and sanitizers tuned for that shape family.