Il corpo dell’interfaccia indirizzo `e formato da quattro attributi (tutti semplici), e nella sua lista di propriet`a (fra parentesi tonde) `e presente l’elemento extent.
4.3 L’estensione di ODL: il linguaggio ODL
I3Esamineremo di seguito le aggiunte e le modifiche che sono state apportate al lin-guaggio ODL seguendo il lavoro dell’I3 workgroup. Si ricorda che il motivo di tali cambiameni `e dovuto al fatto che l’ODL pur essendo ben progettato per la rappresen-tazione della conoscenza relativa ad un singolo schema ad oggetti, risulta insufficiente per la descrizione relativa ad un insieme di sorgenti di basi di dati eterogenee. Nel pro-getto MOMIS, quindi, il linguaggio ODL pu`o risultare solamente una buona base di partenza.
4.3.1 Estensione ai tipi valore
Ad i vari tipi valore presenti in ODL `e stato aggiunto il tipo range. Range `e un tipo di dato semplice che serve per rappresentare un valore intero compreso fra due estremi. Consideriamo l’esempio:
range 10,100 Numero;
la variabile Numero pu`o assumere qualunque valore intero compreso compreso fra i valori 10 e 100. Per rappresentare il concetto di infinito si usano i termini +INF e
-INF; in questo modo una variabile Numero che pu`o assumere i valori da 10 ad infinito
viene dichiarata nella seguente maniera:
4.3.2 Estensioni ai tipi classe
Le estensioni apportate alle classi (interfacce) ODL nel linguaggio ODLI3 sono di-verse:
• Per ogni classe `e data la possibilit`a di indicare il nome ed il tipo della sorgente di
appartenenza (relazionale, ad oggetti, semistrutturato, file). Questa estensione `e resa necessaria dal fatto che, trattando diverse sorgenti di dati, non `e esclusa la possibilit`a di avere due classi con lo stesso nome. La presenza del nome della sorgente rende unica una classe all’interno di un documento ODLI3. Il nome ed il tipo della sorgente si trovano all’interno della lista di propriet`a della classe (assieme all’extent e alla dichiarazione delle chiavi).
• Poich`e il linguaggio ODLI3 deve essere in grado di descrivere anche schemi relazionali, `e stata inserita la possibilit`a di definire (sempre all’interno del-la sezione riguardante le propriet`a deldel-la cdel-lasse) delle foreign keys. In una dichiarazione di chiave estera si deve riportare il nome degli attributi che com-pongono la chiave e , preceduto dalla parola references, il nome della classe cui si riferisce la foreign key.
• `E stato aggiunto il costrutto union tramite il quale si possono assegnare pi`u
interface body ad una stessa classe. La possibilit`a di avere pi`u strutture dati
associate ad una stessa entit`a serve per poter rappresentare in ODLI3 schemi di dati semistrutturati, in cui, appunto, un elemento pu`o comparire nello stesso documento con rappresentazioni differenti.
• Sempre per rappresentare dati semistrutturati `e stato inserito il costrutto option-al. Postponendo un asterisco (*) alla dichiarazione di un attributo (all’interno
del corpo di un’interfaccia) si afferma che in una istanza della classe stessa l’apparizione dell’attributo in questione `e opzionale.
• Oltre ai normali attributi locali (normalmente usati in ODL) `e possibile dichiarare
anche attributi globali. Gli attributi globali (globalAttribute) hanno le stesse caratteristiche dei normali attributi ODL ma, in pi`u, presentano un collegamento ad un oggetto MappingRule.
4.3.3 Gli oggetti mappingRule
Qualora, all’interno di un corpo di interfaccia, un attributo globale presenti un riferi-mento ad una mappingRule (un insieme di regole di mapping) esso `e considerato au-tomaticamente un attributo globale. Gli attributi globali si trovano all’interno di classi generate, dal software del progetto MOMIS, dal raggruppamento di pi`u classi ritenute simili fra loro. Le mappingRule sono, appunto, regole di mapping fra gli attributi di una classe generata con il suddetto procedimento e quelli delle classi originarie. In un mapping di questo tipo si possono presentare i seguenti casi:
• Corrispondenza fra un attributo globale ed un solo attributo locale (di una sola
classe); `e questo il caso pi`u semplice.
• Corrispondenza fra un attributo globale ed una serie di attributi locali in and
fra loro (un insieme di attributi appartenenti a classi differenti ma in fusione tra loro)
• Corrispondenza fra un attributo globale ed una serie di attributi locali in union
fra loro. In questo caso l’attributo globale pu`o corrispondere solamente ad uno per volta fra gli attributi in union.
• Un valore di default. Un valore di default pu`o servire per esprimere un concetto
se non c’`e corrispondenza fra un attributo globale e quelli locali.
4.3.4 Relazioni terminologiche
Un’altra aggiunta alla sintassi base del linguaggio ODL `e la possibilit`a di inserire relazioni terminologiche che possono intercorrere fra classi, attributi o miste fra classi ed attributi. Le relazioni fra attributi sono memorizzate in un oggetto InterfaceRel, quella fra attributi in un oggetto AttributeRel ed invece, quelle miste in uno AttrIntRel. Vi sono quattro tipi di relazioni considerate:
• Sinonimia (SYN) • Ipernimia (BT) • Iponimia (NT) • Associazione (RT)
4.3.5 Regole if-then
ODLI3 offre la possibilit`a di definire regole di integrit`a di tipo if-then in grado di fornire informazioni non specificabili altrimenti. Le condizioni citate in queste regole devono essere rispettate dalle istanze delle classi ODLI3 memorizzate in un Database. La generica sintassi di una regola di integrit`a `e la seguente:
rule nomerule forall iteratore in collezione : antecedente then conseguente
oppure:
rule nomerule [{case of indentifier : caselist }]
I vari termini che compaiono nelle due sintassi hanno I seguenti significati:
• Nomerule: `e il nome fornito dall’utente alla regola d’integrit`a
• Iteratore: rappresenta una istanza di un elemento fra quelli appartenenti a collezione • Collezione: un insieme di istanze. Di solito `e rappresentata da una classe o parte
di essa.
• Antecedente: `e la parte if della regola, `e formata da una serie di predicati
booleani in AND fra loro
• Conseguente : `e la parte then della regola; definisce il comportamento delle
Specifica di un wrapper per schemi
XML
5.1 Introduzione
In questo capitolo si tratter`a una possibile traduzione dal linguaggio Xml-Schema ad ODLI3. Tale traduzione potr`a essere sfruttata nella realizzazione di un wrapper da impiegare all’interno del sistema MOMIS. Naturalmente le traduzioni possibili fra un linguaggio e l’altro possono essere molte ed anche discretamente differenti fra loro. La trasposizione presentata di seguito `e stata influenzata dalle seguenti scelte:
• Si vuole avere una traduzione il pi`u possibile bidirezionale (con la possibilit`a,
quindi, di poter tornare dalla versione ODLI3 a quella Xml-Schema)
• Nella trasposizione dei concetti non si devono MAI perdere informazioni
fon-damentali come il nome degli elementi e la struttura degli stessi
Diciamo subito che, purtroppo, il primo punto sar`a, per quanto riguarda alcuni costrutti dei due linguaggi, irrealizzabile; Xml-Schema ed ODLI3 sono stati creati per scopi molto differenti tra loro e, proprio per questo motivo, molti concetti non riusci-ranno ad essere tradotti efficacemente. Il secondo punto, invece, `e dato dal fatto che la traduzione `e presentata nell’ambito del progetto MOMIS. L’intenzione `e quella di tradurre in una rappresentazione comune (il linguaggio descrittivo ODLI3) schemi re-lazionali, ad oggetti, e semistrutturati (`e il nostro caso) per poter trovare similarit`a fra le varie classi ODLI3. Come si pu`o ben comprendere `e pertanto necessario mantenere intatti tutti i nomi delle classi, degli elementi e degli attributi contenuti in esse che
ci possono fornire preziose indicazioni sul contenuto della classi stesse. Il progetto MOMIS non intende solamente trovare similarit`a fra le classi, ma si propone anche di poter reperire le informazioni ed i dati contenuti nei differenti documenti originari tramite l’esecuzione di query. Le query saranno prima di tutto formulate in OQL (Object Query Language), un linguaggio di interrogazione per ODL ed ODLI3, e suc-cessivamente tradotte nei linguaggi di interrogazione specifici per i vari documenti le cui viste sono state tradotte in classi ODLI3. E’ importante comprendere quindi che Xml-Schema descrive la struttura di documenti Xml e che le informazioni reperi-bili da una Query (scritta ad esempio nel linguaggio XQuery 1.0 per l’interrogazione di fogli Xml) si trovano proprio in tali documenti; la traduzione di un Xml-Schema in uno ODLI3 non dovr`a assolutamente compromettere la reperibilit`a di tali infor-mazioni. Volendo essere pi`u specifici possiamo dire che, per ottenere lo stesso dato, una eventuale query XQuery 1.0 e la sua corrispondente in OQL devono attraversare lo stesso percorso (path) all’interno del documento Xml (istanza dell’Xml-Schema) ed attraverso le classi dello schema OLDi3.