Diagramma entità relazione: cos'è e come si costruisce

Un diagramma entità-relazione (diagramma ER) è il modo con cui si progetta la struttura di un database prima di costruirlo davvero. Secondo GeeksforGeeks, l’ER model è “a conceptual model for designing a database”: un livello di ragionamento a monte delle tabelle, dove si decide cosa tracciare e come collegarlo, non ancora come immagazzinarlo fisicamente.

Un diagramma ER non è un algoritmo che risolve un problema passo dopo passo, ma il ragionamento che lo produce è simile: scompone un dominio complesso — pensato in astratto, come racconta l’algoritmo — in pezzi più piccoli e collegati tra loro. Anche i siti scritti in JavaScript o in PHP, dietro le quinte, appoggiano su un database che a monte è stato pensato proprio con un diagramma di questo tipo. Per una panoramica più generale su cosa sia un database e sui suoi tipi, il Recap sul DBMS è il punto di partenza; questo Recap si concentra invece sulla tecnica per progettarlo prima di scriverlo.

I tre elementi di base

Un diagramma ER si costruisce con tre elementi. Visual Paradigm li definisce così: un’entità è “a definable thing or concept within a system”, cioè una persona o un ruolo (per esempio uno Studente), un oggetto (una Fattura), un concetto (un Profilo) o un evento (una Transazione). GeeksforGeeks fa un esempio concreto: Studente, Corso o Azienda sono entità.

Un attributo, sempre secondo Visual Paradigm, è “a property or characteristic” dell’entità che lo possiede: GeeksforGeeks fa gli esempi di StudentID, CourseName o EmployeeEmail. E una relazione, per finire, è il collegamento che segnala che due entità sono associate tra loro — l’esempio più semplice, di nuovo da GeeksforGeeks, è “Student enrolls in a Course”: lo Studente si iscrive al Corso.

La cardinalità: quante istanze si collegano

Definire entità, attributi e relazioni non basta: bisogna anche dire quante istanze di un’entità si collegano a quante istanze dell’altra. È la cardinalità, che Visual Paradigm descrive come il numero di occorrenze possibili di un’entità associate al numero di occorrenze di un’altra.

GeeksforGeeks propone tre esempi minimi, uno per ciascun tipo di cardinalità:

Tipo	Esempio	Significato
Uno a uno (1:1)	Persona e passaporto	Una persona ha un solo passaporto, e un passaporto è di una sola persona
Uno a molti (1:N)	Reparto e medici	Un reparto può avere più medici, ma ogni medico appartiene a un solo reparto
Molti a molti (N:M)	Dipendenti e progetti	Un dipendente lavora su più progetti, e un progetto ha più dipendenti

Il manuale di database design di Watt ed Eng aggiunge un dettaglio pratico: la relazione uno a molti “should be the norm in any relational database design”, cioè è il tipo più comune nei database relazionali. La stessa fonte segnala anche che una relazione molti a molti “cannot be implemented as such in the relational model”: non si traduce direttamente in un’unica tabella, e richiede un passaggio ulteriore in fase di conversione verso il database vero e proprio.

Le due notazioni: Chen e Crow’s Foot

Per disegnare entità, attributi, relazioni e cardinalità esistono simboli standard, raccolti in due notazioni diverse.

La notazione di Chen, secondo GeeksforGeeks, usa forme geometriche distinte per ogni elemento:

Simbolo	Significato
Rettangolo	Entità
Rettangolo doppio	Entità debole
Ovale	Attributo
Ovale sottolineato	Attributo chiave
Ovale doppio	Attributo multivalore
Ovale tratteggiato	Attributo derivato
Rombo	Relazione

La notazione Crow’s Foot (il “piede di corvo”), spiegata da freeCodeCamp, rappresenta invece la cardinalità con dei segni alla fine delle linee che collegano le entità:

Simbolo	Significato
Cerchio	Zero
Barra singola	Uno
Piede di corvo (tre linee)	Molti
Cerchio + piede di corvo	Zero o molti
Barra + piede di corvo	Uno o molti
Due barre	Uno e uno solo

Visual Paradigm conferma lo stesso principio da un’altra angolazione: “In an ER diagram, cardinality is represented as a crow’s foot at the connector’s ends”. freeCodeCamp fa anche due esempi minimi: in un rapporto Insegnante-Corso, un insegnante insegna “one and only one” corso, mentre un corso è insegnato da “one or many” insegnanti; in un rapporto Cliente-Pizza, un cliente ordina “zero or many” pizze, e una pizza è ordinata da “zero or many” clienti.

Come si costruisce: un esempio passo passo

Esempio pratico: immaginiamo di dover disegnare un pezzo di database per un’università.

Primo passaggio: si individuano le entità coinvolte. Qui servono uno Studente, un Corso e un Docente.

Secondo passaggio: si elencano gli attributi di ciascuna entità. Lo Studente ha uno StudentID, il Corso ha un CourseName.

Terzo passaggio: si individuano le relazioni tra le entità. Uno Studente si iscrive a un Corso. Un Docente insegna un Corso — per esempio, come racconta lo stesso manuale, il professor Ba insegna il corso di Database Systems.

Quarto passaggio: si assegna la cardinalità a ogni relazione, scegliendo se disegnarla con Chen o con Crow’s Foot. Una relazione può essere uno a uno, uno a molti o molti a molti, a seconda di cosa succede davvero tra le due entità.

Quinto passaggio: si disegna. Con la notazione di Chen, un rettangolo per ogni entità, un ovale per ogni attributo collegato al suo rettangolo, un rombo per ogni relazione. Con Crow’s Foot, le entità restano in un riquadro con gli attributi elencati dentro, e sono le linee che le collegano — con cerchio, barra o piede di corvo alle estremità — a raccontare la cardinalità.

Un diagramma così, con le sue entità, i suoi attributi e le sue relazioni cardinalizzate, è il punto di partenza da cui poi si scrivono davvero le tabelle del database: per i concetti generali di cosa sia un database e come funzioni, resta valido il rimando al Recap sul DBMS.