Rondo Automed

Università degli Studi di Salerno
Corso di Laurea Specialistica in Informatica
Corso di Basi di Dati 2
Gli approcci Rondo e Automed

Docente: Studente
Studente:
Prof. Giuseppe Polese Giovanni Cannizzaro
Matricola 0521000857
Anno Accademico 2009-2010

2009
Gli approcci Rondo e Automed BD2
Sommario
Introduzione ............................................................................................................... 4
1. Rondo..................................................................................................................... 6
2. Scenario ................................................................................................................. 8
3. Strutture ............................................................................................................... 12
3.1 Modelli............................................................................................................ 12
3.2 Morphisms (morfismi) .................................................................................... 13
3.3 Selectors (selettori).......................................................................................... 15
4. Operatori .............................................................................................................. 16
4.1 Operatori Primitivi .......................................................................................... 16
4.2 Extract e Delete ............................................................................................... 18
4.3 Match .............................................................................................................. 19
4.4 Merge .............................................................................................................. 19
5. Implementazione .................................................................................................. 20
5.1 Extract e Delete ............................................................................................... 20
5.2 Match .............................................................................................................. 22
5.3 Merge .............................................................................................................. 23
6. Automed .............................................................................................................. 27
7. HDM .................................................................................................................... 28
7.1 Modellare i linguaggi di alto livello in HDM .................................................. 29
8. Il wrapper Automed XML-Schema ...................................................................... 32
8.1 Le trasformazioni HDM .................................................................................. 33
8.2 Trasformazioni tra XML-Schema e HDM ....................................................... 34
2
8.3 Trasformazioni tra HDM e SQL ...................................................................... 35
9. XSDOM ............................................................................................................... 36
9.1 Conversione da XML Schema API a XSDOM ................................................ 36
9.2 Da XSDOM a Automed XML-Schema ........................................................... 38
9.3 Da Automed XML-Schema a XSDOM ........................................................... 38
9.4 Da XSDOM a JTree ........................................................................................ 39
9.5 Materializzare l’Automed XML-Schema ........................................................ 40
9.6 Creazione di tabelle SQL ................................................................................ 42
Confronto tra Rondo e Automed .............................................................................. 43
Confronto tra le categorie di approcci ...................................................................... 44
Conclusioni .............................................................................................................. 45
Riferimenti ............................................................................................................... 47
3
Introduzione
In questo documento verranno presentate due piattaforme per la sincronizzazione delle viste, Rondo
e Automed. Rondo è un prototipo che si occupa di implementare gli operatori del model
management al fine di automatizzare il più possibile l’esecuzione di questo tipo di operazioni.
Automed è un framework che si occupa della modellazione e dell’integrazione dei linguaggi di
modellazione, e verrà presentato un lavoro di manipolazione su schemi XML. Uno degli obiettivi
principali del model management è quello di ridurre la quantità di programmazione necessaria per
lo sviluppo di applicazioni ad alta intensità di metadati. Tali applicazioni vengono distribuite nel
contesto della progettazione di database, di data integration, di conversione dei dati, dei data
warehouse, ecc. Esse manipolano una varietà di manufatti e metadati che prendono il nome di
modelli, come ad esempio modelli relazionali e schemi XML. Molte delle normali operazioni di
model management vengono ancora svolte manualmente, questo perché un approccio automatizzato
richiede uno sforzo di implementazione troppo elevato a causa della mancanza di una piattaforma di
programmazione comune.
I ricercatori di database e di ingegneria del software hanno studiato dettagliatamente i singoli aspetti
di model management per decenni. Tuttavia, i dettagli sugli aspetti comuni del model management
sono divenuti oggetto attivo di ricerca solo recentemente [7]. Uno degli obiettivi principali della
recente ricerca è stato quello di sviluppare un insieme di operatori algebrici, come Compose, Match
e Merge, che generalizzano le operazioni di trasformazione utilizzate tra le diverse applicazioni.
Questi operatori vengono applicati generalmente a modelli e mappature, piuttosto che a singoli
elementi, semplificando la programmazione di applicazioni ed innalzando il livello di astrazione.
Inoltre, gli operatori sono generici in quanto possono essere utilizzati per diversi tipi di modelli e
scenari. Anche se molti dei compiti del model management possono essere automatizzati, restano
delle situazioni critiche in cui le decisioni umane sono necessarie; così, parte delle operazioni è
semiautomatica e richiede il feedback di un utente, prima, durante o dopo l'esecuzione.
L’obiettivo dei ricercatori è quello di scoprire se la gestione dei metadati può essere svolta in
maniera generica. Sono state esaminate varie procedure sui problemi di model management in
maniera dettagliata per affrontare questa questione [5,9]. Come risultato di queste ricerche è stata
realizzata una piattaforma, Rondo, che verrà descritta in questo documento insieme alle strutture
concettuali ed agli operatori che sono stati sviluppati per realizzarla. Questo prototipo supporta,
innanzitutto, lo sviluppo di soluzioni di model management, fornendo un ambiente di
programmazione ad alto livello. Tuttavia gli sviluppatori si sono occupati anche della necessità
4
degli utenti che utilizzeranno queste soluzioni, offrendo loro una interfaccia utente grafica (GUI)
per gestire il feedback delle operazioni semiautomatiche.
La recente crescita del commercio elettronico e la necessità di trasferire dati su Internet ha
comportato il bisogno di uscire dal modello restrittivo di rappresentazione dei dati stessi. XML [39]
è emerso come lo standard dominante per la rappresentazione e lo scambio di questi dati, in modo
tale che un meccanismo per lo spostamento di dati da RDBMS a XML e viceversa sia divenuto un
settore di studio molto importante.
In questo documento verrà presentata questa operazione utilizzando il framework Automed.
L’approccio utilizza un linguaggio comune di basso livello che rappresenta la semantica di entrambi
i linguaggi di modellazione. Le trasformazioni all'interno del linguaggio di basso livello consentono
di creare una mappatura del linguaggio sorgente. Questo tipo di approccio ha il vantaggio di astrarre
i linguaggi di modellazione riducendo notevolmente la difficoltà del procedimento stesso. Un
ulteriore vantaggio è che, una volta che un linguaggio di modellazione è stato specificato dal
linguaggio di basso livello esso può essere convertito in qualsiasi altro linguaggio che è stato già
specificato in basso livello. Il modello di dati Hypergraph (HDM) [28] è uno di questi linguaggi ed
è stato utilizzato per questo scopo.
Esso ha l'ulteriore vantaggio di essere di natura grafica, cosa molto positiva in quanto gli utenti
preferiscono di gran lunga interpretare dati grafici che non dati testuali. Utilizzare una
rappresentazione grafica di due modelli differenti rende inoltre molto più facile notare le
somiglianze e le differenze tra loro. Esistono già un certo numero di strumenti in grado di migrare i
dati tra XML e RDBMS [30, 34, 41, 42], ma molti di essi soffrono dello svantaggio di dover
rappresentare in anticipo lo schema XML, e per un complesso insieme di dati questo può essere un
compito lungo e difficile. Quindi, uno strumento che rileva automaticamente un preciso schema
XML direttamente dallo schema relazionale è ovviamente molto utile. Questo campo di ricerca è
abbastanza recente e sono stati elaborati solo un paio di strumenti che svolgono questo lavoro [25,
27]. Durante questo procedimento è anche molto importante scegliere un formato per descrivere
adeguatamente lo schema XML. Fino a poco tempo fa, ciò era molto difficile, in quanto venivano
utilizzati in questo ambito i Document Type Definition (DTD), essi infatti avevano una serie di
svantaggi; infatti la specifica di un DTD è scritta con sintassi non-XML ed offre solo dati limitati.
XML-Schema [40] è emerso come standard per la definizione di schemi XML. Si tratta di un
potente standard globale che supporta varie tipologie di dati e permette la creazione di ulteriori tipi
complessi. Verrà presentato attraverso il framework Automed, un metodo per trasferire dati da un
formato XML in un RDBMS e viceversa basato su XML-Schema utilizzando come intermediario
HDM.
5
1. Rondo
Il Model Management mira a ridurre la quantità di programmazione necessaria allo sviluppo di

applicazioni ad alta densità di metadati. Iniziamo con il descrivere Rondo, un prototipo completo di
sistema generic model management, in cui vengono utilizzati gli operatori di alto livello per
manipolazione di modelli e di mapping tra modelli. L’architettura di Rondo è mostrata in Figura 1.
Il componente principale è l’interprete che esegue gli script. Esso può essere eseguito da riga di
comando, o invocato da applicazioni e tool esterni; il suo compito è quello di orchestrare il flusso di
dati tra gli operatori.
Gli operatori possono essere definiti mediante un'implementazione nativa, oppure per mezzo degli
stessi script. Ad esempio, un operatore nativo come ReadSQLDDL legge un documento di testo
contenente le definizioni di un database relazionale e crea il grafo di rappresentazione, mentre
WriteSQLDDL esporta il grafo come testo; allo stesso modo, due operatori nativi ReadDb e
WriteDb caricano e memorizzano i grafi direzionati in un DBMS SQL. Gli operatori nativi sono
definiti negli script utilizzando istruzioni come alias ReadSQLDDL <Java class name>. Altri
operatori, invece, sono stati implementati in modo nativo, come gli operatori che lanciano GUI per
editare morfismi e selettori (EditMap o EditSelector), quelli che eseguono la traduzione dello
schema, gli operatori di conversione e gli operatori SFjoin e GraphMerge. Tutti gli altri operatori,
come Range, Match o Merge, sono implementati tramite script, come vedremo nei paragrafi
successivi. La specifica degli operatori nativi o derivati può essere raggruppata in un unico script e
può essere utilizzato in altri.
FIGURA 1: Architettura del prototipo
6
L'interprete offre una struttura che permette il debug esaminando le tracce d’esecuzione di script
complessi, e supporta una gestione flessibile dei parametri degli operatori di input ed output. Ad
esempio, se un operatore restituisce più argomenti (implementazione dell’operatore Match), alcuni
dei quali non sono utilizzati successivamente (script PropagateChanges par 2), questi possono
essere tacitamente ignorati. Allo stato attuale, il prototipo supporta le funzionalità di base di SQL
DDL, XML, degli schemi RDF, delle viste SQL, e in forma preliminare UML. Per inserire un
nuovo linguaggio di modellazione nel prototipo, sono necessari due passi: in primo luogo, devono
essere forniti gli operatori import / export, i quali devono garantire una conversione senza perdita
dati dal formato nativo alla conversione in grafo e viceversa; in secondo luogo, callback diverse
devono essere implementate per supportare gli operatori All, Extract, e GraphMerge. Gran parte
dello sforzo di implementazione è stato rivolto alla realizzazione delle API, responsabili della
rappresentazione in memoria, della manipolazione di grafi e morfismi e del supporto per i database.
Le funzionalità chiave di questo prototipo per il generic model management raggiungono circa le
7mila righe di codice. Esse comprendono l'interprete (2050 righe di codice), gli operatori primitivi
(660 righe), le implementazioni di SFjoin (1760 righe) e di GraphMerge (700 righe), così come gli
operatori generici GUI (1400 righe). La parte non generica è sostanzialmente divisa tra il codice
necessario per supportare SQL DDL, gli schemi XML, e le viste SQL. La più piccola porzione di
codice è composta dai convertitori: XSD2SQL (260 righe), SQL2XSD (250 righe),
View2Morphism (90 righe), e Morphism2View (200 righe). La loro compattezza è dovuta
principalmente al fatto che operano sull’intero grafo di rappresentazione mediante query espressive.
La quantità totale delle righe di codice di Rondo è inferiore a 24mila, mentre il totale delle righe di
codice degli script sviluppati finora è dell’ordine delle centinaia.
7
2. Scenario
Per illustrare la definizione degli operatori che saranno utilizzati in questa prima parte del
documento verrà usato lo scenario della Figura 2, che mostra uno dei pattern più comuni nelle
applicazioni ad alta intensità di metadati. In particolare, lo scenario in figura è relativo ad una
società di e-commerce che ha bisogno di fornire i propri dati relativi agli ordini di acquisto ad un
business partner. I dati sono memorizzati in un database relazionale secondo uno schema
relazionale s1 come indicato in Figura 2. Ai fini dello scambio di dati, entrambe le imprese
decidono di utilizzare uno schema XML comune che chiameremo in figura d1 (Le corrispondenze
tra gli elementi degli schemi s1 e d1 sono rappresentati come linee chiare). Lo schema d1 differisce
da s1 in termini di struttura e di naming.
Uno schema relazionale subisce però variazioni periodiche per effetto della natura dinamica del
business. Supponiamo che s2 è una nuova versione di s1, in cui le colonne "Brand" e "Discount"
sono state eliminate, mentre le colonne "ShipDate", "FreightCharge" e "Rebate" sono state
aggiunte; la colonna "UnitPrice" è stata rinominata in "Price". Questi cambiamenti (elementi
sottolineati) necessitano di essere propagati nello schema XML, in modo che d1 diventi d2.
La propagazione delle modifiche elencate sopra può essere fatta nel modo seguente: in primo luogo,
le modifiche apportate da s2 devono essere rilevate, vale a dire, che s1 e s2 devono essere
confrontati; successivamente, gli elementi eliminati in s1 devono essere rimossi da d1. Infine, le
modifiche nello schema XML delle colonne aggiunte e delle colonne rinominate di s1 hanno
bisogno di essere inserite in d1 per ottenere d2. Durante questi passaggi, può essere richiesto
l’intervento dell’utente, per decidere ad esempio, se la nuova colonna "Rebate" dovrebbe
effettivamente essere aggiunta allo schema o se non fa parte del procedimento e dovrebbe essere
omessa. Tuttavia, una parte importante del lavoro è meccanica e può essere automatizzata.
Si noti che la procedura appena descritta potrebbe essere applicata anche nel caso inverso, ossia
quando è lo schema XML d1 quello ad essere stato modificato, e le sue modifiche si dovranno
propagare all’indietro sullo schema relazionale s1. Un'idea di fondo del model management è quella
di risolvere tali compiti ad un livello elevato di astrazione utilizzando uno script generico.
8
FIGURA 2: Scenario che illustra la propagazione delle

modifiche da un relazionale a uno schema XML
Qui di seguito viene presentato uno script che implementa la soluzione vista in precedenza. Lo
script verrà usato per introdurre i principali operatori del model-management, che verranno definiti
nei paragrafi successivi. Per spiegare i singoli passaggi dello script, useremo una rappresentazione
schematica mostrata nella Figura 3.
FIGURA 3: Rappresentazione schematica per la risoluzione della

propagazione delle modifiche dello scenario in Figura 2
9
I rettangoli contrassegnati con s1, s2, d1, e d2 rappresentano i quattro schemi della Figura 2. Gli
archi tra i rettangoli indicano il mapping tra gli schemi. Per esempio, le corrispondenze tra gli
schemi s1 e d1 sono indicate da un unico arco dal rettangolo s1 a quello d1. Nella parte inferiore
della figura, vi è uno schema c, che non compare nella figura 2. Per capire il perché esso è
necessario, bisogna ricordare che s1 e d1 sono realizzati usando due linguaggi di schema differenti.
Inoltre, un nuovo elemento dello schema aggiunto ad s1 tramite s2 non ha controparti nello schema
d1, quindi, i nuovi elementi devono essere convertiti dallo schema di origine a quello di
destinazione. Si noti che lo schema c non è ancora il risultato desiderato d2, poiché può contenere
uno o più tipi non necessari, che possono differire da d1 strutturalmente.
operator PropagateChanges(s1, d1, s1_d1, s2, c, s2_c)

1. s1_s2 = Match(s1, s2);
2. 〈d1′, d1′_d1〉 = Delete(d1, Traverse(All(s1) − Domain(s1_s2), s1_d1));
3. 〈c′, c′_c〉 = Extract(c, Traverse(All(s2) − Range(s1_s2), s2_c));
4. c′_d1′ = c′_c ∗ Invert(s2_c) ∗ Invert(s1_s2) ∗ s1_d1 ∗ Invert(d1′_d1);
5. 〈d2, c′_d2, d1′_d2〉 = Merge(c′, d1′, c′_d1′);
6. s2_d2 = s2_c ∗ Invert(c′_c) ∗ c′_d2 + Invert(s1_s2) ∗ s1_d1 ∗ Invert(d1′_d1) ∗ d1′_d2;
7. return 〈d2, s2_d2〉;
Nello script si definisce un operatore generico PropagateChanges, che prende sei parametri in input
(tra cui lo schema c), e produce due valori di ritorno <d2, s2_d2> come output. Nella riga 1, gli
schemi s1 e s2 sono confrontati per rilevare le modifiche. Il risultato è una mappatura s1_s2. In
modo informale, la mappatura collega gli elementi equivalenti di s1 e s2. Nella riga 2 si può
osservare come gli operatori possono essere combinati. In primo luogo, gli elementi eliminati di s1
sono identificati mediante l'espressione All (s1) - Domain (s1_s2), cioè tutti gli elementi di s1 senza
riscontri. Quindi, questi elementi sono usati per "attraversare" la mappatura s1_d1. Infine, le
immagini degli elementi eliminati vengono rimossi da d1 con l’operatore Delete. Il risultato è un
nuovo schema d1' (un sottoschema di d1), e una mappatura d1'_d1, che descrive come d1' si
riferisce a d1. La riga 3 è abbastanza simile alla 2. I nuovi elementi di s2, vale a dire, quelli
mancanti dal range di s1_s2, attraversano s2_c tramite il modello di conversione c. Viene creato un
"sottoschema" c' contenente le immagini dei nuovi elementi che sono stati estratti da c utilizzando
l’operatore Extract, che restituisce anche la mappatura c'_c. Oltre agli elementi ottenuti con
l'attraversamento, c' contiene elementi extra di c, come i tipi complessi, al fine di rendere c' uno
schema XML ben formato. Tali elementi extra sono chiamati "elementi di supporto"[5]. A questo
punto, d1' è un sottoschema di d1 senza elementi cancellati, e c' contiene gli elementi aggiunti e gli
elementi di supporto. Bisogna unire gli schemi d1' e c' per ottenere come risultato finale d2 (riga 5).
10
La mappatura tra d1' e c' è mostrata in figura 3 come un arco che collega i due rettangoli chiusi.
Questa mappatura può essere ottenuta "componendo" i mapping tra c', c, s1, s2, d1, e d1' come
c′_c * Invert(s2_c) * Invert(s1_s2) * s1_d1 * Invert(d1′_d1). Per ottenere la giusta composizione,
le mappature s2_c, s1_s2 e d1'_d1 devono essere "invertite", cioè i domini e il range del mapping
devono essere scambiati. Il risultato finale della propagazione delle modifiche, lo schema d2, è
calcolato dall’operatore Merge. Inoltre, l'operatore restituisce due mappature, c'_d2 e d1'_d2, che
descrivono come d2 si riferisce agli input di Merge, c' e d1'. Come ultimo passo, si calcola s2_d2,
una nuova versione della mappatura di s1_d1 data come parte dell'input. Abbiamo bisogno di s2_d2
per garantire che lo script di propagazione delle modifiche possa essere ri-applicato se lo schema
originale evolve ancora. Poiché d2 si ottiene dalla fusione di d1' e c'; la mappatura s2_d2 è
essenzialmente un’unione di due mappature, quella tra s2 e la porzione d1' di d2 e quella tra la s2 e
la porzione c' di d2. Queste due mappature possono essere ottenute rispettivamente dalla
composizione di s2_c * Invert(c′_c) * c′_d2 e Invert(s1_s2) * s1_d1 * Invert(d1′_d1) * d1′_d2.
Si noti che lo script non si limita alla propagazione delle modifiche da schemi relazionali in schemi
XML. Infatti, il processo di propagazione inverso può essere effettuato utilizzando lo stesso script,
assegnando gli schemi originali, le modifiche XML per s1 e s2 e lo schema relazionale per d1.
Naturalmente, l'input dei parametri c e s2_c devono essere ottenuti utilizzando un convertitore
diverso. Ogni risultato intermedio di uno script può essere esaminato e regolato dall’utente
utilizzando uno tool grafico. In particolare, il risultato del Match nella riga 1 può essere post-
processato per rimuovere suggerimenti errati ed aggiungere elementi mancanti. Allo stesso modo, la
fusione nella riga 5 è in generale, un processo semiautomatico, che richiede feedback umano.
Infine, regolando i risultati intermedi degli operatori di composizione nelle righe 2 e 3, l’utente può
decidere quali integrazioni e/o cancellazioni non devono essere propagate. Fino ad ora sono stati
citati diversi operatori informali. Per rendere efficaci questi operatori e renderli utilizzabili dagli
sviluppatori, la loro semantica deve essere specificata con precisione. Come già detto in precedenza
l’obiettivo dei realizzatori di Rondo è di rendere la semantica più "generica" possibile, in modo che
gli operatori possano essere usati per una vasta gamma di compiti.
11
3. Strutture
Le applicazioni di model management hanno a che fare con una vasta gamma di artefatti di
metadati. Le descrizioni formali, o i modelli, di questi artefatti vengono rappresentati attraverso
grafi direzionati etichettati. Questo tipo di rappresentazione è molto flessibile e può realizzare
virtualmente qualunque tipo di modello. Verranno usate due ulteriori strutture, morphisms
(morfismi) e selectors (selettori). I morfismi sono relazioni binarie che stabiliscono corrispondenze
n:m tra gli elementi di due modelli. La terza struttura, il selettore, è un insieme di elementi utilizzati
nei modelli. Un notevole vantaggio nell’ utilizzare i selettori, è che operazioni diverse, in
particolare le operazioni di Set, che in genere producono modelli che non sono ben formati, se
utilizzate direttamente, possono essere applicati ai selettori in modo sicuro.
3.1 Modelli
Come detto in precedenza i modelli vengono rappresentati come grafi direzionati etichettati. I nodi
dei grafi denotano gli elementi del modello, come le relazioni e gli attributi degli schemi relazionali,
le definizioni dei tipi negli schemi XML, e clausole di istruzioni SQL. Partiamo dal presupposto che
ogni elemento è identificato univocamente da un identificatore di oggetto (OID). Un grafo
direzionato etichettato è un insieme di archi <s, p, o> dove s è il nodo di origine, p è l'etichetta
dell’arco ed o è il nodo target. Per una sorgente s ed un etichetta p i nodi target possono essere
ordinati in sequenza. Il loro ordine può essere catturato da una proprietà ordinale sugli archi. Così,
concettualmente un grafo può essere visto come una relazione M con quattro attributi, M (S: OID,
P: OID, O: OID ∪ Literal, N: integer), dove N è un attributo facoltativo utilizzato per
l’ordinamento e S, P, O formano una chiave univoca. Gli identificatori dei nodi e le etichette degli
archi sono ottenuti dal set di OID. Essi possono essere implementati come interi, puntatori, ecc. I
literal comprendono stringhe, interi, valori in virgola mobile, ed altri tipi di dati. Il tipo di attributo
O è definito come una unione tra i tipi OID e literal.
12
FIGURA 4: Esempio che mostra un modello di grafo e 4 Tuple
Si consideri l'esempio in Figura 4. Esso illustra come una tabella relazionale PRODUCTS definita
in SQL DD è rappresentata sotto forma di grafo e come un insieme corrispondente di 4-tuple. Gli
ovali in OID denotano il grafo, ed i rettangoli denotano i literal. I nodi a1, a2, a3 rappresentano
rispettivamente la tabella PRODUCTS e le sue colonne PID e PNAME. Il nodo a4 rappresenta il
vincolo di chiave primaria su PID. Per facilitare la lettura, gli identificatori come Table o Column
sono specificati come nomi piuttosto che come ID. L'ordine delle colonne individuate dai nodi a2 e
a3 è determinato dai valori 1 e 2 dell’attributo N (quarto attributo della tabella con 4-tuple).
Una specifica formale delle regole per codificare un modello come un grafo è chiamata
meta-model.
Un modello è ben formato se è conforme al suo meta-model. Per esempio, la figura 4 mostra un
grafo codificato da schemi relazionali che utilizza specifici archi etichettati, come tipi SQL o nomi,
e nodi ausiliari, come Table, varchar o PrimaryKey. Se conosciamo il meta-model relazionale,
possiamo affermare se un dato grafo rappresenta uno schema relazionale ben formato.
3.2 Morphisms (morfismi)
Molte applicazioni ad alta intensità di metadati, come i tool di data warehouse e data integration,
usano una metafora grafica simile a quella mostrata nella Figura 4 per la rappresentazione dello
schema di mapping. Queste mappature appaiono all’utente come insiemi di linee di collegamento
degli elementi di due schemi. Questo tipo di schema è un morfismo, ossia una relazione binaria su
due serie di OID (eventualmente sovrapposte), cioè un insieme di coppie <l, r> ottenuto da OID ×
13
OID. Chiaramente, un morfismo è una rappresentazione più debole rispetto ad una vista SQL o ad
un linguaggio di mapping [3,5,14,19,20]. In particolare, un morfismo non possiede informazioni
sulla trasformazione semantica delle istanze che sono conformi ai modelli. Tuttavia, si è scoperto
che molte mappature possono essere espresse tramite questa rappresentazione.
I morfismi hanno molti altri vantaggi, possono rappresentare una mappatura tra diversi tipi di
modelli, ad esempio, tra uno schema relazionale e uno XML. Un morfismo può sempre essere
invertito e composto. Inoltre, potendo essere espressi come relazioni binarie, i morfismi possono
essere facilmente manipolati.
FIGURA 5: Morfismo tra uno schema relazionale ed uno XML
Consideriamo l'esempio in Figura 5. La parte superiore mostra lo schema relazionale della Figura 4
ed uno schema XML. Un morfismo tra i due schemi è rappresentato graficamente attraverso quattro
archi che collegano gli elementi degli schemi. La parte inferiore della figura mostra il morfismo
stesso rappresentato come un relazione. I nodi identificatori a1, a2, a3 corrispondono a quelli della
Figura 4. I nodi b2, b3, b4, b5 denotano rispettivamente i tipi complessi "Product" e gli elementi
"ProductID", "ProductName", e "ProductType" definiti nello schema XML (mostrato in Figura 6).
Si noti che un nodo può essere collegato a più nodi, ad esempio, a3 è collegato b4 e b5. Inoltre,
possono essere inclusi in un morfismo, vari tipi di elementi, come relazioni o attributi. In una
implementazione, può essere comodo annotare le coppie <l,r> con proprietà aggiuntive. Per
esempio, la maggior parte delle implementazioni dell’operatore Match calcola i valori di
somiglianza tra gli elementi di due modelli. Questi valori possono essere restituiti
convenientemente come un morfismo in cui ogni coppia ha una somiglianza e delle proprietà
aggiuntive. Pertanto, anche se si definisce un morfismo concettualmente come una relazione binaria
H (L: OID, R: OID), esso può contenere attributi aggiuntivi, come richiesto dai singoli operatori. In
genere, gli elementi L sono generati da un modello, e gli elementi di R da un altro.
14
3.3 Selectors (selettori)
Un selettore è un insieme di identificativi di nodi che può essere generato da un modello singolo o
da modelli multipli. Esso può essere rappresentato come una relazione con un singolo attributo,
S (V: OID), dove V è una chiave univoca. La figura 7 mostra un esempio di un selettore che
contiene tutti gli OID utilizzati nel modello raffigurato in Figura 4.
FIGURA 6: Grafo che rappresenta FIGURA 7: Selettore

lo schema XML della Figura 5 relativo alla Figura 4
15
4. Operatori
Sin qui sono stati menzionati gli operatori di alto livello come Match, Delete, Traverse, Extract e
Invert, i cui input e output sono modelli, morfismi e selettori. Tali operatori aumentano il livello di
astrazione, al fine di manipolare le strutture di metadati, analizzando contemporaneamente i modelli
interi ed i morfismi, rispetto alle primitive che operano analizzando un nodo alla volta. Vedremo la
semantica dei vari operatori, per primi quelli che prendono il nome di operatori primitivi. Questi
sono gli operatori generici la cui semantica può essere definita formalmente con la manipolazione
algebrica relazionale delle rappresentazioni. Per comodità di notazione questa manipolazione sarà
rappresentata in SQL. Dopo di che, verranno introdotti altri operatori più potenti come Extract,
Delete, Match, e Merge, la cui semantica è più complessa ed è tuttora oggetto di ricerca.
4.1 Operatori Primitivi
La tabella 1 elenca le definizioni di sette operatori primitivi. La colonna sinistra contiene le

definizioni degli operatori espresse in SQL. Le Variabili m, s, e map si riferiscono rispettivamente
ad un modello, ad un selettore, ed un morfismo. La colonna di destra mostra l'applicazione degli
operatori utilizzando semplici esempi. Tutti gli operatori primitivi definiti nella tabella sono
operatori insiemistici standard. Si noti che le loro definizioni sono espresse in modo dichiarativo,
cioè, l'attuazione di questi operatori, o le loro combinazioni funzionali, possono essere ottimizzate
utilizzando le normali tecniche di ottimizzazione delle query.
16
Tabella 1: Definizione degli operatori primitivi
L'operatore Domain estrae gli elementi "a sinistra" da un morfismo e restituisce un selettore
contenente il risultato. L'operatore RestrictDomain riduce un morfismo a un elemento più piccolo
del dominio, che è specificato dal selettore passato come secondo parametro dell'operatore.
L'operatore Invert scambia gli elementi sinistri e destri di un morfismo. L’operatore Compose (*) è
definito come il natural join di due morfismi, che produce un altro morfismo. L’operatore
TransitiveClosure è specificato su di un morfismo mediante una definizione ricorsiva SQL.
L'operatore Id crea un morfismo identità su di un selettore dato. L'operatore Subgraph(m,s) estrae
da un modello m un sottografo indotto dai nodi di riferimento in s. I literals legati ai nodi di s sono
anche estratti da m. Il sottografo estratto non può essere un modello ben formato, cioè, non può
essere completamente connesso e non è conforme al suo meta-model.
Gli operatori menzionati Unione (+), Differenza (-) e Intersezione (∩) sono altri tre importanti
operatori primitivi. Si noti che, applicando il set di operazioni su modelli ben formati potremmo
ottenere un modello che non è ben formato.
Gli ultimi due operatori primitivi sono All e Copy. L’operatore All(m) restituisce un selettore che
contiene solo i nodi di m che denotano gli elementi presenti nel meta-model. Spesso è importante
assicurare che un dato nodo identificatore venga utilizzato esattamente in un modello. Per questo
17
motivo, si usa l'operatore Copy per creare una copia di un modello m in cui vengono sostituiti gli ID
dei nodi selezionati da nuovi ID univoci.
4.2 Extract e Delete
L'estrazione e l'eliminazione di porzioni di modelli sono operazioni che sono frequentemente

implementate nelle applicazioni di metadati. Per eseguire queste operazioni, vengono proposti gli
operatori generici Extract e Delete.
L'operatore Extract è applicato come segue: <m', m'_m> = Extract(m, s).
Gli input sono un modello m ben formato e uno selettore s che definisce l'insieme di nodi da
estrarre. Il risultato è un modello m' che soddisfa le seguenti proprietà: (i) m' contiene tutti i nodi
selezionati, (ii) m' è un modello ben formato, (iii) m' è una rappresentazione minore o uguale del
modello m, cioè, m può possedere tutte le informazioni di m', e (iv) m' è un modello "minimale che
soddisfa le condizioni (i) - (iii). La condizione (ii) può richiedere che non vengano selezionati
"elementi di supporto" da inserire in m'. La condizione (iii) può essere caratterizzata formalmente in
termini di posizione dominante e di capacità informazionale [15,19]. Il morfismo m'_m è una
funzione iniettiva da All (m') a All (m), vale a dire, ogni elemento del modello m' ha al più una
controparte in m. In generale, un modello può contenere informazioni implicite, come relazioni
transitive tra gli elementi del modello. In tali casi, il risultato di Extract può avere bisogno di
rendere esplicite tali informazioni.
Concettualmente, la semantica dell’operatore Extract(m,s) può essere realizzata utilizzando il

seguente algoritmo:
1. Si crea una "chiusura" di m, cioè un modello m' in cui tutte le informazioni implicite di m sono
rappresentate in modo esplicito.
2. Si assegna s' = s, dove s' è un selettore temporaneo.
3. Per ogni x in s', si estende s' con gli elementi necessari per soddisfare condizioni (ii) e (iii).
4. Si applica il passo 3 fino a che non viene raggiunto un punto fisso, vale a dire, s' non cambia.
5. Si estrae il sottografo t’ indotto da s' , t'= Subgraph (m', s').
6. Si ottiene una"copertura" di t', cioè un modello minimale t che è semanticamente equivalente a t'.
7. Return Copy (t, All(t)) è come il risultato di una estrazione.
18
L’eliminazione di una parte selezionata di un modello può essere definita come l’estrazione della
porzione selezionata. Quindi, si definisce:
operator Delete(m, s)
return Extract(m, All(m) – s);
Si noti che i nodi di s che non rappresentano gli elementi del modello m, ossia, che non sono
membri di All(m), non hanno impatto sul risultato di cancellazione dovuta all’applicazione di All
(m) - s.
4.3 Match
L'obiettivo di Match è quello di scoprire in che modo due modelli "corrispondono". La funzione
necessita di due modelli come input e restituisce un morfismo. Match è per sua natura un’euristica,
così come descritto anche da documenti precedenti sul Match [23]. In generale, le corrispondenze di
due schemi richiedono informazioni che non sono presenti negli schemi stessi. Quindi, questa
operazione non può essere completamente automatizzata. L’utente ha bisogno di rivedere e di
adeguare i suggerimenti prodotti da una procedura automatica, o in una post-elaborazione passo-
passo o iterativa.
4.4 Merge
Per fondere due modelli in uno si utilizza l'operatore Merge, <m, m1_m, m2_m> = Merge (M1, M2,
map). Se i modelli m1 e m2 in input sono ben formati, Merge dovrebbe produrre un modello m ben
formato che (i) è espressivo quanto ciascuno dei modelli in input, cioè, è in grado di rappresentare
le informazioni contenute in entrambi i modelli, (ii) è "minimale", cioè l'eliminazione di qualsiasi
elemento rende il modello meno espressivo di uno dei modelli in input. Il terzo parametro di Merge
è un morfismo che descrive gli elementi di m1 ed m2 che sono equivalenti e che possono essere
"fusi" in un unico elemento in m. I morfismi in output m1_m m2_m identificano le controparti degli
elementi di m1 e m2 nel modello m. La definizione concettuale di Merge non dice nulla circa la
denominazione e l'ordinamento degli elementi del modello. Per esempio, non prescrive che i nomi
degli attributi di m1 prevalgono su quelli di m2, o viceversa. Questi dettagli non sono considerati
come parte della semantica di Merge poiché di per sé implicano processi decisionali degli utenti
finali.
19
5. Implementazione
Per semplificare l’implementazione e la specifica degli operatori si è scelto un approccio relazionale

anziché uno object-oriented [5]. Il modello di grafo relazionale utilizzato si basa sul W3C Resource
Description Framework (RDF). Con esso vengono rappresentati la codifica di schemi relazionali, di
schemi XML e di viste SQL sotto forma di grafi, mentre il meta-model scelto è basato su Open
Information Model (OIM) [8]. La rappresentazione grafica di schemi XML si basa su XML DOM,
mentre quella grafica delle viste SQL utilizzata è paragonabile ad un albero sintattico prodotto da
un processo SQL, dove tutte le clausole, le dichiarazioni, le definizioni di alias, i termini funzionali,
ecc, sono rappresentati come nodi separati. Una vista di un grafo non replica i nomi degli attributi e
le relazioni utilizzate negli schemi, ma si riferisce direttamente ai nodi corrispondenti nel grafo.
L'output degli operatori primitivi è definito in modo univoco fatta eccezione per l'operatore All, che
viene realizzato in maniera diversa per ogni meta-model.
5.1 Extract e Delete
Per descrivere l’implementazione degli operatori Extract e Delete ci concentriamo sugli schemi
relazionali. Si consideri lo schema m indicato a sinistra in Figura 8. I vincoli di chiave primaria su
PID e DID sono realizzati come barre orizzontali sottolineando i rispettivi attributi. Il vincolo
referenziale è rappresentato come una linea di collegamento PRODUCTS.PID e O-DETAILS. PID.
Supponiamo che nella rappresentazione del grafo i tre vincoli sono indicati rispettivamente con i
nodi c1, c2 e c3. Per brevità, d'ora in avanti faremo riferimento ai nodi del grafico che
rappresentano gli attributi di m semplicemente usando i loro nomi.
20
FIGURA 8: Esempio di estrazione e cancellazione da uno

schema relazionale(morfismo risultante non visualizzato)
La Figura 8 illustra sei esempi di estrazione e di eliminazione. I morfismi in output m1_m, ..., m6_m
sono omessi nella figura per compattezza, il primo esempio illustra l'estrazione dell’attributo
PName cedendo nello schema m1. La condizione (ii) del paragrafo 4.2 assicura che m1 è uno
schema relazionale ben formato. Applicata a schemi relazionali, la condizione (iii) richiede che lo
schema estratto debba contenere tutti i vincoli presenti nello schema originale che riguardano gli
elementi selezionati. Nel prototipo, l’implementazione dell’operatore Extract(m, s) per gli schemi
relazionali è basata sull'algoritmo concettuale visto nel paragrafo 4.2. Il passo 1 ("chiusura") e 6
("copertura") sono assegnazioni paritarie. Il passo 3 dell'algoritmo è implementato come segue:
• Se s' contiene il vincolo x, aggiungere ad s' tutti gli attributi che partecipano nella definizione del
vincolo.
• Se s' contiene l'attributo x, s' è esteso fino a comprendere (a) la relazione legata a x, (b) la
definizione del tipo di x, (c) il vincolo referenziale o il vincolo not-null per x, (d) la definizione di
chiave primaria o di chiave unica per x, ma solo quando tutti gli attributi che partecipano alla
definizione chiave sono contenuti in x.
Nella Figura 8, gli schemi m3 ed m5 illustrano l'estrazione di nodi che indicano i vincoli. Si noti
che la condizione (iii) di Extract rende impossibile eliminare un vincolo su un attributo relazionale
senza eliminare la definizione dell’attributo, oppure eliminare l'attributo di chiave primaria che
partecipa ad un vincolo referenziale senza cancellare i suoi attributi chiave esterni. Esistono
operatori più flessibili quali ExtractMin, DeleteHard e DeleteSoft che permettono eliminazioni
21
fornendo minori garanzie di coerenza rispetto ad Extract e Delete[18]. L’estrazione da schemi XML
è implementata analogamente dallo stesso algoritmo. I riferimenti ai tipi negli schemi XML sono
trattati analogamente ai vincoli referenziali degli schemi relazionali, mentre i tipi derivati non sono
ancora supportati.
5.2 Match
L'operatore Match prende come input due modelli dello stesso tipo e restituisce come output un
morfismo. Match è implementato utilizzando l’algoritmo Similarity Flooding (SF), un algoritmo di
matching grafico[17]. L'algoritmo SF sfrutta la struttura dei grafi per effettuare i confronti e
funziona particolarmente bene per rilevare le differenze fra due versioni di uno schema.
L'algoritmo prende come input due grafi m1 ed m2 ed un insieme di valori iniziali di somiglianza
tra i nodi dei grafi, espressi come seed di una relazione binaria pesata. Ogni coppia di seed <l, r>
contiene un valore di somiglianza compreso tra zero e uno. In un punto fisso calcolato, l'algoritmo
propaga iterativamente la somiglianza iniziale dei nodi a quelli circostanti, utilizzando l'intuizione
che i nodi vicini sono simili fra loro. L'output dell’algoritmo è un’altra relazione binaria pesata, nel
paragrafo 3.2 si è definito un morfismo appunto come una relazione binaria. Per includere il “peso”
in un morfismo è stato aggiunto un terzo attributo Sim contenente un valore di similarità per ogni
coppia di nodi. L’operatore primitivo visto nel paragrafo 4.3 ignora queste informazioni aggiuntive.
L’operatore Match è implementato come segue:
operator Match(m1, m2, seed)

multimap = SFjoin(m1, m2, seed);
multimap = Restrict(multimap, m1, m2);
map = FilterBest(multimap);
return <map, multimap>;
L'operatore SFjoin incapsula l'algoritmo SF. La Multimap restituita dall’algoritmo può contenere
una frazione del prodotto incrociato dei nodi di m1 e m2, ma essa deve essere filtrata, l'operatore
FilterBest implementa il filtro [17], che sfrutta la proprietà stable-marriage. Oltre a filtrare, si
limitano i risultati dell'operatore SFjoin ai nodi che rappresentano gli elementi del modello di m1 ed
m2 utilizzando l'operatore Restrict. Il morfismo in input è in genere ottenuto con un altro operatore
22
ausiliario NGramMatch (m1, m2), che calcola le somiglianze dei literal in m1 ed m2 in base al
numero di n-grammi che essi hanno in comune. In alternativa, i seed possono essere ottenuti tramite
composizione di morfismi, se il seed è omesso. NGramMatch è invocato dalla SFjoin come
impostazione predefinita. L’implementazione di Match restituisce sia un morfismo filtrato, sia il
Multimap non filtrato. Il morfismo può essere regolato dall’utente utilizzando uno strumento
grafico, invocando l'operatore EditMap sugli output di Match. Lo strumento grafico permette
all’utente di ispezionare tutti i match candidati suggeriti in Multimap. Lo script usato per
l'implementazione dell’operatore Match può essere facilmente adattato a chiamare altre
corrispondenze esterne allo schema. Questo però potrebbe produrre tesauri (collezione di termini
priva di definizioni).
5.3 Merge
Per descrivere l’implementazione dell’operatore Merge osserviamo l’esempio in Figura 9. In alto, vi

sono due modelli campione m1 ed m2 che vengono fusi in m (i morfismi in output sono omessi). La
mappa del morfismo è rappresentata con archi diretti. La direzione di ogni arco stabilisce una
preferenza tra due elementi del modello; quando si collassano due elementi, l'elemento di
destinazione m è mantenuto in output, mentre l'elemento di origine viene scartato. Tali preferenze
non fanno parte della semantica dell’operatore Merge (par 4.4), ma sono essenziali per la sua
realizzazione. La mappa del morfismo in input contiene un attributo extra Dir che contiene la
direzione degli archi (→ o ←). Prima che il Merge sia eseguito, l’utente ha la possibilità di
specificare la direzione dell’arco mediante un tool grafico, invocando l'operatore EditMap. La parte
inferiore della figura visualizza m1 ed m2 sotto forma di grafi. Per brevità, le etichette degli archi, i
tipi ed i literal vengono omessi (si confronti con fig. 4). La mappa del morfismo è {<x, y, ←>,<x1,
y2, →>, <x2, z1, →>}.
23
FIGURA 9: Merge di due schemi
Per implementare l'operatore Merge è stato sviluppato un algoritmo chiamato GraphMerge.

L'algoritmo si compone di tre fasi concettuali: ridenominazione del nodo, unione del grafo,
risoluzione dei conflitti.
1. Nella prima fase, i nodi del grafo alle estremità della mappa sono rinominati nei nodi obiettivi,
per entrambi i grafi m1 ed m2. Il risultato di ridenominazione è mostrato in basso a sinistra in figura
9.
2. Nella seconda fase si esegue il merge, cioè l’unione di due insiemi di archi, ottenendo il grafo
raffigurato in basso a destra in figura. Questo grafo non è un modello ben formato, perché il nodo z1
è ora diventato un attributo di due relazioni diverse, x (Order) e z (CUST) rispettivamente.
3. Tali conflitti sono stati risolti nel terzo ed ultimo passo dell’ algoritmo GraphMerge. Il
precedente conflitto è eliminato con la cancellazione degli archi tra x e z1, o tra z e z1, rendendo
effettivamente “Customer” un attributo di entrambe le relazioni “CUST” o della relazione
“ORDER” nello schema risultante dalla fusione. Questa scelta è fatta dall’utente.
Il passo 3 è il più costoso dell'algoritmo, in quanto richiede feedback umano. Per automatizzare
parzialmente la risoluzione dei conflitti, è stata sviluppata un’euristica. Si osservi che sembra più
"naturale" mantenere l’attributo Customer nella relazione CUST piuttosto che spostarlo in Order.
Per generalizzare questa osservazione si traccia l'origine di ciascun arco del grafo risultante dalla
fusione, e si assegna ad ogni vertice un tag, ad esempio +, − o + , che indicano se ciascuno dei nodi
incidenti sull’arco era un nodo sorgente della mappa (-), un nodo di destinazione della mappa (+), o
nessuno dei due (o) (questi sono i solo tre casi possibili partendo dal presupposto che i nodi di
origine e di destinazione della mappa sono disgiunti). Se sapessimo che gli archi + o sono sempre
24
preferiti rispetto agli archi + -, un conflitto potrebbe essere eliminato senza richiedere l’intervento
dell’utente.
Sono stati esaminati una serie di problemi di “merging” nell'ambito degli schemi relazionali, degli
schemi XML, e delle viste SQL, ed è stato stabilito empiricamente un ordine totale tra tutte le
varianti di tag. Questa cosa aiuta a risolvere molti conflitti automaticamente in maniera simile ad un
intervento umano. Questo ordine è mostrato nella metà destra della figura 9. Intuitivamente, gli
archi tra i nodi invariati (oo) hanno una minore probabilità di essere respinti in un conflitto, e quindi
hanno la priorità più alta. Allo stesso modo, sembra più probabile che gli archi incidenti + siano
preferiti rispetto a quelli -; così, i passi 2 e 3 sono realizzati come segue. In primo luogo, tutti gli
archi del grafo risultante dalla fusione sono in ordine decrescente di priorità; poi, iterativamente,
ogni arco è preso dalla cima della lista ordinata e viene aggiunto ad un grafo G (inizialmente
vuoto). Se aggiungendo l’arco si viola la coerenza del modello, esso viene scartato. Una volta che
tutti gli archi sono stati aggiunti, l'utente esamina il risultato e le scelte operate euristicamente, ed
esegue gli adeguamenti necessari. L'algoritmo GraphMerge è così riepilogato:
Algorithm GraphMerge(m1, m2, map)

M := m1 ∪ m2; L := empty list; G := empty graph
for each edge e in M do
rename nodes of e using map; assign tag to e; append e to L;
end for
sort edges in L by decreasing tag priority;
maxN := SELECT max(M.N) FROM M;
while L not empty do
take edge e=〈s, p, o, n〉 off top of L;
if tag(e) one of {“−o”, “−+”, “−−”} then
n := n + maxN;
if o is literal then continue loop end if
end if
if exists e′ = 〈s, p, o, n′〉 in G then
replace e′ in G by 〈s, p, o, min{n, n′}〉;
else if not conflictsWith(〈s, p, o, n〉, G) then
append 〈s, p, o, n〉 to G; end if
end if
end while
return G
Il numero maxN è ottenuto come il valore più alto esistente della proprietà ordinale N in m1 ed m2.
Esso è utilizzato per spostare i nodi sospesi e ridenominare i nodi nelle ultime posizioni. Per
eseguire il test per i nodi rinominati, si controlla che il tag dell’arco corrispondente inizi con -, vale
a dire, è uno dei -o, -+, oppure --. I literal appartenenti a tali nodi rinominati vengono rimossi. La
25
funzione conflictsWith() verifica se aggiungendo un nuovo arco a G questo crea un conflitto.

L'algoritmo GraphMerge può essere utilizzato per vari tipi di modelli, implementando la funzione
conflictsWith() in modo appropriato. L'operatore Merge è implementato come segue:
operator Merge(m1, m2, map)

G = GraphMerge(m1, m2, map);
s = SELECT L FROM map WHERE Dir=”→” UNION
SELECT R FROM map WHERE Dir=”←”;
m1_G = RestrictDomain(map, All(m1) ∩ s) + Id(All(m1) – s);
m2_G = RestrictDomain(map, All(m2) ∩ s) + Id(All(m2) – s);
<m, m_G> = Copy(G, All(G));
return <m, m1_G > Invert(m_G), m2_G < Invert(m_G) >;
Merge deve anche restituire dei morfismi per ciascuno dei suoi modelli in input. Così, dopo
l'esecuzione di GraphMerge per ottenere il modello di fusione G, si calcolano i morfismi m1_G e
m2_G, ed il selettore s contenente ogni nodo sorgente della mappa. L'algoritmo GraphMerge non
"inventa" nuovi elementi del modello e non instanzia nuove relazioni tra elementi già esistenti.
Pertanto, l'operatore Merge, così implementato non può riorganizzare gli schemi per risolvere
conflitti strutturali. Attualmente, si sta lavorando al fine di affrontare tali conflitti strutturali
utilizzando l’unione a n-vie, in cui sono utilizzati Sj schemi intermedi per descrivere le
trasformazioni strutturali. Nel paragrafo 4.4 sono state ipotizzate due condizioni "semantiche" che
Merge dovrebbe soddisfare, ma questa implementazione non garantisce automaticamente che la
condizione (i) sia rispettata. Si sta cercando di realizzare una versione più restrittiva di Merge che
riesca sempre a garantire ed a soddisfare (i) e (ii).
26
6. Automed
Il framework Automed [24] supporta la trasformazione e l'integrazione di schemi espressi

in diversi linguaggi di modellazione di dati. L’utilizzo di modelli di alto livello come il Common
Data Model (CDM) rende molto complicata la rappresentazione degli schemi, questo perché un
modello di alto livello necessita di un elevato numero di costrutti. Per ovviare a questi problemi
Automed utilizza il modello Hypergraph (HDM), basato su CDM. Automed è implementato come
una serie di API Java [24], esso può incorporare uno schema o dei dati da qualsiasi sorgente
scrivendo un wrapper per tale origine dati.
Il wrapper interroga direttamente la fonte di dati e crea successivamente i necessari schemi
Automed e gli SchemaObject per rappresentare la fonte. Uno schema viene trasformato in modo
incrementale applicando su di esso una serie di trasformazioni primitive. Questo insieme di
trasformazioni costituisce il percorso di trasformazione, dallo schema sorgente da cui si è partiti ad
uno schema di destinazione. Un vantaggio fondamentale dell’approccio Automed è che le
trasformazioni, quindi i percorsi di trasformazione, sono reversibili. Ciò si ottiene inserendo
l’estensione del costrutto creato (o rimosso) in ogni trasformazione. L’estensione definisce come i
dati associati al nuovo (o rimosso) costrutto possano essere derivati da altri costrutti esistenti nello
schema originale. La reversibilità delle trasformazioni permette la traduzione automatica delle
query di ogni schema su un dato percorso in query appropriate per un particolare schema target
presente nel percorso stesso. Quindi, uno schema creato da un wrapper Automed può essere
trasformato un infinito numero di volte ed una query su qualsiasi schema di quel percorso di
trasformazione potrà recuperare i dati dalla fonte di dati originale.
Per interrogare un qualsiasi schema lungo un percorso di trasformazione dato, Automed utilizza
IQL, un linguaggio di query intermedio. Le interrogazioni poste su uno schema target vengono
tradotte nello schema di origine che è stato generato direttamente da una sorgente dati. Il codice
all'interno del wrapper per tale origine dati effettua l’interrogazione direttamente per ottenere un
risultato. IQL supporta un tipo di collezione detto bag e supporta un numero di operatori predefiniti.
Le classi SQLWrapper e SQLWrapperFactory [47] sono utilizzate per creare una rappresentazione
Automed di uno schema relazionale. SQLWrapperFactory crea costrutti che si avvicinano a quelli
del database sottostante. Ad esempio, le relazioni e gli attributi sono modellati
come tabelle e colonne. Come rappresentazione dei dati relazionali in Automed si è scelto di
utilizzare il modello SQL.
27
7. HDM
HDM è un linguaggio di modellazione di basso livello basato su una struttura dati Hypergraph di
nodi e archi. A questa struttura è associato un insieme di vincoli che costituiscono il linguaggio. E’
anche definita una piccola serie di operazioni di trasformazione primitive che possono essere
effettuate sugli schemi rappresentati. Questo permette la derivazione automatica di regole di
trasformazione in HDM. Il carattere generale del linguaggio offre molti vantaggi rispetto alle
tecniche specifiche per ogni modello dati. Ad esempio XPath non può essere utilizzato per
rappresentare schemi relazionali e il modello ER non può essere utilizzato per rappresentare XML.
Al contrario HDM può rappresentare entrambi.
Uno schema in HDM è una tripla S = <Nodi, Archi, Vincoli>. I nodi e gli archi definiscono una
label (etichetta) annidata per l’Hypergraph direzionato; con “annidato” si intende che un nodo può
essere collegato a qualsiasi altro nodo o arco. Una query su S è un’espressione le cui variabili
appartengono a Nodi ∪ Archi, ed i vincoli sono un insieme di booleani su S; i nodi sono
univocamente identificati dal loro nome, gli archi e i vincoli possono avere un nome facoltativo.
Una istanza I di uno schema S è un insieme di insiemi che soddisfa le condizioni seguenti:
• Ogni vincolo n Nodi ha un tipo facoltativo t che vincola i valori che possono essere presenti in
n.
• Ogni vincolo c Nodi ∪ Archi ha una estensione indicata da ExtS,I(c) che può essere ricavata da I.
• Ogni insieme I può essere derivato dall’insieme di estensioni { ExtS,I(c)| c Nodi ∪ Archi } .
• Per ogni e Archi, ExtS,I(e) contiene solo i valori che appaiono legati ai vincoli di e.
• Per ogni c Vincoli, la query c[v1 /ExtS,I(v1),…, vn /ExtS,I(vn)] restituisce true, dove v1,…,vn
Nodi ∪ Archi sono le variabili di c.
La funzione ExtS,I è chiamata extension mapping. Un modello è una tripla <S,I, ExtS,I>. Due schemi
sono equivalenti se hanno lo stesso insieme di istanze; due schemi S ed S’ possono essere
condizionatamente equivalenti rispetto ad una condizione f se qualsiasi istanza di S’ che soddisfa f,
è anche una istanza di S.
Ogni trasformazione è una funzione che, quando applicata su un modello restituisce un nuovo
modello. Ogni trasformazione ha una condizione che afferma che la trasformazione è riuscita. Se
invece la trasformazione non ha successo, viene restituito un modello “indefinito” denotato da .
Qualsiasi trasformazione applicata a , restituisce .
28
Le funzioni per effettuare le trasformazioni base sono le seguenti:

1. renameNode(fromName, toName) rinomina un nodo. Condizione: toName non è il nome di
un nodo già esistente.
2. renameEdge((fromName,c1,…,cm)toName) rinomina un arco. Condizione: toName non è il
nome di un arco esistente.
3. addConstraint c aggiunge un nuovo vincolo c. Condizione: c restituisce true.
4. delConstraint c rimuove un vincolo c. Condizione: c esiste.
5. AddNode (« name, q ») aggiunge un nodo name il cui grado è dato dal valore della query q,
name non è il nome di un nodo esistente.
6. delNode (« name, q ») rimuove un nodo, q è una query che indica come l’estensione del
nodo cancellato potrebbe essere recuperata dalle estensioni dei rimanenti vincoli dello schema.
Condizione: il nodo esiste e non partecipa a nessun arco.
7. addEdge(«« name,c1,…,cm», q ») aggiunge un nuovo arco tra una sequenza di vincoli esistenti c1,
... cm; q è il grado. Condizione: name non è un arco esistente, c1, ... cm esistono e q
soddisfa i vincoli appropriati di dominio.
8. delEdge(«« name,c1,…,cm», q ») cancella l’arco name, q indica l’arco eliminato potrebbe essere r
recuperato dalle estensioni dei rimanenti vincoli dello schema. Condizione: l’arco esiste e non
partecipa in nessun altro arco.
Una trasformazione t è schema-dipendente rispetto ad uno schema S se t non restituisce per ogni
modello di S, altrimenti t è istanza-dipendente rispetto ad S. Se S può essere trasformato in S’
essi hanno lo stesso insieme di istanze e devono essere equivalenti. Se una condizione f è necessaria
per trasformare S in S’ allora S e S’ sono condizionatamente equivalenti rispetto ad f.
Ogni trasformazione t andata a buon fine è reversibile mediante una trasformazione t-1. Ad esempio,
la trasformazione AddNode (« name, q ») può essere invertita da delNode (« name, q »).
7.1 Modellare i linguaggi di alto livello in HDM
In generale, qualsiasi linguaggio di modellazione semantico è costituito da due tipi di costrutto :

costrutto estensionale e costrutto di vincolo. Lo schema di un costrutto lo identifica in modo
univoco. Il costrutto estensionale rappresenta l'insieme di valori di dati in un dato dominio, Vi sono
tre classi di elementi:
29
• Nodal : Questi possono essere presenti indipendentemente da altri costrutti. Essi vengono
rappresentati come nodi in HDM.
• Linking : L’estensione di un costrutto di collegamento è un sottoinsieme del prodotto cartesiano
delle estensioni dei costrutti a cui è collegato. Ovviamente, il costrutto di collegamento non può
esistere singolarmente. Essi vengono rappresentati come archi in HDM.
• Nodal-Linking: Questi sono costrutti nodal che possono esistere solo quando alcuni costrutti
si collegano fra di loro. Essi vengono rappresentati come nodi o archi in HDM.
I costrutti di Vincolo sono restrizioni dei costrutti estensionali, essi possono anche essere utilizzati
per rappresentare la struttura di uno schema di dati in un modello semi-strutturato. I vincoli sono
supportati direttamente da HDM. La tabella 2 mostra come i costrutti relazionali sono rappresentati
in HDM. Una volta che i costrutti del nuovo linguaggio di modellazione M sono stati definiti in
HDM abbiamo bisogno di definire le seguenti trasformazioni di M all'interno di HDM:
• Per ogni costrutto in M abbiamo bisogno di una trasformazione add che inserisca i nodi, gli archi
ed i vincoli allo schema HDM sottostante. Questa trasformazione consiste di zero o
più trasformazioni AddNode HDM. L'operando deve essere preso dal campo Nodo nella
definizione del costrutto, seguita da zero o più trasformazioni addEdge prelevato dal campo Arco.
Infine, una sequenza di zero o più trasformazioni addConstraint tratte dal campo Vincoli.
• Abbiamo bisogno di una trasformazione del per ogni costrutto di M, che inverta la sua
trasformazione add. È costituita da una sequenza di trasformazioni delConstraint HDM seguita
eventualmente da delEdge e possibilmente delNode.
• Per i costrutti che hanno un nome testuale è definita una trasformazione rename in termini
delle trasformazioni HDM renameNode e renameEdge.
Data una rappresentazione di M in HDM queste trasformazioni possono essere derivate

automaticamente applicando una o più delle trasformazioni primitive HDM definite in precedenza.
30
Tabella 2: Definizione dei costrutti del modello relazionale in HDM

Class indica la classe degli elementi di HDM
31
8. Il wrapper Automed XML-Schema
Si tratta di un nuovo wrapper che permette ai documenti XML vincolati da uno schema o agli stessi
documenti XML-Schema di essere rappresentati in Automed. Una caratteristica distintiva di questo
wrapper è che le estensioni degli oggetti dello schema possono essere gli stessi elementi dei dati se
ad essere rappresentato è un documento XML, oppure i tipi se ad essere rappresentato è un
documento XML-Schema. La struttura del documento XML è vincolata dal tipo complesso e dalle
definizioni degli elementi, mentre i valori dei dati sono vincolati dai tipi semplici assegnati agli
elementi o agli attributi.
Il wrapper XML-Schema è composto da due classi:
• La classe XMLSchemaWrapperFactory che crea gli oggetti dello schema Automed. Questa classe
contiene anche i metodi per creare i costrutti del modello Automed XML-Schema.
• La classe XMLSchemaWrapper che stabilisce una connessione al documento XML-Schema
e crea una rappresentazione interna XSDOM di esso.
Un quadro dell’algoritmo per creare una rappresentazione del documento XML-Schema in

Automed è di seguito riportato :
1. I metodi della classe XMLSchemaWrapper stabiliscono una connessione al documento XML-

Schema specificato.
2. Quando una connessione è stata stabilita, i metodi XMLSchemaWrapper utilizzano lo
Schema API [45] per estrarre le diverse componenti dello schema. Queste vengono utilizzate per
creare una rappresentazione interna XSDOM.
3. La rappresentazione interna XSDOM viene utilizzata da XMLSchemaWrapperFactory per
popolare lo schema Automed.
32
8.1 Le trasformazioni HDM
Tutte le trasformazioni svolte dalla classe XMLSchemaTransform sono effettuate tramite il modello
HDM. Per consentire al tipo di dati dell’XML-Schema di essere rappresentato, il modello HDM è
esteso per aggiungere un tipo di etichetta per il nodo da costruire. Si è deciso di utilizzare questo
approccio piuttosto che passare direttamente dall’XML-Schema al modello SQL per rendere il
wrapper più generale. Il codice è stato scritto per convertire un documento XML-Schema nelle
componenti di base HDM: nodi, archi e vincoli. Dopo aver svolto questa prima operazione
dovrebbe essere possibile trasformare facilmente queste strutture in modelli di dati che sono
supportati da Automed.
Le trasformazioni necessarie per passare dal modello HDM ad XML-Schema sono eseguite in due
passi, il primo trasforma tutti i nodi parent HDM in costrutti di tipo XML-Schema; nel secondo
passaggio tutti i nodi child HDM sono trasformati in elementi dello XML-Schema e gli archi HDM
che collegano i nodi parent ed i nodi child si trasformano in costrutti XML-Schema
complexTypeNest. Come per le trasformazioni da XML-Schema al modello relazionale, anche
queste sono reversibili.
33
8.2 Trasformazioni tra XML-Schema e HDM
Due etichette opzionali sono state aggiunte al costrutto nodo HDM, la prima per il tipo di
nodo e la seconda per eventuali vincoli.
• Un nodo HDM è un parent se esso appare come il secondo elemento in uno schema arco HDM.
• Un elemento è un child se esso appare come il terzo elemento in uno schema arco HDM.
• L'insieme dei child-p di un particolare parent(p) sono tutti quei nodi che hanno lo stesso
parent.
• Un nodo p HDM è un grandparent se uno dei child nei child-p è un nodo parent.
Le trasformazioni da HDM a XML-Schema sono le seguenti:
1. Ogni nodo HDM che rappresenta un element XML-Schema genera un attributo con lo stesso
nome per ogni nodo parent
addTypexs(«xs:nodeName»,«nodeName»)
2. Per ogni nodo child rappresentato dai costrutti nodo e arco:
«nodeName, nodeType»
«_ ,parentNode, nodenName»
vengono creati dei costrutti XML-Schema element e un complexTypeNest che collega un nuovo
elemento XML-Schema child al suo parent ed al suo tipo.
addElemxs(«xs:nodeName:nodeType»)
addCTNxs(«_,xs:parentNode, xs:nodeName:nodeType»)
Se non c'è alcun tipo associato al nodo viene quindi creato un elemento di tipo anyType.
3. Se ci sono un vincolo key o keyref associati ad un arco HDM
«_ ,parentNode, childNode»
viene poi creato un costrutto XML-Schema attribute
addAttxs(«xs:parentNode:childNode»)
34
questa trasformazione è valida solo se il nodo HDM child associato è di tipo semplice.
4. Se c’è un vincolo key associato ad un arco HDM viene creato un costrutto XML-Schema key
addKeyxs(«xs:keyName:parentNode:keyField»)
questa trasformazione è valida solo se l’attributo XML-Schema «xs:parentNode:keyField» esiste.
5. Se un arco HDM collega due nodi foglia viene creato un costrutto XML-Schema keyref
addKeyRefxs(«xs:keyrefName:parentType:refType:keyField»)
questa trasformazione è valida solo se il costrutto XML-Schema attributo che rappresenta ambedue
i nodi HDM child esiste e vi è un costrutto XML-Schema key per la tabella di riferimento.
Le trasformazioni sono fatte in 3 passi:
1. Tutti i nodi parent HDM sono trasformati in costrutti XML-Schema type.

2. I nodi child HDM sono trasformati in costrutti XML-Schema element e complexTypeNest.
3. Sono infine aggiunti i costrutti XML-Schema key e keyref.
Le trasformazioni da schema XML-Schema a HDM devono avere un passaggio extra. Nel

passaggio finale il vincolo XML-Schema key e l’annidamento generato dagli archi HDM vengono
chiamati: _pk per un vincolo key, ed _fk per un keyref e per un collegamento ad un annidamento.
8.3 Trasformazioni tra HDM e SQL
Per la trasformazione da HDM a SQL viene praticata una trasformazione simile ai tre passaggi visti
in precedenza. In primo luogo sono inserite le tabelle, poi le colonne sono aggiunte alle tabelle e,
infine, i vincoli di chiave primaria o di chiave esterna sono aggiunti alle tabelle. Quando si effettua
la trasformazione da SQL a HDM i vincoli chiave da SQL non vengono mantenuti, questo perché si
preferisce che sia l'utente a scegliere le proprie chiavi e la nidificazione per lo schema finale XML.
Un’altra giustificazione è che al momento i vincoli di chiave possono essere aggiunti solo tramite
interfaccia grafica, e non possono essere rimossi.
35
9. XSDOM
Lo standard XML-Schema è molto complesso. Per cercare di ovviare a questa complessità e per
consentire di concentrarsi su quegli aspetti di XML-Schema che sono più rilevanti per la
memorizzazione dei dati e la trasformazione sono state implementate le classi XSDOM. Esse sono
basate su JDOM [36].
La classe Element rappresenta il costrutto XML-Schema element. Questo può essere incluso
all'interno di un complexType, oppure l'elemento principale può anche essere indipendente. Ogni
elemento ha un nome e un tipo, può anche possedere una keyref ad un attributo key in un altro
complexType.
La classe Attribute rappresenta il costrutto XML-Schema attribute. Ogni attributo ha un nome e un
tipo, come la classe element, e può avere una keyref ad un attributo key in un altro complexType.
La classe ComplexType rappresenta un costrutto XML-Schema complexType, ha 0 o più child
element e 0 o più child attribute. Inoltre, uno degli attributi può essere una key.
La classe Document rappresenta un intero documento XML-Schema. Essa contiene l'elemento
radice dello schema ed un elenco di tutti i complexTypes.
9.1 Conversione da XML Schema API a XSDOM
XML-Schema viene caricato in memoria in due modi, diversi a seconda se operiamo su un

documento XML da trasformare oppure su un documento già in XML-Schema. Se vogliamo
trasformare un file XML esso viene prima analizzato, poi il post schema validation infoset (PSVI)
viene utilizzato per ottenere le informazioni dallo schema e, qualora tali informazioni non venissero
trovate, viene sollevata un'eccezione ed il programma termina. Se un documento viene trasformato
in XML-Schema i metodi DOM [35] vengono usati per caricare le informazioni dello schema.
L'XML Schema API [45] fornisce i metodi per estrarre tutte le diverse componenti di un documento
XML-Schema. Non tutti i modelli di XML-Schema sono però attualmente supportati. I tipi
supportati sono soltanto due: integer e string. I componenti che è stato possibile catturare e
memorizzare nel modello XSDOM sono quelli considerati più utili.
La Figura 10 mostra come le componenti del'XML Schema API mappano un tipo complesso in
oggetti XSDOM. I metodi per effettuare la trasformazione si trovano nella classe
XMLSchemaWrapper. Ogni scatola contiene un mapping da un campo XML Schema API al campo
appropriato nell'oggetto XSDOM. I componenti XSDOM sono stati progettati per assomigliare alla
36
struttura degli oggetti XML-Schema che rappresentano, così da rendere il mapping dallo schema
XML API a XSDOM più semplice.
Il processo di conversione avviene in più passi :
1. Il modello del documento XML-Schema è memorizzato in un oggetto XSModel. Il nome

dell’oggetto radice diventa il nome dell’elemento radice nel documento XSDOM.
2. Le dichiarazioni di tipo complesso sono tutte generate da oggetti complexType che sono aggiunte
al documento XSDOM. Questo è il primo passo del mapping.
3. Dopo che il tipo di oggetto complesso è stato creato, nessuna dichiarazione XSAttributeUses del
tipo di dichiarazione complesso XML-Schema, è aggiunta come oggetti attributo child al tipo
complesso XSDOM. Il nodo XSParticle, primo ramo di destra della struttura ad albero in Figura 10,
rappresenta una sequenza XML-Schema, qualsiasi XSElementDeclarations nella sequenza è
aggiunto come element child del tipo complesso del parent. Se l’XSObjectList contiene un altro
XSModelGroup, tutte le XSElementDeclarations in esso sono aggiunte al tipo complesso di
XSDOM. L’inserimento di attributi ed element per gli oggetti di tipo complesso costituisce il
secondo passo del mapping.
4. Un ultimo passo è fatto per aggiungere i vincoli XML-Schema key e keyref. Le chiavi sono
aggiunte come un campo key per il tipo di oggetto complesso a cui si riferiscono. Se un elemento o
un attributo agisce come un keyref, un campo keyref viene aggiunto nell’oggetto element o
nell’oggetto attributo.
37
Figura 10: XML Schema API per mappare componenti di tipo complesso in XSDOM
9.2 Da XSDOM a Automed XML-Schema
I metodi della classe XMLSchemaWrapper usano la rappresentazione XSDOM dello schema XML
per popolare lo schema Automed. L'uso delle classi XSDOM come intermediario tra l’XML
Schema API e Automed rende il mapping lineare. Esso viene effettuato in tre passi:
1. Tutti gli oggetti di tipo complesso generano costrutti XML-Schema type in Automed.
2. Tutti gli attributi e gli elementi figli di tipo complesso generano costrutti attribute e element,
nonchè coppie complexTypeNest.
3. Infine, tutti gli oggetti di tipo complesso con un campo key non-nullo generano un costrutto key,
mentre ogni elemento o attributo con un campo keyref non-nullo genera un costrutto keyref.
9.3 Da Automed XML-Schema a XSDOM
Questa è l’operazione inversa di quella descritta nel paragrafo precedente ed è necessaria quando
uno schema relazionale è stato trasformato in un Automed da un Automed XML-Schema. La
traduzione viene effettuata dalla classe XMLSchemaBuilder. La rappresentazione XSDOM può poi
essere visualizzata con la classe BuildJTree.
38
Per consentire la massima flessibilità viene visualizzato lo schema relazionale nella sua forma più
semplice senza le relazioni chiave. Questo permette all'utente di scegliere il modo in cui
rappresentare lo schema XML.
9.4 Da XSDOM a JTree
La classe BuildJTree contiene i metodi per convertire la rappresentazione dello schema XSDOM
in oggetti DefaultMutableTreeNode che possono essere visualizzati come un JTree. L’utilizzo di
XSDOM come intermediario, invece di convertire oggetti XML Schema API in astrazioni
DefaultMutableTreeNodes (DMTN) elimina gran parte della complessità dello schema XML API.
Le DMTN sono istanze di TransferableTreeNodes che hanno un name, keyref, un type e un'icon.
Il metodo createJTree crea una rappresentazione JTree del documento XML-Schema. In Figura 11
vediamo una serie di screenshot che mostra come delle key e keyref possono essere aggiunte ad un
semplice schema; l'albero di sinistra non ha chiavi, quello al centro ha i vincoli di chiave aggiunti
tramite xsshoeid e xsmakeid, mentre quello di destra ha un vincolo keyref aggiunto collegando
xsshoemakeid alla key xsmymakes_type:xsmakeid
Figura 11: JTree mostra delle semplici trasformazioni su uno Schema XML
39
9.5 Materializzare l’Automed XML-Schema
I metodi in XMLSchemaTreeBuilder prendono i nodi di JTree e li convertono in una

