3.Rendiconto scientifico delle attivitą presso le sedi partecipanti

Unità di       Universita' degli Studi di BOLOGNA

Responsabile PAOLO CIACCIA

Quota Cofinanziamento Murst  81.480.000

Quota Cofinanziamento Ateneo  72.000.000 (RD+RA certificata)

Fondi complessivi utilizzati il primo anno  39.009.888

Illustrazione dell'attivita' svolta

L'unita` di Bologna e` impegnata nei Temi 2, 4 e 6. I risultati ottenuti nel primo anno sono quelli previsti nella proposta e sono descritti nei rapporti T2-R05, T2-R15, T4-R01, T4-R07, T6-R03 e includono anche i prototipi software T2-S16 e T6-S09. L'attivita` di ricerca del primo anno si e` articolata come descritto nel seguito. Per quanto concerne il Tema 2, il primo anno di progetto e` stato inizialmente dedicato allo studio di un modello per la rappresentazione di informazioni residenti sul World Wide Web da integrare con dati locali relativi ad un dato dominio di interesse. Il modello introdotto, denominato WDM (WaDer Data Model), descritto in T2-R05, e` un'estensione del modello relazionale con alcuni costrutti che permettono la definizione di viste su Web e di collegamenti funzionali tra ordinarie relazioni e tali viste, oltre alla posssibilita` di esprimere relazioni di ereditarieta` sulle viste, al fine di permettere un progressivo raffinamento di porzioni del Web di interesse. Piu` in dettaglio, WDM si basa sul concetto di "Space", ad indicare un insieme generico di dati, sia locali che residenti su sorgenti remote. Un particolare tipo di Space, detto "W-space", modella il concetto di "vista sul Web", individuando un insieme di informazioni relative a documenti residenti sul WWW e accomunate da una medesima semantica. I collegamenti funzionali da Space a W-space sono realizzati mediante "WD-link". Lo scopo principale dei WD-link e` permettere di associare insiemi di documenti Web a informazione di altra natura (generalmente propria del domino applicativo, ma non solo). Una caratteristica comune sia ai W-space che ai WD-link e` che essi possono essere costituiti sia da una parte materializzata che da una parte virtuale, quest'ultima definita dinamicamente mediante una query del linguaggio di interrogazione WDQL. Il linguaggio WDQL e` di tipo "SQL-like", e permette di specificare predicati navigazionali, di richiedere informazioni da piu` sorgenti di dati e di combinarle tra loro. Sia WDM che il linguaggio WDQL sono stati implementati nel sistema WaDer (WWW and Database environment), il cui disegno e realizzazione sono stati portati avanti durante la seconda fase del progetto. WaDer e` di fatto definibile come un sistema "middleware" orientato al Web, in linea con quanto sopra descritto. L'interazione tra WaDer e le sorgenti di dati e` resa uniforme mediante la definizione di appositi "wrapper", i cui scopi principali sono fornire una visione dei dati sottostanti che sia conforme a WDM e gestire le richieste formulate in WDQL traducendole nel linguaggio nativo della sorgente. A livello architetturale, WaDer consiste di un'interfaccia per la formulazione di query WDQL, e di un "motore" in grado di analizzare le query e provvedere alla loro esecuzione (T2-R15). La forma interna adottata in WaDer e` di tipo algebrico, e presenta un nuovo operatore di join funzionale per la traduzione dei WD-link. Una fase di riscrittura algebrica non banale provvede a risolvere tutti i riferimenti a "oggetti virtuali" e a cercare di pervenire ad una forma parzialmente ottimizzata in cui non si abbia duplicazione di parti comuni e in cui le parti di competenza di un singolo wrapper siano assemblate congiuntamente, al fine di ridurre al minimo le interazioni e, al tempo stesso, permettere alle sorgenti sottostanti, ove possibile, di applicare criteri locali di ottimizzazione. Dal punto di vista dell'esecuzione, e` presente un modulo Executor che interagisce con i wrapper sincronizzando le loro attivita` di estrazione. Il primo prototipo del sistema WaDer (T2-S16) e` stato sviluppato in Java, e attualmente implementa due wrapper: il primo interagisce via JDBC con un sistema relazionale (PostgreSQL) che gestisce il database locale di WaDer e le informazioni di catalogo; il secondo interagisce con il sistema WebSQL per accedere a informazioni sul Web. Il prototipo, di tipo client-server, e` eseguibile tramite un'interfaccia grafica (client WaDer) scaricabile come applet Java dal sito Internet del Tema 2 su cui e` in funzione il server WaDer. Nell'ambito del Tema 4 l'attivita` si e` concentrata sulle problematiche di progettazione di data warehouse. La costruzione di un data warehouse (DW) richiede l'adozione di tecniche di progetto completamente diverse da quelle utilizzate per i sistemi informativi operazionali; d'altronde, nessun passo significativo è stato ancora fatto per mettere a punto una metodologia completa di progetto. In particolare, una accurata progettazione concettuale e' il necessario fondamento per la costruzione di un sistema informativo ben documentato e che soddisfi pienamente le aspettative degli utenti. Durante il primo anno, l'attivita' di ricerca e' stata focalizzata sul progetto concettuale di DW. In primo luogo e' stato messo a punto un modello concettuale di tipo grafico, chiamato DFM (Dimensional Fact Model) e descritto in dettaglio nel rapporto T4-R01, per la rappresentazione dei requisiti degli utenti. Lo schema della realta' costruito viene chiamato schema dimensionale e consiste in un insieme di schemi di fatto. I principali concetti che possono essere modellati sono fatti, misure, attributi, dimensioni e gerarchie; e' inoltre possibile rappresentare l'opzionalita' delle associazioni, l'esistenza di attributi non utilizzabili per l'aggregazione e l'additivita' delle misure in relazione alle diverse dimensioni. Schemi di fatto compatibili possono essere sovrapposti al fine di mettere in relazione e comparare misure, rendendo possibile la formulazione di query di drill-across. Gli schemi dimensionali possono essere integrati con informazioni sul carico di lavoro atteso, espresso in termini di interrogazioni che selezionano istanze dei fatti. E' stato quindi definito un semplice linguaggio per la codifica di interrogazioni sul DFM, che permettera' la rappresentazione del carico di lavoro ai fini della successiva fase di progettazione logica. Ogni interrogazione viene espressa indicando il livello a cui le istanze di fatto devono essere aggregate, Infine, e' stato affrontato il problema della progettazione concettuale. La maggior parte dei sistemi informativi realizzati durante l'ultimo decennio sono relazionali, e in molti casi la loro documentazione consiste di schemi Entity/Relationship. E' quindi stata sviluppata una metodologia, delineata nel rapporto T4-R07, che permette la costruzione di schemi dimensionali in modo semi-automatico a partire dagli schemi Entity/Relationship che descrivono il sottostante sistema operazionale. Il primo passo da effettuare e' la ricerca dei fatti tra le entita' e le associazioni dello schema; un fatto e' un evento di interesse che accade dinamicamente nell'impresa. Per ogni fatto individuato viene costruito un albero che evidenzia le dipendenze funzionali presenti tra gli attributi dello schema Entity/Relationship; ciascun albero viene poi opportunamente ristrutturato e infine trasformato in uno schema di fatto attraverso la scelta di dimensioni e misure. Nell'ambito del Tema 6, l'unita' si e' occupata di estensioni delle tecnologie WWW atte ad incorporare funzionalita' di gestione di versioni di risorse secondo il tempo di transazione. Lo studio preliminare svolto nei primi sei mesi prevedeva un'implementazione del tempo di transazione basata su un'estensione temporale del protocollo di negoziazione (HTTP), e quindi la realizzazione sia di un prototipo di Web Server in grado di gestire il protocollo e le versioni temporali delle risorse, sia di apposite estensioni del Web Client. In questa fase sono state prospettate quattro diverse soluzioni (T6-R03), evidenziandone e soppesandone caratteristiche positive e negative. La prima soluzione prevedeva l'uso di tecnologia Web "standard", senza modifiche ne' al Server, ne' al Client, ne' al protocollo, necessitando pero' di una enorme proliferazione dei dati per dover memorizzare versioni temporali dell'intero sito. La navigazione spazio/temporale poteva venire effettuata giocando sull'uso di URL relativi all'interno di una particolare versione del sito preliminarmente indirizzata tramite un URL assoluto. La seconda soluzione prevedeva una particolare organizzazione del sito e l'uso di un Client con funzionalità estese, pur non richiedendo modifiche del protocollo. La navigazione era supportata dal Client mappando URL "logici" scelti dall'utente in URL "fisici" da negoziare, corrispondenti ad una particolare versione del documento desiderato. Il mapping fra URL logici e fisici poteva essere realizzato dal Client grazie alla conoscenza dell'organizzazione dell'intero sito che doveva essere codificata all'interno dei documenti scaricati. La terza e la quarta soluzione si basavano invece sulla negoziazione separata delle coordinate spaziali (URL) e temporali e quindi su un estensione del protocollo. Un server opportunamente esteso avrebbe quindi interpretato tali coordinate e selezionato la versione di risorsa desiderata da ritornare al Client (standard). Per ovviare, con l'adozione della terza soluzione, a problemi relativi all'esistenza di sistemi intermedi (es. cache e proxy) ignari del significato della coordinata temporale, la quarta soluzione prevedeva un'estensione piu' "spinta" dei protocolli Internet e delle funzionalita' di tutte le componenti Web in gioco. Risultando in tal modo la piu' sofisticata (ovvero la piu' efficiente ed elegante) ma al tempo stesso anche la piu' difficile da realizzare e soprattutto da "imporre al mercato". Il prosieguo della ricerca ha invece consentito l'ideazione e la a messa a punto di una quinta strategia alternativa, che in pratica non richiede particolari estensioni delle tecnologie Web correnti, senza pero' rinunciare a nessuna delle funzionalita' di navigazione temporale e di gestione di versioni di risorse specificate nella fase iniziale. Tale soluzione si basa fondamentalmente su una opportuna organizzazione del sito Web, e comporta un minimo sforzo da parte del gestore del sito e del disegnatore delle risorse. Le risorse base seguono una codifica del tutto standard (es. documenti HTML), e vengono memorizzate, assieme di un "timestamp" che ne definisce la pertinenza temporale, all'interno di un database. L'adozione di tale strategia ha consentito una buona semplificazione nel lavoro di implementazione di un prototipo (T6-S09), realizzato al termine del primo anno. Ogni estensione richiesta al Client e' stata infatti ridotta alla semplice gestione di un "cookie" (che memorizza lo stato - contesto temporale) durante la navigazione nel tempo, realizzata su un comune browser commerciale di ultima generazione (Netscape). Gli strumenti di supporto alla navigazione sono realizzati tramite semplici strumenti Web, quali una "toolbar" presentata in un apposito frame, e la gestione di una finestra ausiliaria dedicata alla scelta di una nuova coordinata spazio/temporale. Per quanto riguarda invece le funzionalita' del Server, le versioni temporali sono gestite in maniera "dinamica" e differenziale, riducendo al minimo indispensabile le necessita' di memorizzazione. A fronte di una richiesta di una particolare versione temporale, il Server esteso provvede ad un assemblaggio "in tempo reale" del documento temporale desiderato. La manipolazione del documento viene realizzata grazie alla combinazione delle estensioni Microsoft ASP (Active Server Pages) con l'interrogazione di un database temporale realizzato "on top" ad un DBMS relazionale standard. In tale database e' realizzato fisicamente il sito Web temporale, che viene di volta in volta interrogato, grazie alla tecnologia ODBC, a seconda delle coordinate temporali di navigazione. Nel caso di una risorsa ipertestuale, il risultato e' una pagina HTML perfettamente standard che ricostruisce la versione completa della risorsa corrispondente al contesto temporale di navigazione richiesto. Per la realizzazione del prototipo sono state utilizzate le estensioni ASP del MS Personal Web Server servendosi di Visual Interdev 1.0. Il database contenente le versioni di risorse e' stato realizzato con MS Access 97 e interfacciato con ODBC. I risultati ottenuti, oltre ad essere descritti nei rapporti tecnici elencati alla fine della presente relazione, hanno portato a 1 pubblicazione su riviste internazionali e 6 pubblicazioni in atti di convegni internazionali con revisione. Prodotti della ricerca T2-R05 "The WaDer System: Data Model and Query Language" Paolo Ciaccia, Wilma Penzo. T2-R15 "The Architecture of the WaDer System" Paolo Ciaccia, Wilma Penzo. T2-S16 "WaDer: WWW and Database Environment" Paolo Ciaccia, Wilma Penzo. T4-R01 "The Dimensional Fact Model: A Conceptual Model for Data Warehouses" Matteo Golfarelli, Dario Maio, Stefano Rizzi. T4-R07 "Conceptual Design of Data Warehouses from Entity/Relationship Schemes" Matteo Golfarelli, Dario Maio, Stefano Rizzi. T6-R03 "Gestione di versioni temporali di risorse nel World Wide Web secondo il tempo di transazione" Claudio Cristofori, Fabio Grandi, Federica Mandreoli, Maria Rita Scalas. T6-S09 "WSwTTV: Web Server with Transaction Time Versioning" Claudio Cristofori, Fabio Grandi, Federica Mandreoli, Maria Rita Scalas.

Schema riassuntivo dei fondi utilizzati (cifre spese o impegnate)
 

Voce di spesa	Cifra spesa o impegnata	Descrizione
Materiale inventariabile	973.360	libri e riviste
Grandi Attrezzature	0.000
Materiale di consumo	0.000
Spese per calcolo ed elaborazione dati	0.000
Personale a contratto	4.264.000	Sviluppo software
Servizi esterni	1.790.400	Servizi copisteria
Missioni	31.982.128	Partecipazione a convegni
Altro	0.000