next up previous contents index
Next: Interrogazione in presenza di Up: Il problema del tempo Previous: Livello estensionale   Indice   Indice analitico

Livello intensionale

In [VMRC02] viene presentato un prototipo che supporta gli aggiornamenti delle dimensioni, sia a livello degli schemi che su quello dei dati.


Tabella 3.3: Operatori di aggiornamento strutturale
Operatori di Aggiornamento Descrizione
Generalize

Entrambi questi differenti livelli hanno un insieme di operatori di aggiornamento: a livello degli schemi insistono gli operatori strutturali, descritti in dettaglio nella tabella 3.3 , mentre sul livello dei dati lavorano gli operatori delle istanze, elencati nella tabella 3.2. Molte delle operazioni di modifica che lavorano sui dati sono il frutto della composizione di queste operazioni elementari, sulle quali possono venire definite le operazioni complesse di modifica delle istanze.


Tabella 3.4: Operatori di aggiornamento delle istanze
Operatori di Aggiornamento Descrizione
Add Instance

Esempio 2   La figura 3.6 mostra un esempio di una dimensione che descrive una localizzazione geografica, aggiornandola attraverso una sequenza di operazioni strutturali. Rispetto al primo grafo (a), il secondo (b) mostra una generalizzazione del livello della città al livello della regione, il terzo (c) mostra lo schema della dimensione dopo aver collegato il livello regione con il paese, ed infine il quarto mostra una specializzazione del livello della città ad una granularità più fine, il quartiere.

Figura 3.6: Esempio di aggiornamento di una dimensione

Questo esempio chiarisce anche i limiti di un approccio basato sull'evoluzione: le istanze che corrispondono al grafo (a) della figura 3.6 devono essere tutte adattate alla nuova descrizione (d) introdotta nelle varie fasi successive. Non è quindi possibile fare riferimento alle vecchie descrizioni attraverso i gli schemi che sono stati sostituiti attraverso le nuove modifiche.

In [LHV02] viene studiato il problema della consistenza di dati relativi alle dimensioni in presenza di una evoluzione nella loro gerarchia.

Definizione 9 (Schema delle dimensioni)   Uno schema di dimensione è un grafo orientato aciclico $ D_S = (L_S,F_S)$ dove $ L_S$ è un insieme fissato di livelli o nodi ed $ F_S$ è un insieme fissato di archi orientati tra i nodi.

Il grafo ha le seguenti proprietà:

  1. Definiamo come grado interno di un nodo il numero dei livelli che lo precedono a partire dalla radice e come grado esterno il numero dei livelli di un nodo a partire dall'ultimo livello. Esiste un distinto nodo terminale $ l_t \in L_S$ di livello interno 0 ed un implicito nodo $ l_{all} \in L_S$ di grado esterno 0. Il grado interno ed esterno di tutti gli altri nodi in $ L_S$ è più grande di zero.

  2. Se un livello $ l_i \in L_S$ determina funzionalmente il livello $ l_j \in L_S$ (cioè se $ l_i \to l_j$ nella notazione standard dei database), che significa che $ (l_i,l_j) \in F_S$, allora non c'è un altro percorso da $ l_i$ ad $ l_j$ attraverso uno o più nodi intermedi.

  3. A ciascun livello delle dimensioni è associato un valore di dominio. In particolare, il valore del dominio del livello $ l_{all}$ è $ \lbrace all \rbrace$.

Una dimensione presente in più di uno schemi delle dimensioni è chiamata dimensione multipla.

Una dimensione multipla $ D_1 = (L_1, F_1)$ su più schemi di dimensione $ D_S = (L_S,F_S)$ è consistente se sono soddisfatte le seguenti condizioni:

  1. Se c'è più di un percorso nello schema dal livello $ l_i$ al livello $ l_j$, dove $ l_i, l_j \in L_S$, allora i percorsi differenti da un membro di $ l_i$ ad un membro di $ l_j$ devono portare allo stesso elemento di $ l_j$.
  2. Se c'è un solo percorso dallo schema $ l_i$ allo schema $ l_j$ per $ l_i, l_j \in L_S$, allora c'è anche solo un percorso per qualsiasi membro di $ l_i$ ad un membro di $ l_j$.

Si nota, quindi, che una dimensione su uno schema che ha solo un percorso da un livello $ l_t$ ad $ l_{all}$ è sempre consistente.

Dato uno schema di dimensione $ D_S$ definito come sopra, $ D_S^+ = (L_S, F_S^+)$ denota la chiusura transitiva di $ D_S$.

L'insieme dei diretti successori di un dato livello $ l_i \in L_S$ è definito come $ Succ_{l_i} = \lbrace l_x \vert (l_i, l_x) \in F_S \rbrace$, mentre l'insieme di tutti i successori di $ l_i$ è definito come $ Succ_{l_i}^+ = \lbrace l_x \vert (l_i, l_x) \in F_S^+ \rbrace$