rappresentazione XSDOM. I metodi nella classe XMLSchemaOutputter materializzano l’XSDOM.
Le diverse classi degli elementi dell’Automed XML-Schema sono definite come segue:
• Un elemento XML-Schema è un parent se esso appare come il secondo elemento in uno schema
complexType-Nest.
• Un elemento XML-Schema è un child, se esso appare come il terzo elemento in uno schema
complexType-Nest.
• L'insieme dei children-p di un particolare parent(p) sono tutti elementi XML-Schema
che hanno lo stesso parent.
Regole per trasformare il modello Automed XML-Schema in un documento XML-Schema:
1.Per uno schema Automed chiamato AM_Schema viene creato un element XML-Schema chiamato
AM_Schema:
<element name="AM_Schema">
<complexType>
<sequence>

</sequence>
</complexType>
</element>
2. Per ogni elemento parent complexTypeNest in un Automed XML-Schema viene creato un
costrutto XML-Schema complexType chiamato nodeName_type:
<complexType name = "nodeName_type">
<sequence>

</sequence>
</complexType>
3. Per ogni child element Automed XML-Schema collegato al suo parent da complexTypeNest :
«xs:elementName:elementType»
«_,xs:parentType,xs:elementName:elementType »
viene creato un element XML-Schema all'interno della sequenza di element del parent
XML-Schema complexType
<complexType name = "parentType">
<sequence>
<element name = "elementName" type = "elementType" />
40


</sequence>
</complexType>
4. Per ogni costrutto attributo Automed XML-Schema

«xs:parentType:attributeName:attributeType »
viene creato un attribute XML-Schema parentType:

<complexType name = "parentType">

<attribute name = "attributeName" type = "attributeType" />
</complexType>
5. Per ogni costrutto key Automed XML-Schema

«keyName,xs:parentType:keyField»
viene creato un elemento key XML-Schema:

<key name = "keyName">
<selector xpath="" />
<field xpath="@keyField" />
<key>
6. Per ogni costrutto keyref Automed XML-Schema

«keyrefName,xs:parentType:refType:keyrefField»
viene creato un elemento keyref XML-Schema:

<keyref name = "keyrefName" refers = "refType">
<selector xpath="" />
<field xpath="@keyrefField" />
<key>
41
9.6 Creazione di tabelle SQL
La classe RelationalOutputter converte i costrutti dal modello SQL in tabelle relazionali.

L'algoritmo è il seguente:
1. Ogni costrutto tabella e colonna viene associato alla tabella

«sql:tableName»
«sql:tableName:columnName1:columnType1»
.
.
«sql:tableName:columnNamen:columnTypen»
genera una tabella SQL:

CREATE TABLE tableName
(ColumnName1 columnType1, ..., columnTypen columnNamen);
2. Una volta che tutte le tabelle sono state create, vengono aggiunti vincoli principali. Per ogni
costrutto primaryKey
«sql:tableName:keyColumn»
genera una chiave primaria:

ALTER TABLE tableName
ADD CONSTRAINT tableName_pk PRIMARY KEY (columnName);
3. Ogni costrutto chiave esterna

«sql:tableName:refTableName:keyColumn»
genera una chiave esterna:

ALTER TABLE tableName
ADD CONSTRAINT tableName_fk
FOREIGN KEY (columnName) REFERENCES refTableName;
4. Se la trasformazione era su un documento XML, allora i costrutti rilevanti vengono interrogati

utilizzando istruzioni IQL ed SQL INSERT e vengono rilasciate per popolare il nuovo database.
Come si evince da quanto sopra esposto, le trasformazioni Automed sono state fatte per creare
costrutti strettamente connessi ad ogni modello.
42
Confronto tra Rondo e Automed
I due approcci presentati svolgono i loro compiti su campi diversi: Rondo sul Model Management e
Automed sul Data Integration (DI) problem, ma hanno alcuni aspetti in comune in quanto entrambi
operano anche su linguaggi di modellazione.
Il punto più importante è la generalizzazione delle operazioni di trasformazione. Entrambi gli
approcci infatti puntano su questo aspetto. In Rondo si è cercato di implementare operatori che
lavorino in modo “generico”, mentre in Automed si è scelto di usare HDM proprio per offrire uno
standard di rappresentazione di linguaggio di basso livello. Da questo punto in comune deriva la
facilità con cui Automed e Rondo possono incrementare la gamma di modelli su cui lavorare.
Per inserire un nuovo linguaggio di modellazione nel prototipo Rondo, sono necessari due passi.
Nel primo, devono essere definiti gli operatori import / export, i quali devono garantire una
conversione senza perdita dati dal formato nativo alla conversione in grafo e viceversa; il secondo
passo prevede l’implementazione di diverse callback per supportare gli operatori di model
management All, Extract, e GraphMerge. Per quanto riguarda Automed invece basta scrivere un
nuovo wrapper che operi la conversione. Queste operazioni richiedono un moderato sforzo dal
punto di vista della programmazione ed hanno il grande vantaggio di aumentare la loro potenza
computazionale.
Un altro aspetto che accomuna i due approcci è la reversibilità delle trasformazioni, per Automed la
reversibilità è pressoché automatica in quanto basta applicare le trasformazioni nel “percorso”
inverso, mentre Rondo bisogna modificare i parametri di input (es script di propagazione delle
modifiche).
Infine, un ultimo punto in comune è l’uso da parte di entrambi gli approcci di tool grafici, molto più
intuitivi e semplici da usare.
43
Confronto tra le categorie di approcci
La sincronizzazione delle query o delle viste è uno dei problemi più importanti riguardanti lo
schema evolution. Nel documento a noi affidato [53] vengono descritti vari approcci riguardanti
questo campo di studio, essi sono stati raggruppati in tre categorie che differiscono tra loro a
seconda delle operazioni di modifica da essi utilizzate:
• Approcci basati sullo Schema Change.

• Approcci basati sul Mapping.
• Approcci Ibridi.
Della prima categoria fanno parte gli approcci: Automatic Relational Database System Conversion,
EVE Project, Bellahsene, Mediation Queries, Adaptive Query Formulation e Queries over Stars
and Snowflakes [53]. Questa tipologia di approcci permette di implementare differenti politiche di
gestione delle modifiche, ma ogni modifica allo schema deve essere trattata separatamente da un
differente algoritmo.
Della seconda categoria fanno parte gli approcci: Generic Model Management View, Rondo
(trattato in questo documento), Default Mappings, XPath View Synchronization e Schema Log [53].
La categoria degli approcci basati sul mapping permette di operare su un gruppo di operazioni di
modifica in modo uniforme.
Della terza categoria fanno parte gli approcci: Automed (anch’esso trattato in questo documento),
Toronto Mapping Adaptation System (TOMAS), Coupled Transformation, Breaking Queries Over
Ontologies e Prism [53]. La categoria degli approcci ibridi offre i tool più recenti per lo schema
evolution e risultano essere molto funzionali.
44
Conclusioni
I database relazionali sono il modello dominante di memorizzazione dei dati e XML è di fatto lo
standard per l'invio di informazioni su Internet. Essere quindi in grado di trasferire i dati tra i due
formati è diventato un compito importante. In questo lavoro è stato presentato Automed, un
framework, mediate il quale è stato implementato un metodo di trasferimento dei dati basato su un
linguaggio di modellazione dei dati di basso livello (HDM), astraendo così alcune delle differenze
tra i modelli e mettendo in luce le loro somiglianze. Nel processo di traduzione sono state
identificate tre grandi difficoltà:
1. Trasformare un file XML in uno schema relazionale e viceversa.

2. Offrire un modo di valutare l’idoneità dello schema trasformato.
3. Offrire la possibilità di interrogare il nuovo schema.
Per affrontare il primo punto si è scelto di utilizzare XML-Schema. Questa scelta è risultata utile
anche per poter affrontare il secondo punto in quanto sono state rappresentate graficamente le
componenti XML-Schema. Infine, è stato utilizzato IQL per interrogare lo schema finale, lungo il
percorso di trasformazione.
E’ stata inoltre presentata una piattaforma di programmazione per il model management che
implementa tutti gli operatori generici suggeriti nell’ambito della ricerca. Sono stati descritti i
morfismi, i selettori ed il loro utilizzo, è stata descritta la semantica degli operatori e gli algoritmi
che sono stati sviluppati per la loro implementazione. Si è in oltre dimostrato che l'introduzione di
un nuovo tipo di modello nel prototipo richiede uno sforzo di programmazione moderato, portando
dei grandissimi vantaggi, ed aumentando la potenza del prototipo di model management. Le
principali conclusioni che sono state tratte sono le seguenti:
1. Si possono risolvere problemi pratici utilizzando gli operatori di model management.

2. Le soluzioni richiedono una quantità relativamente limitata di codice.
3. Può essere svolto un buon lavoro anche usando una rappresentazione relativamente debole per i
modelli e per il mapping.
La realizzazione di questa piattaforma, sostenuta da un approfondito esame svolto da ricercatori

