DIPARTIMENTODI SCIENZE

ECONOMICHE

Aprile 2000

Il progetto e la realizzazione diDBVeneto OnLine

Luca Sabaini e Riccardo Golia

NOTA DI LAVORO 2000.02

Serie DBVenetocon la collaborazione della

Fondazione Cassa di Risparmio di Venezia

RiassuntoIn questo lavoro si ripercorrono alcune delle fasi di progettazione e realizzazione del progetto

DBVeneto, nato nel 1997 come ricerca caratterizzante del Dipartimento di Scienze Economichedell'Università Ca' Foscari di Venezia. In particolare si considerano le procedure informaticheseguite 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 reteInternet e la base di dati che contiene le informazioni, si descrive l'applicazione, ossia larealizzazione ed il funzionamento del sito DBVeneto OnLine.

Il disegno concettuale della base di dati ha seguito il modello Entity-Relationship (ER) cheviene 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 setteprovince venete.

Dopo aver illustrato le soluzioni adottate per risolvere i problemi emersi nella fase di verificae controllo, vengono rapidamente presentate alcune pagine dell'interfaccia utente.

SummaryThis 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 ofVenice. In particular, it considers the procedures followed to construct a system able to manage andsearch a Data Base Management System (DBMS) with a simple browser Web connected toInternet.

Explanation is given of a generic interface mechanism established among users, Internet andthe data base containing information. There follows a description of the application, i.e. theconstruction and operation of the DBVeneto OnLine site.

The conceptual structure of the data base matches the Entity-Relationship (ER) model, whichis described in relation to the first data base worked on: imports and exports carried out by Venetianprovinces.

The solutions of the problems that emerged in the pilot phase are set out, and some pages ofuser interface are shown.

Gli autori ringraziano la professoressa Maristella Agosti (Università di Padova) ed il professorGiuseppe Tattara (Università Ca' Foscari di Venezia) rispettivamente relatrice e correlatore dellatesi di laurea di Luca Sabaini in Ingegneria Informatica dalla quale è stato tratto in parte ilpresente lavoro.Inoltre gli autori ringraziano per la collaborazione il professor Dino Rizzi, il personale del Centrodi Telecomunicazioni di Ateneo e la dottoressa Rita Canu.La stesura del presente lavoro e la realizzazione operativa del progetto DBVeneto OnLine sono daattribuirsi in parti uguali ai due autori.

1

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

2

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 www.unive.it/dbveneto, con la descrizione del loro ruolo

all’interno dell’applicazione.

3

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

4

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.

5

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.

6

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 6.5.2 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.

7

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 10.000 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.

8

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.

3.1.3 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;

9

• 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.

3.1.4 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 1997.

• STATI: circa 250 senza incrementi né decrementi.

• PROVINCE: 7.

• VALORI NELLA TABELLA PRINCIPALE: circa 40.000 tuple per ogni

anno, da aggiornare. Questi i valori precisi delle tuple riferite ai diversi

anni:

1987 26.454 1993 38.210

1988 29.763 1994 40.443

1989 30.847 1995 42.475

1990 31.719 1996 43.872

1991 32.472 1997 44.276

1992 36.538

Per un totale di circa 400.000 tuple da gestire ed interrogare.

10

• 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

11

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.

12

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)

• Email; (1,N)

• Password (C);

• DataScad;

• Data;

• Ora.

E.3) Entità Data e Ora:

• Data (C);

• Ora (C);

13

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 e-mail ed un numero telefonico.

Analizzando la tabella degli utenti (PASS) si nota che è inutile prevedere più di una o

due e-mail 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 e-mail,

inserendo semplicemente due attributi e-mail e due attributi telefono nella entità PASS

14

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;

• Email1;

• Email2;

• 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

15

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.

16

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.

3.6.1 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:

17

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 (

18

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),Email1 VARCHAR(40),Email2 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.

3.6.2 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.

19

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 www.unive.it/dbveneto.

