C'è mai un momento in cui ha senso usare una relazione di database 1: 1?

Stavo pensando l'altro giorno alla normalizzazione, e mi è venuto in mente, non riesco a pensare a un momento in cui ci dovrebbe essere una relazione 1: 1 in un database.

• Name:SSN? Li avrei sullo stesso tavolo.
• PersonID:AddressID? Ancora una volta, lo stesso tavolo.

Posso trovare un milione di esempi di 1: molti o molti: molti (con appropriate tabelle intermedie), ma mai un 1: 1.

Mi sto perdendo qualcosa di ovvio?

Una relazione 1: 1 indica in genere che hai partizionato un'entità più grande per qualche motivo. Spesso è a causa di motivi di prestazioni nello schema fisico, ma può accadere anche nel lato logico se si prevede che un grosso blocco di dati sia "sconosciuto" allo stesso tempo (nel qual caso si ha un 1: 0 o 1: 1, ma non di più).

Come esempio di una partizione logica: hai dati su un dipendente, ma esiste un insieme più ampio di dati che devono essere raccolti, se e solo se scelgono di avere una copertura sanitaria. Vorrei conservare i dati demografici relativi alla copertura sanitaria in una tabella diversa sia per semplificare il partizionamento della sicurezza sia per evitare di trascinare quei dati in query non correlate all'assicurazione.

Un esempio di partizione fisica potrebbe essere lo stesso dato ospitato su più server. Potrei conservare i dati demografici di copertura sanitaria in un altro stato (dove si trova l'ufficio risorse umane, ad esempio) e il database primario può collegarsi ad esso solo tramite un server collegato ... evitando di replicare i dati sensibili in altre posizioni, ma rendendoli disponibili per (supponendo qui rare) domande che ne hanno bisogno.

Il partizionamento fisico può essere utile ogni volta che si hanno query che richiedono sottoinsiemi coerenti di un'entità più grande.

Uno dei motivi è l'efficienza del database. Avere una relazione 1: 1 ti consente di dividere i campi che saranno interessati durante un blocco di riga / tabella. Se la tabella A ha una tonnellata di aggiornamenti e la tabella b ha una tonnellata di letture (o ha una tonnellata di aggiornamenti da un'altra applicazione), il blocco della tabella A non influirà su ciò che sta accadendo nella tabella B.

Altri sollevano un buon punto. La sicurezza può anche essere una buona ragione a seconda di come le applicazioni ecc. Stanno colpendo il sistema. Tenderei ad adottare un approccio diverso, ma può essere un modo semplice per limitare l'accesso a determinati dati. È davvero facile negare l'accesso a un determinato tavolo in un pizzico.

Il mio post sul blog a riguardo.

Sparseness. La relazione dati può essere tecnicamente 1: 1, ma non devono esistere righe corrispondenti per ogni riga. Quindi, se hai venti milioni di righe e esiste un insieme di valori che esiste solo per lo 0,5% di esse, i risparmi di spazio sono enormi se spingi quelle colonne in una tabella che può essere scarsamente popolata.

La maggior parte delle risposte di alto livello forniscono utili motivi di ottimizzazione e ottimizzazione del database per le relazioni 1: 1, ma voglio concentrarmi solo su esempi "allo stato brado" in cui si verificano naturalmente relazioni 1: 1.

Si noti una caratteristica importante dell'implementazione del database della maggior parte di questi esempi: nessuna informazione storica viene conservata sulla relazione 1: 1. Cioè, queste relazioni sono 1: 1 in un dato momento. Se il progettista del database desidera registrare nel tempo le modifiche apportate ai partecipanti alla relazione, le relazioni diventano 1: M o M: M; perdono la loro natura 1: 1. Con ciò capito, ecco qui:

• Relazioni "Is-A" o supertipo / sottotipo o ereditarietà / classificazione: Questa categoria è quando un'entità è un tipo specifico di un'altra entità. Ad esempio, potrebbe esserci un'entità Dipendente con attributi che si applicano a tutti i dipendenti e quindi entità diverse per indicare tipi specifici di dipendente con attributi univoci per quel tipo di dipendente, ad esempio Dottore, Ragioniere, Pilota, ecc. Questo progetto evita più null poiché molti dipendenti non avrebbero gli attributi specializzati di un sottotipo specifico. Altri esempi in questa categoria potrebbero essere Prodotto come supertipo e Prodotto manifatturiero e manutenzione Fornire come sottotipi; Animale come supertipo e Cane e gatto come sottotipi; ecc. Si noti che ogni volta che si tenta di mappare una gerarchia di ereditarietà orientata agli oggetti in un database relazionale (come in un modello relazionale ad oggetti), questo è il tipo di relazione che rappresenta tali scenari.

• Rapporti "capo" , come manager, presidente, presidente, ecc., In cui un'unità organizzativa può avere un solo capo e una persona può essere capo di una sola unità organizzativa. Se si applicano queste regole, allora hai una relazione 1: 1, come un manager di un dipartimento, un CEO di un'azienda, ecc. Le relazioni "Boss" non si applicano solo alle persone. Lo stesso tipo di relazione si verifica se esiste un solo negozio come la sede di una società, o se solo una città è la capitale di un paese, per esempio.

• Alcuni tipi di scarsa allocazione delle risorse , ad esempio un dipendente possono essere assegnati a una sola auto aziendale alla volta (ad esempio un camion per camionista, un taxi per conducente di taxi, ecc.). Un collega mi ha dato questo esempio di recente.

• Matrimonio (almeno nelle giurisdizioni legali in cui la poligamia è illegale): una persona può essere sposata con un'altra persona alla volta. Ho preso questo esempio da un libro di testo che lo utilizzava come esempio di una relazione unaria 1: 1 quando un'azienda registra matrimoni tra i suoi dipendenti.

• Prenotazioni corrispondenti : quando una prenotazione unica viene effettuata e quindi soddisfatta come due entità separate. Ad esempio, un sistema di autonoleggio potrebbe registrare una prenotazione in un'entità, quindi un noleggio effettivo in un'entità separata. Sebbene una simile situazione possa in alternativa essere progettata come un'entità, potrebbe avere senso separare le entità poiché non tutte le prenotazioni sono soddisfatte e non tutti i noleggi richiedono prenotazioni ed entrambe le situazioni sono molto comuni.

