2011-01-20 28 views
11

Questa è probabilmente una domanda di base (stupida) ma quando si ha una relazione uno a uno in un database l'altra tabella ha un ID di chiave esterna (in questo esempio). E in una relazione uno-a-molti la tabella contiene molte chiavi esterne.Differenza tra la relazione uno-a-uno e uno-a-molti nella banca dati

Ma il database non sa se si tratta di una relazione uno-a-uno o uno-a-molti, giusto? Le relazioni che creo in un diagramma ER sono solo per indicare dove dovrebbero essere le chiavi esterne quando si realizzano le tabelle attuali?

Non capisco completamente l'idea delle relazioni, anche se ho letto molti tutorial su questo.

Grazie in anticipo.

risposta

13

In un certo senso, tutte le relazioni di cui parliamo non sono note al, sono costrutti che abbiamo inventato per capire meglio come progettare le tabelle.

La grande differenza in termini di struttura della tabella tra one-to-one e one-to-many è che in uno-a-uno è possibile (ma non necessario) avere una relazione bidirezionale, ovvero la tabella A può avere una chiave esterna nella tabella B e la tabella B può avere una chiave esterna nel record associato nella tabella A. Ciò non è possibile con una relazione uno-a-molti.

Le relazioni one-to-one associano un record in una tabella con un singolo record nell'altra tabella. Le relazioni uno-a-molti associano un record in una tabella con molti record nell'altra tabella.

3

Ho difficoltà a capire quale sia la vera domanda.

L'analisi è per la maggior parte corretta, in quanto se si dispone di un 2 tabelle e tabella2 ha una chiave esterna per la tabella uno, potrebbe essere un uno-a-uno o un molti-a-uno.

La frase "E in una relazione uno-a-molti la tabella contiene molte chiavi esterne."

La tabella del lato 'molti' contiene ancora una colonna che è una chiave esterna, è solo che più di una riga può avere lo stesso valore di chiave esterna (molte righe puntano a un genitore).

Si noti inoltre che è possibile inserire la chiave esterna sul tavolo padre, sul bambino, anziché viceversa. In questo modo, puoi prevenire uno a molti se vuoi farlo. Si noti inoltre che in questo modo, più di un genitore può condividere un figlio, che potrebbe o meno essere ciò che si desidera.

2

L'equivalente a livello di database di 1: 1 rispetto a 1: m sta avendo un indice univoco sulla colonna chiave esterna. Si noti che questo funziona solo per 1: 1, NON 1: 0..1, come null è considerato quando si valuta l'unicità. Esistono soluzioni alternative per questa limitazione, ma è a livello di base.

+0

Per essere precisi è un unico * vincolo * che conta. Un indice è accidentale perché un indice è solo una funzionalità di ottimizzazione delle prestazioni. In un DBMS che segue lo standard SQL (la maggior parte dei DBMS tranne SQL Server e le sue derivate) i valori null sono * ignorati * in un vincolo di unicità: il requisito univoco si applica solo alle righe che non hanno valori null nelle colonne vincolate. – sqlvogel

5

Per abilitare la relazione uno-a-uno è necessario aggiungere un vincolo univoco a chiave esterna. Non è possibile avere due chiavi esterne per ogni tabella poiché sarà impossibile creare record.

+0

Non è un buon progetto, ma sarebbe possibile se fosse veramente un 1: 1 (non 1: 0 ... 1) e si creerebbe una delle tabelle con la chiave della chiave esterna nullable. –

1

beh, hai ragione, questa relazione è importante per te, ma non per db stesso. Quando hai due tabelle, una con le tue informazioni di base e un'altra con le tue informazioni dettagliate .. per entrambe le tabelle sei tu, quindi è una relazione uno a uno, non puoi mappare i tuoi dati a qualcun altro.

Ora aggiungi la terza tabella "città" e uno dei tuoi punti informazioni alla città in cui vivi - questo è un esempio di uno a molti (una città può essere utilizzata e dovrebbe essere utilizzata per molte persone).

one-to-many/one-to-one mostra solo l'interazione delle tue tabelle. E sempre, vuoi "salvare" righe/colonne nella tabella non duplicandole, userai la relazione uno a molti con un'altra tabella. O molti-a-molti :)

0

Supponiamo di avere una tabella con due attributi A e B. Se A è una chiave candidata e B non è quindi la relazione tra A e B è 1 a molti. Se A e B sono chiavi candidate, allora il rapporto è di 1 a 1.

0

determinata tabella A e B se

  1. A e B hanno una stretta relazione 1 a 1
  2. Per ogni esempio B, ci sarà sempre un un'istanza

l'approccio migliore è quello di rendere la chiave primaria di B anche un riferimento A. chiave esterna Questo è anche chiamato "Tabella per tipo di ereditarietà" e la "è" un rapporto. Esistono altri modi per applicare una chiave esterna unica, ma l'utilizzo della chiave primaria rende la relazione chiara nello schema e nei diagrammi ER.

Ovviamente ci sono sempre altri scenari e se il tuo design non soddisfa entrambi i criteri sopra, dovrai usare un altro approccio.

1

Allo stesso modo con l'esempio, un prodotto ha un unico codice prodotto, quindi è uno-a-uno (prodotto < -> ABC123), ma un cliente può acquistare più di un prodotto, quindi è one-to- molte relazioni (persona < - >>> prodotto).

Problemi correlati