Perché le relazioni esistono
Un database raramente vive di una sola tabella. Il mondo reale è fatto di connessioni: un cliente effettua degli ordini, uno studente si iscrive a più corsi, un libro è scritto da uno o più autori. Il modello relazionale cattura queste connessioni tramite le relazioni tra entità, rappresentate nel diagramma ER e poi tradotte in tabelle collegate da chiavi esterne.
I tre tipi di cardinalità
La cardinalità è il “numero” che appare su ciascun lato di una relazione ER. Esistono tre combinazioni fondamentali:
| Tipo | Simbolo | Significato | Esempio reale |
|---|---|---|---|
| 1:1 | |—| | Una istanza di A è associata a una sola istanza di B, e viceversa | PERSONA — PASSAPORTO |
| 1:N | |—< | Una istanza di A è associata a molte istanze di B, ma ogni B appartiene a un solo A | CLIENTE — ORDINI |
| N:M | >—< | Molte istanze di A si associano a molte istanze di B, e viceversa | STUDENTE — CORSI |
Per leggere la cardinalità pensa sempre dal punto di vista di una singola istanza: “Un cliente può avere quanti ordini?” → molti → lato N. “Un ordine appartiene a quanti clienti?” → uno solo → lato 1. Risultato: relazione 1:N.
Relazione 1:1 — PERSONA e PASSAPORTO
Ogni persona ha al massimo un passaporto, e ogni passaporto appartiene a una sola persona. Questo tipo di relazione è meno comune: spesso indica che le due entità potrebbero essere unite in una sola tabella. Si mantengono separate quando le informazioni hanno cicli di vita diversi o accessi distinti.
Relazione 1:N — CLIENTE e ORDINE
Un cliente può effettuare più ordini nel tempo, ma ogni ordine è associato a un solo cliente. È la relazione più frequente nei database aziendali.
Nella relazione 1:N, la chiave esterna va sempre nella tabella sul lato N (il lato “molti”). In questo caso ORDINE ha la colonna id_cli che punta alla PK di CLIENTE.
La chiave esterna (Foreign Key)
Nell’esempio sopra, ORDINE.id_cli è una FK che referenzia CLIENTE.id_cli. Se un ordine contiene un valore di id_cli che non esiste nella tabella CLIENTE, il DBMS rifiuta l’operazione con un errore.
| Concetto | Tabella padre (lato 1) | Tabella figlia (lato N) |
|---|---|---|
| Ruolo | Ha la PK referenziata | Ha la FK che referenzia |
| Esempi | CLIENTE, STUDENTE, PRODOTTO | ORDINE, ESAME, DETTAGLIO_ORDINE |
| Vincolo | PK deve essere unica e NOT NULL | FK può essere NULL (relazione opzionale) o NOT NULL (obbligatoria) |
Relazione N:M e tabella di giunzione
Una relazione N:M non si può implementare direttamente con una sola FK. Il motivo è semplice: se uno studente può essere iscritto a molti corsi e un corso ha molti studenti, non c’è un posto “naturale” in cui mettere la FK. La soluzione è introdurre una tabella di giunzione (anche detta tabella associativa o bridge table).
Attributi di relazione
La tabella di giunzione è anche il posto giusto per gli attributi di relazione: dati che non appartengono né allo studente né al corso in modo indipendente, ma descrivono l’associazione stessa. In questo caso data_iscrizione e voto_finale appartengono all’iscrizione, non allo studente né al corso separatamente.
Ogni volta che vedi una relazione N:M nel diagramma ER, in fase di progettazione logica devi sempre creare una terza tabella. La PK della tabella di giunzione è tipicamente la coppia delle due FK (chiave composta), oppure si aggiunge un id artificiale.
La notazione crow’s foot
La notazione più usata nei software di modellazione (draw.io, Lucidchart, MySQL Workbench) è la crow’s foot (zampa di corvo). Ogni estremità del connettore indica la cardinalità massima e minima.
| Simbolo | Cardinalità | Significato |
|---|---|---|
|—| | Esattamente 1 | Obbligatorio, uno e uno solo |
|—O | Zero o uno | Opzionale, al massimo uno |
|—< | Uno o molti | Almeno uno, obbligatorio |
O—< | Zero o molti | Opzionale, quanti se ne vuole |
Nella notazione min-max invece si scrive esplicitamente il valore minimo e massimo di partecipazione: (0,1), (1,1), (0,N), (1,N). Il primo numero indica se la partecipazione è obbligatoria (1) o facoltativa (0).
Esempio completo: gestione ordini
Vediamo uno schema ER completo con i tre tipi di relazione in un unico contesto realistico:
Il campo prezzo_unitario in DETTAGLIO_ORDINE è un attributo di relazione critico: memorizziamo il prezzo al momento dell’acquisto, non quello attuale del prodotto. Se il prodotto cambia prezzo in futuro, gli ordini storici rimangono corretti. Questo è un caso in cui l’attributo di relazione ha un significato che non potrebbe essere ricavato dalle entità coinvolte.
- 1:1 — ogni istanza di A è associata a una sola istanza di B e viceversa. FK in una delle due tabelle (solitamente la dipendente).
- 1:N — una istanza di A ha molte istanze di B. La FK va sempre nella tabella sul lato N (il lato “molti”).
- N:M — richiede una tabella di giunzione con due FK. Gli attributi di relazione vivono in questa tabella.
- La chiave esterna (FK) garantisce l’integrità referenziale: non possono esistere figli senza padre.
- La notazione crow’s foot indica cardinalità min-max con simboli grafici su ciascun lato del connettore.
- Gli attributi di relazione descrivono proprietà dell’associazione stessa (es. voto, prezzo al momento dell’acquisto) e appartengono alla tabella di giunzione.