Ripeto l'avvertimento che ho fatto in precedenza che la maggior parte di questi sono relazioni 1: 1 solo se non vengono registrate informazioni storiche. Quindi, se un dipendente cambia il suo ruolo in un'organizzazione, o un manager si assume la responsabilità di un dipartimento diverso, o un dipendente viene riassegnato un veicolo, o qualcuno è vedovo e si risposa, allora i partecipanti alla relazione possono cambiare. Se il database non memorizza alcuna cronologia precedente relativa a queste relazioni 1: 1, rimangono relazioni legittime 1: 1. Ma se il database registra informazioni storiche (come l'aggiunta di date di inizio e fine per ogni relazione), praticamente tutte si trasformano in relazioni M: M.

Vi sono due notevoli eccezioni alla nota storica: in primo luogo, alcune relazioni cambiano così raramente che normalmente le informazioni storiche non verrebbero memorizzate. Ad esempio, la maggior parte delle relazioni IS-A (ad es. Tipo di prodotto) sono immutabili; cioè, non possono mai cambiare. Pertanto, il punto di riferimento storico è controverso; questi sarebbero sempre implementati come relazioni 1: 1 naturali. In secondo luogo, il negozio di relazioni prenotazione-noleggio risale separatamente, poiché la prenotazione e il noleggio sono eventi indipendenti, ognuno con le proprie date. Poiché le entità hanno le proprie date, piuttosto che la relazione 1: 1 stessa abbia una data di inizio, queste rimarrebbero come relazioni 1: 1 anche se le informazioni storiche sono archiviate.

La tua domanda può essere interpretata in diversi modi, a causa del modo in cui la hai formulata. Le risposte mostrano questo.

Ci possono essere sicuramente relazioni 1: 1 tra elementi di dati nel mondo reale. Nessuna domanda al riguardo. La relazione "è un" è generalmente uno a uno. Un'auto è un veicolo. Un'auto è un veicolo. Un veicolo potrebbe essere una macchina. Alcuni veicoli sono camion, nel qual caso un veicolo non è un'auto. Diverse risposte affrontano questa interpretazione.

Ma penso che quello che stai veramente chiedendo sia ... quando esistono relazioni 1: 1, le tabelle dovrebbero mai essere divise? In altre parole, dovresti mai avere due tabelle che contengono esattamente le stesse chiavi? In pratica, la maggior parte di noi analizza solo le chiavi primarie e non altre chiavi candidate, ma questa domanda è leggermente diversa.

Le regole di normalizzazione per 1NF, 2NF e 3NF non richiedono mai la scomposizione (divisione) di una tabella in due tabelle con la stessa chiave primaria. Non ho capito se mettere uno schema in BCNF, 4NF o 5NF possa mai portare a due tabelle con le stesse chiavi. In cima alla mia testa, ho intenzione di indovinare che la risposta è no.

Esiste un livello di normalizzazione chiamato 6NF. La regola di normalizzazione per 6NF può sicuramente comportare due tabelle con la stessa chiave primaria. 6NF ha il vantaggio rispetto a 5NF che NULLS può essere completamente evitato. Questo è importante per alcuni, ma non per tutti, i progettisti di database. Non mi sono mai preso la briga di mettere uno schema in 6NF.

In 6NF i dati mancanti possono essere rappresentati da una riga omessa, anziché da una riga con un NULL in qualche colonna.

Esistono motivi diversi dalla normalizzazione per la divisione delle tabelle. A volte le tabelle divise producono prestazioni migliori. Con alcuni motori di database, puoi ottenere gli stessi vantaggi prestazionali partizionando la tabella invece di dividerla effettivamente. Ciò può avere il vantaggio di mantenere la progettazione logica di facile comprensione, fornendo al motore di database gli strumenti necessari per accelerare le cose.

Li uso principalmente per alcuni motivi. Uno è la differenza significativa nella velocità di modifica dei dati. Alcune delle mie tabelle potrebbero avere tracce di controllo in cui tracciamo le versioni precedenti dei record, se mi interessa solo tenere traccia delle versioni precedenti di 5 colonne su 10, suddividendo quelle 5 colonne su una tabella separata con un meccanismo di controllo traccia su di esso è più efficiente. Inoltre, potrei avere dei record (diciamo per un'app di contabilità) che sono solo di scrittura. Non è possibile modificare gli importi in dollari o l'account per cui sono stati utilizzati, se si è commesso un errore, è necessario creare un record corrispondente per cancellare il record errato, quindi creare una voce di correzione. Ho dei vincoli sulla tabella che impongono il fatto che non possono essere aggiornati o eliminati, ma potrei avere un paio di attributi per quell'oggetto che sono malleabili, quelli sono conservati in una tabella separata senza la restrizione alla modifica. Un'altra volta che faccio questo è nelle applicazioni di cartelle cliniche. Esistono dati relativi a una visita che non possono essere modificati dopo la firma e altri dati relativi a una visita che possono essere modificati dopo la firma. In tal caso, dividerò i dati e metterò un trigger sulla tabella bloccata rifiutando gli aggiornamenti alla tabella bloccata quando disconnesso, ma consentendo gli aggiornamenti ai dati su cui il medico non sta firmando.

Un altro poster ha commentato che 1: 1 non è stato normalizzato, non sarei d'accordo con quello in alcune situazioni, in particolare il sottotipo. Supponiamo che io abbia una tabella dei dipendenti e che la chiave primaria sia il loro SSN (è un esempio, salviamo il dibattito se questa è una buona chiave o no per un altro thread). I dipendenti possono essere di diversi tipi, ad esempio temporanei o permanenti e se sono permanenti hanno più campi da compilare, come il numero di telefono dell'ufficio, che non dovrebbe essere nullo solo se type = 'Permanent'. In un 3 ° database di moduli normale la colonna dovrebbe dipendere solo dalla chiave, ovvero dall'impiegato, ma in realtà dipende dall'impiegato e dal tipo, quindi una relazione 1: 1 è perfettamente normale e desiderabile in questo caso. Inoltre impedisce tabelle troppo sparse, se ho 10 colonne che sono normalmente riempite,

Lo scenario più comune a cui riesco a pensare è quando hai BLOB. Supponiamo che tu voglia archiviare immagini di grandi dimensioni in un database (in genere, non il modo migliore per memorizzarle, ma a volte i vincoli lo rendono più conveniente). In genere si desidera che il BLOB si trovi in ​​una tabella separata per migliorare le ricerche dei dati non BLOB.

In termini di pura scienza, sì, sono inutili.

Nei database reali a volte è utile mantenere un campo usato raramente in una tabella separata: per velocizzare le query usando questo e solo questo campo; per evitare blocchi, ecc.

Anziché utilizzare le visualizzazioni per limitare l'accesso ai campi, a volte ha senso mantenere i campi riservati in una tabella separata alla quale solo determinati utenti hanno accesso.

Posso anche pensare a situazioni in cui hai un modello OO in cui usi l'ereditarietà e l'albero delle eredità deve essere mantenuto nel DB.

Ad esempio, hai una classe Bird and Fish che entrambi ereditano da Animal. Nel tuo DB potresti avere una tabella 'Animal', che contiene i campi comuni della classe Animal, e la tabella Animal ha una relazione uno a uno con la tabella Bird e una relazione uno a uno con il Pesce tavolo.

In questo caso, non è necessario disporre di una tabella Animale che contenga molte colonne nullable per contenere le proprietà Bird e Fish, dove tutte le colonne che contengono Fish-data sono impostate su NULL quando il record rappresenta un uccello.

Invece, hai un record nella tabella degli uccelli che ha una relazione uno a uno con il record nella tabella degli animali.

Le relazioni 1-1 sono necessarie anche se hai troppe informazioni. Esiste una limitazione della dimensione del record per ogni record nella tabella. A volte le tabelle sono divise in due (con le informazioni più comunemente richieste nella tabella principale) solo in modo che le dimensioni del record non siano troppo grandi. I database sono anche più efficienti nell'interrogazione se le tabelle sono strette.

È anche un modo per estendere una tabella che è già in produzione con meno rischi (percepiti) rispetto a una modifica "reale" del database. Vedere una relazione 1: 1 in un sistema legacy è spesso un buon indicatore del fatto che i campi sono stati aggiunti dopo la progettazione iniziale.

In SQL è impossibile imporre una relazione 1: 1 tra due tabelle obbligatoria su entrambi i lati (a meno che le tabelle non siano di sola lettura). Ai fini più pratici una relazione "1: 1" in SQL significa in realtà 1: 0 | 1.

L'incapacità di supportare la cardinalità obbligatoria nei vincoli referenziali è una delle gravi limitazioni di SQL. I vincoli "differibili" non contano davvero perché sono solo un modo per dire che il vincolo non viene applicato qualche volta.

Se si utilizzano i dati con uno dei più popolari ORM, è possibile suddividere una tabella in più tabelle in modo che corrispondano alla gerarchia degli oggetti.

Ho scoperto che quando faccio una relazione 1: 1 è totalmente per una ragione sistemica, non per una ragione relazionale.

Ad esempio, ho scoperto che mettere gli aspetti riservati di un utente in 1 tabella e mettere i campi modificabili dell'utente in una tabella diversa consente di scrivere logicamente quelle regole sulle autorizzazioni su quei campi molto più facilmente.

Ma hai ragione, in teoria, le relazioni 1: 1 sono completamente inventate e sono quasi un fenomeno. Tuttavia, logicamente, consente ai programmi e alle ottimizzazioni di semplificare il database.

Il più delle volte, si pensa che i disegni siano 1: 1 finché qualcuno non chiede "bene, perché non può essere 1: molti"? Il divorzio prematuro reciproco dei concetti avviene anticipando questo scenario comune. La persona e l'indirizzo non si legano così strettamente. Molte persone hanno più indirizzi. E così via...

Di solito due spazi oggetti separati implicano che uno o entrambi possono essere moltiplicati (x: many). Se due oggetti erano veramente, veramente 1: 1, anche filosoficamente, allora è più una relazione-is. Questi due "oggetti" sono in realtà parti di un intero oggetto.

informazioni estese necessarie solo in determinati scenari. nelle applicazioni legacy e nei linguaggi di programmazione (come i giochi di ruolo) in cui i programmi sono compilati sopra le tabelle (quindi se la tabella cambia è necessario ricompilare i programmi). Contrassegnare i file può anche essere utile nei casi in cui devi preoccuparti delle dimensioni della tabella.

Più frequentemente è più una costruzione fisica che logica. Viene comunemente utilizzato per partizionare verticalmente una tabella per trarre vantaggio dalla divisione dell'I / O tra dispositivi fisici o altre ottimizzazioni delle query associate alla separazione dei dati a cui si accede meno frequentemente o che devono essere mantenuti più sicuri rispetto al resto degli attributi sullo stesso oggetto (SSN, Stipendio, ecc.).

L'unica considerazione logica che prescrive una relazione 1-1 è quando determinati attributi si applicano solo ad alcune entità. Tuttavia, nella maggior parte dei casi esiste un modo migliore / più normalizzato per modellare i dati mediante l'estrazione di entità.

Il miglior motivo che posso vedere per una relazione 1: 1 è un sottotipo SuperType di progettazione del database. Ho creato una struttura di dati MLS immobiliare basata su questo modello. C'erano cinque diversi feed di dati; Residenziale, commerciale, multifamiliare, hotel e terra.

Ho creato un SuperType chiamato proprietà che conteneva dati comuni a ciascuno dei cinque feed di dati separati. Ciò ha consentito ricerche "semplici" molto veloci in tutti i tipi di dati.

Creo cinque sottotipi separati che memorizzano gli elementi di dati univoci per ciascuno dei cinque feed di dati. Ogni record SuperType aveva una relazione 1: 1 con il record SubType appropriato.

Se un cliente desiderava una ricerca dettagliata, doveva selezionare un tipo Super-Sub, ad esempio PropertyResidential.

A mio avviso, una relazione 1: 1 mappa un'ereditarietà di classe su un RDBMS. Esiste una tabella A che contiene gli attributi comuni, ovvero lo stato della classe parziale. Ogni stato di classe ereditato viene mappato sull'RDBMS con una tabella B con una relazione 1: 1 con una tabella, contenente gli attributi specializzati. La tabella namend A contiene anche un campo "tipo" che rappresenta la funzionalità "casting"

Ciao Mario

È possibile creare una tabella di relazioni uno a uno in caso di vantaggi significativi in ​​termini di prestazioni. È possibile inserire i campi utilizzati raramente in una tabella separata.

Le relazioni 1: 1 non hanno davvero senso se sei nella normalizzazione poiché qualsiasi cosa che sarebbe 1: 1 verrebbe mantenuta nella stessa tabella.

Nel mondo reale, tuttavia, è spesso diverso. Potrebbe essere necessario suddividere i dati in modo che corrispondano all'interfaccia dell'applicazione.

Forse se hai qualche tipo di oggetti digitati nel tuo database.

Di 'in una tabella, T1, hai le colonne C1, C2, C3 ... con una relazione uno a uno. Va bene, è in forma normalizzata. Ora dite in una tabella T2, avete le colonne C1, C2, C3, ... (i nomi possono differire, ma dicono che i tipi e il ruolo sono gli stessi) anche con una relazione uno a uno. Va bene per T2 per gli stessi motivi di T1.

In questo caso, tuttavia, vedo un adattamento per una tabella separata T3, contenente C1, C2, C3 ... e una relazione uno a uno da T1 a T3 e da T2 a T3. Vedo ancora di più un adattamento se esiste un'altra tabella, con la quale esiste già una a più C1, C2, C3 ... diciamo dalla tabella A a più righe nella tabella B. Quindi, invece di T3, usi B e hai una relazione uno a uno da T1 a B, la stessa per da T2 a B e sempre la stessa a una relazione multipla da A a B.

Credo che la normalizzazione non sia d'accordo con questo, e che potrebbe essere un'idea al di fuori di esso: identificare i tipi di oggetto e spostare oggetti dello stesso tipo nel loro pool di archiviazione, usando una relazione uno a uno da alcune tabelle e una a più relazione da alcune altre tabelle.

È superfluo per motivi di sicurezza, ma esistono modi migliori per eseguire i controlli di sicurezza. Immagina di creare una chiave che può aprire solo una porta. Se la chiave può aprire qualsiasi altra porta, è necessario suonare l'allarme. In sostanza, puoi avere "CitizenTable" e "VotingTable". Cittadino Un voto per il candidato uno che è archiviato nella tabella delle votazioni. Se un cittadino appare di nuovo nella tabella dei voti, allora dovrebbe essere un allarme. Siate consigli, questa è una relazione uno a uno perché non ci riferiamo al campo del candidato, ci riferiamo alla tabella dei voti e alla tabella dei cittadini.

Esempio:

 Citizen Table
 id = 1, citizen_name = "EvryBod"
 id = 2, citizen_name = "Lesly"
 id = 3, citizen_name = "Wasserman"

 Candidate Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"

Quindi, se vediamo la tabella dei voti in questo modo:

 Voting Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"
 id = 4, citizen_id = 3, candidate_name = "Hill Arry"
 id = 5, citizen_id = 3, candidate_name = "Hill Arry"

Potremmo dire che il cittadino numero 3 è un bugiardo in fiamme che ha ingannato Bern Nie. Solo un esempio

Quando si ha a che fare con un database di un prodotto di terze parti, probabilmente non si desidera modificare il loro database per evitare l'accoppiamento stretto. ma potresti avere dati che corrispondono a 1: 1 con i loro dati

Ovunque due entità completamente indipendenti condividono una relazione uno a uno. Ci devono essere molti esempi:

persona <-> dentista (è 1: N, quindi è sbagliato!)

persona <-> medico (è 1: N, quindi è anche sbagliato!)

persona <-> coniuge (è 1: 0 | 1, quindi è per lo più sbagliato!)

MODIFICARE: Sì, quelli erano esempi piuttosto cattivi, in particolare se cercavo sempre un 1: 1, non uno 0 o 1 su entrambi i lati. Immagino che il mio cervello non funzionasse :-)

Quindi, ci riproverò. Si scopre, dopo un po 'di riflessione, che l'unico modo in cui è possibile avere due entità separate che devono (per quanto riguarda il software) stare insieme tutto il tempo è che esistano insieme in una classificazione superiore. Quindi, se e solo se cadi in una decomposizione inferiore, le cose sono e dovrebbero essere separate, ma a un livello superiore non possono vivere l'una senza l'altra. Contesto, quindi è la chiave.

Per un database medico potresti voler memorizzare diverse informazioni su specifiche regioni del corpo, mantenendole come entità separata. In tal caso, un paziente ha solo una testa e deve averla o non è un paziente. (Hanno anche un cuore e un numero di altri singoli organi necessari). Se ad esempio sei interessato a monitorare gli interventi chirurgici, ogni regione dovrebbe essere un'entità separata unica.

In un sistema di produzione / inventario, se stai monitorando l'assemblaggio di veicoli, allora sicuramente vuoi guardare il motore progredire in modo diverso dalla carrozzeria, ma esiste una relazione uno a uno. Una cura deve avere un motore, e solo uno (o non sarebbe più una "macchina"). Un motore appartiene a una sola auto.

In ogni caso potresti produrre entità separate come un unico grande record, ma dato il livello di decomposizione, sarebbe sbagliato. Sono, in questi contesti specifici, entità veramente indipendenti, anche se potrebbero non apparire ad un livello superiore.

Paolo.