modellazione di database temporale e la normalizzazione

Question

Nel caso le date per un database temporale memorizzato in uno o 2 tavoli? Se uno non la violano la normalizzazione?

PERSON1 DATE11 DATE21 INFO11 INFO21 DEPRECATED
PERSON2 DATE21 DATE22 INFO21 INFO22 CURRENT
PERSON1 DATE31 DATE32 INFO31 INFO32 CURRENT

data1 e data2 colonne indicano che INFO1 e INFO2 sono vere per il periodo compreso tra data1 e data2. Se la data

Devo dividere questo tavolo? Devo memorizzare lo stato (deprecato o corrente) nella tabella?

Per chiarire la questione ulteriormente più, Obsoleto è il termine usato dal Business, se si preferisce "non corrente", il problema non è semantica, non si tratta di query SQL sia, voglio solo sapere quale disegno violi o meglio adatta regole di normalizzazione (so normalizzazione non è sempre la strada da percorrere, che non è la mia domanda o).

Answer 1

"Vorrei sapere quale disegno viola le regole di normalizzazione"

dipende da quale set di regole di normalizzazione che si desidera seguire.

La prima e più probabile violazione di forme normali, e in Il libro di Data si tratta di una violazione della prima NF , è la vostra meta-date nelle righe che contengono "corrente" informazioni (facendo astrazione della possibilità di futuro informazioni aggiornate): si viola 1NF se fate quell'attributo annullabile

.

La violazione delle BCNF può ovviamente verificarsi come conseguenza della vostra scelta di tasti (come è il caso nella banca dati atemporale disegni troppo - l'aspetto temporale non fa alcuna differenza qui). WRT "scelta di chiavi": se si utilizza avvio separato e finali date (e di SQL tipo di ti lascia altra scelta), quindi molto probabilmente si dovrebbe dichiarare due tasti: uno che include la data di inizio, e uno che comprende il end-date.

Un altro problema di progettazione è il più colonne di dati. Questo problema è discusso molto in generale in "temporale dei dati e il modello relazionale": se INFO1 e INFO2 possono cambiare in modo indipendente l'uno dall'altro, potrebbe essere meglio per decomporre le tabelle per contenere solo un attributo, al fine di evitare una "esplosione di contano le righe" che altrimenti potrebbero verificarsi se si deve creare una nuova riga completa ogni volta un singolo attributo nei cambiamenti di fila. In questo caso, il vostro disegno come ti ha dato costituisce una violazione della forma normale SESTO, come (che forma normale è) definito in "temporale dei dati e il modello relazionale".

Answer 2

La normalizzazione è un concetto di database relazionale - non si applica anche per basi di dati temporali. Questo non vuol dire che non è possibile memorizzare i dati temporali in un database relazionale. È sicuramente possibile.

Ma se si sta andando con Temporal Design Database, quindi i concetti di normalizzazione temporale si applicano invece di normalizzazione relazionale.

Answer 3

Non hai indicato il significato delle date. Fanno si riferiscono a: (a) il periodo in cui il fatto dichiarato era vero nella vita reale, o (b) per il periodo in cui il fatto dichiarato è stato creduto per essere vero da parte del titolare del database? Se (b), allora non avrei mai fare in questo modo. Spostare la linea aggiornata a una tabella di archivio / log immediatamente quando l'aggiornamento è fatto. Se (a), quindi la seguente dichiarazione è discutibile:

"i fatti sono obsolete e non dovrebbero mostrare più nell'interfaccia utente"

Se un dato di fatto non "c'è bisogno di arrivare nell'interfaccia utente" più, quindi non ha bisogno di essere nel database più neanche. Mantenere questi fatti ci raggiunge solo una cosa: si deteriorano le prestazioni generali per tutto il resto

.

Se si ha realmente bisogno di queste affermazioni storiche di fatto per soddisfare le vostre esigenze, allora è probabile che i vostri cosiddetti "fatti deprecato" sono ancora molto rilevanti per il business, e quindi non "deprecato" a tutti. Assume di che, per questo motivo, ci sono molto piccoli fatti "genuinamente deprecato" nel database, il vostro disegno è buono. Basta tenere il numero di "fatti realmente deprecate" piccola da loro rimuovendo periodicamente dal database operativo.

(PS) per dire che il design è buono, non significa che non incorrere in eventuali problemi. SQL è estremamente mal si adatta per gestire questo tipo di informazioni con eleganza. "Temporale dei dati e il modello relazionale" è un ottimo trattamento del soggetto. Un altro libro, quello di Snodgrass, viene spesso elogiato troppo, anche se non da me. Quello è qualcosa di un libro di cucina con ricette per affrontare questi problemi in SQL, come dimostra la seguente conversazione su SO di questo libro:

(Q) "Perché dovrei leggere questo?" (A) "Perché il trigger che hai chiesto è a pagina 135".