Che cos'è una relazione uno-a-uno nella modellazione dei dati? Come si implementa questa relazione in un database? Gli esempi in questo articolo risponderanno a queste domande.
Esistono tre tipi di relazioni tra entità (tabelle) nella modellazione dei dati:
- Relazioni uno-a-molti (indicate anche come 1:M).
- Relazioni molti-a-molti (M:N).
- Relazioni uno-a-uno (1:1).
Il tipo più comune di relazione è una relazione uno-a-molti, in cui un record in un'entità può essere referenziato da più record in un'altra entità. Un altro tipo comune è una relazione molti-a-molti. Questo tipo di relazione viene utilizzato solo nei modelli di dati logici. In un database fisico, deve essere implementato utilizzando relazioni uno-a-molti e una tabella di giunzione.
In questo articolo parleremo del terzo tipo di relazione:la relazione uno-a-uno . Questo è il tipo di relazione meno comune in un modello di dati. Forniremo esempi di relazioni uno-a-uno, mostreremo la notazione per le relazioni uno-a-uno in un diagramma ER e discuteremo in pratica le relazioni uno-a-uno.
Esempi di relazioni uno-a-uno
In primo luogo, che cos'è una relazione uno-a-uno? È una relazione in cui un record in un'entità (tabella) è associato esattamente a un record in un'altra entità (tabella).
Vediamo alcuni esempi di vita reale di relazioni uno-a-uno:
- Paese - Capitale :Ogni paese ha esattamente una capitale. Ogni capitale è la capitale di un solo Paese.
- Persona - le sue impronte digitali . Ogni persona ha un set unico di impronte digitali. Ogni serie di impronte digitali identifica esattamente una persona.
- E-mail - account utente . Per molti siti Web, un indirizzo e-mail è associato esattamente a un account utente e ogni account utente è identificato dal suo indirizzo e-mail.
- Coniuge - coniuge :In un matrimonio monogamo, ogni persona ha esattamente un coniuge.
- Profilo utente - impostazioni utente . Un utente ha un set di impostazioni utente. Un insieme di impostazioni utente è associato esattamente a un utente.
Per chiarezza, mettiamo a confronto questi esempi con relazioni che non sono uno a uno:
- Paese - città: Ogni città si trova esattamente in un paese, ma la maggior parte dei paesi ha molte città.
- Genitore - figlio :ogni bambino ha due genitori, ma ogni genitore può avere molti figli.
- Dipendente - manager :ogni dipendente ha esattamente un supervisore o manager immediato, ma ogni manager di solito supervisiona molti dipendenti.
Denotazione di una relazione uno-a-uno in un diagramma ER
Una relazione uno-a-uno in un diagramma ER è indicata, come tutte le relazioni, con una linea che collega le due entità. La cardinalità "uno" è indicata con una singola linea retta. (La cardinalità "molti" è indicata con il simbolo di una zampa di gallina.)
La relazione uno-a-uno tra paese e capitale può essere denotata in questo modo:
Le rette perpendicolari significano "obbligatorio ”. Questo diagramma mostra che è obbligatorio per una capitale avere un Paese ed è obbligatorio per un Paese avere una capitale.
Un'altra possibilità è che uno o entrambi i lati della relazione siano opzionali . Un lato opzionale è indicato con un cerchio aperto. Questo diagramma dice che esiste una relazione uno-a-uno tra una persona e le sue impronte digitali. Una persona è obbligatoria (le impronte digitali devono essere assegnate a una persona), ma le impronte digitali sono facoltative (una persona potrebbe non avere impronte digitali assegnate nel database).
Relazioni uno-a-uno in un database fisico
Esistono alcuni modi per implementare una relazione uno-a-uno in un database fisico.
Chiave primaria come chiave esterna
Un modo per implementare una relazione uno-a-uno in un database consiste nell'utilizzare la stessa chiave primaria in entrambe le tabelle. Le righe con lo stesso valore nella chiave primaria sono correlate. In questo esempio, la Francia è un country con l'id 1 e la sua capitale è nella tabella capital sotto id 1.
country
| id | nome |
|---|---|
| 1 | Francia |
| 2 | Germania |
| 3 | Spagna |
capital
Tecnicamente, una delle chiavi primarie deve essere contrassegnata come chiave esterna, come in questo modello di dati:
La chiave primaria nella tabella capital è anche una chiave esterna che fa riferimento alla colonna id nella tabella paese . Da capital.id è una chiave primaria, ogni valore nella colonna è univoco, quindi la capitale può fare riferimento al massimo a un paese. Inoltre deve fare riferimento a un paese:è una chiave primaria, quindi non può essere lasciata vuota.
Chiave esterna aggiuntiva con vincolo unico
Un altro modo per implementare una relazione uno-a-uno in un database consiste nell'aggiungere una nuova colonna e trasformarla in una chiave esterna.
In questo esempio, aggiungiamo la colonna country_id nella tabella capital . La capitale con id 1, Madrid, è associata al paese 3, la Spagna.
country
| id | nome |
|---|---|
| 1 | Francia |
| 2 | Germania |
| 3 | Spagna |
capital
| id | nome | country_id |
|---|---|---|
| 1 | Madrid | 3 |
| 2 | Berlino | 2 |
| 3 | Parigi | 1 |
Tecnicamente, la colonna country_id dovrebbe essere una chiave esterna che fa riferimento a id colonna nella tabella country . Dal momento che vuoi che ogni capitale sia associata esattamente a un paese, dovresti rendere la colonna della chiave esterna country_id unico.
Relazioni uno-a-uno in pratica
Poche relazioni uno-a-uno durano
Le relazioni uno-a-uno sono il tipo di relazione meno frequente. Uno dei motivi è che nella vita reale esistono pochissime relazioni uno-a-uno. Inoltre, la maggior parte delle relazioni uno-a-uno sono uno-a-uno solo per un certo periodo di tempo. Se il tuo modello include una componente temporale e acquisisce la cronologia delle modifiche, come molto spesso accade, avrai pochissime relazioni uno a uno.
Una relazione monogama può sciogliersi o uno dei partner può morire. Se modelli la realtà delle relazioni monogame (come matrimoni o unioni civili) nel tempo, probabilmente dovrai modellare il fatto che durano solo per un certo periodo.
Penseresti che una persona e le sue impronte digitali non cambino mai. Ma cosa succede se la persona perde un dito o il dito è gravemente ustionato? Le loro impronte potrebbero cambiare. Non è uno scenario molto frequente; tuttavia, in alcuni modelli potrebbe essere necessario tenerne conto.
Anche qualcosa di apparentemente stabile come i paesi e le loro capitali cambiano nel tempo. Ad esempio, Bonn era la capitale della Germania Ovest (Bundesrepublik Deutschland) dopo la seconda guerra mondiale, quando Berlino faceva parte della Germania dell'Est. Questo è cambiato dopo la riunificazione tedesca; la capitale della Germania (Bundesrepublik Deutschland) è ora Berlino. Se dovresti o meno tenerne conto dipende dalla realtà della tua azienda e dall'applicazione su cui stai lavorando.
Uno scenario 1:1 fattibile:parti opzionali della tabella
Posso pensare a uno scenario fattibile per una vera relazione uno-a-uno:parti opzionali di una tabella. Immagina di avere la tabella utente con i dati dell'utente. La tabella contiene informazioni generali sull'utente, come i nomi degli utenti, gli indirizzi e-mail e le date di registrazione. Contiene anche le impostazioni dell'utente, come il tema del colore o l'accesso automatico per quell'app. Tuttavia, la maggior parte degli utenti non ha alcuna impostazione utente; usano le impostazioni predefinite.
user
| id | nome | data_iscrizione | tema | accesso automatico | |
|---|---|---|---|---|---|
| 1 | Nathanael Talbot | [email protected] | 2020-12-12 | scuro | vero |
| 2 | Talitha Yates | [email protected] | 14-12-2020 | ||
| 3 | Markus Weir | [email protected] | 15-12-2020 | luce | falso |
| 4 | Nathalie Hays | [email protected] | 2020-12-18 | ||
| 5 | Chiesa di Maurizio | [email protected] | 20-12-2020 | ||
| 6 | Arwa Valdez | [email protected] | 21-12-2020 |
Ci sono molti campi vuoti in questa tabella. Puoi dividere l'user tabella in due tabelle:user e user_settings , che contiene informazioni sulle impostazioni degli utenti per coloro che hanno scelto di selezionarle.
user
| id | nome | data_iscrizione | tema | accesso automatico | |
|---|---|---|---|---|---|
| 1 | Nathanael Talbot | [email protected] | 2020-12-12 | scuro | vero |
| 2 | Talitha Yates | [email protected] | 14-12-2020 | ||
| 3 | Markus Weir | [email protected] | 15-12-2020 | luce | falso |
| 4 | Nathalie Hays | [email protected] | 2020-12-18 | ||
| 5 | Chiesa di Maurizio | [email protected] | 20-12-2020 | ||
| 6 | Arwa Valdez | [email protected] | 21-12-2020 |
user_settings
| id_utente | tema | accesso automatico |
|---|---|---|
| 1 | scuro | vero |
| 3 | luce | falso |
La divisione dei dati in due tabelle rende le query sulle tabelle più complesse:è necessario unire i dati di entrambe le tabelle. D'altra parte, l'utente principale tabella è più semplice da gestire.
Ulteriori informazioni sulle relazioni tra database
Una relazione uno-a-uno è una relazione in cui un record in una tabella è associato esattamente a un record in un'altra tabella. Questo tipo di relazione è raro nella vita reale. Se includi il tempo nel tuo modello di dati, molte relazioni uno-a-uno diventano relazioni uno-a-molti o molti-a-molti. Lo scenario più comune per l'utilizzo di una relazione uno-a-uno in un database è la divisione di una tabella in due:una con colonne obbligatorie, l'altra con colonne facoltative.
Se ti è piaciuto questo articolo, dai un'occhiata agli altri articoli sulle relazioni uno-a-molti e molti-a-molti sul nostro blog.
Se sei uno studente che segue lezioni di database, assicurati di creare un account accademico gratuito in Vertabelo, il nostro strumento di disegno di diagrammi ER online. Vertabelo ti consente di disegnare diagrammi ER logici e fisici direttamente nel tuo browser. Supporta PostgreSQL, SQL Server, Oracle, MySQL, Google BigQuery, Amazon Redshift e altri database relazionali. Provalo e scopri com'è facile iniziare!
