I data warehouse e le applicazioni che vi si appoggiano rappresentano un potente framework per l'immagazzinamento e l'analisi di enormi quantità di dati finalizzati al supporto alle decisioni. In questo contesto, le analisi effettuate nei data warehouse si focalizzano su insiemi di dati che sono stati raccolti in lunghi periodi di tempo. Un Data warehouse può essere considerato, quindi, come un database specializzato con caratteristiche di raccolta di informazioni temporali o addirittura storiche.
Un cubo di un data warehouse modella un insieme di eventi, ed è composto dal fatto di interesse, dalla descrizione delle dimensioni e dalle misure.
Il fatto d'interesse rappresenta gli elementi dell'informazione atomica nel database multidimensionale, ed è il centro concettuale dell'informazione che si vuole mantenere nel data warehouse. Nel caso dei data warehouse memorizzati in un database relazionale, ad esempio, i dati relativi al fatto vengono memorizzati nella fact table e rappresentano gli eventi che sono al centro dello studio del cubo multidimensionale. Le dimensioni rappresentano il contesto corrispondente al fatto e sono strutturate secondo una gerarchia di dipendenze funzionali che ne descrivono i vari livelli di aggregazione, le proprietà. Le misure sono i valori quantitativi immagazzinati nel data warehouse relativi al fatto d'interesse e sono organizzate eventualmente in una gerarchia che ne descrive le funzioni di derivazione, nel caso delle misure derivate.
Allo stato attuale esistono diversi formalismi che permettono di descrivere gli schemi dei cubi, gli attributi e le gerarchie delle dipendenze funzionali, ognuno dei quali ha caratteristiche e funzionalità proprie. Negli schemi concettuali che descrivono un data warehouse, le dimensioni sono grafi orientati (ciclici o aciclici, a seconda dei formalismi), i cui nodi rappresentano le proprietà corrispondenti ai livelli di aggregazione di interesse, ed i cui archi rappresentano le dipendenze funzionali.
I dati inseriti all'interno di un data warehouse attraverso le diverse tipologie di fonti di alimentazione, quindi, sono sempre visti in un contesto temporale. Ciò avviene a causa della peculiarità dell'immagazzinamento delle informazioni relative al fatto di interesse, che avviene in maniera incrementale nel tempo. Oltre a questo, si deve tenere in considerazione la possibilità che anche le stesse dimensioni e misure possano subire cambiamenti durante questo lungo periodo di tempo.
Le modifiche alle fonti di alimentazione di un data warehouse, quindi, possono essere suddivise in due categorie distinte: quelle che coinvolgono cambiamenti nei dati (inserimento, aggiornamento, cancellazione di tuple) e quelle che corrispondono a cambiamenti nella struttura (schema) che li modella. Entrambe queste categorie possono portare a modifiche dello schema del data warehouse.
Come soluzione al problema della gestione delle modifiche alle fonti di alimentazione si potrebbe decidere di isolarle attraverso uno strato intermedio di middleware, che riconduca gli elementi di informazione alla struttura inizialmente adottata per l'alimentazione del data warehouse. Un approccio di questo tipo non può però protrarsi nel tempo, perché porta ad inconsistenze dovute all'allontanamento incrementale tra la realtà modellata a livello delle fonti e quella gestita dal data warehouse.
Un metodo molto più serio ed inevitabilmente più complesso da gestire, invece, deve prevedere una propagazione dei cambiamenti ad ogni livello, tenendo traccia delle modifiche a livello dell'alimentazione ed applicandole alla definizione del data warehouse. Le due diverse modalità possibili di gestione di questa propagazione sono simili a quelle individuate nei database relazionali: evoluzione e versioning.
Come esempio possiamo pensare ad un data warehouse che studia le caratteristiche politiche ed economiche dei paesi del continente europeo degli ultimi venti anni. E' chiaro che qualsiasi analisi di questo tipo non potrebbe ignorare i cambiamenti politici che hanno modificato la mappa dell'Europa in questo periodo di tempo. L'Unione Sovietica, La Germania, la Cecoslovacchia, etc. hanno subito profondi cambiamenti politici che ne hanno modificato persino i confini geografici. Nelle interrogazioni che tengono in considerazione diversi periodi di tempo sia precedenti sia successivi a questi cambiamenti, il sistema deve gestire il problema della comparabilità dei dati e delle conseguenze di queste differenze sui risultati.
Tramite una evoluzione degli schemi, in questo caso sarebbe possibile adattare il sistema all'attualità, ma si perderebbe la possibilità di interrogare il data warehouse attraverso gli schemi precedenti ed i dati corrispondenti. Lo schema versioning, nelle sue varie forme, permette di gestire questa situazione e di mantenere uno storico delle modifiche apportate agli schemi.
Sorprendentemente, la ricerca non ha ancora sufficientemente approfondito questo ambito, e nessuna soluzione fino ad ora presentata risulta essere completa.
Uno dei motivi per i quali la gestione temporale dei cambiamenti nei data warehouse non è ancora stata approfondita è la considerazione che sta alla base del loro sviluppo, che prevede che le dimensioni siano ortogonali tra loro. In presenza di una dimensione temporale, come accade nella quasi totalità delle implementazioni, l'assunzione dell'ortogonalità delle dimensioni porta alla necessità che queste siano invarianti nel tempo. Questa implicita assunzione, ovviamente, è molto limitante e poco realistica.
L'analisi delle problematiche relative alla gestione del tempo nei data warehouse può essere quindi suddivisa in due sezioni, riguardanti rispettivamente gli aspetti estensionali ed intensionali della gestione del tempo nei data warehouse, anche se è ovvio che profondi cambiamenti apportati ad un livello si propaghino anche nell'altro.