esterni alla realizzazione di Rondo, sulle singole operazioni implementate, ha suggerito che la
gestione dei metadati generici è di fatto realizzabile. Anche se per ora non è possibile gestire casi
45
particolarmente complessi, è possibile risolvere una vasta classe di problemi non banali, quindi
l’uso di questa piattaforma può risultare molto utile. Tuttora la risoluzione del dibattito [7] in misura
completa può essere fatta solo mediante un’intensa operazione di ricerca mediante la realizzazione
di applicazioni reali ed il loro studio. Altre difficili sfide rimangono aperte, su tutte quella di far
accettare queste evoluzioni alla comunità. Così come per ogni nuovo paradigma di
programmazione, la disponibilità di imparare un nuovo modo di affrontare vecchi problemi è
fondamentale per il successo del generic model management.
46
Riferimenti
1. S. Alagic, P. A. Bernstein: A Model Theory for Generic Schema Management. Proc. DBPL, pp. 228-246,
2001
2. P. Atzeni, R. Torlone: Management of Multiple Models in an Extensible Database Design Tool. pp. 79-95,
EDBT 1996
3. S. Bergamaschi, S. Castano, M. Vincini: Semantic Integration of Semistructured and Structured Data
Sources, SIGMOD Record 28(1), pp. 54-59, 1999
4. J. Berlin, A. Motro: Database Schema Matching Using Machine Learning with Feature Selection. pp.
452-466, CAiSE 2002
5. P. A. Bernstein: Applying Model Management to Classical Meta Data Problems. pp. 209-220, CIDR 2003
6. P. A. Bernstein, A. Halevy, R. A. Pottinger: A Vision for Management of Complex Models. SIGMOD
Record 29(4), pp. 54-63, 2000
7. P. A. Bernstein (moderator), L. Hass, M. Jarke, E. Rahm, G. Wiederhold (panelists): Is Generic Metadata
Management Feasible? Panel, pp. 660-662, VLDB 2000
8. P. A. Bernstein, T. Bergstraesser, J. Carlson, S. Pal, P. Sanders, D. Shutt: Microsoft Repository Version 2
and the Open Information Model. Inf. Systems 24(2), p. 71-98, 1999
9. P. A. Bernstein, E. Rahm: Data Warehousing Scenarios for Model Management. pp. 1-15, Proc. Intl.
Conf. on Conceptual Modeling (ER) 2002
10. S. Bowers, L. Declambre: On Modeling Conformance for Flexible Transformation over Data Models,
Workshop on Transformation for the Semantic Web, July 2002
11. P. Buneman, S. B. Davidson, A. Kosky: Theoretical Aspects of Schema Merging. pp. 152-167, EDBT
1992
12. K. T. Claypool, E. A. Rundensteiner: Sangam: A Framework for Modeling Heterogeneous Database
Transformations, ICEIS 2003
13. S. Cluet, C. Delobel, J. Siméon, K. Smaga: Your Mediators Need Data Conversion! pp. 177–188,
SIGMOD 1998
14. S. Davidson, P. Buneman, A. Kosky: Semantics of Database Transformations. In B. Thalheim, L. Libkin,
Eds., Semantics in Databases, LNCS 1358, pp. 55–91, 1998
15. R. Hull: Relative Information Capacity of Simple Relational Database Schemata. SIAM J. Computing,
15(3), pp. 856-886, Aug 1986
16. J. Madhavan, P. A. Bernstein, P. Domingos, A. Y. Halevy: Representing and Reasoning about Mappings
between Domain Models. pp. 80-86, AAAI/IAAI 2002
17. S. Melnik, H. Garcia-Molina, E. Rahm: Similarity Flooding: A Versatile Graph Matching Algorithm and
its Application to Schema Matching. ICDE 2002
18. S. Melnik, E. Rahm, P. A. Bernstein. Rondo: A Programming Platform for Generic Model Management
(ExtendedVersion). Technical Report, Leipzig University, 2003.
19. R. J. Miller, Y. E. Ioannidis, R. Ramakrishnan: Schema Equivalence in Heterogeneous Systems: Bridging
Theory and Practice. Information Systems 19(1), pp. 3–31, 1994
20. P. Mitra, G. Wiederhold, M. L. Kersten: A Graph-Oriented Model for Articulation of Ontology
Interdependencies. p. 86-100, EDBT 2000
21. L. Popa, Y. Velegrakis, R. J. Miller, M. A. Hernández, R. Fagin: Translating Web Data. VLDB 2002
22. R. A. Pottinger, P. A. Bernstein: Creating a Mediated Schema Based on Initial Correspondences. IEEE
Data Engineering Bulletin, 25(3), Sep 2002
23. E. Rahm, P. A. Bernstein: A Survey of Approaches to Automatic Schema Matching. VLDB Journal 10(4),
2001
24. M. Boyd and N. Tong. The Automed repositories and API. Technical report, AutoMed Project, 2001.
25. J. Liu C. Liu, M. Vincent and M. Guo. A virtual XML database engine for relational databases. XSYM
2003, 2003.
26. James Clark and Steve DeRose Eds. XML Path Language (XPath) Version 1.0.
http://www.w3c.org/TR/xpath, November 1999.
27. F. Chiu D. Lee, M. Mani and W. W. Chu. NeT & CoT: Translating relational schemas to XML schemas
using semantic constraints. UCLA CS Technical Report, February 2002.
28. C.J. Date. An introduction to Database Systems. Addison-Wesley Publishing Company, 1995.
47
29. F. H. Lochovsky D.C. Tsichritzis. Data Base Management Systems. New York: Academic Press, 1977.
30. Jayavel Shanmugasundaram et al. Relational databases for querying XML documents: Limitations and
opportunities. In VLDB Conference, 1999.
31. Jayavel Shanmugasundaram et al. Efficiently publishing relational data as XML documents. VLDB
Journal: Very Large Data Bases, 10(2–3):133–154, 2001.
32. Jayavel Shanmugasundaram et al. A general techniques for querying XML documents using a relational
database system. SIGMOD Record, 30(3):20–26, 2001.
33. M. Carey et al. XPERANTO: Middleware for publishing object-relational data as XML documents. In
VLDB Conference, pages 646–648, 2000.
34. Phil Bohannon et al. From XML Schema to relations: A cost-based approach to XML storage. In Proc.
of Intl. Conf. on Data Engineering (ICDE), 2002.
35. Philippe Le Hgaret et al. Document Object Model (DOM). http://www.w3.org/DOM/, April 2004.
36. Brett McArthur et al. Eds. JDOM. http://www.jdom.org/, February 2004.
37. Henry S. Thompson et al. Eds. XML Schema part 1: Structures. http://www.w3.org/TR/xmlschema-1,
2001.
38. Scott Boag et al. Eds. XQuery 1.0: An XML Query Language. W3C Working Draft.
http://www.w3c.org/TR/xquery, November 2003.
39. Tim Bray et al. Eds. Extensible Markup Language (XML) Version 1.0 Third Edition.
http://www.w3.org/TR/REC-xml, February 2003.
40. D.C. Fallside. XML Schema part 0: Primer. http://www.w3.org/TR/xmlschema-0, 2001.
41. Mary Ferandez, Wang-Chiew Tan, and Dan Suciu. Silkroute: Trading between relations and XML. In
Proceedings of the Ninth International World Wide Web Conference, 2000.
42. D. Florescu and D. Kossman. Storing and querying xml data using an RDBMS. Bulletin of the Technical
Commitee on Data Engineering, 22(3):27–34, September 1999.
43. Jonathan Gennick. SQL in, XML out. http://otn.oracle.com/oramag/oracle/03-may/o33xml.html, 2003.
44. Kohsuke Kawaguchi. W3C XML Schema made simple.
45. Elena Litani. XML Schema API. http://www.w3.org/Submission/xmlschema-api/, March 2004.
46. Peter McBrien. Automed in a nutshell. http://www.doc.ic.ac.uk/automed, 2004.
47. Peter McBrien and Alexandra Poulovassilis. A general formal framework for schema transformation. In
Data and Knowledge Engineering, volume 28, pages 47–71, 1998.
48. Peter McBrien and Alexandra Poulovassilis. A uniform approach to inter-model transformations. In
Advanced Information Systems Engineering, volume 1626 of LNCS, pages 333–348. Springer Verlag, 1999.
49. Peter McBrien and Alexandra Poulovassilis. A semantic approach to integrating XML and structured
data sources. In Advanced Information Systems Engineering, volume 2068 of LNCS, pages 330–345.
Springer Verlag, 2001.
50. Dare Obasanjo. W3C XML Schema design patterns: Avoiding complexity.
http://www.xml.com/pub/a/2002/11/20/schemas.html, November 2002.
51. Alexandra Poulovassilis. The automed intermediate query language. Technical report, AutoMed Project,
2001.
52. Lucas Zamboulis and Alexandra Poulovassilis. XML data integration by graph restructuring.
Technical report, 2003.
53. Giuseppe Polese and Mario Vacca. The Query/View Synchronization Problem: a Survey of Approaches.
Università degli Studi di Salerno – DMI – Internal Report , 2009.
48

Rondo Automed

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Rondo Automed

Caricato da

Copyright:

Formati disponibili

Università degli Studi di Salerno

Corso di Laurea Specialistica in Informatica

Corso di Basi di Dati 2

Gli approcci Rondo e Automed

Anno Accademico 2009-2010

3.2 Morphisms (morfismi) .................................................................................... 13

3.3 Selectors (selettori).......................................................................................... 15

4.1 Operatori Primitivi .......................................................................................... 16

4.2 Extract e Delete ............................................................................................... 18

4.3 Match .............................................................................................................. 19

4.4 Merge .............................................................................................................. 19

5.1 Extract e Delete ............................................................................................... 20

5.2 Match .............................................................................................................. 22

5.3 Merge .............................................................................................................. 23

7.1 Modellare i linguaggi di alto livello in HDM .................................................. 29

8. Il wrapper Automed XML-Schema ...................................................................... 32

8.1 Le trasformazioni HDM .................................................................................. 33

8.2 Trasformazioni tra XML-Schema e HDM ....................................................... 34

8.3 Trasformazioni tra HDM e SQL ...................................................................... 35

9.1 Conversione da XML Schema API a XSDOM ................................................ 36

9.2 Da XSDOM a Automed XML-Schema ........................................................... 38

9.3 Da Automed XML-Schema a XSDOM ........................................................... 38

9.4 Da XSDOM a JTree ........................................................................................ 39

9.5 Materializzare l’Automed XML-Schema ........................................................ 40

9.6 Creazione di tabelle SQL ................................................................................ 42

Confronto tra Rondo e Automed .............................................................................. 43

Confronto tra le categorie di approcci ...................................................................... 44

Il Model Management mira a ridurre la quantità di programmazione necessaria allo sviluppo di

FIGURA 1: Architettura del prototipo

FIGURA 2: Scenario che illustra la propagazione delle

FIGURA 3: Rappresentazione schematica per la risoluzione della

operator PropagateChanges(s1, d1, s1_d1, s2, c, s2_c)

FIGURA 4: Esempio che mostra un modello di grafo e 4 Tuple

3.2 Morphisms (morfismi)

FIGURA 5: Morfismo tra uno schema relazionale ed uno XML

3.3 Selectors (selettori)

FIGURA 6: Grafo che rappresenta FIGURA 7: Selettore

4.1 Operatori Primitivi

La tabella 1 elenca le definizioni di sette operatori primitivi. La colonna sinistra contiene le

Tabella 1: Definizione degli operatori primitivi

4.2 Extract e Delete

L'estrazione e l'eliminazione di porzioni di modelli sono operazioni che sono frequentemente

Concettualmente, la semantica dell’operatore Extract(m,s) può essere realizzata utilizzando il

Per semplificare l’implementazione e la specifica degli operatori si è scelto un approccio relazionale

5.1 Extract e Delete

FIGURA 8: Esempio di estrazione e cancellazione da uno

operator Match(m1, m2, seed)

Per descrivere l’implementazione dell’operatore Merge osserviamo l’esempio in Figura 9. In alto, vi

FIGURA 9: Merge di due schemi

Per implementare l'operatore Merge è stato sviluppato un algoritmo chiamato GraphMerge.

Algorithm GraphMerge(m1, m2, map)

funzione conflictsWith() verifica se aggiungendo un nuovo arco a G questo crea un conflitto.

operator Merge(m1, m2, map)

Il framework Automed [24] supporta la trasformazione e l'integrazione di schemi espressi

Le funzioni per effettuare le trasformazioni base sono le seguenti:

7.1 Modellare i linguaggi di alto livello in HDM

In generale, qualsiasi linguaggio di modellazione semantico è costituito da due tipi di costrutto :

Data una rappresentazione di M in HDM queste trasformazioni possono essere derivate

Tabella 2: Definizione dei costrutti del modello relazionale in HDM

8. Il wrapper Automed XML-Schema

Un quadro dell’algoritmo per creare una rappresentazione del documento XML-Schema in

1. I metodi della classe XMLSchemaWrapper stabiliscono una connessione al documento XML-

8.1 Le trasformazioni HDM

8.2 Trasformazioni tra XML-Schema e HDM