Editor di diagrammi ER Mermaid
Un diagramma entità-relazione mostra le tabelle, le loro colonne e il modo in cui si collegano. Va bene quando il tema è lo schema di una base dati e le domande interessanti riguardano chiavi e cardinalità — uno a molti, facoltativo, oppure attraverso una tabella ponte. Per i tipi con comportamento ed ereditarietà è meglio il diagramma delle classi.
Schema ordini normalizzato con tabella ponte
La parte degna di nota è `}o--||` sulla riga d'ordine: è così che si esprime onestamente una relazione molti a molti, attraverso una tabella ponte con colonne proprie, invece di far finta che due tabelle si colleghino direttamente. Conservare il prezzo sulla riga e non solo sul prodotto è esattamente il tipo di decisione che il diagramma dovrebbe rendere visibile. Nota anche che ogni etichetta di relazione è fra virgolette: in italiano non è facoltativo.
erDiagram
CLIENTE ||--o{ ORDINE : "effettua"
ORDINE ||--|{ RIGA_ORDINE : "contiene"
PRODOTTO ||--o{ RIGA_ORDINE : "compare in"
CLIENTE ||--o{ INDIRIZZO : "spedito a"
ORDINE ||--o| FATTURA : "emessa per"
CLIENTE {
int id PK
string email UK "salvata in minuscolo"
string ragione_sociale
string codice_fiscale
datetime creato_il
}
ORDINE {
int id PK
int cliente_id FK
string stato
decimal totale
}
RIGA_ORDINE {
int ordine_id PK, FK
int prodotto_id PK, FK
int quantità
decimal prezzo "prezzo al momento dell'ordine"
}
PRODOTTO {
int id PK
string codice UK
string descrizione
}
INDIRIZZO {
int id PK
int cliente_id FK
string cap
}
FATTURA {
int id PK
string numero UK
decimal imponibile
decimal iva
}Esempi commentati
1. Due entità e una relazione
Ogni relazione ER vuole un'etichetta dopo i due punti — non è facoltativa, a differenza dell'arco di un diagramma di flusso. Si legge come una frase: CLIENTE effettua ORDINE.
erDiagram
CLIENTE ||--o{ ORDINE : "effettua"2. Aggiungere le colonne
Ogni riga di attributo è `tipo nome` ed entrambe le parti sono obbligatorie. `PK`, `FK` e `UK` indicano le chiavi; la stringa fra virgolette in fondo è un commento alla colonna.
erDiagram
CLIENTE ||--o{ ORDINE : "effettua"
CLIENTE {
int id PK
string email UK
string ragione_sociale
}
ORDINE {
int id PK
int cliente_id FK
datetime emesso "in UTC"
}3. Una cardinalità che dice qualcosa
I due segni più vicini a ciascuna entità sono la sua cardinalità. Questo esempio dice che un ordine deve avere almeno una riga, ma che un cliente può non avere alcun ordine: un vincolo reale che lo schema dovrebbe imporre e il diagramma mostrare.
erDiagram
CLIENTE ||--o{ ORDINE : "effettua"
ORDINE ||--|{ RIGA_ORDINE : "contiene"
RIGA_ORDINE }o--|| PRODOTTO : "fa riferimento a"4. Molti a molti attraverso una tabella ponte
Mermaid sa disegnare una relazione molti a molti diretta, ma nello schema non esiste quasi mai: sotto c'è una tabella ponte. Disegnarla è più onesto e lascia spazio alle colonne che appartengono alla relazione stessa.
erDiagram
STUDENTE ||--o{ ISCRIZIONE : "si iscrive a"
CORSO ||--o{ ISCRIZIONE : "erogato tramite"
ISCRIZIONE {
int studente_id PK, FK
int corso_id PK, FK
datetime data_iscrizione
string voto "vuoto fino all'esame"
}
STUDENTE {
int id PK
string cognome
}
CORSO {
int id PK
string codice UK
}5. Relazioni riflessive
Una tabella può mettersi in relazione con sé stessa: una linea gerarchica, un albero di categorie, un thread di commenti. Qui l'etichetta della relazione conta più del solito, perché entrambi i capi sono la stessa entità.
erDiagram
DIPENDENTE ||--o{ DIPENDENTE : "coordina"
DIPENDENTE {
int id PK
int responsabile_id FK "vuoto per la direzione"
string cognome
string ruolo
}Riepilogo della sintassi del diagramma ER
La cardinalità si scrive con due segni a ciascun capo della relazione e si legge dall'interno verso l'esterno. La coppia di sinistra descrive l'entità di sinistra, quella di destra l'entità di destra.
| Sintassi | Significato |
|---|---|
| erDiagram | Apre il diagramma. Distingue maiuscole e minuscole: `erdiagram` non funziona. |
| A ||--o{ B : "etichetta" | Relazione. L'etichetta è obbligatoria. |
| || | Esattamente uno. |
| o| | Zero oppure uno. |
| }| | Uno o più. |
| }o | Zero o più. |
| -- | Relazione identificante — linea continua. |
| .. | Relazione non identificante — linea tratteggiata. |
| A { ... } | Blocco degli attributi dell'entità A. |
| int id PK | Attributo: prima il tipo, poi il nome, poi l'eventuale marcatore di chiave. |
| PK / FK / UK | Chiave primaria, esterna, univoca. |
| int id PK, FK | Più marcatori di chiave, separati da virgola. |
| string email "commento" | La stringa fra virgolette in fondo è un commento alla colonna. |
| A ||--o{ B : "appartiene a" | Le virgolette sono OBBLIGATORIE non appena l'etichetta contiene uno spazio. Senza, si tronca al primo spazio e ogni parola rimasta diventa un'entità fantasma. |
I sei errori che rompono un diagramma ER
L'ER ha la grammatica più severa dei sei tipi: quello che passa in altri diagrammi qui viene respinto apertamente. Ma ha anche un errore silenzioso in cui in italiano si cade con particolare facilità. Tutto riprodotto su Mermaid 11.12.2.
Cosa vedi
Si disegna, l'etichetta è troncata e nel diagramma compaiono entità che non hai scritto
Perché
L'etichetta della relazione contiene uno spazio e non ha le virgolette. È l'errore che in italiano darà più fastidio, perché le nostre espressioni relazionali reggono quasi sempre una preposizione: «appartiene a», «compare in», «spedito a». Misurato: `CLIENTE ||--o{ ORDINE : appartiene a` non segnala alcun errore, accorcia l'etichetta ad «appartiene» e crea un'entità vuota chiamata «a». Con tre parole nascono due entità fantasma. Due tabelle si disegnano come quattro rettangoli e nulla ti avvisa.
Soluzione
Metti fra virgolette ogni etichetta che contenga uno spazio. In italiano vuol dire praticamente sempre; è più facile assumerlo come regola che deciderlo ogni volta.
erDiagram
CLIENTE ||--o{ ORDINE : appartiene aerDiagram
CLIENTE ||--o{ ORDINE : "appartiene a"Cosa vedi
Parse error che finisce con: Expecting 'COLON', 'STYLE_SEPARATOR', got 'NEWLINE'
Perché
Relazione senza etichetta. A differenza dell'arco di un diagramma di flusso, i due punti e l'etichetta sono obbligatori: senza di essi la riga finisce semplicemente troppo presto.
Soluzione
Aggiungi i due punti e un'espressione verbale, fra virgolette se contiene uno spazio.
erDiagram
CLIENTE ||--o{ ORDINEerDiagram
CLIENTE ||--o{ ORDINE : "effettua"Cosa vedi
Parse error che finisce con: got 'UNICODE_TEXT'
Perché
Token di cardinalità non valido. Sono corretti soltanto `||`, `o|`, `}|` e `}o` (e le loro forme speculari); qualunque altra cosa cade. `oo` è il refuso tipico, che nasce dal presupposto che la notazione sia simmetrica.
Soluzione
Usa una delle quattro coppie. `||--o{` — esattamente uno verso zero o più — copre la maggior parte delle chiavi esterne.
erDiagram
CLIENTE ||--oo{ ORDINE : "effettua"erDiagram
CLIENTE ||--o{ ORDINE : "effettua"Cosa vedi
Parse error che finisce con: Expecting 'ATTRIBUTE_WORD', got 'BLOCK_STOP'
Perché
Un attributo ha il nome ma non il tipo. Gli attributi ER si scrivono come `tipo nome`, e il tipo non è facoltativo — cosa che sorprende chi arriva da basi dati senza schema.
Soluzione
Dai un tipo a ogni attributo. Inventalo, se lo schema reale non ce l'ha: `string`, `int`, `json`.
erDiagram
CLIENTE {
email
}erDiagram
CLIENTE {
string email
}Cosa vedi
Parse error che finisce con: Expecting 'NON_IDENTIFYING', 'IDENTIFYING', got 'UNICODE_TEXT'
Perché
La linea fra i due marcatori di cardinalità è sbagliata. Deve avere esattamente due caratteri: `--` per una relazione identificante o `..` per una non identificante. Un trattino singolo non è una forma abbreviata di `--`, è un errore di sintassi.
Soluzione
Fra le coppie di cardinalità scrivi `--` oppure `..`.
erDiagram
CLIENTE ||-o{ ORDINE : "effettua"erDiagram
CLIENTE ||--o{ ORDINE : "effettua"Cosa vedi
La cardinalità si disegna, ma descrive il vincolo opposto
Perché
I due segni più vicini a ciascuna entità appartengono proprio a quell'entità, ed è molto facile leggerli al contrario. `CLIENTE ||--o{ ORDINE` dice che un cliente ha zero o più ordini. Girala in `CLIENTE }o--|| ORDINE` e stai affermando che ogni cliente appartiene a esattamente un ordine, il che non ha senso — e si disegna senza la minima obiezione.
Soluzione
Leggi dall'interno verso l'esterno: i segni che toccano CLIENTE descrivono quanti clienti ci sono, non quanti ordini.
erDiagram
CLIENTE }o--|| ORDINE : "effettua"erDiagram
CLIENTE ||--o{ ORDINE : "effettua"Note sul disegno
Misurato su Mermaid 11.12.2, la versione che usa questo sito.
La disposizione la dettano le relazioni, non il numero di entità
Una catena di entità collegate una all'altra si disegna come una colonna alta: quaranta entità danno un viewBox di circa 116×7315, contro 116×470 con tre. Ma le stesse quaranta entità collegate a un'unica tabella centrale danno qualcosa di molto più largo e basso. È l'unico tipo di diagramma qui in cui la forma dei tuoi dati cambia la forma dell'immagine più della sua dimensione, quindi uno schema che non ci sta si aggiusta più spesso cambiando quali relazioni disegni che il loro numero.
In italiano quasi ogni etichetta richiede le virgolette
Vale la pena ripeterlo, perché è l'errore silenzioso più costoso di questa pagina. Le etichette di relazione inglesi possono essere di una parola sola — places, contains, references — quindi nella documentazione inglese le virgolette sembrano un ornamento. In italiano quasi tutte reggono una preposizione e senza virgolette si sfaldano. Regola pratica: metti sempre l'etichetta fra virgolette e smetti di pensarci.
I nomi delle entità distinguono maiuscole e minuscole, e gli accenti funzionano
`CLIENTE` e `cliente` sono due entità diverse, e nominarle entrambe in un diagramma dà due rettangoli senza alcun avviso. La convenzione delle maiuscole Mermaid non la impone, ma conviene tenerla proprio perché rende visibile il riferimento accidentale in minuscolo. Le lettere accentate funzionano senza problemi nei nomi di entità e di colonna — `quantità` è verificato — ma conviene decidere in partenza se lo schema porta gli accenti e restare coerenti: metà `QUANTITÀ` e metà `QUANTITA` si sdoppia in silenzio.
La grammatica è la più severa dei sei tipi
Le etichette di relazione sono obbligatorie, i tipi degli attributi anche, e i token di cardinalità formano un insieme chiuso. Rispetto al Gantt, dove si disegna quasi tutto e gli errori tacciono, l'ER cade presto e ad alta voce. È un vantaggio: se un diagramma ER si è disegnato, è abbastanza probabile che sia il diagramma che intendevi — con l'eccezione evidente delle etichette senza virgolette.
Le etichette sono HTML, quindi l'esportazione PNG ridisegna
Le tabelle degli attributi delle entità sono disegnate dentro un `<foreignObject>` nell'SVG, quindi i browser non riescono a rasterizzarle direttamente su un canvas. L'esportazione PNG di questo sito prima restituiva in silenzio un file SVG; ora ridisegna il diagramma con etichette di testo SVG semplice e produce un PNG corretto a piena dimensione, con una composizione appena percettibilmente diversa.
Quando conviene un altro diagramma
Se ti servono ereditarietà, interfacce o metodi, è il diagramma sbagliato: l'ER non ha nessuno di questi concetti. Usa il diagramma delle classi e accetta che modelli il tuo codice, non le tue tabelle.
Se lo schema è grande, il diagramma ER completo diventa un poster da parete che nessuno legge. Disegna le cinque tabelle che riguardano ciò che stai spiegando in quel momento e lascia il resto fuori inquadratura; il diagramma è un argomento, non un inventario.
E se la domanda vera è come i dati fluiscono fra i sistemi e non come sono conservati, risponde un diagramma di flusso con un sottografo per sistema, non un diagramma ER.
Altri tipi di diagramma
Scritto da Dominik Malsch · Ultimo aggiornamento: