Aprile Il progetto e la realizzazione di DBVeneto OnLine. Luca Sabaini e Riccardo Golia NOTA DI LAVORO

Transcript

1 DIPARTIMENTO DI SCIENZE ECONOMICHE Aprile 2000 Il progetto e la realizzazione di DBVeneto OnLine Luca Sabaini e Riccardo Golia NOTA DI LAVORO Serie DBVeneto con la collaborazione della Fondazione Cassa di Risparmio di Venezia

2 Riassunto In questo lavoro si ripercorrono alcune delle fasi di progettazione e realizzazione del progetto DBVeneto, nato nel 1997 come ricerca caratterizzante del Dipartimento di Scienze Economiche dell'università Ca' Foscari di Venezia. In particolare si considerano le procedure informatiche seguite per costruire un sistema in grado di gestire ed interrogare un DataBase Management System (DBMS) con un semplice browser Web collegato ad Internet. Una volta spiegato il meccanismo di interfaccia generico che si instaura tra l'utente, la rete Internet e la base di dati che contiene le informazioni, si descrive l'applicazione, ossia la realizzazione ed il funzionamento del sito DBVeneto OnLine. Il disegno concettuale della base di dati ha seguito il modello Entity-Relationship (ER) che viene descritto per quel che concerne la prima base di dati su cui si è lavorato, quella dell''import Export' riguardante le importazioni e le esportazioni eseguite dagli operatori economici delle sette province venete. Dopo aver illustrato le soluzioni adottate per risolvere i problemi emersi nella fase di verifica e controllo, vengono rapidamente presentate alcune pagine dell'interfaccia utente. Summary This report describes some of the planning and construction phases of the DBVeneto project, established in 1997 as a special research project of the Economics Department at the University of Venice. In particular, it considers the procedures followed to construct a system able to manage and search a Data Base Management System (DBMS) with a simple browser Web connected to Internet. Explanation is given of a generic interface mechanism established among users, Internet and the data base containing information. There follows a description of the application, i.e. the construction and operation of the DBVeneto OnLine site. The conceptual structure of the data base matches the Entity-Relationship (ER) model, which is described in relation to the first data base worked on: imports and exports carried out by Venetian provinces. The solutions of the problems that emerged in the pilot phase are set out, and some pages of user interface are shown. Gli autori ringraziano la professoressa Maristella Agosti (Università di Padova) ed il professor Giuseppe Tattara (Università Ca' Foscari di Venezia) rispettivamente relatrice e correlatore della tesi di laurea di Luca Sabaini in Ingegneria Informatica dalla quale è stato tratto in parte il presente lavoro. Inoltre gli autori ringraziano per la collaborazione il professor Dino Rizzi, il personale del Centro di Telecomunicazioni di Ateneo e la dottoressa Rita Canu. La stesura del presente lavoro e la realizzazione operativa del progetto DBVeneto OnLine sono da attribuirsi in parti uguali ai due autori.

3 1. INTRODUZIONE Nell ambito del World Wide Web (WWW), costituito da singole pagine create in un linguaggio ipertestuale HyperText Markup Language (HTML) che l utente finale vede raggruppate in luoghi virtuali chiamati siti, si propongono ai visitatori pagine statiche, memorizzate nella memoria di massa di una macchina Server. Il problema considerato in questo lavoro è stato quello di realizzare un sito Web che non si limitasse all interazione dell utente con pagine HTML statiche, bensì con pagine create dinamicamente nell istante in cui sono richieste, in soddisfacimento di una specifica richiesta eseguita dall utente per mezzo di pagine Web nelle quali formulare l interrogazione. La dinamicità è legata all interazione dell utente con un sistema di gestione di basi di dati (DataBase Management System, DBMS), non per mezzo di un applicazione o di un programma sulla macchina locale, ma attraverso il Web stesso. Il problema è stato risolto prima analizzando i sistemi attualmente disponibili per lo sviluppo del progetto, quindi - dopo aver individuato la tipologia degli strumenti da adottare - utilizzando metodologie e sviluppando programmi di interfaccia conformi ai protocolli legati ad Internet quali l HyperText Transfer Protocol (HTTP) e il Transmission Control Protocol/Internet Protocol (TCP/IP). Questi programmi permettono l accesso ai dati, ossia l interrogazione e la gestione di un server DBMS tramite un qualsiasi Client collegato alla rete Internet. Il client è in realtà un navigatore (browser), cioè un applicazione che permette di impaginare i sorgenti HTML e le immagini che arrivano dal sito Web, trasformandoli nelle pagine finali e, nella direzione contraria, interpretare le richieste dell utente trasformandole in comandi da trasferire al server Web. Il meccanismo può essere indifferentemente e senza alcuna modifica applicato ad una rete aziendale (LAN) realizzata con i protocolli caratteristici della rete Internet (Intranet). Questo permette ad una azienda di mettere a disposizione i dati, o parte di essi, contenuti nel DataBase aziendale in maniera automatica e riducendo al minimo l intervento per gli aggiornamenti. Sfortunatamente, infatti, pubblicare dati attraverso 1

4 pagine Web statiche richiede una manutenzione davvero considerevole, specialmente per siti che si estendono per più di qualche pagina HTML. Se una azienda pubblica i suoi archivi in pagine HTML, qualche addetto alla fine avrà il compito di assicurare che tutte quelle pagine siano tenute aggiornate. Per esempio, le variazioni di un listino prezzi dei prodotti di una azienda dovrebbero essere trascritte dalla tabella del DataBase dei prezzi della contabilità alle singole pagine HTML nel sito Web dell azienda. E decisamente meglio che una variazione agli archivi dei prezzi si rifletta automaticamente anche nelle pagine HTML sul sito Web. E altrettanto ottimale che i clienti dell azienda possano, se autorizzati, aggiornare e manipolare parte dei dati. Per esempio, un cliente potrebbe usare una pagina Web nel sito dell azienda per aggiornare il suo indirizzo o altre informazioni. L obbiettivo del presente lavoro è stato dunque proprio questo: progettare e realizzare la gestione e l'interrogazione di un DBMS con un semplice browser Web collegato ad Internet. La struttura di questo scritto rispecchia la metodologia utilizzata nello sviluppo del lavoro svolto: una prima parte considera l analisi degli strumenti tecnici da utilizzare nell esecuzione del progetto ed una seconda parte descrive il progetto realizzato con gli strumenti scelti. Il secondo capitolo contiene una spiegazione introduttiva del meccanismo di interfaccia generico che deve instaurarsi fra il Web, identificabile in un utente generico, la rete Internet - quale tramite per il passaggio dei dati - e la base di dati, fornitrice delle informazioni. Nel terzo capitolo è raccolto il progetto di banca dati DBVeneto realizzato per il Dipartimento di Scienze Economiche dell Università Ca Foscari di Venezia con il coordinamento del professor Tattara. Vengono descritte sequenzialmente e metodicamente le diverse fasi della realizzazione dell applicazione, i problemi incontrati e le soluzioni adottate. Nell ultimo capitolo, è presentata l applicazione vera e propria. Contiene le immagini delle pagine visibili tramite un browser Web collegato alla rete Internet, all indirizzo del progetto con la descrizione del loro ruolo all interno dell applicazione. 2

5 2. L INTERFACCIA TRA WEB E DBMS Da un punto di vista generico, l interazione è fra un client (il browser) che richiede l accesso ai dati ed il server (il DBMS) che restituisce i dati richiesti: Figura 2-1 Ma se proviamo ad addentrarci nei meccanismi che regolano l interazione, ci accorgiamo che l applicazione client è costituita da un interfaccia che trasforma le pagine in arrivo, raggruppa il testo, le immagini, i suoni ed i filmati ed impagina il tutto a video. L applicazione client interpreta i comandi desunti dalle scelte effettuate nella pagina Web dall utente e li trasforma in comandi HTTP da inviare sulla rete, mentre è il SO del calcolatore client che ingloba i comandi in pacchetti TCP/IP diretti al calcolatore server. Anche tra rete Internet e DBMS c è in realtà qualcosa d altro: un server HTTP di pagine Web, una porta di accesso, detta gateway che permette al server HTTP di interagire con il DBMS ed eventuali procedure applicative di funzionamento. Questo è lo schema più dettagliato: Figura 2-2 3

6 Tutto inizia con la richiesta di un utente (navigatore) della rete Internet che interagisce cliccando nelle pagine, il browser trasforma la richiesta in comandi HTTP che vengono inviati al server tramite la rete. Il server Web esamina la richiesta: se è di una pagina statica la chiede al file system e la spedisce quindi al client Web per soddisfare la sua richiesta. Se invece si tratta di una pagina contenente codice da interpretare, ovvero una pagina da creare dinamicamente, demanda ad un gateway l esecuzione delle diverse parti di codice sparse nella pagina. Una volta eseguite, le accorpa al resto componendole nel codice HTML e dirige il tutto al client. La selezione nell esame del tipo di pagine avviene di solito esaminando l estensione nel nome del file contenente la pagina richiesta oppure il percorso del file. Sono caratteristiche per pagine da interpretare o eseguire le estensioni.asp,.php,.cgi,.exe, e le directory /cgi-bin, /wwwroot, riferite alla home directory dei documenti Web; mentre per pagine da restituire staticamente sono ormai consolidate le estensioni.htm e.html. L interpretazione o l esecuzione della pagina avviene nel gateway che, a seconda dei comandi ricevuti, esegue chiamate al DBMS per l interrogazione di tabelle oppure al SO per conoscere l ora, il giorno, la provenienza dell utente, ed altri dati analoghi. Quando il gateway riceve la risposta alla chiamata, la inoltra al server Web che a sua volta la rispedisce al client attraverso la rete. Molto diverso è il meccanismo di funzionamento del sistema dei Java Applets. Infatti, la fase di interazione con il server Web è solo iniziale, per passare poi ad una interazione browser-dbms diretta, che non utilizza il server Web. L applicazione (Applet) viene scaricata dal browser come succede per una qualsiasi immagine, e quindi la prima parte del meccanismo segue le specifiche descritte sopra. Invece la seconda fase, cioè la vera e propria esecuzione dell applicazione da parte del browser, va ad eliminare la funzione di intermediazione del server Web con il DBMS, permettendo al client di interagire direttamente con il DBMS senza passare dal server Web. 4

7 3. APPLICAZIONE DI PROGETTO: DBVeneto OnLine Figura 3-1: Logo del progetto Lo scopo della realizzazione del sito Internet del progetto DBVeneto, chiamato appunto DBVeneto OnLine, è quello di fornire un DataBase regionale che consenta di affrontare i temi dello sviluppo del Veneto in modo rigoroso e scientifico. L'obiettivo finale è un DataBase organico, uniforme e aggiornabile nel tempo che permetta di analizzare i temi emersi con particolare vivacità nel corso dell'ultimo ventennio. Il DataBase costituisce un prodotto utile per il dibattito economico riferito alla situazione locale, con particolare attenzione a: la necessità di fare un costante paragone tra l'evoluzione dell'economia veneta e quella delle altre regioni della Unione Europea; la possibilità di individuare elementi atti a considerare il comportamento degli agenti economici. Le grandezze prese in esame sono "economiche" in senso lato e comprendono numerosi indicatori con disaggregazione territoriale di diverso livello. 5

8 3.1 Raccolta ed analisi dei requisiti L'analisi dei requisiti presuppone un adeguato studio preliminare della realtà di interesse e delle sue finalità. Gli aspetti da evidenziare sono: 1. gli obbiettivi del sistema informatico da realizzare; 2. le attività che devono essere supportate dal sistema informatico; 3. le unità organizzative (settori e aree funzionali) che utilizzeranno il sistema informatico; 4. il piano di sviluppo del sistema informatico. Il risultato di questo studio preliminare riguarda pertanto scelte fondamentali relativamente alla realtà di interesse considerata e al suo modo di funzionare, presumibilmente invarianti nel medio termine. Da una prima analisi dei requisiti si sono subito individuati gli strumenti da utilizzare e sui quali impostare il lavoro. L Università, infatti, ha messo a disposizione del progetto il proprio server Web già installato e funzionante su un sistema Linux con piattaforma Intel. Per questo motivo è stata subito esclusa la tecnica ASP in quanto legata al mondo Microsoft ed al server Web dedicato. La scelta del DBMS è stata diretta verso un prodotto Open Source di libero utilizzo quale è il DataBase PostGreSql, sviluppato dall Università di Berkeley nel 1985 e perfezionato negli anni fino ad arrivare all ultima versione, la 6.5.2, dove le caratteristiche sono davvero quelle di un prodotto professionale di alto livello. Il DBMS usato è PostgreSql versione 6.3.2: un altro progetto Open Source dell University of California, Berkeley. PostgreSQL è un Object-Relational DBMS sofisticato, che supporta pressoché tutti i costrutti SQL, incluse le subselects, le transactions e le funzioni e tipi user-defined. E il DataBase open-source più evoluto disponibile. E anche disponibile un supporto commerciale dalla PostgreSQL Inc. La versione corrente è la ed è disponibile in molti siti mirror oppure su CD-ROM. PostgreSQL funziona su piattaforme Solaris, SunOS, HPUX, AIX, Linux, Irix, FreeBSD, e molte altre versioni di Unix. 6

9 3.1.1 Raggruppamento dei dati, vincoli, operazioni Il progetto globale prevede la realizzazione di alcune basi di dati disgiunte da gestire con lo stesso DBMS. In questo lavoro si presentano solamente la prima base di dati, già realizzata e collaudata, e cenni della seconda. La prima base di dati considerata è stata IMPORT-EXPORT : un insieme di tabelle contenenti i valori e le quantità delle importazioni e delle esportazioni di ogni categoria merceologica eseguite dagli operatori economici delle sette province della regione Veneto distinte per stato di origine o destinazione (dati di fonte Istat). La seconda base di dati considerata è stata CER- Conti Economici Regionali : un insieme di tabelle contenenti i valori nazionali e della regione Veneto di PIL, consumi, investimenti, redditi, popolazione, risultati di gestione ed altro dall anno 1980 all anno 1991 (dati di fonte Istat). Il DataBase comprende circa tuple nella tabella principale. La realizzazione prevede il recupero di parte del lavoro svolto nella prima base di dati, specialmente dei sorgenti in codice C++ che implementano l interfaccia vera e propria. Da un analisi dei dati disponibili per l IMPORT-EXPORT è stato dedotto quanto segue: Registri cartacei esistenti: nessuno Operazioni effettuate quotidianamente: nessuna Operazioni effettuate periodicamente: raccolta ed aggiornamento annuale delle tabelle con i valori registrati nell anno considerato Utilizzo dei dati: l interrogazione deve essere flessibile ed eseguibile su tutti i campi delle tabelle, ma limitata per non permettere all utente di scaricare tutto il DataBase in poche interrogazioni. Vincoli: è stato richiesto un vincolo di sicurezza riguardante il riconoscimento dell utente e controllo dell accesso con registrazione (tracing) delle interrogazioni effettuate. 7

10 3.1.2 Schema preliminare di settore Concentrando l attenzione sulle tabelle esistenti, questi erano i dati contenuti per ogni singola riga: anno di riferimento; codice a tre cifre della categoria merceologica; codice a tre cifre dello stato di importazione o esportazione del bene; codice a 2 cifre della provincia della regione Veneto di residenza dell importatore o dell esportatore; valore dell importazione o dell esportazione; quantità importata o esportata Specifica delle operazioni degli utenti Una delle esigenze più importanti del progetto era quella di rendere il più possibile autonomi i responsabili del progetto, sia nella gestione degli utenti che nell aggiornamento annuale dei dati. Per questo motivo sono state delineate due tipologie di utenti del DataBase: interrogatore; gestore. Infatti, la gestione degli utenti non è demandata, come di solito succede, all amministratore della base di dati, in quanto gli utenti sono elencati in una tabella del DataBase stesso e vengono gestiti da un utente particolare, il gestore utenti, sempre tramite un browser Web. L utente interrogatore può: accedere alla tabelle in sola lettura; modificare il registro degli accessi, senza possibilità di lettura; modificare il registro di tracing delle interrogazioni svolte, senza poterlo leggere; 8

11 accedere alla tabella degli utenti per la sola fase di controllo dell accesso. Mentre l utente gestore può: accedere alla tabella utenti sia in lettura che in scrittura e quindi modificare gli utenti, per aggiungerne o eliminarne; accedere alla tabella dei log degli accessi e delle queries in sola lettura Verifica completezza e consistenza Da una verifica della completezza e consistenza dei dati, è risultato che non era stato definito il numero (ordine di grandezza) dei dati contenuti e di quelli da aggiungere inserendoli annualmente, né la quantità degli accessi e delle interrogazioni previste. Da una precisa richiesta e dalla successiva valutazione sono stati dedotti i dati che seguono: TIPOLOGIE DI MERCE: circa 250 senza incrementi né decrementi. ANNI DA CONSIDERARE: dal 1987 al STATI: circa 250 senza incrementi né decrementi. PROVINCE: 7. VALORI NELLA TABELLA PRINCIPALE: circa tuple per ogni anno, da aggiornare. Questi i valori precisi delle tuple riferite ai diversi anni: Per un totale di circa tuple da gestire ed interrogare. 9

12 MEDIE DEL NUMERO DI ACCESSI e INTERROGAZIONI: da valutare nella fase di test. 3.2 Analisi dei dati I dati sono stati consegnati su supporto ottico CD-ROM, strutturati in file in formato Excel, in tabelle distinte per anno, provincia e stato. Il lavoro principale è stato quello della conversione dei dati per essere inseriti nella base di dati. Per rendere automatica la procedura di riversamento dei dati, sono state scritte in linguaggio Pascal le procedure di formattazione delle tabelle Excel trasformate quindi in frasi SQL standard. Una volta ottenute le frasi in linguaggio SQL da eseguire al prompt del monitor del DataBase, è stata avviata la procedura batch di inserimento delle tuple, durata complessivamente 28 ore. 3.3 Requisiti della base di dati La Base di Dati deve poter gestire la multiutenza, in quanto una interrogazione non si alterna all altra, ma anzi - essendo interrogabile tramite Web, è possibile che al DataBase abbiano contemporaneamente accesso moltissimi utenti. Deve anche implementare procedure di sicurezza, riuscendo a controllare gli accessi degli utenti, per permettere alle sole persone autorizzate la gestione delle diverse tabelle della base di dati. Deve infine permettere l'interfacciamento con Internet, perché è espressamente richiesto dei responsabili del progetto. 3.4 Progettazione concettuale Lo scopo dell'analisi concettuale è quello di tradurre il risultato dell'analisi dei requisiti settoriali in una descrizione formale e integrata degli aspetti strutturali e dinamici del sistema informatico studiato. L'attenzione viene posta sul come 10

13 progettare la base di dati e sull'insieme di operazioni che garantiscano per tutti i settori le funzionalità desiderate. Il risultato è uno schema concettuale in linguaggio formale con costrutti ad alto livello adatti a descrivere in modo naturale ciò che si sta modellando. Il modello utilizzato per il disegno concettuale della base di dati e' il modello ER (Entity-Relationship). Di seguito vengono specificate entità, relazioni e attributi per la base di dati in esame. Figura 3.5-1: Modello E-R ENTITA' Le entità corrispondono a classi di oggetti del mondo reale che hanno proprietà omogenee, comuni ed esistenza autonoma ai fini delle applicazioni di interesse. Un'occorrenza di un'entità è un oggetto della classe che l'entità rappresenta. E) Insieme delle entità: 1. ImpExp; 2. Utenti; 3. Data e Ora; 4. Codici Query. RELAZIONI Le relazioni corrispondono a legami logici o classi di fatti che sono significativi ai fini dell'applicazione di interesse. Una relazione può sussistere fra due o più entità dell'applicazione di interesse. Una occorrenza di relazione e' un oggetto della classe che la relazione rappresenta. R) Insieme delle relazioni: 1. Accessi; 2. LogQueries. 11

