Implementazione di una relazione da uno a zero o una in SQL

Diciamo che sto progettando un database per uno scenario in cui esiste una relazione da uno a zero o uno (1-0..1). Per esempio:

• Esiste un insieme di utenti e alcuni utenti possono anche essere clienti .

Quindi, ho creato le due tabelle corrispondenti userse customers, ma ...

... Qual è il modo migliore per rappresentare e implementare questa situazione in una determinata piattaforma SQL? Ho considerato due possibili soluzioni:

1. Nella userstabella, aggiungi la customercolonna che può essere un riferimento a CHIAVE ESTERA customerso un NULLsegno.

2. Nella customerstabella, includere una usercolonna (impostata con un UNIQUEvincolo) che punta alla userstabella.

Ho già posto una domanda simile in alcuni forum, ma la risposta è stata sostanzialmente "qualunque cosa tu abbia bisogno", "qualunque cosa tu ritenga conveniente". Non mi piace questo tipo di risposta. Voglio invece un serio pezzo di teoria del DB, una risposta fondata. Dove posso leggere le relazioni 1-0..1?

Voglio un pezzo serio della teoria dei DB

La moderna teoria relazionale rifiuta i null , che sembrerebbero invalidare immediatamente l'opzione 1. Tuttavia, questo strawman può essere eliminato sostituendo il null predefinito con un valore predefinito, ad esempio un cliente 'fittizio' creato esclusivamente per modellare esplicitamente "non è un cliente" corrispondenza.

Penso che la tua opzione 2 sia la più teoricamente valida perché, a differenza dell'opzione modificata 1, le relazioni possono essere nella sesta forma normale (6NF), essendo una forma normale che unisce la proiezione e la forma normale più alta raggiungibile.

Ho anche sentito parlare di una regola empirica di progettazione che afferma che una relazione dovrebbe modellare OGNI entità o la relazione tra entità ma mai entrambe, il che mi sembra sensato. Ancora una volta, ciò favorirebbe l'opzione 2. Tuttavia, ho sentito parlare di questa regola empirica molti anni fa, non ricordo dove e non posso offrire basi teoriche serie (tranne 6NF come menzionato sopra).

Ti è stata data in parte la risposta corretta. La vera risposta viene dal tuo modello di dati e da come è stato normalizzato. Una chiave è come si arriva alla relazione:

• La customerstabella è composta da un numero di campi considerati per la userstabella che appartengono al concetto di cliente e sono nulli a meno che l'utente non sia anche un cliente (sottotipo di utente). In questo caso la customerstabella eredita la chiave primaria dalla userstabella. (È possibile più sottotipi che possono o meno sovrapporsi).

• La customerstabella è composta da una serie di campi relativi al concetto di cliente, ma non necessariamente al concetto di utente. Il cliente è un tavolo forte e non dipende dal concetto di utente. (La rimozione della userstabella non influirebbe in modo significativo sulla progettazione della tabella dei clienti.) In questo caso la tabella dei clienti ottiene la propria chiave primaria.

Quello che hai è un caso speciale di relazione opzionale da una a molte in cui il limite superiore è 1. Consideralo da entrambe le parti: sarebbe possibile per un utente avere più clienti o un cliente per avere più utenti? In tal caso, dovrai modificare i tuoi dati.

L'aggiunta della user-idchiave esterna alla customerstabella potrebbe essere considerata una scelta migliore in quanto mappa correttamente la relazione tra molti (limite superiore 1) ed evita un campo nullable. Per imporre il limite superiore l'indice di chiave esterna deve essere univoco. Ciò si verificherà automaticamente se la chiave primaria è il user-id.

L'aggiunta di customer-idcome chiave esterna opzionale alla userstabella impone il limite superiore di 1 nella relazione ma inverte la dipendenza.

Hai considerato un approccio un po 'più complesso ma flessibile. La tabella padre è "persona" (o "entità" a seconda della complessità che vuoi essere). Quindi la tabella cliente e la tabella utente hanno ciascuna un FK nella tabella persona. La tabella persona contiene dettagli personali mentre le tabelle cliente e utente contengono solo attributi associati a un utente o un cliente. Spesso indirizzi (e-mail e posta ordinaria), numeri di telefono, ecc. Sono anche rappresentati in tabelle separate con tabelle di mappatura per consentire molte situazioni. Questo è un modello relativamente comune che puoi trovare su numerosi siti di riferimento.