🗄️ Mermaid

Diagramma entità-relazione

Progetta schemi di database che abbiano senso

Apri questo esempio nell’editor Generane uno con l’IA

Che cos’è un Diagramma entità-relazione?

Un diagramma ER mostra le entità di un database, i loro attributi e la cardinalità delle relazioni tra di esse (uno a molti, molti a molti). È il progetto di ogni database relazionale.

I diagrammi entità-relazione stanno bene nella pull request che aggiunge una migrazione e nella prima ora di onboarding, dove il modo più rapido per spiegare un prodotto è spesso il suo modello dei dati. Rendono esplicita la cardinalità: un solo indirizzo per cliente oppure diversi è una regola di business, non un dettaglio. Quello che non contengono è il progetto fisico: niente indici, niente partizionamento, niente pattern di query. Il file di migrazione resta la fonte di verità.

Esempio dal vivo

Codice Mermaid

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
    }

Esempio dal vivo

Quando usarlo

Progettare un nuovo schema di database prima della prima migrazione

Documentare uno schema esistente per i nuovi membri del team

Discutere i modelli di dati con interlocutori non tecnici

Errori frequenti

Cardinalità letta dal lato sbagliato

In CUSTOMER ||--o{ ORDER : places, il || accanto a CUSTOMER significa un cliente per ordine, e la o{ accanto a ORDER significa zero o più ordini per cliente. Ogni marcatore conta la propria entità, vista dall’altro capo.

Una relazione senza etichetta

CUSTOMER ||--o{ ORDER da solo è un errore di parsing: Mermaid si aspetta i due punti. Scrivi : places, oppure : "" quando la relazione è evidente. È di gran lunga l’errore più comune negli erDiagram.

Nomi di entità che contengono spazi

ORDER LINE ||--o{ PRODUCT non crea un’entità chiamata ORDER LINE: il nome viene spezzato allo spazio. Mettilo tra virgolette come "ORDER LINE", oppure usa la convenzione con underscore che il resto dello schema già segue.

Sintassi di base

.mmd

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

CUSTOMER ||--o{ ORDER : places
Ogni relazione ha bisogno di un’etichetta dopo i due punti; scrivi : "" quando non c’è nulla di utile da dire. Metti tra virgolette le etichette con spazi, come in : "ordered in".
ORDER { string id PK decimal total "in cents" }
Gli attributi sono tipo, poi nome, poi eventuali marcatori di chiave (PK, FK, UK, separati da virgola) e un commento tra virgolette. I tipi sono testo libero e non viene validato nulla.
ORDER ||--|{ LINE : contains CUSTOMER }o..o{ PROMO : uses
Una linea continua indica una relazione identificante: il figlio non può esistere da solo. I puntini indicano una relazione non identificante, in cui la chiave esterna è facoltativa.
erDiagram direction LR
La direzione predefinita è dall’alto verso il basso. direction LR distribuisce in orizzontale uno schema largo, cosa che di solito sta in una pagina di documentazione meglio di una colonna alta di entità.

Domande su questo diagramma

Come si leggono i simboli di cardinalità come ||--o{ ?

|| significa esattamente uno, o| zero o uno, }| uno o più, }o zero o più. Quindi CUSTOMER ||--o{ ORDER si legge «un cliente effettua zero o più ordini».

Posso generare un diagramma ER dall’SQL?

Sì — incolla le tue istruzioni CREATE TABLE o descrivi i tuoi dati e l’IA produce il diagramma ER corrispondente con chiavi e relazioni.

Posso tenere un diagramma entità-relazione sotto controllo di versione insieme alle migrazioni?

Sì, ed è il motivo principale per scriverlo come testo. Il diagramma sta accanto alla migrazione, si confronta riga per riga in revisione, e una modifica di schema che nessuno vi ha riportato salta fuori come una modifica mancante.

Un diagramma entità-relazione Mermaid può mostrare indici e vincoli?

No. Mostra entità, tipi degli attributi e i marcatori PK, FK o UK, e nient’altro: niente indici, valori predefiniti, vincoli di check o trigger. Consideralo una mappa dello schema, non una specifica da cui generare un database.

Come modello una relazione molti a molti?

O la disegni direttamente con }o--o{, oppure modelli esplicitamente l’entità di collegamento: STUDENT ||--o{ ENROLMENT e COURSE ||--o{ ENROLMENT. Usa la seconda forma appena la giunzione porta colonne proprie, come una data di iscrizione.

Qual è la differenza tra PK, FK e UK?

PK indica la chiave primaria, FK una chiave esterna che punta a un’altra entità e UK un vincolo di unicità. Mermaid li disegna solo come etichette: non verifica mai che una FK corrisponda a una chiave primaria altrove nel diagramma.

Diagramma entità-relazione o un altro tipo di diagramma?

Diagramma entità-relazione o diagramma delle classi?

Scegli in base a ciò che il lettore sta per fare. Se deve scrivere SQL o una migrazione, dagli entità, chiavi e cardinalità. Se deve scrivere codice applicativo, un diagramma delle classi con metodi ed ereditarietà è più vicino a quello che digiterà davvero.

Diagramma entità-relazione o diagramma di flusso?

Il diagramma entità-relazione risponde a «che cosa viene memorizzato e come è collegato»; il diagramma di flusso risponde a «che cosa succede e in che ordine». I riquadri che sono sostantivi con attributi appartengono al primo; i riquadri che sono verbi appartengono al secondo.

Esplora gli altri tipi di diagrammi

🔀 Diagramma di flusso 💬 Diagramma di sequenza 🧩 Diagramma delle classi 🔄 Diagramma degli stati 📅 Diagramma di Gantt 🥧 Grafico a torta 🧠 Mappa mentale 🌿 Grafo Git 🕰️ Linea temporale 🚶 Percorso utente 🎯 Grafico a quadranti

Crea ora il tuo Diagramma entità-relazione

Descrivilo in linguaggio naturale — l’IA scrive il codice Mermaid per te.

Apri Mermaid Studio