14 ATTRIBUTI Gli attributi descrivono proprietà elementari di entità e relazioni di interesse ai fini dell'applicazione. Sono possibili attributi composti. Le chiavi sono contrassegnate con (C). Per alcuni attributi viene specificata la cardinalità. E.1) Entità ImpExp: Anno (C); Provincia (C); Merce (C); Stato (C); QuantitaImport; ValoreImport; QuantitaExport; ValoreExport. E.2) Entità Utenti: Nome (C); Cognome (C); Indirizzo; (1,N) Cap; (1,N) Paese; (1,N) Prov; (1,N) Stato; (1,N) Professione; Tel; (1,N) ; (1,N) Password (C); DataScad; Data; Ora. E.3) Entità Data e Ora: Data (C); Ora (C); 12

15 E.4) Entità Codici Query: Codice Query (C); Descrizione query. R.1) Relazione ACCESSI: Nome (C); Cognome (C); Data (C); Ora (C). R.2) Relazione LOGQUERIES: Nome (C); Cognome (C); Professione; Data (C); Ora (C); Codice Query. NORMALIZZAZIONE DELLO SCHEMA ER Per rendere lo schema ER in prima forma normale, è necessario eliminare la molteplicità di valori assunti da un eventuale attributo nelle entità che lo utilizzano. Per fare ciò, si introduce una nuova entità e la relazione associata che lega a ciascun attributo molteplice i dati relativi ad esso. In questo caso non ci sono normalizzazioni di prima forma normale da eseguire. 3.5 Ristrutturazione dello schema E-R Fra le specifiche non è richiesto più di un ed un numero telefonico. Analizzando la tabella degli utenti (PASS) si nota che è inutile prevedere più di una o due e numeri di telefono per ogni utente. Si può così evitare di dover normalizzare lo schema introducendo una tabella per i telefoni ed una per le , inserendo semplicemente due attributi e due attributi telefono nella entità PASS 13

16 degli utenti, che prevedano un minimo di flessibilità nell informazione conservata. Lo stesso dicasi nel considerare diversi possibili indirizzi per lo stesso utente, in questo modo: E.2) Entità PASS: Nome (C); Cognome (C); Indirizzo; Cap; Paese; Prov; Stato; Professione; Tel1; Tel2; 1; 2; Password (C); DataScad; Data; Ora. Analizzando la tabella ImpExp si nota che l elevata cardinalità del numero delle tuple in essa contenute produce un elevata occupazione di memoria di massa. Considerando poi la continua aggiunta annuale di dati nella tabella, sarà molto elevata la mole di dati, misurata in bytes, che arriverà a contenere. Questa imponente quantità di dati potrebbe essere ridotta se invece di utilizzare la descrizione completa per merci, stati e province nei rispettivi campi, venisse utilizzato il codice degli stessi. Per esempio per gli stati, invece di utilizzare una codifica di 40 caratteri per codificare lo stato in ogni tupla all interno della tabella è meglio usare una codifica di 3 caratteri (codice a tre cifre), riducendo a meno di un decimo l occupazione fisica. Se poi si usassero 3 invece di 55 caratteri per la merce e 14

17 3 invece di 7 per le province, si arriverebbe ad avere un totale di 9 caratteri invece di 102 per ogni tupla della tabella: davvero un enorme risparmio di memoria di massa. Ecco come si presenteranno le nuove entità e relazioni: Figura 3.6-1: Modello E-R Nuove entità: 1. ImpExp; 2. Nome merce; 3. Nome stato; 4. Nome provincia; Nuove relazioni: 1. Codifica merci; 2. Codifica stati; 3. Codifica province. E.1) Entità ImpExp: Anno (C); CodiceProvincia (C); CodiceMerce (C); CodiceStato (C); QuantitaImport; ValoreImport; QuantitaExport; ValoreExport. E.2) Entità Nome merce: NomeMerce(C). E.3) Entità Nome stato: NomeStato(C). E.4) Entità Nome provincia: NomeProvincia(C). R.1) Relazione Codifica merce: CodiceMerce (C); NomeMerce. R.2) Relazione Codifica stato: CodiceStato (C); NomeStato. R.3) Relazione Codifica provincia: CodiceProvincia (C); NomeProvincia. 15

