Per supplire alla necessità di evitare perdita di informazioni, ed allo stesso tempo garantire il corretto funzionamento delle applicazioni che necessitano di lavorare su schemi multipli, lo Schema Evolution non è più sufficiente e diventa necessario il mantenimento di più di uno schema. Per questo motivo sono stati introdotti i concetti di Schema Versioning e Schema Version, a partire da [Rod95,JCE+94].
Anche nella sua forma più semplice, lo Schema Versioning richiede che sia mantenuta una storia dei cambiamenti per la gestione delle definizioni precedenti dello schema.
Una differenza significativa tra l'evoluzione ed il versioning è l'abilità per gli utenti di identificare dei punti e momenti di stabilità delle definizioni degli schemi ed etichettare le definizioni con i rispettivi istanti di validità per l'uso futuro. Lo Schema Evolution, invece, non richiede la possibilità di etichettare versioni degli schemi, fatta eccezione per il caso in cui ogni schema modificato venga considerato una nuova versione. In aggiunta non richiede che il DBMS fornisca un meccanismo per la visualizzazione delle passate definizioni degli schemi.
Non tutti i cambiamenti dello schema portano necessariamente ad una nuova versione della history. Tipicamente i cambiamenti dello schema saranno più frequenti delle versioni che verranno definite. Le nuove versioni verranno etichettate solo in istanti determinati, quando lo schema ha raggiunto una stabilità, oppure prima di altre modifiche sostanziali che si ritiene non possano fare parte della versione attuale.
Le versioni, inoltre, possono essere etichettate sia nel momento della modifica dello schema (transazione), sia attraverso un metodo definito dall'utente (commit).
Una differenza molto importante tra lo Schema Evolution e lo Schema Versioning si può notare nell'evoluzione dei domini degli attributi. Nello Schema Evolution in presenza di un cambiamento dei domini le istanze esistenti devono obbligatoriamente essere convertite al nuovo formato, e le applicazioni che si basano sulle vecchie strutture devono essere modificate. Nello Schema Versioning le definizioni esistenti vengono mantenute, mentre le modifiche vengono apportate solo all'ultima versione.
Lo Schema Versioning presenta una serie di problematiche relative all'aggiornamento dei dati attraverso gli schemi storici. La definizione dello schema versioning è quindi rifinita ulteriormente attraverso una distinzione tra le attività di recupero dei dati ed aggiornamento:
Il Full Schema Versioning può permettere di rendere asincrone le modifiche agli schemi. Seguendo un approccio di questo tipo è possibile vedere sia i vecchi dati sulle nuove definizioni degli schemi sia i nuovi inserimenti attraverso le vecchie definizioni. L'asincronia delle modifiche comporta notevoli vantaggi sul fronte della stabilità delle operazioni nel tempo, evitando una riscrittura delle applicazioni che manipolano e gestiscono questi dati, ma complica la gestione dei depositi e delle query che si appoggiano su schemi multipli.
Questo ci introduce ad un ulteriore livello di distinzione che raffina ulteriormente la scelta di un sistema per la gestione del versioning, presente quando le versioni dei dati intensionali e quelli estensionali vengono gestite attraverso la stessa dimensione temporale.
Nell'approccio che viene introdotto con questo lavoro di tesi, utilizzeremo il Partial Schema Versioning, visto che non si è ritenuto necessario permettere all'utente finale di inserire i nuovi dati nelle le versioni precedenti all'ultima.
Per quanto riguarda l'interrogazione e la gestione dei dati in presenza di versioni multiple degli schemi, in letteratura è stato introdotto il linguaggio TSQL2 [TSQ95], che rappresenta una estensione dell'SQL con il supporto alla gestione temporale. Tramite il TSQL2 viene permesso all'utente di scegliere la versione dello schema sulla quale lavorare, tramite la selezione dell'intervallo di validità:
SET SCHEMA DATE '31-12-2004'
E' chiaro che questo approccio semplifica notevolmente il problema, limitandone notevolmente le potenzialità, ed è utilizzabile nella pratica solo quando si utilizza la tecnica del completed-schema, sul quale ci soffermeremo in maniera più approfondita in seguito.
Le interrogazioni che permettono di prendere in esame versioni multiple degli schemi contemporaneamente sono state considerate in [DGS95] e [Gra02].