ModelGen

1. ModelGen Model indipendent schema translation

2. ModelGen • Dato uno schema sorgente S1 nel modello sorgente M1 ed un modello destinazione M2, ModelGen genera lo schema (destinazione) S2 nel modello M2. • La definizione di Bernstein dice che oltre S2 l’operatore restituisce il mapping tra i due schemi. Per ora trascuriamo questo aspetto.

3. ModelGen: il SuperModello • Atzeni e Torlone hanno proposto, nel ’96, uno strumento CASE per la gestione di schemi eterogenei basato sul concetto di metamodello. • Un metamodello è un insieme di costrutti che può essere usato per definire modelli. Un modello generalmente sfrutta un sottoinsieme dei costrutti presenti nel metamodello. • Osservazione fondamentale (Hull e King): i costrutti usati nei modelli dei dati più noti/usati possono essere espressi da un insieme molto ristretto di costrutti generici (model-indipendent) che possiamo chiamare metacostrutti. • Esempio: i costrutti Entity e Class sono espressi dal metacostrutto Abstract; gli attributi delle entità e delle classi sono espresse dal metacostrutto AttributeOfAbstract; le relazioni tra le entità e tra le classi sono espresse dal metacostrutto AggregationOfAbstract; ecc. • l’insieme dei metacostrutti permette la definizione di costrutti, e quest’ultimi di modelli: l’insieme dei metacostrutti costituisce quello che possiamo definire un SuperModello.

4. ModelGen: le traduzioni • Le trasformazioni tra schemi in modelli diversi comportano la definizione di regole di traduzione da costrutti dello schema sorgente a costrutti dello schema destinazione. • Se siamo così bravi da definire i costrutti a partire dai metacostrutti, allora possiamo definire le regole di traduzione tra i metacostrutti (che sono model-indipendet). • È proprio quello che facciamo! Il tool permette la definizione di nuovi modelli (insieme di costrutti) a partire dai metacostrutti a disposizione nel supermodello. • L’enorme vantaggio è di dover scrivere le traduzioni tra i metacostrutti una sola volta, per poi sfruttarle sui costrutti dei possibili modelli definibili. • Importante: meno di dieci metacostrutti permettono di rappresentare la stragrande maggioranza dei modelli dei dati più diffusi e usati.

5. ModelGen: le traduzioni • Definiamo elementari le traduzioni tra i singoli metacostrutti. • Allora le trasformazioni verso uno schema destinazione possono essere definite come un insieme/sequenza di traduzioni elementari. • Obiettivo delle traduzioni elementari è eliminare i costrutti (o metacostrutti) non ammissibili nel modello destinazione con altri ammissibili • Nella pratica può capitare che la eliminazione di un singolo costrutto richieda più passi elementari: abbiamo una composizione.

6. ModelGen: processo di traduzione • I costrutti dei singoli modelli sono fortemente legati ai metacostrutti del SuperModello. • È “banale” rappresentare lo schema S1 coi metacostrutti del SM associati ai costrutti del modello M1 (salgo verso il SM). • All’interno del SM ho a disposizione le regole di traduzione tra metacostrutti: applico quelle che “mi interessano” (opero nel SM) • Ottenuta una rappresentazione adeguata, ovvero che fa uso dei soli metacostrutti associati ai costrutti del modello M2, è “banale” ottenere lo schema S2 nel modello destinazione M2 (scendo dal SM).

7. ModelGen: osservazioni • Il tool sviluppato nel ’96 è capace di eseguire queste operazioni • Tuttavia il SM come anche le regole di traduzione sono fortemente in esso cablate (stanno nel codice) • Questo rende difficilissimo estendere, modificare, personalizzare, il SM, i modelli e le regole di traduzione: bisogna conoscere il codice (che ha scritto qualcun altro: un botto!) • Allora si è deciso di rivoluzionare la situazione spostando l’attenzione alla gestione dei metadati

8. I metadati di ModelGen: il dizionario • Abbiamo quattro parti: • Il MetaSuperModello (descrizione del SM) • Il SuperModello (SM) • I MetaModelli (descrizione dei modelli) • I Modelli

11. Database dei metadati MSM_Attributes MM_Attributes MSM_Tables MM_Tables Models MSM_References MM_References

12. Usare i metadati • Le informazioni a disposizione permettono: • La generazione dei metacostrutti (SM) • La generazione dei costrutti dei modelli • Conoscere la corrispondenza tra i costrutti (e tra i loro attributi); (automatica…) • Identificare i modelli

13. Cosa fa il tool • Abbiamo adottato una implementazione basata su database relazionale: usiamo l’SQL. • Il tool è capace di generare gli statement SQL necessari per creare i metacostrutti ed i costrutti. Vedi. • Note le corrispondenze tra metacostrutti e costrutti, il tool è capace di generare gli statement necessari a realizzare la “copia” degli schemi da un modello verso il SuperModello e viceversa. Vedi ER-2, Relazionale. • Genera anche gli statement di copia interni al SuperModello, necessari nei casi in cui modello di partenza e di arrivo condividono alcuni metacostrutti (la traduzione avviene nel SuperModello). Vedi.

