In [VMRC02] viene presentato un prototipo che supporta gli aggiornamenti delle dimensioni, sia a livello degli schemi che su quello dei dati.
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.
Operatori di Aggiornamento | Descrizione
Add Instance |
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.
Il grafo ha le seguenti proprietà:
Una dimensione presente in più di uno schemi delle dimensioni è chiamata dimensione multipla.
Una dimensione multipla
su più schemi di dimensione
è consistente se sono soddisfatte le seguenti condizioni:
Si nota, quindi, che una dimensione su uno schema che ha solo un percorso da un livello ad
è sempre consistente.
Dato uno schema di dimensione definito come sopra,
denota la chiusura transitiva di
.
L'insieme dei diretti successori di un dato livello
è definito come
, mentre l'insieme di tutti i successori di
è definito come
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.
Intuitivamente la condizione 1 richiede che il livello 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
se il livello
può essere raggiunto da almeno due diretti livelli successivi di
.
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.
Concettualmente ad ogni versione di struttura 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.
|
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.