18 3.6 Progettazione logica In questa fase di raffinazione fisica della base di dati è da ritoccare la struttura logica delle relazioni fra ImpExp e le tre tabelle Provincia, Merce, Stato. E infatti più corretto implementare nella stessa tabella relazioni che logicamente sarebbero separate in due tabelle diverse. Per esempio l entità NomeMerce con la relazione CodificaMerce, essendo in relazione biunivoca 1 a 1, è meglio metterle nella stessa tabella in questo modo: TABELLA IMPEXP: Anno, CodiceMerce, CodiceStato, CodiceProvincia, ( ); TABELLA MERCI: CodiceMerce, NomeMerce; TABELLA STATI: CodiceStato, NomeStato; TABELLA PROVINCE: CodiceProvincia, NomeProvincia Creazione della base di dati Finita la progettazione logica e fisica, si passa alla creazione vera e propria del DataBase. Per la creazione della base di dati si passa attraverso una fase manuale ed una automatica. Nella fase manuale si crea la struttura fisica del DataBase, con le tabelle di servizio e le variabili di ambiente che vengono impostate autonomamente. Il codice per eseguire questa fase da linea di comando è: createdb h helios dbveneto Nella fase automatica si creano, tramite il codice SQL, le tabelle che serviranno ad implementare la gestione del problema da risolvere. Prima di tutto è necessario entrare nel monitor del DataBase, una specie di interfaccia utente che permette di interpretare comandi in linea: 16