14. Le regole: SM_AttributeOfAggregationOfLexicals (attributeOID_1(attributeOID), name, aggregationOID_1(abstractOID), isNullable, isKey) SM_AttributeOfAbstract(attributeOID, name, abstractOID, isNullable, isID) INSERT INTO SM_AttributeOfAggregationOfLexicals( attributeOID, name, aggregationOID, isNullable, isKey) SELECT attributeOID_1(var1.attributeOID), var1.name, aggregationOID_1(var1.abstractOID), var1.isNullable, var1.isID FROM SM_AttributeOfAbstract var1 WHERE var1.schemaOID = ?2

15. Le funzioni di Skolem • Servono a generare i nuovi identificatori • Vediamo qualche esempio

16. INSERT INTO SM_AttributeOfAggregationOfLexicals( attributeOID, name, aggregationOID, isNullable, isKey, SchemaOID) SELECT newVar1.attributeOID, var1.name, newVar2.aggregationOID, var1.isNullable, var1.isKey, ?1 AS SchemaOID FROM SM_AttributeOfAbstract var1, SM_AggregationOfLexicals_SK newVar2, SM_AttributeOfAggregationOfLexicals_SK newVar1 WHERE var1.schemaOID = ?2 AND var1.abstractOID = newVar2.abstractOID AND newVar2.schemaOID = ?1 AND var1.attributeOID = newVar1.attributeOIDold AND newVar1.schemaOID = ?1 AND NOT EXISTS ( SELECT * FROM SM_AttributeOfAggregationOfLexicals varNotExists WHERE varNotExists.attributeOID = newVar1.attributeOID )

17. Dal datalog con OID-invention allo SQL eseguibile • È possibile passare dal datalog all’SQL, pertanto so passare dal datalog con OID-invention al SQL con OID-invention • Abbiamo realizzato una funzione che traduce l’SQL con OID-invention in SQL eseguibile (a meno dei parametri: schema sorgente e schema destinazione) • Il datalog è ricorsivo: abbiamo introdotto nel tool un costrutto per l’iterazione fino al punto fisso; è per questo che tutte le regole hanno una clausola NOT EXIST: serve a non creare duplicati che impedirebbero il raggiungimento del punto fisso.

18. Composizione di regole • Le regole elementari devono essere composte in una serie più o meno ordinata al fine di ottenere una traduzione completa. • Ad esempio nel passare dall’ER-2 al relazionale devo prima tradurre le entità in tabelle, poi gli attributi delle entità, poi le relazioni, prima le molti a molti, poi le altre, ecc. • Esempio regola complessa • Esempi regola semplice 1, 1_SK, 2

19. Punti di forza • I metadati: • Vedo i metacostrutti ed i costrutti dei modelli • Vedo le corrispondenze tra metacostrutti e costrutti • Posso facilmente estendere il SM e creare nuovi modelli: inserisco tuple nelle tabelle! • Posso facilmente modificare le corrispondenze (ad es. a causa di una modifica ai costrutti del SM) • Le regole: sono visibili! • La correttezza può essere verificata anche senza fare un test di traduzione (leggo la regola) • Sono di semplice comprensione: sono compatte e chiare… • In quanto visibili possono essere personalizzate: la scrivo come voglio.

20. Categorie d’utenza • Progettista: • Sceglie il modello sorgente e crea uno schema • Sceglie un modello destinazione e applica l’operatore ModelGen • Ingegnere dei modelli: • Crea nuovi modelli • Crea regole complesse e regole personalizzate • Ingegnere del SuperModello: • Estende e modifica il SuperModello • Crea le regole semplici di traduzione tra i metacostrutti • Deve essere molto esperto perché è lui che deve inventare nuove regole qualora quelle già presenti non siano sufficienti. • Nota: poter vedere i metadati e le regole semplifica fortemente i compiti; ci si può concentrare sugli aspetti di interesse trascurando (totalmente) gli aspetti tecnologici realizzativi.

21. Spunti per progetti • Descrizione UML dei requisiti del progetto ModelGen • Gestione dei metadati: • Modulo di interfaccia che permetta: • la creazione di nuovi metacostrutti • la creazione di nuovi costrutti (sulla base dei metacostrutti) con costruzione automatica delle corrispondenze • Studio/Sperimentazione della modifica (ALTER TABLE) dei metacostrutti; questa modifica comporta la rivisitazione delle corrispondenze coi costrutti dei modelli (che non devono cambiare). • Gestione regole: • Studiare i metadati per le regole per poterli usare al fine di avere una certa “capacità di ragionamento” per la composizione delle regole (costruire sequenze corrette). • Gestione della personalizzazione delle regole. Esistono più modi di rimuovere un costrutto (o metacostrutto): l’utente deve poter scegliere sia quale modo applicare sia su che intervallo di valori; ai restanti valori sarà applicato un altro dei modi a disposizione. • Studio/modulo identificazione delle regole applicabili per passare da un determinato modello ad un altro.