Per controllare possibili conflittualità durante gli inserimenti di nuovi livelli in uno schema di dimensione viene quindi introdotto il concetto di livelli di conflitto, definito come segue.

Definizione 10 (Livelli di conflitto)   Sia dato uno schema di definizione $ D_S = (L_S,F_S)$ con la chiusura transitiva $ D_S^+ =L_S,F_S^+$. Un livello $ l_j \in L_S$ è un livello di conflitto per una operazione di inserimento nel livello $ l_i \in L_S$ se sono soddisfatte le seguenti condizioni:

  1. $ outdeg(l_i) = \vert Succ_{l_i} \vert > 1 $
  2. $ \exists l_x, l_y \in Succ_{l_i}, l_x \neq l_y: l_j \in Succ_{l_x}^+ \cap Succ_{l_y}^+$

Intuitivamente la condizione 1 richiede che il livello $ l_j$ sia direttamente connesso a più di un livello superiore della gerarchia delle dimensioni, mentre la condizione 2 afferma che un conflitto di inserimento può occorrere al livello $ l_j$ se il livello $ l_j$ può essere raggiunto da almeno due diretti livelli successivi di $ l_i$.

Quando si inserisce un livello nello schema di dimensione, si ha un conflitto in una istanza di dimensione se lo schema ha livelli di conflitto per l'inserimento. In questo caso, deve essere eseguito un test per gli inserimenti nell'istanza della dimensione. Questi conflitti, in ogni caso, avvengono solo se le consistenti dimensioni iniziali subiscono qualche cambiamento. Per questo motivo, le dimensioni potrebbero essere suddivise in due categorie, changing and stable, a seconda che possano o non possano mutare nel tempo. In alcuni casi la storia dei cambiamenti deve essere mantenuta. Alcuni modelli utilizzano dei timestamp valid-time per registrare il periodo di validità delle dipendenze funzionali nello schema e nel grafo dell'istanza, per avere la possibilità di ricostruire lo schema della dimensione e quello dell'istanza in un preciso momento.

Quando un data warehouse è in uso, la conoscenza dell'esistenza di livelli di conflitto all'interno di uno schema di dimensione può essere quindi utilizzato come aiuto per il mantenimento della consistenza dei dati della dimensione. Ogni volta che una dimensione con un livello di conflitto viene aggiornata, può essere testata automaticamente per controllare il verificarsi di un conflitto. Questa possibilità è particolarmente rilevante quando una parte dei dati dimensionali non sono importati da sistemi automatici ma sono mantenuti manualmente o in maniera semiautomatica dall'amministratore del database.

In [EK01] vengono definite le strutture di versione di un database temporale, simili agli schemi di dimensione visti in precedenza.

Definizione 11 (Versione di struttura)   Una versione di struttura è una vista su una struttura multidimensionale che è valida per un intervallo di tempo definito $ [T_s T_e]$, dove $ T_s$ è l'istante iniziale, e $ T_e$ è quello finale.

Figura 3.7: Una dimensione "Divisione" con i relativi timestamp

Concettualmente ad ogni versione di struttura $ SV$ corrisponde un cubo con la stessa validità temporale. Ad ogni elemento della struttura viene quindi associato un periodo di validità, come mostrato in figura 3.7, ed è quindi possibile ricostruire la struttura relativa ad un preciso periodo temporale.

Attraverso la definizione di apposite matrici di trasformazione vengono mappate le corrispondenze tra strutture di versioni diverse, in modo tale che dai dati relativi ad una versione si possano ricavare quelli di un'altra.

In questo modello le istanze dei vari livelli di dimensione (proprietà), vengono chiamate membro della dimensione. Ogni membro di una dimensione ha un timestamp, un istante di validità, attraverso il quale viene inserito in una versione di struttura.

Figura 3.8: Diagramma UML del modello COMET per la gestione dell'evoluzione e del versioning degli schemi di data warehouse

In [EKM02] viene presentato il modello COMET di supporto all'evoluzione ed il versioning degli schemi. Come si vede nel diagramma UML della figura 3.8, ad ogni oggetto viene associato un intervallo temporale di validità, ed ad ogni cubo viene associata una versione (cubeVersion), ad indicare che le diverse istanze del cubo corrispondono a versioni diverse dello schema di riferimento.

Sebbene con l'introduzione del modello COMET venga citato il problema dell'esecuzione delle query che si applicano a cubeVersion diversi, le problematiche connesse non sono state esplorate e le modalità con le quali le differenti istanze vengono mappate tra una versione e l'altra non sono state approfondite.


next up previous contents index
Next: Interrogazione in presenza di Up: Il problema del tempo Previous: Livello estensionale   Indice   Indice analitico
Alessandro Ronchi 2005-07-16