In questo capitolo introdurremo il nostro approccio al problema del versioning degli schemi di data warehousing, basandoci su un esempio di funzionamento. Successivamente formalizzeremo la rappresentazione degli schemi di data warehousing ed introdurremo il concetto di Schema Aumentato, il punto chiave del nostro modello.
(a) (b) (c) |
Consideriamo uno schema che modella la vendita di componenti (part) a clienti sparsi per tutto il mondo. Uno schema concettuale del fatto della vendita (Shipment) è mostrato nella figura 4.1(a), utilizzando il formalismo DFM (Dimensional Fact Model) [GMR98].
Il fatto shipment mostrato nella figura 4.1(a) ha due misure, rispettivamente QtyShipped e ShippingCosts, e cinque dimensioni, Date, Part, Customer, Deal e ShipMode. Una gerarchia di proprietà è connessa ad ogni dimensione. Il significato di ciascun arco è quello dell'associazione molti-a-uno, cioè quello di una dipendenza funzionale.
Ora supponiamo che all'istante
,
subisca una revisione allo scopo di adattarsi meglio ad alcune necessità di business. La versione
subirà quindi le seguenti differenze rispetto alla versione
:
Successivamente, nel momento
, viene creata un'altra versione
:
Gli schemi concettuali per le versioni ed
sono mostrati nella figura 4.1(b,c).
All'interno di un sistema che non supporta le versioni, nel momento di un cambiamento tutti i dati vengono migrati nella nuova versione dello schema. Viceversa se il sistema supporta il versioning, tutti gli schemi precedenti rimarranno ancora a disposizione, per essere eventualmente interrogati insieme ai dati registrati durante il loro periodo di validità. In alcune implementazioni dello schema versioning l'utente ha la possibilità di decidere quale versione dello schema deve essere utilizzato per l'interrogazione dei dati di uno stesso periodo temporale. Questo può accadere solamente se la dimensione temporale delle versioni è completamente indipendente da quella dei dati del cubo multidimensionale, come in [EK01]. Per esempio i dati del 2002 potrebbero essere interrogati attraverso lo schema , introdotto solo nel 2003. In particolare si potrebbe richiedere la distribuzione dei costi sulle sotto-categorie, introdotte nello schema dopo il primo Gennaio del 2003.
Nel nostro caso, invece, verrà utilizzato il partial schema versioning, dato che all'utente non viene permesso l'inserimento dei nuovi dati nelle versioni precedenti all'ultima. Ogni versione avrà un insieme di eventi propri e non sarà possibile interrogare tutto l'insieme degli eventi attraverso una sola versione. Per supplire a questa mancanza verrà introdotta l'operazione di intersezione degli schemi e la possibilità di aumentare le versioni precedenti con le modifiche apportate a quelle nuove. Attraverso questa interfaccia sarà possibile eseguire una query su versioni multiple, su tutti i dati corrispondenti all'intervallo temporale delle versioni coinvolte, eventualmente ricoprendo l'insieme totale degli eventi del data warehouse. Nella figura 4.2 viene mostrata la differenza tra un sistema di versioning nel quale ogni versione è associata ad un insieme di eventi preciso (a) ed un sistema nel quale ogni versione può essere utilizzata per interrogare tutto l'insieme degli eventi (b). Nel primo caso ad ogni versione corrisponde un determinato intervallo di tempo
, che coincide con quello degli eventi che sono relativi a
. L'insieme degli attributi e delle dipendenze funzionali sarà diverso, ma in generale uno stesso attributo potrà avere una validità temporale che coinvolge più versioni (e le istanze di questo attributo saranno pertanto le stesse). Nel secondo caso tutto l'insieme degli eventi è interrogabile attraverso un insieme di matrici di conversione, che fanno corrispondere i valori di alcuni attributi delle versioni precedenti ad attributi nuovi. E' chiaro che nel secondo caso la gestione delle versioni è "virtuale", dal momento che i dati sono immagazzinati secondo una struttura unica, trasformata attraverso le matrici per renderla disponibile anche alle versioni precedenti.
Nell'approccio che abbiamo introdotto, le modifiche che avvengono sullo schema nel corso di operazioni sul data warehouse portano alla creazione di una history delle versioni dello schema. Tutte queste versioni sono disponibili per i processi di interrogazione, e la scelta del contesto di formulazione delle query può essere scelto sia in maniera esplicita dall'utente sia in maniera implicita dal sottosistema delle interrogazioni.
L'idea chiave è di supportare un sistema flessibile di interrogazioni cross-versionali, che permettono cioè di essere eseguite su versioni diverse dello schema in maniera trasparente per l'utente, a seconda del contesto analitico sul quale desidera lavorare. Per ottenere questo risultato il progettista deve avere la possibilità di arricchire le precedenti versioni utilizzando le informazioni delle modifiche correnti. A questo scopo, quando viene creata una nuova versione il progettista potrà scegliere se creare uno Schema Aumentato che estende le versioni precedenti, per riflettere le aggiunte dello schema corrente, sia a livello di schema sia a livello delle istanze. Successivamente definiremo in maniera formale gli schemi aumentati e delle operazioni che portano alla loro popolazione, fornendo al contempo un esempio del loro utilizzo.
Per essere più precisi, sia la versione corrente dello schema ed
la nuova versione. Dato l'insieme delle differenze tra
ed
, viene proposto in maniera automatica al progettista un insieme delle possibili Azioni di aumento da eseguire sui dati delle versioni precedenti. Queste azioni possono richiedere un controllo sui dati estensionali prima dell'inserimento di nuovi vincoli di integrità oppure l'inserimento di nuove informazioni attraverso l'interazione dell'utente. L'insieme delle azioni che il progettista intende applicare portano alla definizione ed alla popolazione di uno schema aumentato
, associato ad
, che verrà utilizzato al posto di
in maniera trasparente per l'utente, per rispondere alle interrogazioni che coinvolgono l'intervallo di validità di
. E' importante notare come
sia sempre una estensione di S, nel senso che l'istanza di
può essere sempre ricavata attraverso una proiezione di
.
Si consideri, ad esempio, le operazioni di modifica dello schema che introducono l'attributo SubCategory, eseguito nell'istante
per produrre la versione
.
E' chiaro che per tutti i componenti venduti dopo
(inclusi quelli introdotti dopo
e quelli già esistenti prima di
) sia necessario definire una sotto-categoria nel momento della migrazione dei dati, in modo tale che le interrogazioni che coinvolgono SubCategory possano essere soddisfatte da
in poi. In ogni caso, se l'utente è interessato alla possibilità di eseguire interrogazioni cross-versionali sugli anni 2002 e 2003, come ad esempio nel caso in cui chieda di interrogare anche i vecchi dati sull'attributo SubCategory, è necessario:
Questo processo permetterà di rispondere alle interrogazioni che coinvolgono SubCategory nei vecchi dati attraverso l'istanza di . Bisogna inoltre notare che mentre i primi due passaggi del procedimento sono interamente gestiti dal sistema del versioning, l'ultimo è di responsabilità del progettista.
Nella figura 4.3 l'aggiunta di un attributo nello schema
viene propagata negli schemi aumentati corrispondenti alle versioni
e
. L'attributo sarà quindi disponibile per tutte le query che coinvolgono l'intervallo temporale
o un suo sotto-intervallo. In alternativa le versioni
e
possono essere interrogate singolarmente ed ottenute attraverso una operazione di proiezione (
) sugli schemi aumentati
e
.
Come secondo esempio, si consideri l'aggiunta di un nuovo vincolo di integrità tra i distretti di vendita e le nazioni. In questo caso, il progettista può chiedere al sistema di controllare se la dipendenza funzionale tra SaleDistrict e Nation viene soddisfatta anche sui dati inseriti in passato.
Sebbene questa dipendenza non sia stata individuata in fase di progettazione iniziale, potrebbe essere stata soddisfatta sin dal principio, oppure dopo una fase di pulizia dei dati. Quando questo avviene, inserire la nuova dipendenza nello schema aumentato permette di aumentare le potenzialità delle operazioni di roll-up e drill-down nelle sessioni OLAP.