next up previous contents index
Next: Un prototipo per la Up: Un approccio al versioning Previous: Storia delle versioni   Indice   Indice analitico


Interrogazioni su schemi multipli

L'approccio al versioning presentato in questo lavoro è incentrato sulla possibilità di eseguire interrogazioni su schemi multipli, avvalendosi della disponibilità degli schemi aumentati e della history delle versioni. A differenza di quanto visto in [EK01], nel nostro approccio non è possibile interrogare tutto l'insieme degli eventi attraverso una unica versione. Ogni versione ha i suoi eventi corrispondenti, e solo attraverso di essa si può accedere ai dati relativi allo stesso periodo temporale di validità. Sotto questa limitazione, la possibilità di fare interrogazioni su schemi multipli è quindi subordinata all'individuazione di uno schema che funga da interfaccia verso tutte le versioni coinvolte. Questo schema deve inoltre essere univocamente determinato a partire dall'intervallo temporale di validità, attraverso una funzione di intersezione degli schemi. Definiamo quindi l'operatore di intersezione, denotato da $ \otimes $, che permette di determinare lo schema comune di due versioni differenti, e per composizione di stabilire quindi lo schema comune di versioni multiple.

Definizione 24   Sia $ S=(\{E\} \cup U, F)$ e $ S'=(\{E\} \cup U', F')$. Allora l'intersezione di $ S$ con $ S'$, denotata da $ S \otimes S'$, è lo schema definito come
$ S \otimes S'=(\{E\} \cup (U \cap U'), (F^* \cap F'^*)^-)$.

In maniera intuitiva, l'intersezione tra due versioni $ S$ ed $ S'$ è lo schema sul quale i dati registrati sotto $ S$ ed $ S'$ possono essere interrogati in maniera uniforme. Lo schema intersezione include quindi solo gli attributi che appartengono sia ad $ S$ che ad $ S'$, come pure per le dipendenze funzionali comuni. Un esempio dell'intersezione è riportata nella figura 4.9.

Figura 4.9: Intersezione tra due schema graph

Figura 4.10: Interrogazione In Presenza Di Schemi Multipli

Nella figura 4.10 viene mostrato l'effetto di una query $ Q_1$ su un intervallo temporale $ [t_1,t_3]$ che è un sottoinsieme di $ [t_0,t_2]$, che a sua volta è l'unione degli intervalli delle versioni $ V_1$ e $ V_2$. La query viene quindi applicata sullo schema comune di intersezione tra $ V_1$ e $ V_2$, individuato da $ [t_1,t_3]$, con $ t_0<t_1<t_2<t_3$. $ Q_1$ verrà automaticamente spezzata dal sistema di gestione delle query multi-schema in modo tale che il risultato sia l'unione dei risultati applicati a $ V_1$ ed a $ V_2$, in maniera trasparente per l'utente. Gli attributi a disposizione per la sessione OLAP saranno quelli dello schema intersezione, mentre gli eventi saranno quelli avvenuti nell'intervallo $ [t_1,t_3]$.

L'operatore di intersezione è chiuso sugli gli schema graph, è commutativo ed associativo. Questo è molto importante, dal momento che ci permette di applicare l'operatore $ \otimes $ ad insiemi di schemi.

Definizione 25   Data una history $ H$ ed un intervallo temporale $ T$ non necessariamente contiguo, chiamiamo intervallo di $ T$ su $ H$ $ \mathtt{(Span(H,T))}$ l'insieme

$\displaystyle \mathtt{Span}(H,T)=\{S_i^{AUG} \:\vert\: (S_i, S_i^{AUG}, t_i) \in H
\: \wedge \:[t_i,t_{i+1}[ \:\cap\: T \neq \emptyset\}$

(assumendo per convenzione $ t_{n+1}=+\infty$).

Lo schema comune su $ H$ attraverso $ T$ è definito come $ \mathtt{Com}(H,T)=\bigotimes_{\mathtt{Span}(H,T)} S_i^{AUG}$.

L'esempio che segue mostra l'esecuzione di una query sia in presenza di operazioni di aumento sia in loro assenza.

Esempio 7   Sia $ H=((S_0,S_0^{AUG},t_0),(S_1,S_1^{AUG},t_1),(S_2,S_2^{AUG},t_2))$ una history per il fatto Shipment (ricordando dagli esempi precedenti che $ t_1 = 1/1/2003$ e $ t_2=1/1/2004$), e sia $ q=$ ``Calcola la quantità totale di ciascuna categoria di componenti spedita da ciascun deposito a ciascuna nazione dei clienti dal Luglio 2002''. L'intervallo temporale di $ q$ è $ T=[7/1/2002,+\infty[$, dal momento che $ \mathtt{Span}(H,T)=\{S_0,S_1,S_2\}$ La figura 4.11 mostra il contesto della formulazione, definito da $ S_0^{AUG} \otimes
S_1^{AUG} \otimes S_2^{AUG}$, in due situazioni: nel caso in cui non sia stata effettuata nessuna operazione di aumento (descritto dalle linee semplici), e nel caso siano state fatte tutte le operazioni di aumento possibili (descritte dalle linee tratteggiate).
Figura 4.11: Le differenze sul contesto di formulazione di una interrogazione in assenza o presenza di operazioni di aumento

Prima di tutto dobbiamo osservare che $ q$ è corretta solamente se ShipFrom è stato inserito grazie ad una operazione di aumento in entrambe le versioni precedenti, dal momento che in sua assenza uno degli attributi richiesti non apparterrebbe al contesto della formulazione della query.

Quindi osserviamo che, per esempio, le operazioni di drill-down da Category a SubCategory saranno possibili solamente se le sotto-categorie e le loro relazioni di dipendenza con le categorie sono state stabilite anche per i dati del 2002. Il drill-down da Nation a SaleDistrict sarà possibile solo se la validità della dipendenza funzionale dai distretti di vendita alle nazioni è stata verificata anche per i dati inseriti prima del 2003.

Infine dobbiamo notare che se ShippingCostsEU viene aumentato potrà essere considerato su tutto il periodo di tempo, sebbene i costi di spedizione sono stati registrati solamente in Marchi tedeschi fino a $ t_2$. Più in dettaglio, l'aumento delle misure derivate può essere implementato senza nessun costo di immagazzinamento, dato che può essere registrato come una semplice vista applicata con un fattore di conversione costante.

Nell'eseguire query che coinvolgono versioni differenti, sulla base delle scelte implementative adottate sarà necessario riscrivere la formulazione dell'utente per adattarla ai vari depositi di dati. Le query, quindi, dovranno essere interpretate e riscritte per adattarsi ai cambi di granularità delle dimensioni ed applicarsi ai repository relazionali sui quali sarà appoggiato il sistema.

Alcune informazioni dovranno essere presenti nei meta-dati, per permettere al sistema di eseguire la query in maniera univoca, mentre altre potranno essere derivate automaticamente dai dati già in possesso del sistema di interrogazione.


next up previous contents index
Next: Un prototipo per la Up: Un approccio al versioning Previous: Storia delle versioni   Indice   Indice analitico
Alessandro Ronchi 2005-07-16