Explicit cardinality
Show required, optional, one, and many constraints on both ends of a relationship.
Database relationship modeling
Create a Mermaid ER diagram online to model database entities, attributes, primary and foreign keys, cardinality, and relationship meaning. Preview the ERD and export it as SVG or PNG.
Start with customers, orders, and line items, then edit keys, attributes, cardinality, and relationship labels while the ERD stays visible.
Build a Mermaid ER diagram online
Changes render automatically in the preview.
A Mermaid ER diagram keeps entities, selected attributes, keys, and relationships in text that can be reviewed beside schema changes and documentation.
Show required, optional, one, and many constraints on both ends of a relationship.
Document the fields relevant to the model and mark primary, foreign, or unique keys.
See the rendered result update as you edit and keep syntax feedback beside the source.
Work in a modern browser without installing Mermaid CLI, a desktop app, or an editor extension.
Move the current source into the full editor for AI generation, repair, sharing, and saved projects.
Model one database concern at a time, then verify that every relationship and key expresses a real data constraint.
List the entities needed to answer the current database design question.
Add only the attributes and keys relevant to relationships, identity, and review.
Connect entities with cardinality symbols that match optionality and multiplicity.
Label each relationship with a short verb that reads naturally between entities.
Check the rendered ERD, then export it or continue in the full editor.
An effective ERD makes ownership, optionality, and cardinality clear without duplicating every database column or implementation detail.
Start from concepts that have their own identity and lifecycle. Avoid turning every field or lookup value into a separate entity.
Check whether each side is optional or required and whether it permits one or many records. The two endpoints together define the constraint.
Include PK, FK, and UK markers when they clarify identity, references, or uniqueness, while leaving unrelated columns out of a focused diagram.
Use an ER diagram for persisted entities, keys, and database cardinality. Use a class diagram for software behavior, interfaces, and inheritance.
The example models customers placing orders that contain line items, with primary, foreign, and unique key annotations.
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ LINE_ITEM : contains
CUSTOMER {
string id PK
string email UK
}
ORDER {
string id PK
string customer_id FK
date created_at
}
LINE_ITEM {
string order_id FK
string sku
int quantity
}Compare ER notations
Compare syntax, relationship notation, database modeling depth, and maintainability for text-based ERDs.
Read the ER diagram comparison →Continue with the general editor, browse this release’s tool directory, or compare the diagram with a related modeling view.
Write Mermaid source, preview the result, and export SVG or PNG.
Open tool →Model classes, attributes, methods, inheritance, and object relationships.
Open tool →Describe states, transitions, events, guards, and lifecycle paths in the browser.
Open tool →It is a browser tool for writing Mermaid erDiagram syntax, previewing entities and relationships, and exporting the ERD as SVG or PNG.
Yes. Mermaid relationship endpoints express one, zero-or-one, one-or-more, and zero-or-more cardinality.
Yes. Attribute definitions can include PK, FK, and UK markers to document key roles.
Usually no. Include columns that explain identity, relationships, constraints, or the design question being reviewed.
Yes. Preview the ERD, then download SVG for scalable documentation or PNG for image-based sharing.
Use a class diagram when methods, interfaces, inheritance, and software responsibilities matter more than persisted data relationships.