19 psql h helios dbveneto Nel nostro caso le tabelle da creare sono IMPEXP, PROVINCE, MERCI, STATI, PASS, LOGUSERS, LOGQUERIES. Codice SQL per la creazione della tabella IMPEXP, contenente le transazioni di importazione ed esportazione riferite ad un determinato anno, provincia, merce e stato: CREATE TABLE IMPEXP ( Anno CHAR(4) NOT NULL, CodiceProvincia CHAR(2) NOT NULL, CodiceMerce CHAR(3) NOT NULL, CodiceStato CHAR(3) NOT NULL, QuantitaImport INT4, ValoreImport INT4, QuantitaExport INT4, ValoreExport INT4, PRIMARY KEY (Anno, CodiceProvincia, CodiceMerce, CodiceStato), FOREIGN KEY (CodiceProvincia) REFERENCES PROVINCE, FOREIGN KEY (CodiceMerce) REFERENCES MERCI, FOREIGN KEY (CodiceStato) REFERENCES STATI); Codice SQL per la creazione della tabella PROVINCE, contenente le province della regione Veneto: CREATE TABLE PROVINCE ( CodiceProvincia CHAR(2) UNIQUE NOT NULL, NomeProvincia VARCHAR(7) UNIQUE NOT NULL, PRIMARY KEY (CodiceProvincia)); Codice SQL per la creazione della tabella MERCI, contenente le categorie merceologiche doganali: CREATE TABLE MERCI ( CodiceMerce CHAR(3) UNIQUE NOT NULL, NomeMerce VARCHAR(55) UNIQUE NOT NULL, PRIMARY KEY (CodiceMerce)); Codice SQL per la creazione della tabella STATI, contenente le nazioni oggetto dell importazione o esportazione: CREATE TABLE STATI ( CodiceStato CHAR(3) UNIQUE NOT NULL, NomeStato VARCHAR(40) UNIQUE NOT NULL, PRIMARY KEY (CodiceStato)); Codice SQL per la creazione della tabella PASS degli utenti, contenente l anagrafica, la password e la data e ora dell ultimo accesso al DataBase: CREATE TABLE PASS ( 17

20 Nome VARCHAR(30) NOT NULL, Cognome VARCHAR(30) NOT NULL, Indirizzo VARCHAR(30), Cap VARCHAR(5), Paese VARCHAR(30), Prov VARCHAR(30), Stato VARCHAR(30), Professione VARCHAR(30), Tel1 VARCHAR(30), Tel2 VARCHAR(30), 1 VARCHAR(40), 2 VARCHAR(40), Password CHAR(8) NOT NULL, DataScad DATE, Data DATE, Ora TIME, PRIMARY KEY (Nome,Cognome,Password)); Codice SQL per la creazione della tabella LOGUSERS, che implementa il tracing degli accessi degli utenti al DataBase (o meglio al sito Web): CREATE TABLE LOGUSERS ( Nome VARCHAR(30) NOT NULL, Cognome VARCHAR(30) NOT NULL, Professione VARCHAR(30), Data DATE, Ora TIME, PRIMARY KEY (Nome,Cognome,Data,Ora)); Codice SQL per la creazione della tabella LOGQUERIES, per il tracing delle interrogazioni che gli utenti fanno al DataBase: CREATE TABLE LOGQUERIES ( Nome VARCHAR(30) NOT NULL, Cognome VARCHAR(30) NOT NULL, Professione VARCHAR(30), Data DATE, Ora TIME, Query VARCHAR(200), PRIMARY KEY (Nome,Cognome,Data,Ora)); Finita la fase di creazione del DataBase è possibile iniziare la fase successiva: la popolazione Popolazione della base di dati Una volta create le tabelle sopradescritte è possibile iniziare la popolazione della base di dati attraverso un meccanismo automatico di esecuzione batch di frasi SQL che hanno il compito di inserire tuple nelle diverse tabelle del DataBase. 18

