next up previous contents index
Next: Soluzioni proposte Up: Problema dell'evoluzione degli schemi Previous: Evoluzione dei domini   Indice   Indice analitico

Evoluzione delle relazioni o delle classi

L'evoluzione delle relazioni e delle classi comprende la definizione, la ridefinizione e la cancellazione degli attributi, delle relazioni e delle classi, nel caso del paradigma dei database ad oggetti. Nel caso dei database ad oggetti in questo insieme di operazioni deve essere inclusa anche la modifica della gerarchia delle classi, nel caso si utilizzi una ereditarietà semplice, oppure del grafo aciclico (lattice) che rappresenta l'organizzazione delle classi, nel caso dell'ereditarietà multipla. All'interno del paradigma dei database temporali, invece, bisogna includere la disattivazione e la riattivazione degli attributi e delle relazioni/classi.

In letteratura esistono diverse proposte sulle modalità di gestione dei cambiamenti dello schema del database a livello delle relazioni e delle classi. Nell'ambito del paradigma ad oggetti un metodo consueto è quello di stabilire un insieme di invarianti per assicurare l'integrità semantica dello schema, ed un insieme di regole o di primitive per effettuare i cambiamenti dello schema ([LH90]). Nei database relazionali viene proposto un insieme di operazioni atomiche la cui composizione risulti consistente e porti a modifiche reversibili nella struttura del database ([ST82]).

In [RCR93] viene proposta una tassonomia per lo schema Versioning basata sul modello relazionale ed Entità Relazionale (ER). L'insieme di queste operazioni sono elencate nella tabella 2.2, suddivise per ogni categoria di evoluzione possibile.


Tabella 2.2: Una tassonomia per lo Schema Versioning basata sul modello relazionale
Tipo di evoluzione Operazioni

Evoluzione del dominio e degli attributi


Molte operazioni di modifica sugli schemi coinvolgono operazioni composte, quindi si suggerisce l'utilizzo di un meccanismo per il commit ed il rollback a livello dello schema (DDL), che dovrebbe essere separato dalle operazioni di commit e rollback a livello dei dati (DML). In aggiunta, le operazioni di commit a livello dei dati potrebbero non funzionare correttamente quando sono attive transazioni a livello dello schema. Se i dati da aggiornare possono non essere applicabili ad uno schema le cui modifiche non siano state ancora rese attive con il commit, non è corretto permettere gli inserimenti al di fuori dell'ambito della sessione corrente fino a quando i cambiamenti a livello di schema non sono stati eseguiti ed applicati. Questo porta alla necessità di completare la definizione e la popolazione degli attributi in una unica operazione atomica. L'algoritmo che segue, scritto in pseudo-codice, mostra un esempio della sequenza delle operazioni che possono essere eseguite come test per un programma che modifica e popola un attributo nella relazione di un database.


 Aggiungi un attributo alla relazione;

Popola l'attributo con i dati;
Esegui il commit a livello dei dati;
Esegui i programmi di test;
if (i test sono corretti)
{ Esegui il commit sul livello dello schema; }
else
{ Esegui il rollback sul livello dello schema; }
endif

Il controllo attraverso i programmi di test e la disponibilità delle operazioni di commit e rollback permettono di arrivare ad uno stato consistente sia in presenza di una esecuzione corretta, sia nel caso non vada a buon fine, tornando allo stato precedente della relazione.


next up previous contents index
Next: Soluzioni proposte Up: Problema dell'evoluzione degli schemi Previous: Evoluzione dei domini   Indice   Indice analitico
Alessandro Ronchi 2005-07-16