Se fino ad ora abbiamo considerato prevalentemente la gestione degli schemi in presenza di versioning, la gestione dei dati estensionali relativi alle versioni è uno degli aspetti più problematici. Le scelte implementative analizzate in letteratura sono diverse, a seconda degli obbiettivi richiesti dall'ambito di utilizzo e delle semplificazioni che si possono imporre alla gestione dello Schema Versioning
Possiamo chiarire con un esempio i diversi livelli di intervento richiesti all'amministratore di un database relazionale in presenza di modifiche allo schema, mostrando i tre casi principali di supporto agli aggiornamenti che abbiamo introdotto e le operazioni di migrazione dei dati che vengono richieste.
Nell'esempio 1 viene creato lo schema di una nuova relazione (snapshot) e vengono inserite nel catalogo le corrispondenti informazioni.
CREATE TABLE IMPIEGATI
(NOME CHAR(10) NOT NULL PRIMARY KEY, INDIRIZZO CHAR(20), CITTA CHAR(10));
INSERT INTO IMPIEGATI
VALUES('Brown', 'King's road 15', 'London');
INSERT INTO EMPLOYEE
VALUES('Rossi', 'Via Veneto 7', 'Rome');
Nella tabella che segue viene mostrato il contenuto della relazione relativa allo schema , che dopo le operazioni eseguite nell'esempio 1 è diventato:
IMPIEGATI(NOME, INDIRIZZO, CITTA)
NOME INDIRIZZO CITTA
Brown
Consideriamo ora i cambiamenti nello schema:
ALTER TABLE IMPIEGATI DROP COLUMN ADDRESS;
ALTER TABLE IMPIEGATI ADD COLUMN TELEFONO CHAR(8);
ed esaminiamo quello che accade nelle tre tipologie di supporto ai cambiamenti dello schema.