21 Per esempio, per popolare l intera tabella PROVINCE sono sufficienti 7 righe di codice SQL standard: INSERT INTO PROVINCE VALUES ('23','VERONA'); INSERT INTO PROVINCE VALUES ('24','VICENZA'); INSERT INTO PROVINCE VALUES ('25','BELLUNO'); INSERT INTO PROVINCE VALUES ('26','TREVISO'); INSERT INTO PROVINCE VALUES ('27','VENEZIA'); INSERT INTO PROVINCE VALUES ('28','PADOVA'); INSERT INTO PROVINCE VALUES ('29','ROVIGO'); Mentre per popolare la tabella MERCI sono necessarie molte più righe di codice SQL. Qui se ne riportano solo le prime dieci per semplicità: INSERT INTO MERCI VALUES ('001','FRUMENTO'); INSERT INTO MERCI VALUES ('002','SEGALE, ORZO, AVENA'); INSERT INTO MERCI VALUES ('003','RISO GREGGIO'); INSERT INTO MERCI VALUES ('004','GRANOTURCO'); INSERT INTO MERCI VALUES ('005','ALTRI CEREALI'); INSERT INTO MERCI VALUES ('006','LEGUMI E ORTAGGI FRESCHI'); INSERT INTO MERCI VALUES ('007','LEGUMI E ORTAGGI SECCHI'); INSERT INTO MERCI VALUES ('008','AGRUMI'); INSERT INTO MERCI VALUES ('009','FRUTTA TROPICALE'); INSERT INTO MERCI VALUES ('010','FRUTTA FRESCA'); Lo stesso vale per la tabella STATI, di cui si riportano solo le prime dieci righe di codice necessario per la sua popolazione: INSERT INTO STATI VALUES ('001','FRANCIA'); INSERT INTO STATI VALUES ('002','BELGIO E LUSSEMBURGO'); INSERT INTO STATI VALUES ('003','PAESI BASSI'); INSERT INTO STATI VALUES ('004','GERMANIA'); INSERT INTO STATI VALUES ('005','ITALIA'); INSERT INTO STATI VALUES ('006','REGNO UNITO'); INSERT INTO STATI VALUES ('007','IRLANDA'); INSERT INTO STATI VALUES ('008','DANIMARCA'); INSERT INTO STATI VALUES ('009','GRECIA'); INSERT INTO STATI VALUES ('010','PORTOGALLO'); Una volta creata e popolata la base di dati, è terminata la fase iniziale ed è possibile iniziare ad eseguire le interrogazioni e la gestione. 3.7 Specifiche tecniche ed implementazione Il DataBase è stato implementato sulla macchina helios.unive.it, locata al Centro di Calcolo dell Università Ca Foscari di Venezia. Un reindirizzamento permette di accedere al sito Web anche tramite l indirizzo 19