20

La piattaforma è un PC assemblato con processore 80686 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 2.2.10.

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 6.5.3 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.

21

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.

3.6.1] dei semplici INT4, cioè interi di 4 byte (4,3*109 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*1019 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

22

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.

23

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 http://www.unive.it/dbveneto ha questa forma:

Figura 4-1: Pagina Web iniziale del sito del progetto.

24

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.

25

Figura 4-3

A questo punto l’utente entra nell’interfaccia vera e propria composta di due

procedure: la prima riguardante la fase di composizione della frase di interrogazione

e la seconda che serve per la restituzione dei risultati.

In realtà ci sono due interfacce utente, cioè due diverse pagine disponibili per

la formulazione della frase di interrogazione: una per avere un output sequenziale, ad

una dimensione e continuo, ed un’altra per avere dei risultati in due dimensioni, in

forma tabellare, con valori distribuiti sui due assi. Nella Fig. 4-4 è rappresentata la

fase di formulazione della frase con uscita a due dimensioni.

Nelle quattro variabili - l’anno, lo stato, la provincia e la merce - si possono

scegliere valori singoli oppure più valori sempre all’interno della stessa variabile. In

quest’ultimo caso il programma applicherà l’operatore OR fra le diverse province, ad

esempio, scelte fra quelle disponibili. L’operatore applicato, invece, fra le diverse

variabili è l’AND. Nella Fig. 4-4 si nota la possibilità di decidere quali variabili

associare agli assi con cui lavorare, come anche quale valore restituire all’incrocio

dei valori sugli assi. Il modulo permette di scegliere quale valore assegnare all’asse x

e quale all’asse y, aggregando gli altri valori fra loro.

26

Figura 4-4

27

La Fig. 4-5 presenta la pagina in uscita, in forma tabellare a due dimensioni,

con i valori richiesti nella interrogazione, riportata all’inizio della pagina stessa per

comodità di lavoro e riferimento.

Figura 4-5

28

Tutte le pagine dell’interfaccia sono semplici e senza troppe parole, ma sono

altrettanto efficaci e funzionali. Seppur intuitive, il sito contiene anche le istruzioni

per l’utilizzo delle pagine. Il funzionamento è efficiente e l’interrogazione veloce.

La semplicità apparente di questo sito Web contenente l’applicazione

sviluppata non mostra all’esterno alcun segno della complessità del meccanismo

retrostante: una potente interfaccia di interazione fra il browser client ed il DBMS

server.

29

INDICE

1. INTRODUZIONE ............................................................................................................................ 1

2. L’INTERFACCIA TRA WEB E DBMS ........................................................................................ 3

3. APPLICAZIONE DI PROGETTO: DBVENETO ONLINE ....................................................... 53.1 RACCOLTA ED ANALISI DEI REQUISITI........................................................................................... 6

3.1.1 Raggruppamento dei dati, vincoli, operazioni ..................................................................... 73.1.2 Schema preliminare di settore.............................................................................................. 83.1.3 Specifica delle operazioni degli utenti ................................................................................. 83.1.4 Verifica completezza e consistenza ...................................................................................... 9

3.2 ANALISI DEI DATI........................................................................................................................ 103.3 REQUISITI DELLA BASE DI DATI................................................................................................... 103.4 PROGETTAZIONE CONCETTUALE................................................................................................. 103.5 RISTRUTTURAZIONE DELLO SCHEMA E-R................................................................................... 133.6 PROGETTAZIONE LOGICA............................................................................................................ 16

3.6.1 Creazione della base di dati............................................................................................... 163.6.2 Popolazione della base di dati ........................................................................................... 18

3.7 SPECIFICHE TECNICHE ED IMPLEMENTAZIONE ............................................................................ 193.8 VALIDAZIONE, CONTROLLO, FUNZIONAMENTO .......................................................................... 20

4. REALIZZAZIONE DELL’INTERFACCIA ............................................................................... 23