Viene stabilita una relazione tra due tabelle del database quando una tabella ha una chiave esterna che fa riferimento alla chiave primaria di un'altra tabella. Questo è il concetto base dietro il termine database relazionale.
Come funziona una chiave estera per stabilire una relazione
Rivediamo le basi delle chiavi primarie e straniere. 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:
| Course_ID | Nome del corso | Teacher_ID |
|---|---|---|
| Course_001 | Biologia | Teacher_001 |
| Course_002 | Matematica | Teacher_001 |
| Course_003 | Inglese | Teacher_003 |
Puoi vedere che la chiave esterna in Corsi corrisponde a una chiave primaria in Insegnanti:
| Teacher_ID | Nome dell'insegnante |
|---|---|
| Teacher_001 | Carmen |
| Teacher_002 | Veronica |
| Teacher_003 | Jorge |
Possiamo dire che la chiave straniera Teacher_ID ha contribuito a stabilire un relazione tra i tavoli Corsi e Insegnanti.
Tipi di relazioni tra database
Usando 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 riguarda solo un 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 implementato in una singola tabella e quindi non utilizza una chiave esterna.
Uno-a-molti: Una relazione uno-a-molti consente a un singolo record in una tabella di essere correlato a più record in un'altra tabella.
Considera un'attività commerciale 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 essere collegati a molti record in un'altra tabella. Ad esempio, la nostra azienda probabilmente ha bisogno non solo delle tabelle Clienti e Ordini, ma probabilmente necessita anche di una tabella Prodotti.
Ancora una volta, la relazione tra la tabella Clienti e Ordini è uno-a-molti, ma si consideri la relazione tra la tabella Ordini e Prodotti. Un ordine può contenere più prodotti e un prodotto può essere collegato a più ordini: diversi clienti potrebbero inviare un ordine che contiene alcuni degli stessi prodotti. Questo tipo di relazione richiede almeno tre tavoli.
Quali sono le relazioni tra database importanti?
Stabilire relazioni coerenti tra le tabelle del database aiuta a garantire l'integrità dei dati, contribuendo alla normalizzazione del database. Ad esempio, se non collegassimo nessuna tabella con una chiave esterna e invece combinassimo semplicemente i dati nelle tabelle Corsi e Insegnanti, in questo modo:
| Teacher_ID | Nome dell'insegnante | Corso |
|---|---|---|
| Teacher_001 | Carmen | Biologia, matematica |
| Teacher_002 | Veronica | Matematica |
| Teacher_003 | Jorge | Inglese |
Questo design è inflessibile e viola il primo principio di normalizzazione del database, First Normal Form (1NF), in base al quale ogni cella di tabella deve contenere una singola porzione di dati discreti.
O forse abbiamo deciso di aggiungere semplicemente un secondo disco per Carmen, al fine di far rispettare 1NF:
| Teacher_ID | Nome dell'insegnante | Corso |
|---|---|---|
| Teacher_001 | Carmen | Biologia |
| Teacher_001 | Carmen | Matematica |
| Teacher_002 | Veronica | Matematica |
| Teacher_003 | Jorge | Inglese |
Questo è ancora un progetto debole, che introduce una duplicazione non necessaria e ciò che viene chiamato anomalie nell'inserimento dei dati , il che significa solo 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 che esistono più record? La tabella conterrà quindi dati diversi per lo stesso individuo, senza alcun modo chiaro per identificarlo o evitarlo.
Rompendo questo tavolo in due tabelle, Insegnanti e Corsi (come visualizzato sopra), crea la corretta relazione tra i dati e quindi aiuta a garantire la coerenza e l'accuratezza dei dati.