22 La piattaforma è un PC assemblato con processore AMD K6 da 333Mhz, con 256MB di memoria RAM e tre dischi fissi in tecnologia Ultra Wide SCSI-2 da 18 GB ognuno. Il SO è Linux, il progetto Open Source iniziato da Linus Towald negli anni ottanta ed ancora diretto da lui, ma sviluppato da migliaia di appassionati programmatori. La distribuzione è la Red Had versione 6.0 ed il Kernel del sistema è la versione Come server Web è stato utilizzato Apache Web Server, lo stesso che gestisce anche tutte le altre pagine Web dell Università. Il DBMS usato è PostgreSql versione 6.3.2: un altro progetto Open Source dell University of California, Berkeley. PostgreSQL è un Object-Relational DBMS sofisticato, che supporta pressoché tutti i costrutti SQL, incluse le subselects, le transactions e le funzioni e tipi user-defined. E il DataBase open-source più evoluto disponibile. E anche disponibile un supporto commerciale dalla PostgreSQL Inc. La versione corrente è la ed è disponibile in molti siti mirror oppure su CD-ROM. PostgreSQL funziona su piattaforme Solaris, SunOS, HPUX, AIX, Linux, Irix, FreeBSD, e molte altre versioni di Unix. 3.8 Validazione, controllo, funzionamento Il momento più importante del progetto è consistito nelle prove di funzionamento e collaudo dell intero sistema. Il fulcro dei test sono state le interrogazioni al DBMS effettuate tramite Internet per mezzo di diversi browser funzionanti su calcolatori collegati in rete. Un primo problema è stata la carenza di strumenti di debugging dei sorgenti in linguaggio C, per correggere gli errori intrinseci delle applicazioni di interfaccia sviluppate. Infatti, gli errori che si verificavano durante l esecuzione del programma gateway fra server Web e DBMS, non venivano segnalati e diversificati, ma risultavano tutti nello stesso messaggio: Internal Server Error, rendendo difficile risalire alla causa all interno del programma e quindi alla stesura del codice. 20

