Slides - Dipartimento di Scienze Ambientali, Informatica e Statistica

Interfacce per basi di dati e integrazione
di sistemi informativi
R. Orsini - A. Roncato - F. Dalla Libera
Workshop del Dipartimento di Informatica
2 Marzo 2006
Aree e progetti
• Progetto Rewerse: Query XML e Web
Semantico (accesso integrato a basi di dati e dati
semistrutturati (documenti XML))
• Progetti Corila
• Interfacce per basi di dati
• Indipendenza delle applicazioni
• Integrazione di basi di dati
• Ontologie e strumenti per sistemi informativi
scientifici eterogenei
Query XML
• Xcerpt (François Bry, Monaco)
• Linguaggio deduttivo, basato su regole, con
controparte visuale
• Integrazione con linguaggi di programmazione
tradizionali con definizione di:
• modello di integrazione
• specifiche delle “API”
• sviluppo di un prototipo per Java (tesi di laurea
specialistica)
SQLI
Linguaggio per Interfacce per Basi
di Dati
R. Orsini - A. Roncato
Obiettivi
• Integrazioni di DB diversi
• Sviluppo di nuove applicazioni (Web) su
basi di dati esistenti
• Porting di applicazioni già esistenti per
nuove basi di dati
• Sviluppo separato di applicazione e basi di
dati
Soluzione “tradizionale”
• Viste utente (Schema esterno)
• Non utilizzabili quando:
– Non si può “metter mano” al database
– I dati sono non sono gestiti con un DBMS
• Si vuol rendere indipendente l’evoluzione
della BD e quella della applicazione
(principio di Ingegneria del Software)
• Si vuol portare rapidamente l’applicazione
su tante basi di dati diverse
Proposta
Interfaccia per basi di dati
Si descrive come l’applicazione “vede” il DB
•
•
•
Rende indipendenti le due componenti
È un contratto: evidenzia le responsabilità
Definita con un linguaggio formale, permette lo
sviluppo di strumenti di tipo diverso: controllo di
consistenza con la base di dati, verifica
dell’applicazione in un ambiente semplificato,
generatori di mapping fra interfaccia e DB, ecc.
Analogia con i tipi e interfacce nei
linguaggi di programmazione
•
•
•
•
Information hiding: si vuole che l’interfaccia
nasconda dettagli non interessanti del DB
Benefici interfacce: riuso, sviluppo separato,
manutenzione, collaborazione
Comunque, si vogliono fare più controlli “statici”
possibili: in questo caso non solo a tempo di
compilazione, ma anche a tempo di
“sviluppo” (questo è un aspetto innovativo su cui
è necessario indagare ulteriormente)
Per integrare DB diversi si possono costruire dei
“mapping” sopra le varie interfacce
Perchè SQLI
• Basato su SQL: SQL è conosciuto sia
dall’esperto della base dati, sia dall’esperto
dell’applicazione;
• Vogliamo un linguaggio decidibile (sviluppo
di tool);
• Esistono già delle descrizioni in SQL delle
basi di dati: Dump.
Come SQLI
• Dump descrive esattamente una sola base
di dati
• Interfaccia come “astrazione” del Dump:
dobbiamo permettere di “trascurare dei
dettagli” del DB
• I dettagli da trascurare riguardano sia lo
schema che i dati contenuti nel DB
• Alcuni dati sono importanti e non vanno
dimenticati (metadati etc.)!
Approccio
• Scelto Java come linguaggio e JDBC come
strumento per accedere alla base di dati per
vedere come l’applicazione interagisce con
DB
• Mapping tra tipi Java e tipi SQL
• Potere espressivo del linguaggio
Sintassi SQLI
• EXIST TABLE studenti ( matricola ATMOST int,
nome ATMOST VARCHAR[])
(Specifica semplificata di uno schema di tabella)
• EXIST ROWS WITH Export>=1000 AND
Import<1000 FROM region WHERE Country=‘Italy’
(Come sottoinsieme di SELECT SQL)
Risultati
• Definizione SQLI e modello di valutazione
• Realizzato Tool che, data un’interfaccia SQLI e un
DB, verifica se il DB ha quella interfaccia
In sviluppo:
• Verifica di un’applicazione in ambiente di prova
• Realizzare un driver JDBC che, data
un’applicazione, “estrae” un’interfaccia
• Estendere SQLI per gestire il mapping
• Tool per generare un DB data un’interfaccia
Problemi aperti
•
•
•
•
Completezza del linguaggio di interfaccia
Efficienza
Visione statica o dinamica?
Fino a che punto si può spingere l’analogia con i
tipi?
• Come gestire il mapping tra Java e SQL?
• Qual’è il modo migliore di integrare basi di dati con
il mapping?
• Quali strumenti avanzati dei DBMS si possono
usare per sperimentare l’approccio?
Glossario attivo
Glossario attivo
• Esigenza: semplificare il controllo e l’accesso ad
un sistema informativo complesso, molto
eterogeneo, specializzato in aree scientifiche
(dati ambientali, architettura, economia, storia,
ecc.)
Problemi
• Grandi differenze terminologiche, sui dati
raccolti, sul livello di struttura delle
informazioni, sulle operazioni “ragionevoli” sui
dati
• Utenti poco esperti di strumenti per sistemi
informativi complessi, ma che hanno bisogno di
esplorare i dati con una certa profondità.
• Scarsità di strumenti “intelligenti” ed “effettivi”
per questo tipo di sistemi informativi
Proposta
• Un’ontologia semplificata: più come tesaurus o
glossario che come ontologia nel senso tecnico
del termine (schema concettuale complesso)
• che sia una base terminologica unificante, ma
soprattutto...
• che sia un modo per accedere al sistema
informativo (aspetto innovativo)
Tutto questo ma...
• Con una modalità di creazione più semplice e
immediata possibile, per utenti che non debbano
scrivere codice
Spazio dei
programmi
Spazio dei
contenuti
Generatori
di codici
Databases
Datasets
Pagine web
Operatori
di accesso e
modifica ai dati
Materiale
non
pubblicato
Materiale
pubblicato
Categorie
Termini
Spazio dei glossario /
ontologia
Possibile con...
• Linguaggio ad alto livello, riflessione potente,
estremamente dinamico (oggetti che
acquisiscono tipi dinamicamente, tipi che
possono essere estesi a run-time), con
caratteristiche di scripting e ambiente di sviluppo
rapido di applicazioni web
• cioè... C
• :-) ehm... volevo dire Ruby