Perché abbiamo bisogno di un database temporale?

StackOverflow https://stackoverflow.com/questions/800331

  •  03-07-2019
  •  | 
  •  

Domanda

Stavo leggendo dei database temporali e sembra che abbiano costruito aspetti nel tempo. Mi chiedo perché dovremmo aver bisogno di un modello del genere?

Quanto è diverso da un normale RDBMS? Non possiamo avere un normale database, ad esempio RDBMS e dire avere un trigger che associa un timestamp a ogni transazione che si verifica? Potrebbe esserci un colpo di scena. Ma sono ancora scettico sui database temporali che hanno un caso forte nel mercato.

Qualcuno dei database presenti supporta tale funzionalità?

È stato utile?

Soluzione

Un database temporale memorizza in modo efficiente una serie temporale di dati, in genere con una scala temporale fissa (come secondi o addirittura millisecondi) e quindi memorizzando solo le modifiche nei dati misurati. Un timestamp in un RDBMS è un valore memorizzato in modo discreto per ogni misurazione, il che è molto inefficiente. Un database temporale viene spesso utilizzato in applicazioni di monitoraggio in tempo reale come SCADA. Un sistema consolidato è il database PI di OSISoft ( http://www.osisoft.com/ ).

Altri suggerimenti

Prendi in considerazione il tuo diario di appuntamenti / diario: va dal 1 ° gennaio al 31 dicembre. Ora possiamo interrogare il diario per appuntamenti / voci di giornale in qualsiasi giorno. Questo ordine è chiamato ora valida . Tuttavia, gli appuntamenti / voci non vengono generalmente inseriti in ordine.

Supponiamo che vorrei sapere quali appuntamenti / voci erano nel mio diario il 4 aprile. Cioè, tutti i record che esistevano nel mio diario il 4 aprile. Questo è il tempo di transazione .

Dato che è possibile creare ed eliminare appuntamenti / voci, ecc. Un record tipico ha un orario valido di inizio e fine che copre il periodo della voce e un tempo di transazione iniziale e finale che indica il periodo durante il quale la voce è apparsa nella diario.

Questo accordo è necessario quando il diario può essere sottoposto a revisione storica . Supponiamo che il 5 aprile mi renda conto che l'appuntamento che ho avuto il 14 febbraio è effettivamente avvenuto il 12 febbraio, ovvero ho scoperto un errore nel mio diario: posso correggere l'errore in modo che l'immagine temporale valida sia corretta, ma ora la mia query su ciò che era nel diario del 4 aprile sarebbe sbagliato, A MENO CHE, vengano memorizzati anche i tempi di transazione per gli appuntamenti / voci. In tal caso, se eseguo una query sul mio diario dal 4 aprile, verrà visualizzato un appuntamento esistente il 14 febbraio, ma se eseguo una query al 6 aprile, verrà visualizzato un appuntamento il 12 febbraio.

Questa funzione di viaggio nel tempo di un database temporale consente di registrare informazioni su come gli errori vengono corretti in un database. Ciò è necessario per un vero quadro di controllo dei dati che registra quando sono state apportate le revisioni e consente query relative al modo in cui i dati sono stati rivisti tempo.

La maggior parte delle informazioni aziendali dovrebbe essere archiviata in questo schema bitemporale al fine di fornire un vero record di audit e massimizzare la business intelligence - da qui la necessità di supporto in un database relazionale. Si noti che ogni elemento di dati occupa un quadrato (possibilmente illimitato) nel modello temporale bidimensionale, motivo per cui le persone usano spesso un indice GIST per implementare l'indicizzazione bitemporale. Il problema qui è che un indice GIST è davvero progettato per dati geografici e i requisiti per i dati temporali sono leggermente diversi.

I vincoli di esclusione di PostgreSQL 9.0 dovrebbero fornire nuovi modi di organizzare i dati temporali, ad es. i PERIODI di transazione e tempo valido non devono sovrapporsi per la stessa tupla.

A quanto ho capito (e l'enorme semplificazione enorme), un database temporale registra i fatti su quando i dati erano validi, nonché i dati stessi, e consente di interrogare sugli aspetti temporali. Si finisce per occuparsi delle tabelle "tempo valido" e "tempo di transazione" o "tabelle bitemporali" che coinvolgono aspetti sia di "tempo valido" che di "tempo di transazione". Dovresti prendere in considerazione la lettura di uno di questi due libri:

I database temporali sono spesso utilizzati nel settore dei servizi finanziari. Uno dei motivi è che raramente (se mai) ti è permesso cancellare qualsiasi dato, quindi ValidFrom - ValidTo campi di tipo sui record sono usati per fornire un'indicazione di quando un record era corretto.

Oltre a leggere articolo di Wikipedia ? Un database che mantiene un "registro di controllo" o un registro delle transazioni simile avrà alcune proprietà di essere "temporale". Se hai bisogno di risposte a domande su chi ha fatto cosa a chi e quando , hai un buon candidato per un database temporale.

Puoi immaginare un semplice database temporale che registra la posizione GPS ogni pochi secondi. Le opportunità per comprimere questi dati sono grandi, un normale database di cui avresti bisogno per memorizzare un timestamp per ogni riga. Se è richiesta una grande quantità di throughput, sapere che i dati sono temporali e che gli aggiornamenti e le eliminazioni di una riga non saranno mai necessari consente al programma di eliminare gran parte della complessità ereditata in un tipico RDBMS.

Ciononostante, i dati temporali vengono generalmente memorizzati in un normale RDBMS. PostgreSQL, ad esempio, ha alcune estensioni temporali , il che rende un po 'più semplice.

Due motivi vengono in mente:

  1. Alcuni sono ottimizzati per l'inserimento e la sola lettura e possono offrire notevoli miglioramenti perf
  2. Alcuni hanno una migliore comprensione del tempo rispetto al tradizionale SQL, consentendo operazioni di raggruppamento per secondo, minuto, ora, ecc.

Solo un aggiornamento, il database temporaneo è in arrivo su SQL Server 2016.

Per chiarire tutti i tuoi dubbi sul perché è necessario un database temporale, piuttosto che configurarlo con metodi personalizzati e in che modo & amp; SQL Server lo configura perfettamente per te, controlla il video approfondito e la demo su Channel9.msdn qui: https://channel9.msdn.com/Shows/Data-Exposed/Temporal-in-SQL-Server-2016

Collegamento MSDN: https: // msdn. microsoft.com/en-us/library/dn935015(v=sql.130).aspx

Attualmente con la versione CTP2 (beta 2) di SQL Server 2016 puoi giocarci.

Controlla questo video su come utilizzare le tabelle temporali in SQL Server 2016.

Inoltre " quali nuove cose posso fare con esso " ;, potrebbe essere utile considerare " quali cose vecchie unisce? " ;. Il database temporale rappresenta una particolare generalizzazione della "normale" Database SQL. Come tale, potrebbe darti una soluzione unificata ai problemi che prima apparivano non correlati. Ad esempio:

  • Concorrenza Web Quando il tuo database ha un'interfaccia utente Web che consente a più utenti di eseguire modifiche standard di Crea / Aggiorna / Elimina (CRUD), devi affrontare problema concomitante di modifiche web . Fondamentalmente, è necessario verificare che una modifica dei dati in entrata non influisca sui record che sono stati modificati dall'ultima volta che l'utente ha visto quei record. Ma se hai un database temporale, molto probabilmente associa già qualcosa come un "ID di revisione". con ogni record (a causa della difficoltà di rendere i timestamp unici e monotonicamente ascendenti). Se è così, allora diventa quello naturale, "già incorporato" meccanismo per impedire il blocco dei dati di altri utenti durante gli aggiornamenti del database.
  • Documenti legali / fiscali Il sistema legale (tasse incluse) pone piuttosto più enfasi sui dati storici rispetto alla maggior parte dei programmatori. Pertanto, troverai spesso consigli sugli schemi per le fatture e tali che ti avverte di stare attento all'eliminazione dei record o alla normalizzazione in modo naturale modo - che può portare all'incapacità di rispondere a domande legali di base come " Dimentica il loro indirizzo attuale, a quale indirizzo hai spedito questa fattura nel 2001? " Con una base di struttura temporale, tutte le macchinazioni a quei problemi (di solito sono a metà strada per avere un database temporale) scompaiono. Devi solo usare lo schema più naturale ed eliminare quando ha senso, sapendo che puoi sempre tornare indietro e rispondere alle domande storiche in modo accurato.

D'altra parte, il modello temporale stesso è a metà strada per completare il controllo di revisione, il che potrebbe ispirare ulteriori applicazioni. Ad esempio, supponiamo di disporre la propria struttura temporale su SQL e consentire la diramazione, come nei sistemi di controllo delle revisioni. Anche le ramificazioni limitate potrebbero semplificare l'offerta di "sandboxing" - la capacità di giocare e modificare il database con abbandono senza causare cambiamenti visibili ad altri utenti. Ciò semplifica la formazione di utenti altamente realistici su un database complesso.

La semplice diramazione con una semplice funzione di unione potrebbe anche semplificare alcuni problemi comuni del flusso di lavoro. Ad esempio, un'associazione senza fini di lucro potrebbe avere volontari o lavoratori a basso reddito che effettuano l'inserimento dei dati. Dare a ciascun lavoratore il proprio ramo potrebbe rendere più semplice consentire a un supervisore di rivedere il proprio lavoro o migliorarlo (ad esempio, la duplicazione) prima di fonderlo nel ramo principale in cui diventerebbe visibile "normale"; utenti. Le filiali potrebbero anche semplificare le autorizzazioni. Se a un utente viene concessa l'autorizzazione per utilizzare / vedere il proprio ramo unico, non devi preoccuparti di impedire ogni possibile modifica indesiderata; unirai solo le modifiche che hanno senso comunque.

La mia comprensione dei database temporali è orientata alla memorizzazione di determinati tipi di informazioni temporali. Potresti simularlo con un RDBMS standard, ma usando un database che lo supporta hai idiomi incorporati per molti concetti e il linguaggio delle query potrebbe essere ottimizzato per questo tipo di query.

Per me è un po 'come lavorare con un database specifico GIS piuttosto che con un RDBMS. Sebbene sia possibile inserire le coordinate in un RDBMS run-of-the-mill, avere le rappresentazioni appropriate (ad esempio, tramite i file della griglia) potrebbe essere più veloce e avere primitive SQL per cose come la topologia è utile.

Esistono database accademici e alcuni commerciali. Timecenter ha alcuni link.

Un altro esempio di dove un database temporale è utile è dove i dati cambiano nel tempo. Ho trascorso alcuni anni a lavorare per un rivenditore di energia elettrica dove abbiamo memorizzato le letture dei contatori per 30 minuti. Quelle letture dei contatori potrebbero essere riviste in qualsiasi momento, ma dovevamo comunque essere in grado di guardare indietro alla storia dei cambiamenti delle letture.

Abbiamo quindi avuto l'ultima lettura (la nostra "comprensione attuale" del consumo per i 30 minuti) ma potremmo guardare indietro alla nostra comprensione storica del consumo. Quando hai dati che possono essere regolati in modo tale che i database temporali funzionino bene.

(Detto questo, l'abbiamo intagliato a mano in SQL, ma è stato un bel po 'di tempo fa. Non prendere questa decisione in questi giorni.)

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top