🗄️ Mermaid

Entiteit-relatiediagram

Ontwerp databaseschema’s die hout snijden

Open dit voorbeeld in de editor Genereer er een met AI

Wat is een Entiteit-relatiediagram?

Een ER-diagram toont database-entiteiten, hun attributen en de kardinaliteit van de relaties ertussen (een-op-veel, veel-op-veel). Het is de blauwdruk van elke relationele database.

ER-diagrammen horen thuis in de pull request die een migratie toevoegt, en in het eerste uur van een onboarding, waar het datamodel vaak de snelste uitleg van een product is. Ze maken kardinaliteit expliciet: één adres per klant of meerdere is een bedrijfsregel, geen detail. Wat ze niet dragen is het fysieke ontwerp — geen indexen, geen partitionering, geen querypatronen. Het migratiebestand blijft de bron van waarheid.

Live voorbeeld

Mermaid-code

erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ ORDER_LINE : contains
    PRODUCT ||--o{ ORDER_LINE : "ordered in"
    CUSTOMER {
      string id PK
      string email UK
    }
    ORDER {
      string id PK
      date created_at
    }

Live voorbeeld

Wanneer gebruik je het

Een nieuw databaseschema ontwerpen vóór de eerste migratie

Een bestaand schema documenteren voor nieuwe teamleden

Datamodellen bespreken met niet-technische stakeholders

Veelgemaakte fouten

Kardinaliteit van de verkeerde kant gelezen

In CUSTOMER ||--o{ ORDER : places betekent de || naast CUSTOMER één klant per bestelling, en de o{ naast ORDER nul of meer bestellingen per klant. Elke markering telt de eigen entiteit, gezien vanaf de andere kant.

Een relatie zonder label

CUSTOMER ||--o{ ORDER op zichzelf is een parsefout: Mermaid verwacht een dubbele punt. Schrijf : places, of : "" als de relatie voor zich spreekt. Dit is veruit de meest voorkomende fout in erDiagram.

Entiteitsnamen met spaties

ORDER LINE ||--o{ PRODUCT maakt geen entiteit met de naam ORDER LINE — de naam wordt bij de spatie gesplitst. Zet hem tussen aanhalingstekens als "ORDER LINE", of gebruik de underscoreconventie die de rest van het schema al volgt.

Basissyntaxis

.mmd

erDiagram
    USER ||--o{ POST : writes
    USER {
      string id PK
      string email
    }

CUSTOMER ||--o{ ORDER : places
Elke relatie heeft een label na de dubbele punt nodig; schrijf : "" als er niets zinnigs te melden valt. Zet labels met spaties tussen aanhalingstekens, zoals : "ordered in".
ORDER { string id PK decimal total "in cents" }
Attributen zijn eerst type, dan naam, daarna optionele sleutelmarkeringen (PK, FK, UK, gescheiden door komma’s) en een commentaar tussen aanhalingstekens. Typen zijn vrije tekst en worden niet gevalideerd.
ORDER ||--|{ LINE : contains CUSTOMER }o..o{ PROMO : uses
Een doorgetrokken lijn is een identificerende relatie: het kind kan niet zelfstandig bestaan. Stippen markeren een niet-identificerende relatie, waarbij de foreign key optioneel is.
erDiagram direction LR
De richting staat standaard van boven naar beneden. direction LR spreidt een breed schema zijwaarts uit, wat meestal beter op een documentatiepagina past dan een hoge kolom entiteiten.

Vragen over dit diagram

Hoe lees ik kardinaliteitssymbolen zoals ||--o{ ?

|| betekent precies één, o| nul of één, }| één of meer, }o nul of meer. CUSTOMER ||--o{ ORDER lees je dus als “één klant plaatst nul of meer bestellingen”.

Kan ik een ER-diagram genereren uit SQL?

Ja — plak je CREATE TABLE-instructies of beschrijf je gegevens en de AI produceert het bijbehorende ER-diagram met sleutels en relaties.

Kan ik een ER-diagram samen met mijn migraties in versiebeheer houden?

Ja, en dat is de belangrijkste reden om het als tekst te schrijven. Het diagram staat naast de migratie, is in de review regel voor regel te diffen, en een schemawijziging die niemand erin verwerkte valt op als een ontbrekende bewerking.

Kan een Mermaid-ER-diagram indexen en constraints tonen?

Nee. Het toont entiteiten, attribuuttypen en PK-, FK- of UK-markeringen, en verder niets: geen indexen, standaardwaarden, checkconstraints of triggers. Behandel het als een kaart van het schema, niet als een specificatie waaruit je een database kunt genereren.

Hoe modelleer ik een veel-op-veelrelatie?

Teken hem rechtstreeks met }o--o{, of modelleer de koppelentiteit expliciet: STUDENT ||--o{ ENROLMENT en COURSE ||--o{ ENROLMENT. Gebruik de tweede vorm zodra de koppeling eigen kolommen draagt, zoals een inschrijfdatum.

Wat is het verschil tussen PK, FK en UK?

PK markeert de primaire sleutel, FK een foreign key die naar een andere entiteit wijst, en UK een uniciteitsconstraint. Mermaid rendert ze puur als labels — het controleert nooit of een FK ergens in het diagram bij een primaire sleutel hoort.

Entiteit-relatiediagram of een ander diagramtype?

Entiteit-relatiediagram of klassediagram?

Kies op basis van wat de lezer gaat doen. Schrijft hij SQL of een migratie, geef hem dan entiteiten, sleutels en kardinaliteiten. Schrijft hij applicatiecode, dan ligt een klassediagram met methoden en overerving dichter bij wat hij daadwerkelijk gaat typen.

Entiteit-relatiediagram of flowchart?

Een ER-diagram beantwoordt “wat wordt opgeslagen en hoe hangt het samen”; een flowchart beantwoordt “wat gebeurt er en in welke volgorde”. Blokken die zelfstandige naamwoorden met attributen zijn horen in een ER-diagram; blokken die werkwoorden zijn horen in een flowchart.

Verken de andere diagramtypen

🔀 Flowchart 💬 Sequentiediagram 🧩 Klassediagram 🔄 Toestandsdiagram 📅 Gantt-grafiek 🥧 Cirkeldiagram 🧠 Mindmap 🌿 Git-graaf 🕰️ Tijdlijn 🚶 User journey 🎯 Kwadrantgrafiek

Maak nu je Entiteit-relatiediagram

Beschrijf het in gewone taal — de AI schrijft de Mermaid-code voor je.

Mermaid Studio openen