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 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:
[1/9/1990 - 6/30/94] IMPIEGATI(NOME, INDIRIZZO, CITTA)
NOME INDIRIZZO CITTA
Brown
[7/1/94 -
] 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.
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 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
nonostante lo schema non sia più attuale, e la nuova città sarà disponibile anche per le applicazioni che si basano su
.