23 Questo problema è stato risolto eseguendo il programma da linea di comando di una shell del sistema Unix, inserendo di volta in volta nello standard input i valori che gli sarebbero stati passati compresi nell URL o separatamente, a seconda del metodo GET o POST rispettivamente, con il quale venivano richiamati dal client. Un altro problema ricorrente è stata l operazione di chiusura e rilascio della memoria assegnata all applicazione CGI, dedicata volta per volta ai dati restituiti da operazioni sul DBMS. Se questa memoria non veniva disallocata e reinizializzata ogni volta che si operava sul DataBase tramite il CGI, inspiegabilmente il programma non si atteneva ai risultati aspettati, disorientando durante il debug dei sorgenti ed allungando i tempi di realizzazione. Un errore grossolano fatto durante la progettazione è stato quello di considerare i valori di importazione o esportazione nella tabella principale [vedi par ] dei semplici INT4, cioè interi di 4 byte (4,3*10 9 valori). Durante interrogazioni con aggregazioni, infatti, i risultati venivano presentati in attributi dello stesso tipo degli attributi originari disaggregati. Ma mentre 4 byte erano più che sufficienti per rappresentare i valori semplici nella tabella, non lo erano per rappresentare le loro aggregazioni o sommatorie. Questo problema è stato risolto ridefinendo la precisione delle variabili di presentazione dei risultati, assegnando il valore aggregato ad una variabile INT8 (1,8*10 19 valori). Per ultimo, un problema legato alla gestione degli utilizzatori del sito Web. Questi vengono riconosciuti all atto dell ingresso nel sito, non nell ingresso alla pagina iniziale, ma solo nella parte riguardante le interrogazioni vere e proprie. Una delle esigenze del progetto era quella di poter monitorare l utilizzo del sistema, misurando il tempo che ogni utente rimaneva ad interrogare il DBMS. Una soluzione era di memorizzare la differenza fra il momento dell ultima interrogazione eseguita ed il momento della prima, ottenendo il tempo netto di utilizzo del DBMS. Il problema era come definire quale fosse la prima e quale l ultima interrogazione. Infatti una sessione può essere composta da diverse fasi di lavoro, alcune più intense altre meno, intervallate più o meno nel tempo. Era difficile definire un tempo, passato il quale veniva considerata una diversa sessione di lavoro. La soluzione adottata è stata quella di dare all utilizzatore, una volta superata la fase di login, un tempo T fissato dal momento dell ingresso per poter eseguire diverse 21

24 interrogazioni. In questo modo si può conoscere quante sessioni, di T secondi ciascuna, ha utilizzato l utente e quindi quanto è rimasto collegato al DBMS. E chiaro che più alto è T, minore è la definizione della misura; più basso è T, maggiore è il disagio dell utente nel doversi ricollegare dalla fase di login iniziale. T è stato fissato in 60 minuti. Attualmente, il sistema non presenta problemi e la sua efficienza è stata testata sotto tutte le condizioni di funzionamento (basso e alto carico di interrogazioni), con bassi tempi di risposta, ottimi tempi di scaricamento delle pagine dinamiche ed eccellenti risultati sia nelle interrogazioni semplici che in quelle complesse. 22

25 4. REALIZZAZIONE DELL INTERFACCIA Nella realizzazione del sistema che permette di interrogare il DBMS attraverso pagine Web si è cercato di curare al meglio l interfaccia utente, che è l unica interazione tra l utilizzatore e il DBMS. La pagina iniziale che appare nel navigatore all atto della connessione al sito Web ha questa forma: Figura 4-1: Pagina Web iniziale del sito del progetto. 23

26 A parte le diverse pagine descrittive del progetto e dei dati in esso contenuti, la parte del sito più interessante è quella riguardante l interrogazione della base di dati. All apertura di questa pagina si entra nell applicazione di controllo dell accesso. La figura seguente mostra la fase di riconoscimento dell utilizzatore: Figura 4-2: Riconoscimento dell utente. Una volta inseriti i tre dati Nome, Cognome e Password si ritiene unico il riconoscimento dell utente. Infatti possono esistere due utenti con lo stesso nome e cognome, ma non con la stessa password. Passata la fase di riconoscimento, l utilizzatore viene avvisato di quanto tempo ha a disposizione per eseguire l'interrogazione [Fig.4-3]. Come introdotto nel par.3.8, il limite di tempo oltre il quale deve essere eseguita di nuovo la fase di login è di 60 minuti, sufficienti per eseguire una ventina di interrogazioni. 24