Viene stabilita una relazione tra due tabelle di database quando una tabella utilizza una chiave esterna che fa riferimento alla chiave primaria di un' altra tabella. Questo è il concetto alla base del termine database relazionale.
Come funziona una chiave esterna per stabilire una relazione
Una chiave primaria identifica in modo univoco ogni record nella tabella. È un tipo di chiave candidata che di solito è la prima colonna di una tabella e può essere generata automaticamente dal database per garantire che sia univoca. Una chiave esterna è un' altra chiave candidata (non la chiave primaria) utilizzata per collegare un record ai dati in un' altra tabella.
Ad esempio, considera queste due tabelle che identificano quale insegnante insegna quale corso. Qui, la chiave primaria della tabella Courses è Course_ID. La sua chiave esterna è Teacher_ID:
| ID_corso | Nome_corso | ID_insegnante |
|---|---|---|
| Corso_001 | Biologia | Insegnante_001 |
| Corso_002 | Matematica | Insegnante_002 |
| Corso_003 | Inglese | Insegnante_003 |
Puoi vedere che la chiave esterna in Corsi corrisponde a una chiave primaria in Insegnanti:
| ID_insegnante | Nome_insegnante |
|---|---|
| Insegnante_001 | Carmen |
| Insegnante_002 | Veronica |
| Insegnante_003 | Jorge |
Possiamo dire che la chiave esterna Teacher_ID ha aiutato a stabilire una relazione tra le tabelle Corsi e Insegnanti.
Tipi di relazioni tra database
Utilizzando chiavi esterne, o altre chiavi candidate, puoi implementare tre tipi di relazioni tra le tabelle:
Uno a uno
Questo tipo di relazione consente solo un record su ciascun lato della relazione. La chiave primaria si riferisce a un solo record (o nessuno) in un' altra tabella. Ad esempio, in un matrimonio, ogni coniuge ha solo un altro coniuge. Questo tipo di relazione può essere implementata in una singola tabella e quindi non utilizza una chiave esterna.
Uno-a-molti
Una relazione uno-a-molti consente a un singolo record di una tabella di essere correlato a più record di un' altra tabella. Si consideri un'azienda con un database con tabelle Clienti e Ordini.
Un singolo cliente può acquistare più ordini, ma un singolo ordine non può essere collegato a più clienti. Pertanto la tabella Ordini conterrebbe una chiave esterna che corrisponde alla chiave primaria della tabella Clienti, mentre la tabella Clienti non avrebbe alcuna chiave esterna che punta alla tabella Ordini.
Molti-a-molti
Questa è una relazione complessa in cui molti record in una tabella possono collegarsi a molti record in un' altra tabella. Ad esempio, la nostra azienda probabilmente ha bisogno di tabelle Clienti e Ordini e probabilmente ha bisogno anche di una tabella Prodotti.
Anche in questo caso, la relazione tra la tabella Clienti e Ordini è uno a molti, ma considera la relazione tra la tabella Ordini e Prodotti. Un ordine può contenere più prodotti e un prodotto può essere collegato a più ordini poiché più clienti potrebbero inviare un ordine che contiene alcuni degli stessi prodotti. Questo tipo di relazione richiede almeno tre tabelle.
Perché le relazioni tra database sono importanti?
Stabilire relazioni coerenti tra le tabelle del database aiuta a garantire l'integrità dei dati, contribuendo alla normalizzazione del database. Ad esempio, cosa succede se non collegassimo alcuna tabella tramite una chiave esterna e invece combinassimo i dati nelle tabelle Corsi e Insegnanti, in questo modo:
| ID_insegnante | Nome_insegnante | Corso |
|---|---|---|
| Insegnante_001 | Carmen | Biologia, matematica |
| Insegnante_002 | Veronica | Matematica |
| Insegnante_003 | Jorge | Inglese |
Questo progetto non è flessibile e viola il primo principio della normalizzazione del database, First Normal Form, che afferma che ogni cella della tabella dovrebbe contenere un singolo dato separato.
O forse abbiamo deciso di aggiungere un secondo record per Carmen, al fine di rafforzare 1NF:
| ID_insegnante | Nome_insegnante | Corso |
|---|---|---|
| Insegnante_001 | Carmen | Biologia |
| Insegnante_001 | Carmen | Matematica |
| Insegnante_002 | Veronica | Matematica |
| Insegnante_003 | Jorge | Inglese |
Questo è ancora un design debole, che introduce duplicazioni non necessarie e quelle che vengono chiamate anomalie di inserimento dei dati, il che significa che potrebbe contribuire a dati incoerenti. Ad esempio, se un insegnante ha più record, cosa succede se alcuni dati devono essere modificati, ma la persona che esegue la modifica dei dati non si rende conto dell'esistenza di più record? La tabella conterrebbe quindi dati diversi per lo stesso individuo, senza alcun modo chiaro per identificarlo o evitarlo.
La suddivisione di questa tabella in due tabelle, Insegnanti e Corsi, crea la corretta relazione tra i dati e quindi aiuta a garantire la coerenza e l'accuratezza dei dati.
