Una relazione uno-a-molti in un database si verifica quando ogni record nella tabella A può avere molti record collegati nella tabella B, ma ogni record nella tabella B può avere solo un record corrispondente nella tabella A. Una relazione uno-a-molti in un database è il design di database relazionale più comune ed è al centro del buon design.
Considera la relazione tra un insegnante e i corsi che insegna. Un insegnante può insegnare più corsi, ma il corso non avrebbe lo stesso rapporto con l'insegnante.
Pertanto, per ogni record in una tabella Insegnanti, potrebbero esserci molti record nella tabella Corsi. Questa è una relazione uno-a-molti: un insegnante a più corsi.
Perché è importante stabilire una relazione uno-a-molti
Per rappresentare una relazione uno-a-molti, sono necessarie almeno due tabelle. Vediamo perché.
Forse abbiamo creato una tabella in cui volevamo registrare il nome e i corsi insegnati. Potremmo progettarlo in questo modo:
| Teacher_ID | Nome dell'insegnante | Corso |
|---|---|---|
| Teacher_001 | Carmen | Biologia |
| Teacher_002 | Veronica | Matematica |
| Teacher_003 | Jorge | Inglese |
E se Carmen insegnasse due o più corsi? Abbiamo due opzioni con questo design. Potremmo semplicemente aggiungerlo al record esistente di Carmen, in questo modo:
| Teacher_ID | Insegnante_Nome | Corso |
|---|---|---|
| Teacher_001 | Carmen | Biologia, matematica |
| Teacher_002 | Veronica | Matematica |
| Teacher_003 | Jorge | Inglese |
Il design sopra, tuttavia, non è flessibile e potrebbe causare problemi in seguito quando si tenta di inserire, modificare o eliminare dati.
Rende difficile la ricerca di dati. Questo disegno viola il primo principio di normalizzazione del database, First Normal Form (1NF), che stabilisce che ogni cella di tabella dovrebbe contenere una singola porzione di dati discreti.
Un'altra alternativa di design potrebbe essere quella di aggiungere semplicemente un secondo disco per Carmen:
| Insegnante_ID | Insegnante_Nome | Corso |
|---|---|---|
| Teacher_001 | Carmen | Biologia |
| Teacher_001 | Carmen | Matematica |
| Teacher_002 | Veronica | Matematica |
| Teacher_003 | Jorge | Inglese |
Ciò aderisce a 1NF ma è ancora un progetto di database scadente perché introduce ridondanza e potrebbe gonfiare inutilmente un database molto grande. Ancora più importante, i dati potrebbero diventare incoerenti. Ad esempio, cosa succede se il nome di Carmen è cambiato? Qualcuno che lavora con i dati potrebbe aggiornare il suo nome in un record e non aggiornarlo nel secondo record. Questo design viola la Second Normal Form (2NF), che aderisce a 1NF e deve anche evitare le ridondanze di più record separando sottoinsiemi di dati in più tabelle e creando una relazione tra loro.
Come progettare un database con relazioni uno-a-molti
Per implementare una relazione uno-a-molti nella tabella Insegnanti e Corsi, suddividiamo le tabelle in due e le collegheremo utilizzando una chiave esterna.
Qui, abbiamo rimosso la colonna Corso nella tabella Insegnanti:
| Insegnante_ID | Insegnante_Nome |
|---|---|
| Teacher_001 | Carmen |
| Teacher_002 | Veronica |
| Teacher_003 | Jorge |
Ed ecco la tabella dei corsi. Nota che la sua chiave esterna, Teacher_ID, collega un corso a un insegnante nella tabella Insegnanti:
| Course_ID | Nome del corso | Teacher_ID |
|---|---|---|
| Course_001 | Biologia | Teacher_001 |
| Course_002 | Matematica | Teacher_001 |
| Course_003 | Inglese | Teacher_003 |
Abbiamo sviluppato una relazione tra la tabella Insegnanti e quella dei corsi utilizzando una chiave esterna.
Questo ci dice che sia Biologia che Matematica sono insegnate da Carmen e che Jorge insegna inglese.
Possiamo vedere come questo design evita eventuali ridondanze, consente ai singoli insegnanti di insegnare più corsi e implementa una relazione uno-a-molti.
I database possono anche implementare una relazione uno-a-uno e una relazione molti-a-molti.
