Tesi di Laurea

DIPARTIMENTO
DI SCIENZE
ECONOMICHE
Aprile 2000
Il progetto e la realizzazione di
DBVeneto OnLine
Luca Sabaini e Riccardo Golia
NOTA DI LAVORO 2000.02
Serie DBVeneto
con la collaborazione della
Fondazione Cassa di Risparmio di Venezia
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.
1 . I NT RO D U ZI O NE
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
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.
2
2 . L ’ I NT E R F A C C I A T R A W E B E D B M S
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
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
3 . A PP L I C A ZI O N E D I P R O G E T T O : D B V e n e t o O n L i n e
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
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.
6
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.
7
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;
8
•
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.
9
•
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
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
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);
12
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
13
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
14
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
E.2) Entità Nome merce:
Nuove entità:
1.
ImpExp;
2.
Nome merce;
3.
Nome stato;
4.
Nome provincia;
•
NomeMerce(C).
E.3) Entità Nome stato:
•
NomeStato(C).
Nuove relazioni:
1.
Codifica merci;
2.
Codifica stati;
3.
Codifica province.
E.4) Entità Nome provincia:
•
NomeProvincia(C).
R.1) Relazione Codifica merce:
E.1) Entità ImpExp:
•
CodiceMerce (C);
•
NomeMerce.
•
Anno (C);
•
CodiceProvincia (C);
•
CodiceMerce (C);
•
CodiceStato (C);
•
CodiceStato (C);
•
QuantitaImport;
•
NomeStato.
•
ValoreImport;
•
QuantitaExport;
•
ValoreExport.
R.2) Relazione Codifica stato:
R.3) Relazione Codifica provincia:
15
•
CodiceProvincia (C);
•
NomeProvincia.
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:
16
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
Nome
Cognome
Indirizzo
Cap
Paese
Prov
Stato
Professione
Tel1
Tel2
Email1
Email2
Password
DataScad
Data
Ora
PRIMARY KEY
VARCHAR(30) NOT NULL,
VARCHAR(30) NOT NULL,
VARCHAR(30),
VARCHAR(5),
VARCHAR(30),
VARCHAR(30),
VARCHAR(30),
VARCHAR(30),
VARCHAR(30),
VARCHAR(30),
VARCHAR(40),
VARCHAR(40),
CHAR(8) NOT NULL,
DATE,
DATE,
TIME,
(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.
18
Per esempio, per popolare l’intera tabella PROVINCE sono sufficienti 7 righe
di codice SQL standard:
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INTO
INTO
INTO
INTO
INTO
INTO
INTO
PROVINCE
PROVINCE
PROVINCE
PROVINCE
PROVINCE
PROVINCE
PROVINCE
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
('23','VERONA');
('24','VICENZA');
('25','BELLUNO');
('26','TREVISO');
('27','VENEZIA');
('28','PADOVA');
('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
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INTO
INTO
INTO
INTO
INTO
INTO
INTO
INTO
INTO
INTO
MERCI
MERCI
MERCI
MERCI
MERCI
MERCI
MERCI
MERCI
MERCI
MERCI
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
('001','FRUMENTO');
('002','SEGALE, ORZO, AVENA');
('003','RISO GREGGIO');
('004','GRANOTURCO');
('005','ALTRI CEREALI');
('006','LEGUMI E ORTAGGI FRESCHI');
('007','LEGUMI E ORTAGGI SECCHI');
('008','AGRUMI');
('009','FRUTTA TROPICALE');
('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
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INSERT
INTO
INTO
INTO
INTO
INTO
INTO
INTO
INTO
INTO
INTO
STATI
STATI
STATI
STATI
STATI
STATI
STATI
STATI
STATI
STATI
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
VALUES
('001','FRANCIA');
('002','BELGIO E LUSSEMBURGO');
('003','PAESI BASSI');
('004','GERMANIA');
('005','ITALIA');
('006','REGNO UNITO');
('007','IRLANDA');
('008','DANIMARCA');
('009','GRECIA');
('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.
19
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.
20
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
21
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
4 . RE ALI Z ZA ZI O NE DEL L ’I NT ER F AC CI A
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.
23
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
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.
25
Figura 4-4
26
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
27
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.
28
INDICE
1. INTRODUZIONE ............................................................................................................................ 1
2. L’INTERFACCIA TRA WEB E DBMS ........................................................................................ 3
3. APPLICAZIONE DI PROGETTO: DBVENETO ONLINE ....................................................... 5
3.1 RACCOLTA ED ANALISI DEI REQUISITI........................................................................................... 6
3.1.1 Raggruppamento dei dati, vincoli, operazioni ..................................................................... 7
3.1.2 Schema preliminare di settore.............................................................................................. 8
3.1.3 Specifica delle operazioni degli utenti ................................................................................. 8
3.1.4 Verifica completezza e consistenza ...................................................................................... 9
3.2 ANALISI DEI DATI........................................................................................................................ 10
3.3 REQUISITI DELLA BASE DI DATI................................................................................................... 10
3.4 PROGETTAZIONE CONCETTUALE ................................................................................................. 10
3.5 RISTRUTTURAZIONE DELLO SCHEMA E-R ................................................................................... 13
3.6 PROGETTAZIONE LOGICA ............................................................................................................ 16
3.6.1 Creazione della base di dati............................................................................................... 16
3.6.2 Popolazione della base di dati ........................................................................................... 18
3.7 SPECIFICHE TECNICHE ED IMPLEMENTAZIONE ............................................................................ 19
3.8 VALIDAZIONE, CONTROLLO, FUNZIONAMENTO .......................................................................... 20
4. REALIZZAZIONE DELL’INTERFACCIA ............................................................................... 23
29