next up previous contents index
Next: Migrazione dei dati Up: Gestione dei dati estensionali Previous: Schema evolution   Indice   Indice analitico

Schema versioning

Se il nostro schema supporta invece lo schema versioning, assumiamo che la tabella IMPIEGATIsia stata creata in data 1/1/1990 ed il cambiamento nello schema $ S_1$ sia stato effettuato nel 7/1/1994. A questo punto, possiamo rappresentare gli effetti del cambiamento dello schema, che sono le due versioni risultati assieme alla loro vista sui dati della relazione IMPIEGATI:

$ SV_1$ [1/9/1990 - 6/30/94] IMPIEGATI(NOME, INDIRIZZO, CITTA)

NOME INDIRIZZO CITTA
Brown

$ SV_2$ [7/1/94 - $ \infty$] IMPIEGATI(NOME, CITTA, TELEFONO)

NOME CITTA TELEFONO
Brown

Dal punto di vista implementativo, nello Schema Versioning esistono due diversi tipi di approccio per la gestione ed il mantenimento delle versioni a livello estensionale ([TSQ95]): single-Pool e multi-pool.

Figura 2.1: Sistema di gestione dei dati estensionali Single-pool
Image singlepool

Definizione 7 (Single Pool)   Nella soluzione single pool (figura 2.1)tutte le versioni degli schemi sono associate ad un unico e condiviso deposito delle informazioni estensionali, in modo tale che gli stessi oggetti non possono avere differenti valori per le stesse proprietà quando vengono viste attraverso differenti versioni dello schema.

Definizione 8 (Multi Pool)   Nella soluzione multi-pool (figura 2.2) ogni versione di uno schema è associata ad una sorgente privata dei dati estensionali; sorgenti diverse possono contenere gli stessi oggetti ed eventualmente avere rappresentazioni ed evoluzioni completamente differenti.

Figura 2.2: Sistema di gestione dei dati estensionali Multi-pool
Image multipool

Sebbene la soluzione multi-pool risulti più flessibile, una soluzione single-pool viene solitamente considerata soddisfacente per l'implementazione, per esempio nel caso della tecnica del completed schema, presentato in [RS95,CGS97].

Secondo l'approccio definito nel completed schema, tutte le relazioni sono definite attraverso l'unione di tutti gli attributi che vengono definiti su di loro, incluse quelle che successivamente vengono cancellate. Il DROP delle colonne non elimina fisicamente i dati, ma li disattiva in una determinata versione. Il linguaggio TSQL2 permette di visualizzare il contenuto di tutta la relazione associata al suo completed schema, attraverso l'uso dei doppi asterischi nel comando SELECT:

SELECT ** FROM IMPIEGATI

Seguendo l'esempio della tabella degli impiegati, il risultato della query precedente risulterebbe essere:

NOME INDIRIZZO CITTA TELEFONO
Brown

In questo modo, non è necessario effettuare nessuna modifica al modello dei dati. Di fatto, questo modello di Schema Versioning non introduce nessun livello di versioning dei dati e può essere basato sul meccanismo classico delle viste. In questo caso, però, non esistendo due diverse versioni delle tuple relative agli stessi impiegati, viene impedita la possibilità di avere due città diverse nelle due versioni. Questo chiarisce ulteriormente il significato delle diverse dimensioni temporali: sebbene lo schema $ SV_1$ sia relativo allo spazio temporale [1/9/1990 - 6/30/94], i dati relativi alle tuple possono essere aggiornati anche successivamente. Se nel 1995 verrà modificata la città di residenza di un impiegato, il dato verrà aggiornato anche nelle relazioni corrispondenti ad $ SV_1$ nonostante lo schema non sia più attuale, e la nuova città sarà disponibile anche per le applicazioni che si basano su $ SV_1$.


next up previous contents index
Next: Migrazione dei dati Up: Gestione dei dati estensionali Previous: Schema evolution   Indice   Indice analitico
Alessandro Ronchi 2005-07-16