Nei data warehouse l'evoluzione nel tempo degli schemi coinvolge dimensioni e misure. Il fatto d'interesse non è solitamente soggetto a variazioni, dato che il cubo multidimensionale si basa sulla sua centralità e sull'importanza che questo ricopre all'interno del dominio che si sta studiando.
Uno dei nodi centrali della gestione dell'evoluzione del cubo multidimensionale è lo studio dei cambiamenti nelle dimensioni. In letteratura si utilizza il termine Changing Dimensions quando le relazioni delle dimensioni vengono aggiornate nel tempo, modificando alcune tuple già inserite. Quando la percentuale delle tuple modificate rispetto a quelle totali è inferiore al 2%-5%, queste dimensioni sono chiamate Slowly Changing Dimensions.
A livello estensionale, nei data warehouse esistono problematiche da gestire molto simili a quelle presenti nei database relazionali. Nel caso particolare dei sistemi ROLAP (Relational OnLine Analytical Processing ), dove il backend delle applicazioni si basa su database relazionali, le soluzioni per l'immagazzinamento delle informazioni relative all'evoluzione o al versioning degli schemi sono quelle utilizzate nei database temporali. Per questo motivo gli approcci di evoluzione e versioning sfruttano la ricerca effettuata in precedenza in questo campo, introducendo innovazioni principalmente nella modellazione e gestione degli schemi di data warehousing e nella consistenza dei diversi livelli che compongono i sistemi informativi di questo tipo.
In [Yan01] viene analizzato un metodo per la gestione dell'evoluzione delle dimensioni, organizzate in viste materializzate che supportano una dimensione temporale. L'immagazzinamento delle relative informazioni temporali avviene inserendo un apposito attributo timestamp nel database relazionale di supporto, sul quale viene inserito il modello temporale introdotto e sul quale vengono tradotte le query temporali.
Nella tabella 3.1 viene mostrato un esempio di relazione temporale. L'attributo T definisce la validità temporale della tupla di riferimento, come composizione di periodi temporali composti da istanti (chronon), sui quali viene definito un ordinamento totale .
In questo modello non viene analizzata la possibilità di effettuare query multi-schema, ma viene permesso il mantenimento e l'interrogazione in uno specifico periodo temporale.
L'evoluzione degli schemi introduce inoltre problematiche di consistenza e di qualità dei dati presenti nel data warehouse. Diversi studi in letteratura hanno finora affrontato l'impatto dell'evoluzione sulla qualità dei processi di mantenimento del data warehouse e sulla consistenza dei dati, senza analizzare il versioning degli schemi e conseguentemente la possibilità di effettuare interrogazioni che coinvolgono versioni diverse.
In [Qui99] viene analizzato e discusso in termini generali l'impatto dell'evoluzione sulla qualità dei processi di data warehousing, proponendo come soluzione un meta-modello di supporto. In questo studio vengono prese in esame le necessità di modifiche al data warehouse sotto tre diverse prospettive:
Ciascuna di queste prospettive ha tre differenti livelli: il sorgente, il data warehouse e quello del cliente. Un ruolo centrale in questo modello viene giocato dal modello del data warehouse, che dovrebbe essere una rappresentazione concettuale dei dati che sono disponibili nell'azienda.
Il meta-modello presentato attraverso il progetto Data Warehouse Quality (DWQ) [JJQV99] per la gestione dei meta-dati in un data warehouse tiene traccia sia delle componenti architetturali sia dei fattori qualitativi che lo caratterizzano.
La figura 3.1 mostra il framework 3x3 sul quale si basa il modello, che identifica le tre prospettive (concettuale, logica e fisica) ed i tre livelli (sorgente, data warehouse, cliente). Il primo strato della figura 3.1 corrisponde al meta-modello proposto e fornisce una notazione per le entità generiche per il data warehouse, come lo schema, inclusa la prospettiva di business. Il meta-modello viene istanziato con i meta-dati del data warehouse, che sono mostrati nel secondo strato della figura 3.1, come le definizioni degli schemi relazionali o la descrizione del modello concettuale del data warehouse. Il terzo strato rappresenta il mondo reale nel quale i dati attuali risiedono: qui i meta-dati sono istanziati con le istanze dei dati, come ad esempio le tuple di una relazione o gli oggetti del mondo reale che sono rappresentati dalle entità del modello concettuale.
Ogni oggetto presente nei tre livelli e nelle tre prospettive del framework può essere soggetto a misure di qualità, che sono inserite direttamente nella modellazione. Questo significa che il modello per la qualità è parte integrante del deposito dei meta-dati, e le informazioni riguardanti la qualità sono esplicitamente connesse agli oggetti architetturali.
Nella figura 3.2 viene mostrato il modello per la qualità DWQ. La classe ObjectType si riferisce ad un qualsiasi meta-oggetto del framework DWQ, mostrato nel primo strato della figura 3.1. Un obbiettivo di qualità (quality goal) è una necessità astratta di interesse per lo stakeholder, definita su un tipo di oggetto. Un obbiettivo di qualità esprime in maniera diretta alcune richieste in un linguaggio naturale, come ad esempio la disponibilità della sorgente fino alla fine del mese per l'amministratore del database. Le dimensioni di qualità (quality dimensions (ad esempio "disponibilità") sono utilizzate per classificare gli obbiettivi in categorie differenti. Un fattore di qualità (quality factor) rappresenta una misura attuale del valore della qualità, e connette quindi i valori di qualità ad oggetti misurabili. La misura di questi fattori di qualità avviene attraverso gli agenti di misura (measuring agents).
1.1
Operatori di evoluzione | Effetti sui fattori di qualità | Livello sul quale operano
Aggiunta di una relazione di base/vista |
Il workflow necessario per la costruzione ed il mantenimento del data warehouse viene descritto attraverso un modello per i processi (figura 3.3), che raccoglie le problematiche principali della gestione delle operazioni sul data warehouse. In questo modello viene introdotta la gestione delle evoluzioni del data warehouse, ed analizzato il suo impatto sulla qualità dei processi.
Per un maggiore controllo dell'evoluzione vengono introdotti dei meta-dati che tengono traccia della storia dei cambiamenti e forniscono un insieme di regole di consistenza da rafforzare quando un fattore di qualità deve essere rivalutato. Il processo di evoluzione è composto da operatori di evoluzione e da processi standard. Un tipico processo di evoluzione è ad esempio la materializzazione della vista di un nuovo data warehouse (figura 3.4). Questo processo include, tra le altre, le operazioni di aggiunta di una nuova relazione allo schema del data warehouse e quelle di inserimento, estrazione e scrittura necessarie a valutare una vista e registrarne il contenuto.
Per gestire il controllo di qualità viene tenuta traccia dei processi di evoluzione che hanno modificato la configurazione ed i dati del data warehouse. Attraverso queste informazioni, per ogni eventuale problema di qualità è possibile stabilire quale processo lo ha causato.
Nella tabella 3.2 vengono elencati gli operatori di evoluzione per le relazioni di base e le viste, collegati ai fattori di qualità che vengono coinvolti dalla loro applicazione.
In [BEK+04] viene presentato un modello di data warehouse multidimensionale basato sul versioning, introducendo il concetto di versioni alternative.
Accanto alle versioni reali, basate sui cambiamenti del dominio applicativo, le versioni alternative permettono di confrontare le analisi in risposta ad interrogazioni del tipo what-if, improntate su ipotesi applicate ad eventuali futuri cambiamenti del dominio. Attraverso queste versioni l'utente riesce a ricavare delle proiezioni dei risultati basate su ipotesi di cambiamento, ed introdurre decisioni applicate direttamente al dominio in base a questi scenari alternativi.
Questo modello multidimensionale è formato da un grafo di derivazione delle versioni (reali ed alternative), ognuna derivata esplicitamente da una versione precedente. Ad ogni versione viene quindi associato un insieme di dati consistenti corrispondenti.
Anche in questo caso ogni versione è valida per un determinato periodo di tempo, individuato da un istante iniziale ed uno finale, ma più versioni alternative possono condividere lo stesso periodo di validità.
Come è possibile vedere nella figura 3.5, il grafo di derivazione permette al progettista di gestire le versioni reali ed alternative sia in fase di modellazione che di interrogazione.
è l'insieme delle versioni reali,
è quello delle versioni alternative. Le versioni che sono sovrapposte in verticale (quindi hanno la stessa ipotetica proiezione sull'asse orizzontale) hanno la stessa validità temporale.