UNIVERSITÀ DEGLI STUDI DI TRIESTE

FACOLTÀ DI INGEGNERIA

Tesi di laurea in
INGEGNERIA INFORMATICA

SVILUPPO DI UNA APPLICAZIONE WEB PER LA

GESTIONE DELL’ATTIVITA’ SCIENTIFICA DI UN
LABORATORIO DI GEOMATICA

Laureando: Bais Andrea

Relatore: Prof. Maurizio Fermeglia

Correlatore: Prof. Raffaela Cefalo

ANNO ACCADEMICO 2009-2010

 Indice
1. Introduzione Pg. 4
2. Obbiettivi Pg. 5
3. Stato dell’arte e Vincoli di progetto Pg. 6
4. Analisi (Progettazione Concettuale) Pg. 8
4.1. Requisiti espressi in forma ristrutturata Pg. 9
4.2. Glossario dei termini Pg. 12
4.3. Progettazione del Diagramma E-R Pg. 13
4.3.1. Strategia di approccio Pg. 13
4.3.2. Definizione delle Entità Pg. 13
4.3.3. Definizione delle Relazioni Pg. 13
4.3.4. Descrizione dei concetti Pg. 14
4.3.5. Stesura lista degli attributi Pg. 14
4.4. Diagramma E-R con attributi e Cardinalità Pg. 15
5. Realizzazione (Progettazione Logica) Pg. 16
5.1. Tabella dei Volumi Pg. 17
5.2. Stima frequenza delle operazioni sui dati Pg. 18
5.3. Workflow di alcune operazioni di esempio Pg. 20
5.3.1. Inserimento nuovo progetto Pg. 20
5.3.2. Inserimento nuovo utente con credenziali Pg. 21
5.4. Eliminazione delle generalizzazioni e partizionamento dei concetti Pg. 22
5.4.1. Generalizzazione Utente Pg. 22
5.4.2. Generalizzazione Utente Interno Pg. 23
5.4.3. Partizionamento dei concetti Pg. 24
5.5. Normalizzazione e scelta delle chiavi primarie Pg. 25
5.6. Schema finale E-R Ristrutturato Pg. 26
5.7. Realizzazione del Data Base Pg. 27
5.8. Descrizione delle tabelle della base di dati Pg. 28
5.8.1. tblUtenti Pg. 28
5.8.2. tblCredenziali Pg. 29
5.8.3. tblCurriculum Pg. 29
5.8.4. tblContatti Pg. 30
5.8.5. tblContatti_Telefonici Pg. 30
5.8.6. tblContatti_Mail Pg. 31
5.8.7. tblProgetto Pg. 31
5.8.8. tblModifica_Progetto Pg. 32
5.8.9. tblPubblicazione Pg. 32
5.8.10. tblModifica_Pubblicazione Pg. 33
5.8.11. tblAutore Pg. 33
5.8.12. tblCollaboratore Pg. 34
5.8.13. tblCollegamenti Pg. 34
5.9. Descrizione delle funzionalità Pg. 35
5.10. Stored Procedure Pg. 36
5.10.1. Esempio 1: geosnav_Utente_SelectTuttiUtenti Pg. 37
5.10.2. Esempio 2: geosnav_Utente_DeleteUtenteTotale Pg. 38
5.10.3. Esempio 3: geosnav_Progetto_InsertProgetto Pg. 39
5.10.4. Esempio 4: geosnav_Pubblicazione_UpdatePubblicazione Pg. 40
5.10.5. Esempio 5: geosnav_Pubblicazione_SelectLikePubblicazione Pg. 41
5.10.6. Esempio 6: geosnav_Progetto_CountProgetti Pg. 41
5.10.7. Esempio 7: geosnav_Utente_SelectUtenteNomeCognome Pg. 42
5.11. Interfaccia Pg. 43
2
 5.11.1. Struttura logica dell’Interfaccia Utente Base Pg. 44
5.11.2. Struttura logica dell’Interfaccia Di Gestione Pg. 45
5.11.3. Esempio di interfaccia: Interfaccia Utente Base Pg. 46
5.11.4. Esempio di interfaccia: Visualizza profilo utente Pg. 47
5.11.5. Esempio di interfaccia: Visualizza tutti i progetti Pg. 47
5.11.6. Esempio di interfaccia: Visualizza singolo progetto Pg. 48
5.11.7. Esempio di interfaccia: Autenticazione Pg. 49
5.11.8. Esempio di interfaccia: Interfaccia Di Gestione Pg. 49
5.11.9. Esempio di interfaccia: Modifica/Inserimento profilo utente Pg. 50
5.11.10. Esempio di interfaccia: Gestione dei collegamenti Pg. 51
5.11.11. Esempio di interfaccia: Visualizza singolo progetto lato gestione Pg. 52
5.12. Il Sito Web Pg. 53
5.12.1. Analisi e valutazione del Sito Web Pg. 55
5.12.2. JavaScript Pg. 56
6. Conclusioni Pg. 57
7. Sviluppi futuri Pg. 57
8. Bibliografia e fonti web Pg. 58

3
 1. Introduzione
Il Dipartimento di Ingegneria Civile Ambientale (DICA) dell’Università degli Studi di Trieste con l’intenzione
di presentare e rendere pubblici al dominio internet alcuni suoi progetti e i relativi risultati ottenuti, ha
richiesto la realizzazione di un sito web per la presentazione ed il continuo aggiornamento dell’attività
scientifica di un loro laboratorio di Geomatica. Si richiede inoltre la realizzazione teorica di una base di dati
da interfacciare possibilmente al sito web e che permetta al personale del laboratorio la gestione di articoli
scientifici, altri progetti relativi a quello più generale GeoSNaV e pubblicazione e gestione delle informazioni
relative ai ricercatori operanti in tali progetti.
Scopo principale di questo progetto dovrà essere quindi quello di fornire la possibilità al dipartimento di
presentare e fornire un costante aggiornamento sullo sviluppo del progetto chiamato GeoSNaV (Geodesy
and Satellite Navigation) mediante l’utilizzo del sito web richiesto e di realizzare una base di dati, completa
di procedure di gestione e interrogazione, da poter poi in futuro andare ad inserire nel sito.

Il Laboratorio GeoSNaV è stato creato presso il Dipartimento di Ingegneria Civile per enfatizzare le attività
di ricerca condotte dai membri del gruppo nell’ambito del GNSS (Global Navigation Satellite Systems),
rinforzare i collegamenti con partner europei, connettere le attività sperimentali comuni su GNSS e in
particolare EGNOS (European Geostationary Navigation Overlay Service) e facilitare la creazione di network
con altri centri di ricerca e imprese europee per la partecipazione ad altri Progetti di Ricerca banditi dalla
Comunità Europea.
Attività di ricerca e campagne sperimentali sono state condotte assieme a ricercatori di paesi come
Slovenia, Croazia, Albania, Bosnia e Erzegovina, Repubblica Ceca, Polonia, Inghilterra e Francia.

In considerazione del fatto che il contenuto della base di dati dovrà quindi essere consultabile su molte
postazioni differenti spesso localizzate al di fuori dello stesso laboratorio e dipartimento DICA, la soluzione
migliore e anche più ovvia, risulta quella di rendere l’applicativo per la comunicazione e gestione del data
base direttamente implementabile sul portale web mediante un’interfaccia utente disponibile su apposite
pagine del sito.
Questo tipo di approccio progettuale e costruttivo garantisce una facile ed immediata accessibilità ai
contenuti e alla gestione del data base senza dover essere costretti ad installazioni di programmi specifici
sui computer che in seguito verranno usati come client.
Particolare attenzione va quindi prestata al fattore compatibilità che impone all’interfaccia
dell’applicazione di essere perfettamente fruibile su tutti i browser più comunemente usati oggigiorno:
Internet Explorer, Mozilla Firefox, Google Chrome, Opera e Safari. Questo approccio risulta essere spesso
utilizzato per lo sviluppo di software simili in quanto permette di sorvolare le problematiche relative al
possibile e frequente utilizzo di postazioni con sistemi operativi differenti, come Windows, Linux o Mac OS
anche all’interno dello stesso laboratorio. Nonostante questo risulti essere un approccio abbastanza
consueto e che quindi si presentino spesso caratteristiche comuni ad altri progetti, ciò non toglie che sia
necessaria comunque un’analisi completa di tutte le problematiche e delle relative soluzioni da adottare
per arrivare poi alla realizzazione finale del sistema. Questa condizione risulta essere vera anche nel caso in
cui per la realizzazione si vadano a sfruttare delle tecnologie ben consolidate negli anni come Java, HTML,
PHP, CSS, e MS SQL Server.

4
 2. Obbiettivi
Obbiettivo del lavoro di questa tesi è quello di sviluppare un sito web che come scopo primario ha quello di
presentare, descrivere e fornire aggiornamenti sullo stato del progetto GeoSNaV e degli altri progetti ad
esso correlati. Realizzare un data base che consenta la memorizzazione di tutto il materiale scientifico e dei
dati che si richiede di gestire e progettare l’interfaccia grafica dell’applicativo per la gestione di tale sistema.
Obbiettivi che ci si prefigge con lo sviluppo del data base, nel caso di una sua reale implementazione, sono
quelli di riuscire a gestire e documentare particolari progetti di interesse scientifico, gestire ed ottimizzare il
flusso di informazioni relative al progetto su scala europea fra le varie università, permettere un costante
aggiornamento sullo stato di avanzamento e sviluppo e facilitare la creazione di network con altri centri di
ricerca e imprese europee per la partecipazione ad altri Progetti di Ricerca in ambito GNSS e EGNOS.

Dagli incontri e colloqui avuti con il committente del progetto, sono emerse più chiaramente le necessità ed
esigenze espresse sulle funzionalità e caratteristiche che il prodotto software dovrà possedere. Dalla
racconta di queste informazioni è stato possibile definire quelli che saranno gli obbiettivi e passaggi
strategici per la progettazione, sviluppo e realizzazione di tale progetto:

Realizzazione del data base attraverso lo studio della

lista dei requisiti raccolti

Verifica del rispetto di tali requisiti in base alle

procedure di gestione implementate sul data base

Determinazione e sviluppo teorico dell'interfaccia

utente in base alle funzionalità richieste

Sviluppo del sito web di presentazione del progetto,

suo studio e valutazione

Testing, pubblicazione del sito e sua messa in

funzione.

Il software scelto per creare il tutto è stato il seguente:

 Microsoft SQL Server 2008 Express Edition per la costruzione del Data Base.
 Microsoft SQL Server 2008 Management Studio per la progettazione fisica del Data Base e
creazione delle query.
 Linguaggio HTML per la costruzione della parte statica della pagina web.
 Linguaggio PHP per la creazione dell’interfaccia dinamica di gestione Data Base.
 Java Script per la cura di alcuni dettagli grafici del sito web e per la visualizzazione della galleria
d’immagini.
 CSS per la gestione e definizione degli stili delle pagine e del Java Script.
 Web Page Maker per la realizzazione della parte statica del sito.
 Adobe Dreamweaver CS3 per la realizzazione e progettazione di tutte le componenti dinamiche.
 Microsoft Visio 2008 per la realizzazione dei diagrammi.
 Microsoft Visual Studio 2008
 VS.php 2008 per la costruzione e relativo test dei form in php
5
 3. Stato dell’Arte e Vincoli di progetto

L’applicativo che ci si prefigge di realizzare non va a sostituire nessun software preesistente quindi non si
necessita di nessuna analisi del software già eventualmente in utilizzo all’interno del laboratorio.
Attualmente per la presentazione di progetti o dati scientifici ci si affida solamente a conferenze o alla
pubblicazione di articoli scientifici su riviste specializzate.
Ora, con la realizzazione di questo progetto, si cerca di concentrare tutte le informazioni comuni al progetto
GeoSNaV in un unico sito web ponendosi come obbiettivo quello di massimizzare il numero di lettori di
questi dati grazie ai vantaggi offerti dalla tecnologia web e dal network che si cerca di andare a creare.

Caratteristica fondamentale e vincolo per questo sviluppo sarà quello di rendere le informazioni
perfettamente reperibili e consultabili da qualsiasi centro di ricerca e impresa europea e quindi più in
generale, da qualsiasi postazione con accesso ad internet.
Ciò implica la realizzazione teorica anche di un’interfaccia che sia compatibile con tali requisiti e vincoli.
Per questo motivo inoltre, la lingua usata per la realizzazione del sito sarà necessariamente l’inglese in
modo permettere la chiara lettura delle informazioni in esso contenute a chiunque ne fosse interessato.

6
La presente tesi si suddivide in due capitoli principali che riguardano strettamente lo sviluppo del software:

Il capitolo di Analisi descrive quelle che sono state le metodologie usate per arrivare alla progettazione
concettuale del data base e le conclusioni alla quali esse hanno portato grazie all’utilizzo del modello entità-
relazioni con tutto ciò che esso comporta.

Il capitolo di Realizzazione riporta i passi realizzativi e di implementazione della Business Logic inerente
all’applicazione, la descrizione e lo sviluppo delle funzionalità, la definizione delle modalità di interazione
degli utenti con l’applicativo e quindi con il data base, la realizzazione teorica dell’interfaccia messa loro a
disposizione e la creazione ed analisi del sito web su cui essa si andrà ad appoggiare.

7
 4. Analisi
Il questo capitolo si procederà con l’analisi concettuale e funzionale del problema. Quest’analisi viene
utilizzata per determinare le specifiche ed i vincoli per la successiva realizzazione logica dell’applicazione.
Nel dettaglio, la progettazione concettuale della base di dati si articola nei seguenti passi:

Acquisizione dei requisiti espressi dal committente e loro

ristrutturazione per classi omogenee

Creazione delle definizioni nel glossario dei termini

Progettazione dello schema scheletro del diagramma E-R

Analisi delle entità e delle relazioni con i loro attributi

Costruzione dello schema concettuale E-R finale con

l'inserimento degli attributi e delle cardinalità

8
 4.1. Requisiti espressi in forma ristrutturata

L’acquisizione dei requisiti del progetto dalle richieste espresse dal committente del software, permette di
determinare fin da subito quali proprietà e caratteristiche dovrà possedere il sistema di cui si richiede la
realizzazione fornendo così anche delle idee più chiare sulla quantità di lavoro che comporterà la
realizzazione del progetto e della conseguente miglior strategia di approccio per la sua realizzazione.
Risulta essere questa una delle fasi più importanti dell’analisi per lo sviluppo del sistema in quanto un
eventuale errore di valutazione verificatosi in questa fase, si propagherebbe al resto del progetto
attraversando tutti i passaggi successivi aumentandone così la sua importanza ed il conseguente impatto
sulla sua realizzazione finale.
Si riporta di seguito il passaggio subito successivo a quello della raccolta dei requisiti; la strutturazione
dettagliata di tali requisiti per classi omogenee:

 Requisiti e richieste a CARATTERE GENERALE:

 Si chiede di realizzare una base di dati e la realizzazione teorica dell’interfaccia del Sistema
Informativo per la presentazione del progetto GeoSNaV e la gestione dei dati, pubblicazione
scientifiche e progetti ad esso collegati.
 Il sistema e i dati contenuti all’interno del data base dovranno essere raggiungibili da
qualsiasi postazione che abbia un collegamento ad internet.
 Il sistema non dovrà risentire o essere vincolato dal tipo di sistema operativo utilizzato sulla
postazione in quanto è frequente l’utilizzo di macchine con sistemi diversi all’interno dello
stesso laboratorio.
 La gestione del data base dovrà essere di facile comprensione e di rapido apprendimento.
 La pagina web di presentazione del progetto dovrà essere semplice, chiara e possibilmente
in lingua inglese in quanto si tratta di un progetto a livello europeo.

 Requisiti e vincoli sugli UTENTI:

 Ogni utente potrà visitare liberamente la pagina web senza alcuna restrizione.
 Ogni utente dovrà poter consultare liberamente i contenuti messi eventualmente a
disposizione dal data base in sola lettura.

 Requisiti e vincoli sul PERSONALE:

 Ogni individuo facente parte del personale del progetto o di altri progetti ad esso correlati,
potrà accedere ai dati in lettura ed al sito stesso come ogni altro comune utente.
 Al personale comune non sarà concessa la modifica e cancellazione dei dati contenuti nel
data base.
 Di ogni individuo facente parte del personale, verranno memorizzati nel data base le sue
informazioni personali di base, il suo curriculum in forma standardizzata con possibilità di
inserire un link ad un curriculum esterno più esauriente e la lista dei suoi contatti.
 Si richiede la presenza di una particolare classe di utenti chiamati Collaboratori Stretti che
potranno accedere al data base per modificarne i dati presenti assieme al coordinatore del
progetto.
 Alla classe dei collaboratori stretti sarà concesso l’inserimento, la modifica e la
cancellazione di progetti, articoli, curriculum vitae e profili utente del personale.
 Ai collaboratori stretti non sarà possibile modificare o cancellare il profilo del coordinatore.

9
 Requisiti e vincoli per la parte di AUTENTICAZIONE
 L’applicazione e le operazioni di autenticazione dovranno essere di immediata intuizione e
facilmente raggiungibili dal coordinatore e dai suoi collaboratori stretti.
 L’accesso al sistema tramite autenticazione sarà fruibile solo al coordinatore del progetto e
ai suoi collaboratori stretti in possesso delle credenziali necessarie.
 Il processo di autenticazione verrà eseguito dopo l’inserimento di un Username e di una
Password.
 Per facilitare l’accesso e la procedura di identificazione, password e nome utente verranno
scelte direttamente dalla stessa persona e fornite al collaboratore o ai collaboratori stretti
per l’inserimento e la successiva attivazione.

 Requisiti e vincoli sui CURRICULUM VITAE e CONTATTI:

 Saranno memorizzate nel CV le informazioni personali di base del contatto fra cui nome,
cognome, ruolo, titolo di studio conseguito e relativo anno, luogo di conseguimento del
titolo di studio, e link a curriculum esterno più dettagliato.
 Il CV dovrà fornire la lista della pubblicazioni fatte e dei progetti a cui ha partecipato quella
determinata persona.
 Dovranno essere memorizzate per l’utente anche le informazioni relative ai suoi contatti e
quindi la città in cui vive, l’eventuale università in cui studia o lavora, il motivo per cui si
trova in quella città o università, la lista dei suoi contatti telefonici (massimo 3) e la lista dei
suoi contatti mail (massimo 3).

 Requisiti e vincoli sulle PUBBLICAZIONI / ARTICOLI:

 Ogni articolo potrà essere immesso una sola volta nel data base dal coordinatore o dai suoi
collaboratori stretti sotto forma di URL o di link ad altra pagina web in cui esso è contenuto
o visualizzato. La motivazione di questa scelta deriva dal fatto che si ha disposizione poco
spazio per la memorizzazione di tali articoli all’interno del server e così facendo inoltre, si
evitano e aggirano molti problemi relativi al copyright di queste pubblicazioni.
 Per ogni articolo verranno memorizzati il titolo, una sua breve descrizione, la lista degli
autori e dei progetti ad esso correlati, il link alla risorsa e la data di pubblicazione o stesura.
 Si dovranno memorizzare le eventuali modifiche fatte ai dati della pubblicazione, l’utente
che le ha fatte e la data di modifica.

 Requisiti e vincoli sui PROGETTI:

 Ogni nuovo progetto potrà essere inserito una sola volta nel data base dal coordinatore o
dai suoi collaboratori stretti.
 Per ogni progetto si memorizzeranno il titolo, la data, lo stato del progetto, una breve
descrizione, la lista del personale che vi ha partecipato, la lista delle pubblicazione relative
al progetto in questione e un campo di note e aggiornamenti.
 Si dovranno inoltre memorizzare le eventuali modifiche fatte ai dati del progetto, l’utente
che le ha fatte e la data di questa modifica.

10
 Requisiti e vincoli sulle operazioni di RICERCA possibili sul Data Base:
 La consultazione dei dati messi a disposizione dal data base sarà permessa a qualsiasi
visitatore della pagina web.
 Dovrà essere resa disponibile all’utente la ricerca per nome o cognome personale che come
risultato deve visualizzazione il CV, le pubblicazioni personali e la lista dei progetti a cui
quella persona ha partecipato.
 Dovrà essere resa disponibile la ricerca per titolo del progetto che come risultato deve
fornire i dati relativi al progetto ricercato, la lista del personale che vi ha partecipato e la
lista delle pubblicazioni che lo riguardano.
 Dovrà essere resa disponibile la ricerca per titolo della pubblicazione che come risultato
deve fornire il link o URL del file della pubblicazione, la lista degli autori e del progetto a cui
essa fa riferimento.
 Dovrà essere resa disponibile una ricerca di tutte le pubblicazioni e di tutti i progetti che
restituirà una lista di tutte le pubblicazioni o dei progetti che sono stati inseriti fino a quel
momento all’interno del data base.
 Dovrà essere resa disponibile una ricerca che permetta di visualizzare la lista di tutti gli
utenti inseriti fino a quel momento all’interno del data base.
 Non ci dovranno essere limiti al numero massimo di ricerche per persona o alcun limite
temporale fra una ricerca e quella successiva.
 I risultati delle ricerche dovranno essere visualizzati possibilmente in una semplice tabella.
In caso di link o URL a file, sarà concesso lo scaricamento diretto o un reindirizzamento ad
una pagina esterna tramite link cliccabile.

11
 4.2. Glossario dei termini

Passo successivo alla stesura dei requisiti in forma ristrutturata è quello di creare un glossario dei termini
che come scopo, non ha solo quello di accumunare le parole ed i sinonimi, ma anche quello di creare le
prime relazioni fra i concetti principali che in esso sono contenuti.

Termine Descrizione Sinonimi Collegamenti

E’ la base di partenza per l’accesso ai dati contenuti nel Data Applicativo
Sito Progetto GeoSNaV, Utente
Base e alla presentazione del progetto GeoSNaV. Web, Pagina

È la persona fisica esterna al personale del progetto. Ha

comunque la possibilità di accedere ai sito in lettura e di User,
Utente Progetto, Pubblicazione, Sito
consultare i dati. Può inoltre essere un autore di una Utilizzatore
pubblicazione e un collaboratore di un progetto.

Raggruppa in esso la lista di tutte le persone che collaborano Amministratore,

Personale al progetto in questione o a progetti collegati. Di loro si Staff Collaboratore, Progetto,
memorizza anche il Curriculum Vitae e la lista dei Contatti. Pubblicazione

E’ colui che ha creato il sistema e che è in possesso di tutti i

Amministratore Coordinatore
privilegi.

Rappresenta il gruppo di collaboratori più vicini al

Collaboratore
Coordinatore. Sono in possesso delle credenziali di accesso
Stretto
per la gestione dati sul DB.
Personale, Progetto,
Fa parte del personale interno all’università che ha Pubblicazione
Collaboratore
collaborato al progetto o pubblicazione. Non possiede
Interno
credenziali o privilegi sul DB.

Fa parte del personale esterno all’università di Trieste che ha

Collaboratore
collaborato al progetto o pubblicazione. Non possiede
Esterno
credenziali.

Username, Criterio di identificazione del personale con privilegi sul Data Amministratore,
Credenziali
Password Base, come l’amministratore e i suoi collaboratori stretti. Collaboratore Stretto

Ogni individuo facente parte del personale del progetto, avrà

Personale, Pubblicazioni,
Curriculum memorizzato un suo CV nel data base, contenente anche la Carriera, CV
Progetti
lista dei progetti a cui ha partecipato e le sue pubblicazioni.

Articolo relativo a GeoSNaV o a progetti ad esso collegati, Articolo,

Pubblicazione pubblicati dal personale come risultati di studi e rilevazioni Pubblicazione Progetto, Curriculum
condotte sempre nell’ambito del laboratorio di geomatica. Scientifica

Rappresenta l’autore o gli autori della pubblicazione in Pubblicazione, Curriculum,

Autore
questione. Utente

Possono riguardare le singole rilevazioni condotte per sotto- Rilevazioni,

Progetto Pubblicazione, Curriculum
progetti sempre relativi al progetto madre GeoSNaV. Project

Rilevazioni Indica l’acquisizione di dati, relativa ad un progetto. Dati Progetto, Pubblicazione

E’ l’atto attraverso il quale l’utente in possesso dei privilegi Amministratore,

Inserimento Upload,
necessari, inserisce e memorizza nel Data Base un nuovo Collaboratore Stretto,
Nuovo Record Caricamento
record. Personale, Articolo, Progetto

Operazione con cui qualsiasi utente può ricercare e consultare Consultazione, Utente, Articolo, Curriculum,
Ricerca Record
il contenuto del Data Base. Utilizzo Progetto

Amministratore,
Cancellazione E’ l’eliminazione di un record dal database concessa solo
Eliminazione Collaboratore Stretto,
Record all’amministratore e ai suoi collaboratori stretti.
Articolo, Progetto, Utente

12
 4.3. Progettazione del Diagramma E-R

Il modello E-R ( Entità-Relazioni ) è impiegato nelle fasi iniziali della progettazione di un sistema data base e
serve per fornire uno schema concettuale che sia il più possibile congruo con la realtà dei dati e del sistema
che si sta cercando di realizzare.
Scopo pratico di questo modello è quello di semplificare il data base che si cerca di realizzare rendendo di
conseguenza leggibili a tutti le intenzioni e i passi necessari per raggiungere l’implementazione fisica e
quindi finale della struttura della base di dati.

4.3.1. Strategia di approccio

Per questa fase della realizzazione del progetto e lo sviluppo del diagramma E-R, si è scelto di adottare la
classica strategia mista. Partendo da uno schema scheletro di base in cui si inseriscono le entità principali,
grazie a successive ristrutturazioni, raffinamenti, espansioni e generalizzazioni, esso permette di arrivare
alla stesura del diagramma concettuale E-R con attributi e cardinalità.

4.3.2. Definizione delle Entità

Dall’analisi del problema e dei requisiti espressi si sono identificate le seguenti entità: Utente, Utente
Interno, Utente Esterno, Utente Con Credenziali, Utente Senza Credenziali, Pubblicazione, Progetto,
Contatti E-Mail e Contatti Telefonici.

4.3.3. Definizione delle Relazioni

Con lo stesso procedimento attuato per la definizione delle entità, si sono individuate le relazioni che
legano fra loro le entità trovate poco prima. Le relazioni individuate sono: Autore, Collaboratore, Relazione,
Inserimento, Modifica e Possessore.

13
 4.3.4. Descrizione dei concetti

Un Utente inserito e memorizzato all’interno del data base, può non far parte del personale interno al
progetto e quindi in questo caso essere considerato come un Utente Esterno. Ogni tipo di Utente può però
essere Autore di una o più Pubblicazioni contemporaneamente, o Collaboratore di uno o più Progetti
contemporaneamente.
Un Utente Interno fa parte del personale interno al progetto GeoSNaV e in quanto tale risulta in possesso di
un curriculum vitae. Un Utente Interno può essere poi anche un Utente Con Credenziali nel caso in cui sia
anche un collaboratore stretto del coordinatore, oppure un Utente Senza Credenziali nel caso opposto.
Ogni Utente Interno è Possessore di nessuno o più Contatti E-Mail (se disponibili e forniti in fase di
inserimento) e di nessuno o più Contatti Telefonici (sempre se disponibili e forniti in fase di inserimento).
Ai soli Utenti Con Credenziali è concesso l’Inserimento nel sistema di uno o più nuovi Progetti e di una o più
nuove Pubblicazioni. La stessa cosa è valevole anche per quanto concerne la Modifica di tali dati dove ai soli
Utenti Con Credenziali è concessa la Modifica dei dati di una Pubblicazione o di un Progetto.
In fine, un Progetto può essere collegato in Relazione a nessuna o più Pubblicazioni che lo possono
riguardare e viceversa, una Pubblicazione può essere Relazionata a nessuno o più Progetti
contemporaneamente.

4.3.5. Stesura degli attributi

Dopo un’attenta analisi delle entità e delle relazioni si è giunti alla stesura della seguente lista degli Attributi
individuati dalle Entità poco sopra descritte:

 Utente: ID_Utente, Nome, Cognome.

 Utente Interno: Titolo Conseguito, Luogo, Anno, Città, Università, Scopo, Link Curriculum.
 Utente Esterno: (Nessun attributo).
 Utente Con Credenziali: Username, Password.
 Utente Senza Credenziali: (Nessun attributo).
 Contatti E-Mail: ID_Mail, ID_Utente, Mail.
 Contatti Telefonici: ID_Telefono, ID_Utente, Tipo Numero, Numero.
 Progetto: ID_Progetto, Titolo, Anno, Stato, Breve Descrizione, Note, Inserito Da, Data Inserimento.
 Pubblicazione: ID_Pubblicazione, Titolo, Anno, Breve Descrizione, URL o Link, Inserito Da, Data
Inserimento.

14
 4.4. Diagramma E-R con Attributi e Cardinalità

In questa fase della progettazione sono ancora presenti delle generalizzazioni come ad esempio l’entità
generale Utente e l’entità generale Utente Interno che poi in fase di progettazione logica verranno
eliminate in modo da avvicinare questo sistema il più possibile ad un modello di tipo relazionale.

15
 5. Realizzazione
Nella prima parte di questo capitolo si tratta l’analisi e la progettazione logica della base di dati.
E’ infatti la progettazione logica il passaggio successivo a quella concettuale.
Essa si compone principalmente di un’attività di ristrutturazione dello schema E-R precedentemente
ottenuto con una traduzione dello stesso verso il modello logico e quindi più vicino a quello che poi si andrà
a realizzare concretamente con MS SQL.
La progettazione logica della base di dati si articola secondo i seguenti passi che risultano essere nella
sequenza specificata, tutti collegati fra loro:

Definizione della Tabella dei Volumi

Stima della frequenza delle operazioni sui dati

Workflow di alcune operazioni di esempio

Eliminazione delle generalizzazioni e

partizionamento dei concetti

Normalizzazione delle tabelle e scelta delle

chiavi primarie

Costruzione dello schema E-R finale

ristrutturato

Realizzazione del data base e descrizione delle

tabelle

16
 5.1. Tabella dei volumi

Nelle tabelle dei volumi vengono riportati i concetti principali dello schema E-R come le entità e relazioni
con i relativi volumi di utilizzo previsti a regime. Questa costituisce la base per l’effettiva realizzazione
dell’applicazione in quanto permette di attuare una ristrutturazione basata su dei criteri di ottimizzazione e
semplificazione, più una traduzione in riferimento ad un modello logico in quanto si tratta di una
valutazione dei costi delle operazioni sul data base.

ENTITÀ RELAZIONI

CONCETTO VOLUME CONCETTO VOLUME

Utenti 100 Inserimento Pubblicazione 100

Utente Interno 20 Modifica Pubblicazione 50

Utente Esterno 80 Inserimento Progetto 20

Utente con Credenziali 4 Modifica Progetto 10

Utente senza Credenziali 16 Autore 200

Pubblicazione 100 Collaboratore 60

Progetto 20 Possessore Contatti Tel. 90

E-Mail 200 Possessore Mail 90

Contatti Telefonici 200

17
 5.2. Stima frequenza operazioni sui dati

N° TIPO OPERAZIONE FREQUENZA

1 Creazione e inserimento nuovo profilo personale interno Circa 2 volte a settimana

2 Modifica profilo personale già esistente Circa 1 volta a settimana

3 Cancellazione profilo personale dal Data Base Circa 1 volta al mese

4 Creazione e inserimento nuovo progetto Circa 1 volta al mese

5 Modifica e aggiornamento dati del progetto Circa 1 volta a settimana

6 Cancellazione progetto dal Data Base Circa 1 volta all’anno

7 Creazione e inserimento nuova pubblicazione Circa 5 volte a settimana

8 Modifica e aggiornamento dati della pubblicazione Circa 1 volta al mese

9 Cancellazione pubblicazione dal Data Base Circa 1 volta al mese

10 Visualizzare il profilo personale di un collaboratore Circa 5 volte a settimana

11 Visualizzare il Curriculum Vitae di un collaboratore Circa 5 volte a settimana

12 Visualizzare i dati di un progetto Circa 20 volte a settimana

13 Visualizzare una pubblicazione Circa 20 volte a settimana

14 Visualizzare tutte le pubblicazioni di cui un individuo è autore Circa 20 volte a settimana

15 Visualizzare tutti i progetti in cui un individuo ha collaborato Circa 20 volte a settimana

16 Visualizzare la lista di tutti collaboratori di un progetto Circa 20 volte a settimana

17 Visualizzare la lista di tutti gli autori di una pubblicazione Circa 20 volte a settimana

18 Visualizzare la lista di tutti gli articoli collegati ad un progetto Circa 20 volte a settimana

19 Accesso alla parte riservata del sito Circa 5 volte al giorno

20 Creazione nuovo record su tabella degli utenti Circa 10 volte a settimana

21 Cancellazione record di un utente dalla tabella Circa 1 volta a settimana

22 Modifica e aggiornamento campi utente Circa 1 volta a settimana

23 Visualizza la lista di tutti gli utenti inseriti Circa 5 volte a settimana

24 Visualizza la lista di tutti i progetti inseriti Circa 5 volte a settimana

25 Visualizza la lista di tutte le pubblicazioni inserite Circa 5 volte a settimana

Come si può ben notare dalla stima circa la frequenza delle varie operazione che verranno svolte dal
sistema sul data base, non si ha come principale preoccupazione quella di dover gestire nel complesso
grossi carichi e quindi di dover ottimizzare i flussi di lavoro. La stessa cosa vale per la normalizzazione e il
controllo delle ridondanze, anche queste fasi fondamentali per lo sviluppo logico di una base di dati che
cerchi di avvicinarsi il più possibile al modello di tipo relazionale.

18
Questa considerazione sul basso carico di lavoro sorge naturale se si va a considerare che il sistema che si
sta cercando di realizzare, ha più uno scopo di immagazzinamento informazioni, piuttosto che quello di
gestione di grossi e continui flussi di dati e utenti sia in ingresso che in uscita dal sistema.
Anche per le operazioni di autenticazione mediante l’uso di Username e Password in questo caso non si
prevede di superare i 5 accessi al giorno nonostante questa sia usualmente una delle operazione che più
spesso si ripete su sistemi e applicazioni web di questo genere.
Quindi da queste analisi specifiche, il progetto conferma la sua iniziale idea di concezione, e cioè quella di
diventare una collezione di dati per la memorizzazione e divulgazione di informazioni a carattere scientifico.
Nel caso di sua implementazione sul sito web, si assume infatti per certo e scontato un iniziale intenso
utilizzo del data base e di tutte le operazioni prima elencate, soprattutto quelle di inserimento, per poi
procedere verso una fase di stabilizzazione dell’intensità di utilizzo secondo le stime appena fatte.

Va considerato inoltre che in questo caso, risulta molto difficile riuscire a fornire delle stime precise
riguardo alla reale intensità di utilizzo a regime e quindi al numero di operazioni nell’unità di tempo in
quanto il più delle operazioni, e nella maggior parte dei casi, verranno svolte da utenti non registrati e
probabilmente solo in visita al sito.

19
 5.3. Workflow di alcune operazioni di esempio

5.3.1. Inserimento nuovo progetto

Username
Password

UTENTE CON
CREDENZIALI

(0,N) (0,N)

INSERIMENTO INSERIMENTO

(1,1) (1,1)

RELAZIONE

(0,N) (0,N)

PUBBLICAZIONE PROGETTO

URL o Link ID_Pubblicazione Note ID_Progetto

Inserito Da Titolo Inserito Da Titolo
Data Inserimaneto Anno Data Inserimaneto Anno
Breve Descrizione Stato
Breve descrizione

Per quanto riguarda l’operazione di inserimento nuovo Progetto ci sono due possibili strade da seguire in
base a dei fattori ben precisi. Nella prima ipotesi (quella in verde) si procede ad inserire un nuovo Progetto
di cui sono state anche già memorizzate le eventuali pubblicazioni ad esso collegate. Una volta inseriti tutti i
dati del progetto, per completare l’operazione passo infatti a collegare ad esso tutte le pubblicazioni che lo
riguardano.
Nella seconda ipotesi (quella in giallo) invece si procede ad inserire un nuovo Progetto di cui non sono
ancora state inserite le eventuali pubblicazioni correlate. Dopo aver inserito infatti tutti i dati relativi al
Progetto, passo all’inserimento anche di tutte le Pubblicazioni che lo riguardano e di cui sono in possesso al
momento. Una volta inserite queste pubblicazioni, le collego al progetto prima inserito.
Per l’analisi di questa operazione si è dato per scontato il fatto che ogni utente collaboratore del progetto o
autore della relativa pubblicazione correlata, sia già inserito e memorizzato all’interno del sistema. In caso
contrario si dovrà perciò procedere anche all’inserimento di tali utenti. Si può inoltre verificare il caso in cui
al nuovo progetto inserito, non sia correlata nessuna pubblicazione e che quindi quest’ultimo passaggio
non risulti più essere necessario.

20
 5.3.2. Inserimento nuovo Utente Con Credenziali

ID_Telefono
ID_Utente
Tipo Numero
Numero ID_Utente
Nome
Cognome

ID_Mail CONTATTI TELEFONICI Link Curriculum

ID_Utente Città
UTENTE
Mail Università
Scopo
Foto
E-MAIL DETENTORE Titolo conseguito
Luogo
Anno

UTENTE INTERNO
DETENTORE

Username
Password

UTENTE CON
CREDENZIALI

Si analizza in questa occasione l’inserimento di un nuovo Utente Con Credenziali e quindi il caso più
complesso e completo che si possa realizzare all’interno del sistema. Proprio perché esso rappresenta il
caso più complesso in assoluto, sarà anche quello usato meno di frequente. L’inserimento di un Utente Con
Credenziali può essere effettuato dal coordinatore o dai suoi collaboratori stretti.
Questa operazione comincia con la definizione del tipo di persona da inserire scegliendo fra un Utente Con
Credenziali, un Utente Senza Credenziali o un semplice Utente Esterno; valore che rappresenterà il
contenuto dell’attributo Tipo della tblUtenti. Una volta scelto il tipo (un Utente Con Credenziali in questo
caso) si procede con l’inserimento di Nome, Cognome, Titolo conseguito, Luogo, Anno, Città, Università,
Scopo e Link Curriculum. Successivamente si passa poi all’inserimento della lista dei contatti e quindi dei
numeri telefonici e delle mail che possono essere in numero diverso da utente a utente. Infatti un Utente
Interno può avere zero, una o più mail e numeri di telefono ad esso associati. Per pura scelta pratica, il
numero delle mail o dei numeri di telefono a disposizione di ogni singolo utente, non potrà superare la
quantità di 3 mail e 3 numeri telefonici.
Come ultima operazione viene richiesto l’inserimento di una Username e Password. Per semplicità, non si è
considerata la possibilità di legare questo nuovo utente a dei progetti o a delle pubblicazioni di cui
potrebbe essere collaboratore o autore poiché si cerca di analizzare il solo inserimento nuovo Utente.

21
 5.4. Eliminazione delle generalizzazioni e partizionamento dei concetti

L’eliminazione delle generalizzazioni è uno dei passaggi fondamentali per il raggiungimento del diagramma
E-R finale in quanto apporta ad una notevole semplificazione della struttura interna e rappresenta un
processo obbligatorio per lo sviluppo di un data base relazionale.

5.4.1. Generalizzazione Utente

Questa generalizzazione si può tranquillamente eliminare introducendo un campo di tipo che specifichi la
differenza fra un Utente Interno ed uno Esterno. Risulta inoltre evidente che l’entità Utente Esterno e
Utente, possiedono fisicamente gli stessi attributi. Quindi con l’introduzione di un campo attributo
chiamato Tipo passo ad eliminare l’entità Utente Esterno e a legare quella dell’Utente Interno all’Utente
con una relazione chiamata Utente Specializzato. In un’ottica di ottimizzazione del data base, questa
eliminazione sorge spontanea osservando la tabella dei volumi dove si può facilmente notare che la
maggior parte degli utenti, saranno Utenti Esterni (80 unità) rispetto a quelli Interni (20 unità)

ID_Utente
Nome
Cognome
Tipo

UTENTE
UTENTE

UTENTE
UTENTE INTERNO UTENTE ESTERNO SPECIALIZZATO

ID_Utente Titolo conseguito ID_Utente

Nome Luogo Nome
Cognome Anno Cognome
Città UTENTE INTERNO
Università
Scopo
Titolo conseguito
Link Curriculum
Luogo
Anno
Città
Università
Scopo
Link Curriculum

22
 5.4.2. Generalizzazione Utente Interno

Del tutto similmente al caso della generalizzazione precedente, anche in questo caso essa può essere
tranquillamente eliminata introducendo un campo che identifichi la differenza fra un Utente Con
Credenziali e uno Senza Credenziali visto che l’utente senza credenziali possiede gli stessi attributi
dell’entità Utente Interno. Anche in questo caso, l’eliminazione sorge spontanea guardando nuovamente la
tabella dei volumi dove si può osservare che la maggior parte degli utenti, in questa categoria saranno
Utenti Senza Credenziali (16 unità) rispetto a quelli Con Credenziali (4 unità)

Link Curriculum
Città

Link Curriculum Università

Città Scopo

Università Titolo conseguito

Link Curriculum
Luogo
Scopo
Città
Anno
Username UTENTE INTERNO Università Tipo
Password Scopo
Titolo conseguito Titolo conseguito
Luogo Luogo UTENTE INTERNO
Anno Anno

UTENTE CON UTENTE SENZA

CREDENZIALI CREDENZIALI
UTENTE
AUTORIZZATO

UTENTE CON
CREDENZIALI

Username
Password

23
 5.4.3. Partizionamento dei concetti

Per quanto riguarda l’applicativo web e la visualizzazione dei dati ottenuti dalle interrogazione al data base
inerenti agli Utenti, si è scelto per questioni pratiche di dividere le informazioni ( info personali di base /
curriculum e informazioni di recapito ) appartenenti ad uno stesso Utente Interno in quanto esse vengono
poi visualizzate dall’applicativo solo su richiesta specifica e in modalità separata dai dati restanti.
Anche se i requisiti prestazionali del sistema risultano essere piuttosto bassi, si è comunque scelto di
frammentare tutte le informazioni relative ad un Utente Interno in quattro tabelle che conterranno
rispettivamente il Curriculum, i Contatti, i Contatti Mail e i Contatti Telefonici. Tutte e quattro queste
tabelle verranno relazionate all’utente tramite la chiave primaria identificativa ID_Utente andando così a
creare una struttura nidificata per l’entità Utente.
Si procede quindi con la creazione di quattro tabelle che descriveranno quattro entità singole e separate
seguendo anche l’indicazione imposte dalla 2 Forma Normale.
Questo partizionamento permette di garantire una riduzione del numero degli accessi e delle interrogazioni
inutili a particolari tabelle. Basti pensare che ad esempio, non sempre quando si effettua una ricerca per
nome o cognome utente sulla base di dati, si desidera poi anche visualizzare tutte le informazioni
disponibili su quel contatto. Risulta quindi evidente uno spreco di risorse come la visualizzazione dell’intero
profilo di un utente, compreso anche di tutte le sue partecipazioni in articoli e progetti quando magari di
questo, si aveva l’intenzione di trovare solo il suo contatto mail.

ID_Utente
Nome
Cognome
Tipo

UTENTE INTERNO

FORMAZIONE DETENTORE
DETENTORE DETENTORE

CURRICULUM VITAE TELEFONO

ID_Utente ID_Telefono
Titolo conseguito MAIL ID_Utente CONTATTI
Luogo Tipo Numero
Anno Numero
ID_Mail ID_Utente
Link Curriculum
ID_Utente Città
Mail Università
Scopo

24
 5.5. Normalizzazione e scelta delle chiavi primarie

Per quanto riguarda la scelta di tutte le chiavi primarie, si è prestato attenzione ad alcuni criteri
fondamentali per lo sviluppo di un data base il quanto più possibile vicino al modello relazionale:

 Ad una chiave primaria non può essere associato un valore NULL. Conseguenza di questa azione
sarebbe quella di rendere irraggiungibili e indistinguibili univocamente quei specifici record nella
tabella violando quindi i basilari vincoli di integrità referenziali.
 E’ preferibile utilizzare chiavi primarie di tipo semplice, e quindi non composte da più attributi della
stessa tabella.
 La chiave primaria è univoca ed in quanto tale, non si può ripetere per più di una volta all’intero
dello stesso concetto. Non possono esistere due record differenti ma con uguale chiave primaria
all’interno della stessa tabella.

CHIAVE
NOME DESCRIZIONE UTILIZZO ATTRIBUTI
PRIMARIA
Tabella di partenza che memorizza tutti gli
UTENTI ID_Utente Nome, Cognome, Ruolo
utenti, collaboratori e autori presenti nel DB

Tabella che memorizza Username e Password da

CREDENZIALI ID_Utente Username, Password
associare all’Utente con Credenziali

Titolo conseguito, Luogo,

Tabella che contiene i dati del curriculum di un
CURRICULUM ID_Utente Anno_Titolo,
utente interno
Link_A_Curriculum

CONTATTI Tabella che memorizza i contatti dell’utente ID_Utente Città, Università, Scopo

CONTATTI Tabella che memorizza i recapiti telefonici ID_Utente, Tipo numero,

ID_Telefono
TELEFONICI dell’utente Numero

CONTATTI MAIL Tabella che memorizza i recapiti Mail dell’utente ID_Mail ID_Utente, Mail

Titolo_Pro, Anno_Pro,
Tabella in cui vengono memorizzati i dati relativi Stato, Descrizione_Pro,
PROGETTO ID_Progetto
a tutti i progetti memorizzati nel DB Note, Pro_Inserito da,
Data inserimento Pro

MODIFICA Tabella che tiene conto di tutte le modifiche e ID_Progetto, ID_Utente,

ID_ModProgetto
PROGETTO aggiornamenti fatti ad un progetto Data, (val. mod.)

Titolo_Pub, Anno_Pub,
Tabella in cui vengono memorizzati i dati relativi Descrizione,_Pub URL o
PUBBLICAZIONE ID_Pubblicazione
a tutte le pubblicazioni memorizzati nel DB Link, Pub_Inserito da,
Data inserimento Pub

ID_Pubblicazione,
MODIFICA Tabella che tiene conto di tutte le modifiche e
ID_ModPubblicazione ID_Utente, Data, (val.
PUBBLICAZIONE aggiornamenti fatti ad una pubblicazione
mod.)

Tabella che memorizza l’elenco degli autori di ID_Utente,

AUTORE
tutte le pubblicazioni inserite nel DB. ID_Pubblicazione

Tabella che memorizza l’elenco dei collaboratori ID_Utente,

COLLABORATORE
di tutti i progetti inseriti nel DB. ID_Progetto

E’ la tabella che lega se necessario, progetti con ID_Progetto,

COLLEGAMENTI
pubblicazioni ID_Pubblicazione

25
Il data base è stato normalizzato secondo le prime 3 Forme Normali:

 1FN: Colonne atomiche. Una colonna, un valore e quindi senza unità ripetitive.
 2FN: Se è 1FN e se ogni colonna dipende solo dalla chiave primaria. Tabelle distinte per entità
distinte.
 3FN: Se è 2FN e se ogni colonna è indipendente dalle altre. Eliminazione delle colonne calcolate.

Dalla normalizzazione in terza forma si deduce inoltre l’assenza di ridondanze all’interno del data base.

5.6. Schema finale E-R ristrutturato

26
 5.7. Realizzazione del data base

Dopo aver ristrutturato lo schema E-R si procede ora alla progettazione e creazione vera e proprio della
base di dati grazie al software MS SQL Server 2008 Express Edition. All’inizio si costruiscono le tabelle, poi si
definiscono gli attributi e su questi si fissano dei vincoli di integrità dei dati, successivamente si provvede a
dar vita alle relazioni fra le varie tabelle. Il risultato così ottenuto è il seguente:

Il Diagramma dello schema dei dati è la rappresentazione grafica creata automaticamente ma su richiesta
da MSSQL Server Management Studio una volta che è stata completata la creazione di tutte le tabelle, la
definizione delle chiavi primarie e la creazione delle relazioni secondo le indicazioni ottenute dallo schema
E-R ristrutturato. Dalla creazione del diagramma dell’intero data base si può notare la presenza di 3 tabelle
di sponda create appositamente per le relazioni molti a molti che si sono venute a creare in fase di
realizzazione. Le 3 tabelle di sponda sono la tblCollaboratore_Progetto, la tblAutore_Pubblicazione e la
tblCollegamenti le cui chiavi primarie sono date dai soli attributi di cui sono composte e quindi dalle chiavi
esterne delle rispettive tabelle a cui fanno da collegamento.

27
 5.8. Descrizione delle tabelle della base di dati

Di seguito verrà riportata la descrizione di tutte le tabelle realizzate per il data base con l’analisi degli
attributi, il loro significato ed il tipo di variabile a cui essi sono stati associati. Verranno inoltre descritti i
motivi di alcune scelte a carattere tecnico che possono riguardare vari fattori all’interno di tutta la struttura
appena creata.

5.8.1. Tabella tblUtenti

La tblUtenti è la tabella di partenza per l’analisi della base di dati in quanto in essa si memorizzano tutti gli
utenti che sono stati inseriti nel sistema. Chiave primaria di questa tabella è ID_Utente che identifica
univocamente ogni utente inserito. Essa è una variabile int di tipo contatore assegnata automaticamente
dal sistema in fase di inserimento di un nuovo record. Gli attributi della tabella sono il nome (Nome), il
cognome (Cognome) ed il ruolo (Ruolo). Gli attributi Nome e Cognome sono di tipo nchar(20), valore
ritenuto più che sufficiente per memorizzare un nome o un cognome. L’attributo ruolo è invece una
variabile di tipo smallint. Questo campo indica il tipo di ruolo che l’utente in questione ricopre all’interno
del progetto; esso che può variare fra Collaboratore Stretto, Collaboratore Interno o Collaboratore Esterno.
Per ogni tipo di ruolo viene assegnata una variabile numerica (ad esempio 0, 1, 2 o 3) la cui gestione è
molto più facile a livello applicativo piuttosto che andare ad utilizzare la stringa di testo con scritto
direttamente al suo interno il ruolo.

int = E’ il tipo di dati integer primario in SQL a 4 byte.

nchar(20) = Dati di tipo Unicode carattere a lunghezza fissa contenenti di massimo 20 caratteri.
smallint = Altro tipo integer però a 2 byte.

28
 5.8.2. Tabella tblCredenziali

La tabella tblCredenziali serve per la memorizzazione delle credenziali associate ad un utente che ha come
ruolo quello di collaboratore stretto o ruolo di coordinatore. Chiave primaria di questa tabella è sempre
l’ID_Utente e come attributi si hanno solamente l’username (Username) e la password (Password),
entrambi variabili di tipo nchar(30).

5.8.3. Tabella tblCurriculum

All’interno della tabella tblCurriculum vengono memorizzate tutte le informazioni del curriculum vitae
relative ad un utente interno. Chiave primaria di questa tabella è sempre l’ID_Utente mentre gli attributi
sono il titolo di studio che l’utente ha conseguito (Titolo_Conseguito), il luogo in cui è stato conseguito il
titolo (Luogo), l’anno di conseguimento (Anno_Titolo) e un Link o URL, se presente, ad un file contenente
un curriculum più completo ed esauriente di quello memorizzato nel sistema (Link_A_Curriculum).

nvarchar(200) = Dati di tipo Unicode carattere a lunghezza variabile contenenti di massimo 200 caratteri.

29
 5.8.4. Tabella tblContatti

All’interno di questa tabella vengono memorizzati informazioni quali la città in cui si trova adesso la
persona (Città), l’università nella quale studia o lavora adesso (Università) e lo scopo (Scopo) che motiva la
presenza dell’utente in questa particolare città o università. Chiave primaria di questa tabella resta sempre
l’ID_Utente.

5.8.5. Tabella tblContatti_Telefonici

Questa tabella serve per memorizzare i recapiti telefonici dell’utente. Chiave primaria è l’ID_Telefono che è
una variabile int di tipo contatore assegnata automaticamente dal sistema in fase di inserimento di un
nuovo record. Attributi della tabella sono l’ID_Utente, Tipo_Numero e Numero. In questo caso l’ID_Utente
è una chiave esterna che lega ogni record ad un utente ben preciso. L’attributo Tipo_Numero è una
variabile di tipo smallint che specifica di che tipo sia il numero inserito scegliendo possibilità fra cui
Cellulare, Numero Dell’Ufficio o Numero Di Casa. Per ogni tipo di numero viene assegnata una variabile
numerica la cui gestione è molto più facile a livello applicativo piuttosto che andare a considerare la stringa
di testo con scritto direttamente il tipo di numero appena inserito.

30
 5.8.6. Tabella tblContatti_Mail

In questa tabella vengono memorizzati i contatti mail, se presenti, di ogni singolo utente. Chiave primaria è
l’ID_Mail, variabile di tipo int contatore assegnata automaticamente dal sistema in fase di inserimento del
nuovo record. Attributi della tabella sono l’ID_Utente che serve ad associare la mail all’utente che la
possiede e la mail stessa (Mail) memorizzata in una stringa di massimo 40 caratteri.

5.8.7. Tabella tblProgetto

In questa tabella vengono memorizzate tutte le informazioni relative ad un progetto. Chiave primaria è
l’ID_Progetto, variabile contatore di tipo int assegnata automaticamente dal sistema in fase di inserimento
di un nuovo record e che identifica univocamente ogni singolo progetto. Attributi di questa tabella sono il
titolo del progetto (Titolo_Progetto), l’anno del progetto (Anno_Progetto), lo stato (Stato) che si differenzia
fra In Corso, Completato, Sospeso o Abbandonato, una sua breve descrizione (Descrizione_Progetto), un
campo per l’inserimento di alcune note di servizio (Note), un campo per la memorizzazione dell’utente che
ha inserito il progetto all’interno del sistema (Progetto_Inserito_Da) e la relativa data di inserimento
(Data_Inserimento_Progetto). Nell’attributo Progetto_Inserito_Da è concesso l’inserimento di un valore
NULL per rendere possibile e definitiva la totale cancellazione di un utente. Senza questa clausola infatti,
non sarebbe mai stato possibile eliminare definitivamente un utente dal sistema nel caso in cui avesse
inserito ad esempio un progetto visto che avrebbe comportato la rottura di alcuni vincoli di integrità
referenziale.

smalldatetime = Definisce una data combinata con un'ora del giorno nel formato a 24 ore.

31
 5.8.8. Tabella tblMod_Progetto

In questa tabella si tiene conto di tutte le modifiche e aggiornamenti attuati ad un progetto da parte di un
utente con credenziali. Chiave primaria e l’ID_Mod_Progetto che è una variabile contatore di tipo int
assegnata automaticamente dal sistema e che garantisce l’univocità di ogni record nella tabella. Chiavi
esterne sono l’ID_Progetto che identifica il progetto sul quale sono state effettuate le modifiche e
l’ID_Utente che identifica l’utente che ha apportato queste modifiche. All’ID_Utente in questo caso è
permesso l’inserimento di un valore NULL visto che si è andati a considerare il particolare caso della
cancellazione di un utente che abbia apportato delle modifiche ad un progetto. Attributi della tabella sono
la data in cui viene effettuata questa modifica (Data_Modifica_Progetto) e l’elenco dei campi della tabella
tblProgetto che possono essere modificati dall’utente (Mod_Progetto_Titolo, Mod_Progetto_Anno,
Mod_Progetto_Stato, Mod_Progetto_Descrizione, Mod_Progetto_Note). Questi attributi sono di tipo
booleano e quindi a soli valori 1 (true) per indicare che quel campo sia stato modificato e 0 (false) per
indicare che quel campo non è stato modificato.

bit = Tipo di dati integer che può accettare un valore di 1, 0 o NULL.

5.8.9. Tabella tblPubblicazione

In questa tabella vengono memorizzate tutte le informazioni relative ad una pubblicazione. Chiave primaria
della tabella è l’ID_Pubblicazione, variabile contatore di tipo int assegnata automaticamente dal sistema in
32
fase di inserimento di un nuovo record e che identifica univocamente ogni pubblicazione. Attributi di
questa tabella sono il titolo assegnato alla pubblicazione (Titolo_Pubblicazione), l’anno della pubblicazione
(Anno_Pubblicazione), una sua breve descrizione (Descrizione_Pubblicazione), il link da cui poter accedere
al file pubblicazione vero e proprio (URL_o_Link), un campo per la memorizzazione dell’ID_Utente che ha
inserito la pubblicazione nel sistema (Pubblicazione_Inserita_Da) e la data in cui essa è stata inserita nel
sistema (Data_Inserimento_Pubblicazione). Anche in questo caso è consentito l’inserimento di un valore
NULL nell’attributo Pubblicazione_Inserita_Da per gli stessi motivi prima descritti.

5.8.10. Tabella tblMod_Pubblicazione

In questa tabella si tiene conto di tutte le modifiche e aggiornamenti applicati da parte di un utente con
credenziali ad una pubblicazione. Chiave primaria e l’ID_Mod_Pubblicazione che è una variabile contatore
di tipo int assegnata automaticamente dal sistema e che garantisce l’univocità di ogni record della tabella in
questione. Chiavi esterne sono l’ID_Pubblicazione che identifica la pubblicazione sul quale sono state
effettuate le modifiche e l’ID_Utente che identifica l’utente che ha apportato queste modifiche. Attributi
della tabella sono la data in cui viene effettuata la modifica (Data_Modifica_Pubblicazione), e per ultimi
l’elenco dei campi della tabella tblPubblicazione che si possono modificare (Mod_Pubblicazione_Titolo,
Mod_Pubblicazione_Anno, Mod_Pubblicazione_Descrizione, Mod_Pubblicazione_URL). Questi attributi
sono di tipo booleano e quindi a soli valori 1 (true) per indicare che quel campo sia stato modificato e 0
(false) per indicare che quel campo non è stato modificato.

5.8.11. Tabella tblAutore_Pubblicazione

Questa è la tabella che collega un utente ad una pubblicazione secondo la relazione che esso sia l’autore di
quella pubblicazione. Chiavi primarie di questa tabella sono l’ID_Pubblicazione e l’ID_Utente che assieme
identificano univocamente ogni record e che da sole costituiscono la relazione voluta.

33
 5.8.12. Tabella tblCollaboratore_Progetto

Questa è la tabella che collega un utente ad una progetto secondo la relazione che esso sia un
collaboratore di quel progetto. Chiavi primarie di questa tabella sono l’ID_Progetto e l’ID_Utente che
assieme identificano univocamente ogni record e che da sole costituiscono la relazione voluta.

5.8.13. Tabella tblCollegamenti

Questa è la tabella che correla un progetto ad una pubblicazione secondo la relazione che essi siano
associato l’uno con l’altro. Chiavi primarie di questa tabella sono l’ID_Pubblicazione e l’ID_Progetto che
assieme identificano univocamente ogni record e che da sole costituiscono la relazione voluta.

34
 5.9. Descrizione delle funzionalità

L’applicativo, come anche la stessa struttura del data base, prevede una serie di funzionalità derivate in
parte dall’analisi fatta del sistema ed in parte dalle specifiche richieste espresse dal committente.
Le funzionalità derivate dall’analisi sono principalmente quelle necessarie all’inserimento, modifica e
cancellazione dei dati mentre le funzionalità derivanti dalle richieste espresse in fase di acquisizione dei
requisiti, riguardano principalmente le modalità con cui si vanno a gestire le operazioni, il loro workflow
operativo e la semplicità con cui esse devono essere implementate nel sistema.
Segue un elenco delle principali funzionalità implementate:

 Solamente dopo aver effettuato l’autenticazione, all’utente con credenziali sarà concesso di
visualizzare la zona riservata del sito mediante una pagina Home Profilo dove vi sarà implementata
l’interfaccia per la gestione di tutti i tipi di dati presenti sul data base partendo da una schermata
iniziale che permetterà di scegliere che operazione effettuare e su cosa effettuarla.

 I tipi di ricerca disponibili saranno principalmente due: uno che permetta di visualizzare la lista di
tutti i progetti, pubblicazioni e utenti inseriti nel data base e l’altra che implementa una ricerca
specifica di un utente per nome o cognome, di un progetto per titolo del progetto e di una
pubblicazione per titolo della pubblicazione.

 Sarà implementata la possibilità di effettuare le proprie ricerche sul motore di ricerca Google,
opzione molto utile nel caso in cui le ricerca effettuate all’interno del data base, non diano i risultati
sperati.

 Una volta visualizzato il singolo profilo utente, o singolo progetto o singola pubblicazione, sarà nel
caso possibile selezionare che tipo di azione fare sul record scegliendo fra la sua modifica o la sua
cancellazione.

 Viene data la possibilità all’utente autenticato di inserirei collegamenti fra le varie entità principali,
modificare i collegamenti esistenti o eliminarli del tutto grazie ad una apposita pagina dedita
solamente a queste genere operazioni.

 Per ogni nuovo inserimento di dati all’interno del data base, ci sono dei campi in cui non sono
concessi valori di tipo NULL per garantire l’integrità della base di dati. Sono quindi stati
implementati dei vincoli per l’immissione di tali dati.

 Nel caso in cui si effettui una ricerca per visualizzare la lista di tutti gli utenti, progetti o
pubblicazioni inseriti all’interno del data base, come risultato si otterrà una lista che contiene al suo
interno solo le informazioni necessarie ad identificare precisamente il soggetto interessato da parte
dell’utente. Da questa lista poi sarà possibile il reindirizzamento alla specifica risorsa voluta.

 E’ concesso l’inserimento di più utenti con lo stesso nome e cognome a patto che il loro ruolo sia
diverso fra loro. Il controllo di sicurezza che non permette l’inserimento di utenti doppioni viene
infatti eseguito sui campi di Nome, Cognome e Ruolo contemporaneamente.

 Seppur questo sia un fattore molto importante, non viene considerato e rispettato l’ordine degli
autori di una pubblicazione in quanto si ritiene che esso sia ben stabilito e dichiarato nel file della
pubblicazione stessa di cui si fornisce il link alla risorsa. La lista degli autori considerata nel data
base ha uno scopo puramente informativo. La stessa cosa vale per i collaboratori di un progetto.

35
 5.10. Stored procedure

Per quanto riguarda la progettazione delle funzionalità, della gestione e della comunicazioni fra interfaccia
e data base, due erano le possibili strade percorribili: l’uso di stored procedure o l’uso di singole query.
In questo caso per le interrogazioni, l’inserimento, la cancellazione di dati e più in generale per tutte le
varie operazioni possibili sul data base, si è scelto l’utilizzo delle sole stored procedure.
Queste, si possono considerare come dei moduli o delle routine che incapsulano del codice che viene
eseguito quando la stessa stored procedure che lo contiene, viene richiamata o avviata dall’applicativo.
L’uso di questo particolare tipo di approccio ha permesso di ottenere i seguenti vantaggi:

 Un notevole aumento della sicurezza all’interno dello stesso applicativo in quanto non risulta così
possibile scrivere manualmente e richiamare delle singole query direttamente dall’interfaccia web.
Questo permette infatti di prevenire attacchi che mirano all'esecuzione di istruzioni SQL dannose.
Le applicazioni risultano infatti vulnerabili a questo tipo di attacchi quando chiedono all'utente
informazioni che vengono poi concatenate in una stringa che costituisce l'istruzione SQL; cosa che
spesso avviene nell’applicativo. Un utente malintenzionato che dispone di qualche informazione sul
database potrebbe infatti immettere nella casella di testo un'istruzione SQL incorporata insieme al
contenuto originale della casella di testo, affinché venga composta ed eseguita un'istruzione che
potrebbe compromettere l’intero data base.

 Usando delle stored procedure che contengono al loro interno già del codice e delle routine, si
diminuisce il numero di informazioni scambiate fra client e server a tutto vantaggio delle
prestazioni. In questo caso infatti si richiama la stored procedure desiderata passandogli solamente
i parametri richiesti ottenendo come risultato anche valori calcolati oltre a quelli direttamente
richiesti.

 Questo tipo di approccio rende significativamente più facile la gestione da parte dell’applicazione
dei privilegi e delle relative azioni a disposizione per i vari tipi di utenti. Nel caso infatti di un utente
con credenziali, verranno richiamate delle particolari stored procedure, mentre nel caso in cui
l’utente sia solo un utente esterno, ne verranno richiamate delle altre in cui magari sono esclusi dei
dati o eliminare alcune possibili operazioni.

La scelta del nome dato alle varie stored procedure non è affatto casuale e spesso riuscire a comprendere
la struttura del loro nome, può aiutare a capire già al primo colpo d’occhio a che cosa essa serva. Questo è
un tipo di approccio pratico costruttivo molto importante nel caso in cui siano molte le stored procedure o
le query da creare proprio per evitare confusione quando il loro numero comincia ad essere importante.
Come prima parte del nome, compare il titolo del data base sul quale esse vanno ad agire che in questo
caso risulta essere per l’appunto GeoSNaV. Successivamente viene scritto il nome dell’entità principale su
cui essa va ad agire (ad esempio Progetto o Utente). In seguito viene scritto il tipo di azione che essa svolge
(ad esempio Select, Delete o Insert) e per ultimo l’attributo o il nome dell’entità stessa su cui viene
apportata quella modifica e opzionalmente la modalità con cui essa viene apportata (ad esempio se
attraverso l’ID o il Titolo).

36
 5.10.1. Esempio: geosnav_Utente_SelectTuttiUtenti

Questa stored procedure permette all’applicativo di visualizzare la lista di tutti gli utenti presenti all’interno
del data base. Non si necessita di nessun parametro in ingresso infatti essa viene solo richiamata e come
risultato fornisce la lista di tutti gli utenti in ordine alfabetico, ordinata prima per cognome e
successivamente per nome. La lista restituita contiene attributi quali l’ID_Utente utile per la successiva
identificazione del singolo utente, il nome e il cognome dell’utente, il ruolo che esso ricopre e attraverso
una operazione di JOIN viene richiamato anche l’attributo Città della tabella tblContatti sempre attraverso
l’ID_Utente dell’interessato.

ALTER PROCEDURE [dbo].[geosnav_Utente_SelectTuttiUtenti]

AS
SET NOCOUNT ON;

SELECT tblUtenti.ID_Utente, tblUtenti.Nome, tblUtenti.Cognome, tblUtenti.Ruolo,

tblContatti.Città
FROM tblUtenti LEFT OUTER JOIN
tblContatti ON tblUtenti.ID_Utente = tblContatti.ID_Utente
ORDER BY tblUtenti.Cognome, tblUtenti.Nome
RETURN

37
 5.10.2. Esempio: geosnav_Utente_DeleteUtenteTotale

Questa stored procedure viene chiamata dall’applicativo quando ad esempio l’amministratore desideri
eliminare dalla base di dati un particolare utente con tutti i suoi collegamenti a progetti o pubblicazioni
fatte, operazione eseguita mediante il comando DELETE del linguaggio SQL. L’unico parametro che viene
fornito in input alla stored procedure è appunto l’ID_Utente della persona specifica che si vuole andare a
cancellare. Logicamente, l’applicativo risale dal Nome e Cognome all’ID_Utente e lo fornisce come dato alla
stored procedure. Una volta ottenuto questo dato comincia una routine che elimina dalle tabelle ogni
riferimento all’ID_Utente in questione, successivamente provvede a svuotare i campi attributo come
“Progetto_Inserito_Da”, “Pubblicazione_Inserita_Da” , “ID_Utente” delle tabelle tblPubblicazione,
tblProgetto, tblMod_Progetto e tblMod_Pubblicazione inserendovi all’interno un valore NULL ed in fine,
cancella l’ultimo riferimento ID_Utente nella tblUtenti. L’eliminazione dell’utente dalla tblUtenti è l’ultima
delle operazioni fatte in quanto se essa venisse effettuata prima di tutte le altre, alla successiva operazione
si solleverebbe un’eccezione di conflitto referenziale sulla chiave primaria ID_Utente in quanto il suo
riferimento non esisterebbe ormai più all’interno della base di dati ma tutto il resto dei dati del record si.

ALTER PROCEDURE [dbo].[geosnav_Utente_DeleteUtenteTotale]

(
@ID_Utente int
)
AS
BEGIN
SET NOCOUNT ON;

DELETE
FROM tblContatti
WHERE (ID_Utente = @ID_Utente);
DELETE
FROM tblContatti_Mail
WHERE (ID_Utente = @ID_Utente);
DELETE
FROM tblContatti_Telefonici
WHERE (ID_Utente = @ID_Utente);
DELETE
FROM tblCurriculum
WHERE (ID_Utente = @ID_Utente)
DELETE
FROM tblCredenziali
WHERE (ID_Utente = @ID_Utente)
DELETE
FROM tblAutore_Pubblicazione
WHERE (ID_Utente = @ID_Utente)
DELETE
FROM tblCollaboratore_Progetto
WHERE (ID_Utente = @ID_Utente)
UPDATE tblProgetto
SET Progetto_Inserito_Da = NULL
WHERE Progetto_Inserito_Da = @ID_Utente
UPDATE tblPubblicazione
SET Pubblicazione_Inserita_Da = NULL
WHERE Pubblicazione_Inserita_Da = @ID_Utente
UPDATE tblMod_Progetto
SET ID_Utente = NULL
WHERE ID_Utente = @ID_Utente
UPDATE tblMod_Pubblicazione
SET ID_Utente = NULL
WHERE ID_Utente = @ID_Utente
DELETE
FROM tblUtenti
WHERE (ID_Utente = @ID_Utente)

END

38
 5.10.3. Esempio: geosnav_Progetto_InsertProgetto

Questa stored procedure viene chiamata dall’applicativo nel caso in cui un utente con credenziali desisderi
inserire un nuovo progetto all’interno della base di dati. In questo caso alla stored procedure vengono
passati in input numerosi parametri che altro non sono che delle variabili attributo identificate da una @
prima del nome della variabile stessa.
L’applicativo legge i dati scritti dall’utente in fase di creazione del nuovo progetto, li memorizza nelle
variabili secondo dei criteri di integrità del dato ben precisi e passa tutte queste informazioni alla sorted
procedure nel caso in cui tutti questi vincoli siano stati rispettati. Caso particolare da considerare è
l’inserimento del dato nell’attributo Data_Inserimento_Progetto dove l’informazione necessaria viene
automaticamente generata dal motore del data base ed inserita tramite la funzione GETDATE() definita fra
le funzioni standard di MS SQL.

ALTER PROCEDURE [dbo].[geosnav_Progetto_InsertProgetto]

(
@ID_Utente int,
@Titolo_Progetto nchar(50),
@Anno_Progetto smallint,
@Stato smallint,
@Descrizione_Progetto varchar(1000),
@Note varchar(200)
)
AS
BEGIN
SET NOCOUNT ON;

INSERT INTO tblProgetto(Titolo_Progetto, Anno_Progetto, Stato, Descrizione_Progetto,

Note, Progetto_Inserito_Da, Data_Inserimento_Progetto)
VALUES (@Titolo_Progetto, @Anno_Progetto, @Stato, @Descrizione_Progetto, @Note,
@ID_Utente, GETDATE())
END

39
 5.10.4. Esempio: geosnav_Pubblicazione_UpdatePubblicazione
geosnav_Pubblicazione_InsertMod_Pubblicazione

L’operazione di modifica di un progetto già esistente coinvolge due stored procedure differenti ma che
vengono sempre richiamate in coppia a causa delle funzionalità richieste per il sistema:
geosnav_Pubblicazione_UpdatePubblicazione e geosnav_Pubblicazione_InsertMod_Pubblicazione.

Nella prima stored procedure (geosnav_Pubblicazione_UpdatePubblicazione) si fa uso del comando

UPDATE che consente di aggiornare dei valori già esistenti di un record sovrascrivendoli con quelli nuovi
passati tramite l’ausilio della variabili interne.

ALTER PROCEDURE [dbo].[geosnav_Pubblicazione_UpdatePubblicazione]

(
@ID_Pubblicazione int,
@Titolo_Pubblicazione nchar(50),
@Anno_Pubblicazione smallint,
@Descrizione_Pubblicazione varchar(1000),
@URL_o_Link nvarchar(200)
)
AS
BEGIN
SET NOCOUNT ON;

UPDATE tblPubblicazione
SET Titolo_Pubblicazione = @Titolo_Pubblicazione, Anno_Pubblicazione =
@Anno_Pubblicazione, Descrizione_Pubblicazione = @Descrizione_Pubblicazione,
URL_o_Link = @URL_o_Link
WHERE ID_Pubblicazione = @ID_Pubblicazione
END

Nella seconda stored procedure (geosnav_Pubblicazione_InsertMod_Pubblicazione) invece il sistema

provvede ad inserire le informazioni della tabella relative alle modifiche apportate ad una pubblicazione in
modo da rispettare l’integrità delle informazioni mantenute all’interno della base di dati. In questa si fa uso
del comando INSERT in quando vado a creare un nuovo record e non a modificarne uno già esistente come
nell’operazione precedente a questa in cui procedevo con l’uso del comando UPDATE.

ALTER PROCEDURE [dbo].[geosnav_Pubblicazione_InsertModPubblicazione]

(
@ID_Pubblicazione int,
@ID_Utente int,
@Mod_Pubblicazione_Titolo bit,
@Mod_Pubblicazione_Anno bit,
@Mod_Pubblicazione_Descrizione bit,
@Mod_Pubblicazione_URL bit
)
AS
BEGIN
SET NOCOUNT ON;

INSERT INTO tblMod_Pubblicazione (ID_Pubblicazione, ID_Utente, Data_Mod_Pubblicazione,

Mod_Pubblicazione_Titolo, Mod_Pubblicazione_Anno,
Mod_Pubblicazione_Descrizione, Mod_Pubblicazione_URL)
VALUES (@ID_Pubblicazione, @ID_Utente, GETDATE(), @Mod_Pubblicazione_Titolo,
@Mod_Pubblicazione_Anno, @Mod_Pubblicazione_Descrizione,
@Mod_Pubblicazione_URL)
END

40
 5.10.5. Esempio: geosnav_Pubblicazione_SelectLikePubblicazione

La stored procedure geosnav_Pubblicazione_selectLikePubblicazione si occupa della gestione delle ricerche

di pubblicazioni mediante l’inserimento del nome dell’articolo. Questa infatti, grazie al comando LIKE del
linguaggio SQL, cerca la stringa di tipo nvarchar passata in input dall’utente nell’attributo
Titolo_Pubblicazione. Il particolare modo con cui viene passato questo parametro stringa inserito
dall’utente (‘%’+Titolo_Pubb+’%’) sta ad indicare che quella particolare stringa viene cercata in qualsiasi
posizione all’interno dell’attributo Titolo_Pubblicazione. Nel caso in cui ad esempio si passi il solo carattere
‘a’ come parametro alla stored procedure, essa provvederà a dare come risultato la lista di tutti i progetti
che all’interno del loro nome contengono almeno una volta il carattere ‘a’.

ALTER PROCEDURE [dbo].[geosnav_Pubblicazione_SelectLikePubblicazione]

(
@Titolo_Pubb nvarchar
)
AS
BEGIN
SET NOCOUNT ON;

SELECT Titolo_Pubblicazione, Anno_Pubblicazione

FROM tblPubblicazione
WHERE Titolo_Pubblicazione LIKE '%'+@Titolo_Pubb+'%'
END

5.10.6. Esempio: geosnav_Progetto_CountProgetti

Questa stored procedure ha come solo scopo quello di effettuare il conteggio del numero dei record inseriti
all’interno della tabella tblProgetto. Questa operazione viene effettuata grazie alla presenza del comando
COUNT al quale viene passato come parametro l’attributo sul quale andare ad effettuare il proprio
conteggio e ovviamente la tabella in cui andarlo ad effettuare tramite il comando FROM. La scelta più logica
dell’attributo sul quale effettuare questo conteggio è stata quella di optare direttamente per l’ID_Progetto
in quanto rappresenta una delle variabili a cui sicuramente non potranno essere associati dei valori NULL e
che propriamente identificano univocamente ogni singolo progetto.

ALTER PROCEDURE [dbo].[geosnav_Progetto_CountProgetti]

AS
SET NOCOUNT ON;

SELECT COUNT (ID_Progetto)

FROM tblProgetto
RETURN

La stessa stored procedure è stata implementata anche per il conteggio delle pubblicazioni e degli utenti
inseriti all’interno del sistema con ovviamente le opportune modifiche sul tipo di attributo da conteggiare e
la tabella in cui effettuare questo conteggio.

41
 5.10.7. Esempio: geosnav_Utente_SelectUtenteNomeCognome

Questa particolare stored procedure si occupa delle ricerche di un utente all’interno del data base nel caso
in cui questa ricerca venga effettuata mediante l’inserimento di un nome o cognome nell’apposita text box
messa a disposizione sul sito per l’utente. La scelta di non permettere la ricerca per nome e cognome
contemporaneamente deriva da una motivazione di tipo tecnico in quanto risulta molto difficile effettuare
una simile ricerca combinata su due attributi differenti. Gestire invece una ricerca di un solo attributo come
nome o cognome su entrambi i campi all’interno della tabella risulta essere di facile gestione grazie all’uso
di due comandi LIKE correlati fra loro dall’operatore logico OR. Questo particolare problema deriva dal fatto
che per la realizzazione di questo progetto si è cercato di osservare sempre le regole di normalizzazione
della base di dati che non permettono ad esempio la creazione di un campo unico per gli attributi di nome e
cognome. La creazione di un simile campo avrebbe permesso la ricerca combinata per nome e cognome
contemporaneamente.

ALTER PROCEDURE [dbo].[geosnav_Utente_SelectUtenteNomeCognome]

(
@String nchar(20)
)
AS
SET NOCOUNT ON;

SELECT tblUtenti.ID_Utente, tblUtenti.Nome, tblUtenti.Cognome, tblUtenti.Ruolo,

tblContatti.Città
FROM tblUtenti LEFT OUTER JOIN
tblContatti ON tblUtenti.ID_Utente = tblContatti.ID_Utente
WHERE Nome LIKE '%'+@String+'%' OR
Cognome LIKE '%'+@String+'%'
RETURN

42
 5.11. Interfaccia

Lo sviluppo dell’interfaccia utente spesso risulta uno dei passaggi più complessi per lo sviluppo di tali
applicazioni in quanto non esiste una particolare strategia di approccio al problema e costringe il
programmatore a dover prestare particolare attenzione alla disposizione delle componenti, alla struttura
dei workflow delle operazioni e alla logica di interazione fra la varie componenti dell’interfaccia. Per
l’applicazione in questione si è cercato di ottenere la massima praticità e semplicità d’uso in modo da
rendere il passaggio a questo sistema il meno traumatico possibile per l’utente che spesso ne dovrà far uso.

L’interfaccia utente dell’applicazione si divide principalmente in due componenti: la parte chiamata

Interfaccia Utente Base è quella che qualsiasi utente e visitatore del sito può visualizzare e da cui sono
possibili effettuare tutte le interrogazioni alla base di dati in lettura, mentre le seconda parte, chiamata
Interfaccia Di Gestione, è quella a cui possono accedere solo gli utenti autorizzati dopo aver effettuato
l’autenticazione. Da quest’ultima infatti è possibile gestire i dati all’interno del data base e quindi
manipolare le informazioni all’interno memorizzate.

Interfaccia Utente

Interfaccia Utente
Interfaccia Di Gestione
Base

Lettura Dati Lettura Dati Modifica Dati

Data Base

Un’altra particolarità importante che differenzia le due interfacce è il fatto che quella Di Gestione sia stata
progettata in lingua italiana, mentre quella di Utente Base è stata realizzata in lingua inglese visto che essa
sarà utilizzabile da qualsiasi tipo di utente che lo riterrà necessario e non solo da utenti interni di
nazionalità italiana come per l’altro caso.

43
 5.11.1. Struttura logica dell’Interfaccia Utente Base

Come detto in precedenza, l’Interfaccia Utente Base è quella particolare parte dell’applicativo che verrà
messa a disposizione di ogni utente visitatore sul sito nella pagina chiamata “Find Information”. Questa
interfaccia permette all’utilizzatore di effettuare le sue ricerche all’interno della base di dati senza però
fornirgli la possibilità di modificare i dati in esso contenuti. Oltre alla possibilità di poter effettuare le sue
ricerca su utenti, progetti e pubblicazioni, verrà messa a disposizione dell’utente la possibilità di effettuare
la propria ricerca sul motore Google nel caso in cui i risultati della sua precedente ricerca all’interno del
data base, non abbiano fornito i risultati sperati.
Di seguito è riportata la struttura logica dell’Interfaccia Utente Base tradotta in italiano per praticità:

Interfaccia
Utente Base

Utenti Progetti Pubblicazioni Google

Seleziona Seleziona Seleziona

Utente Progetto Pubblicazione

Visualizza Tutti Visualizza Tutti Visualizza Tutte

44
 5.11.2. Interfaccia Di Gestione

L’Interfaccia Di Gestione è quella particolare parte dell’applicazione messa a disposizione dell’utente

registrato, una volta che si abbia effettuato l’autenticazione. Questa particolare interfaccia infatti è lo
strumento di gestione attraverso il quale il coordinatore o un suo collaboratore stretto, possono agire,
modificare e cancellare i dati presenti all’interno della base di dati. L’interfaccia oltre a riproporre tutte le
possibili opzioni concesse nell’Interfaccia Utente Base, aggiunge anche quelle di gestione della base di dati
nella forma più comoda e pratica possibile.
Di seguito è riportata la struttura logica dell’Interfaccia Di Gestione:

Interfaccia Di
Gestione

Profilo
Utenti Progetti Pubblicazioni Collegamenti Google
Personale

Visualizza
Seleziona Seleziona Seleziona Crea
Profilo
Utente Progetto Pubblicazione Collegamento
Personale

Modifica Profilo Modifica

Visualizza Tutti Visualizza Tutti Visualizza Tutti
Personale Collegamento

Crea Nuovo Crea Nuovo Crea Nuova Elimina

Utente Progetto Pubblicazione Collegamento

Modifica Dati Modifica Dati Modifica Dati

Utente Progetto Pubblicazione

Elimina Elimina
Cancella Utente
Progetto Pubblicazione

45
 5.11.3. Esempio di interfaccia: Interfaccia Utente Base

In questo esempio di interfaccia, all’utente o al semplice visitatore viene data la possibilità di cercare nel
data base tutti i tipi di informazioni messi a disposizioni per la ricerca. L’interfaccia frammenta e raggruppa
queste possibilità di ricerca per concetti (Project, Articles e Users) e mette inoltre a disposizione dell’utente
la possibilità di poter effettuare le proprie ricerche sul motore di ricerca Google. Per ogni concetto di
ricerca viene data la possibilità di scegliere se visualizzare la lista completa di tutti i record inseriti fino a
quel momento nella base di dati o di provare ad effettuare una ricerca mirata ad esempio per nome del
progetto nel caso in cui si sia già a conoscenza di tale informazione. Viene data infatti la possibilità
all’utente di inserire una stringa di testo che successivamente, in fase di invio richiesta, viene trasformata in
una variabile di tipo nvarchar ed analizzata dalla stored procedure geosnav_Progetto_selectLikeProgetto
che grazie al comando LIKE provvederà a restituire come risultato della query la lista di tutti i progetti che
contengono quel pezzo di stringa all’interno del loro attributo Titolo_Progetto.

46
 5.11.4. Esempio di interfaccia: Visualizza profilo utente

L’interfaccia appena mostrata fornisce un’idea di come dovrebbe apparire la visualizzazione del profilo di
un utente inserito all’interno del sistema. Inizialmente vengono mostrare in una tabella solo le informazioni
base dell’utente come il nome, cognome, ruolo titolo conseguito, luogo di conseguimento e anno di
conseguimento. Successivamente, grazie all’ausilio dei tasti navigazionali messi a disposizione in basso, è
possibile espandere queste informazioni visualizzando, sempre in altre tabelle che compariranno una sotto
all’altra, prima i contatti, poi la lista delle pubblicazioni e per ultima quella dei progetti che si legano
all’utente in questione. Nel caso in cui l’utente di cui si cerca di visualizzare il profilo, sia un utente di tipo
esterno, allora verranno mostrati in tabella solo i suoi dati disponibili e quindi il solo nome e cognome.

5.11.5. Esempio di interfaccia: Visualizza tutti i progetti

Quest’interfaccia mostra il risultato di una possibile ricerca effettuata da un utente che voglia visualizzare la
lista di tutti i progetti inseriti all’interno del data base. I risultati ottenuti dalla stored procedure vengono
divisi dall’applicativo in base all’anno e visualizzati così separati in semplici tabelle. Le tabelle contengono il
nome del progetto e il suo relativo stato. Il nome del progetto risulta cliccabile, azione che porta ad un’altra
47
interfaccia per permette la lettura di tutti i dati del solo progetto specifico scelto. Questo particolare tipo di
reidirizzamento ai dati del progetto specifico è reso disponibile grazie al fatto che oltre al suo titolo, viene
richiamato dalla stored procedure anche il suo ID_Progetto; ed è infatti questo che poi viene inviato come
parametro alla stored procedure geosnav_Progetto_SelectProgetto_ID che provvede a caricare e inviare
all’applicativo tutte le informazioni relativa al progetto in questione che presenta quel particolare
ID_Progetto.

5.11.6. Esempio di interfaccia: Visualizza singolo progetto

Questa interfaccia è dedita alla visualizzazione dei dati relativi ad un solo progetto. Anche in questo caso il
nome dei collaboratori e il titolo della pubblicazioni correlate è cliccabile, azione che porta ad una pagina
che visualizza tutti i dati relativi al soggetto interessato e di cui si è desiderato visualizzare le informazioni.

48
 5.11.7. Esempio di interfaccia: Autenticazione

Come espresso inizialmente nei requisiti del sistema, per accedere alla parte riservata dell’applicativo, si
deve effettuare una procedura di autenticazione mediante l’utilizzo di un username e password. Il form che
permette l’accesso al sistema è presente nella pagina “Management” del sito e risulta di facile e immediata
comprensione. Della coppia username/password inserita dall’utente registrato per l’autenticazione, viene
verificata la corrispondenza nella tabella tblCredenziali andando a richiamare la stored procedure
geosnav_Utente_SelectUtente_DaCredenziali che nel caso di verifica confermata, restituisce
all’applicazione l’ID_Utente mediante il quale si andrà poi a generare la sessione autenticata. La sessione
rimane in vita fino a quando la pagina web non viene chiusa.

5.11.8. Esempio di interfaccia: Interfaccia Di Gestione

Questa è l’interfaccia che compare subito dopo la conferma di avvenuta autenticazione. Essa si differenza
dall’Interfaccia Utente Base solamente per il fatto che al suo interno sono rese disponibili le opzioni di
inserimento di un nuovo progetto, pubblicazione o utente e di modifica dei collegamenti fra queste entità.
Nel caso si desideri inserire un nuovo record del tipo scelto all’interno della base di dati, l’utente viene
reindirizzato ad una pagina in cui è contenuta la form per l’inserimento di tutti i dati necessari.

49
 5.11.9. Esempio di interfaccia: Modifica/Inserimento profilo utente

Con questa interfaccia viene data la possibilità ad un utente autenticato di inserire il profilo di un nuovo
utente all’interno della base di dati o di modificarne uno già esistente. Una volta inseriti tutti i dati richiesti,
o almeno quelli strettamente necessari e contrassegnati dal simbolo “*”, si può procedere con il suo
inserimento nel data base richiamando tutte le stored procedure che riguardano l’inserimento di un nuovo
utente e riconoscibili grazie alla presenza del parametro INSERT all’interno del loro nome. Se l’utente che ci
si appresta ad inserire è ad esempio di tipo collaboratore interno e non collaboratore stretto, allora
qualsiasi stringa di caratteri inseriti nei campi di Username e Password non verrà considerata. La stessa
cosa vale anche nel caso in cui ci si appresti ad inserire un utente esterno; ogni dato inserito oltre al solo
nome, cognome e ruolo, non verranno considerati e quindi scartati automaticamente dal sistema. Nel caso
in cui invece si avesse in precedenza scelto di modificare un profilo già esistente, allora all’interno delle text
box verrebbero caricati automaticamente tutti i dati già presenti all’interno della base di dati riguardanti
quel particolare utente in modo da permetterne la corretta modifica. Nell’ulteriore caso in cui si cerchi di
inserire un utente che è stato già inserito in precedenza, al momento dell’invio delle informazioni
comparirà una finestra con un avviso di errore e che specificherà che quel utente risulta già presente
all’interno della base di dati.

50
 5.11.10. Esempio di interfaccia: Gestione dei collegamenti

L’interfaccia gestione dei collegamenti permette all’utente autenticato di creare o eliminare i collegamenti
di relazione che esistono fra le diverse entità già inserite all’interno della base di dati. Per questo tipo di
operazioni si è scelto di far uso delle sole Drop Down List in modo da permettere all’utente di poter
effettuare delle scelte sicuramente corrette per quanto riguarda le combinazioni fra progetti, pubblicazioni
o utenti da collegare o scollegare fra loro. Tramite dei controlli di integrità dei dati non sarà possibile creare
due collegamenti di tipo uguale sulle stesse entità e nel caso in cui per sbaglio si desideri scollegare entità
non collegate fra loro, l’operazione non fornirà nessun avviso di errore ma darà all’utente l’impressione che
essa sia stata svolta normalmente.

51
 5.11.11. Esempio di interfaccia: Visualizza singolo progetto lato gestione

Come preannunciato dal titolo, questa interfaccia si preoccupa di mostrare tutte le informazioni di un
progetto da parte di un utente autenticatosi come coordinatore del progetto o suo collaboratore stretto. Le
informazioni visualizzate in questo caso sono maggiori rispetto a quelle che può visualizzare un semplice
utente non autenticato in quanto le informazioni aggiuntive che qui si vanno visualizzare, sono solamente
utili alla gestione interna e alla manutenzione della base di dati da parte di chi ne ha ovviamente i privilegi.

52
 5.12. Il Sito Web

Il sito web risulta essere di tipo informativo / data base e la lingua usata per la sua realizzazione è l’inglese
in quanto esso si propone di fornire informazioni scientifiche ad un panorama di utenze prevalentemente
europeo. La semplice struttura realizzata per il sito è la seguente:

Home Page

Research & How To Find

People Contact Us Management
Activities Reach Us Information

Interfaccia Interfaccia Di
Utente Base Gestione

Descrizione delle pagine del sito:

 Home Page: contiene le informazioni più importanti e la presentazione del progetto GeoSNaV.
 People: contiene la lista key staff e quindi del personale principale del progetto.
 Research & Activities: fornisce le informazioni relative alle attività di ricerca in corso.
 Contact Us: visualizza le informazioni base ed i contatti del coordinatore del progetto.
 How To Reach Us: fornisce informazioni utili su come raggiungere il dipartimento dell’università.
 Find Information: è la pagina base dell’applicativo per la comunicazione libera con il data base.
 Management: pagina dove gli utenti con credenziali potranno accedere alla zona riservata del sito.

53
( Home Page del sito )

54
 5.12.1. Analisi e valutazione del sito web

Sono di vario tipo le valutazioni che si posso fare su un sito web. Di seguito verranno analizzate alcune
caratteristiche fondamentali e qualità che esso deve avere:

 Valutazione architetturale: come richiesto dalle specifiche, la struttura del sito risulta essere molto
semplice e funzionale. Partendo dall’alto si può osservare l’immagine di intestazione contenente il
titolo del progetto ed il logo dell’Università di Trieste, il menù navigazionale orizzontale che
permette di raggiungere rapidamente tutte le pagine del sito, il contenuto vero e proprio della
pagina web e le classiche intestazioni in basso di chiusura pagina e relative al realizzatore del sito
web e dei copyright.

 Valutazione della comunicazione: la grafica ed il layout delle pagine è concepito in modo tale da
facilitare al visitatore la comprensione immediata dei concetti raggruppando le informazioni
correlate ed evidenziando quelle più importanti. Per quanto riguarda il colore, se utilizzato bene,
può essere di grande aiuto alla comprensione di un sito mentre nel caso in cui sia utilizzato male
può anche creare serie difficoltà. La scelta fatta è stata quella di utilizzare pochi colori per evitare
pagine eccessivamente variopinte e fastidiose. Per quanto riguarda lo sfondo si è utilizzato il
classico sfondo bianco con l’inserimento però a scacchiera del logo dell’Università degli Studi di
Trieste semi trasparente che in questi casi risulta essere la soluzione meno aggressiva essendo a
valenza neutra e rende i testi perfettamente leggibili. Il tipo di carattere utilizzato è il Tahoma
cercando di evitare il stile corsivo o “tutto maiuscolo” che può dare l’impressione di un tono
“urlato” derivante dall’uso che se ne fa abitualmente nella posta elettronica.

 Valutazione della funzionalità: il metodo di ricerca delle informazioni all’interno del sito è fornito
dalla pagina Find Information dov’è situato l’applicativo per la comunicazione con il data base.
Nella pagina è anche data la possibilità di effettuare le proprie ricerche direttamente dal sito sul
classico motore di ricerca Google.

 Valutazione del contenuto: L’obiettivo in questa fase di analisi è quello di valutare la qualità dei
contenuti informativi veri e propri del sito, e soprattutto la loro adeguatezza agli obiettivi che esso
si propone di conseguire. I titoli sono abbastanza visibili ed evidenziati in grassetto in modo
sufficiente da attirare da subito l’attenzione dell’utente. Il contenuto delle pagine è inoltre
stringato ed essenziale; si presta quindi bene a una sua facile lettura e comprensione.

 Valutazione sull’accessibilità: è questa una delle componenti fondamentali in quanto si riferisce al

più importante dei principi che riguardano Internet ossia quello dell’universalità dell’accesso al
web. Le principali barriere che possono ostacolare l’accesso al sito web sono: lunghi tempi di
accesso al sito, l’incompatibilità fra le diverse tecnologie che permettono di accedere ad Internet e
la difficoltà di trovarlo. Per evitare che il tempo di scaricamento della pagina superi una certa soglia
psicologica oltre il quale l’utente rinunci ad aspettare e si diriga verso un altro sito, ogni immagine
al suo interno presente è stata compressa i modo da non appesantire la pagina. Lo stesso vale per
le gallerie di immagini per le quali vengono caricate solo delle piccole anteprime per ogni
immagine. Attenzione poi è stata prestata al fatto che il sito risultasse accessibile con ogni browser
in quanto se non progettato con attenzione, può presentarsi in modo diverso se visualizzata con
browser differenti o con sistemi operativi diversi.

55
  Valutazione di usabilità: In sostanza un sito è usabile quando l’utente riesce a fare ciò che vuole
senza dover pensare consapevolmente a come farlo infatti esso interagisce con il sito attraverso la
tastiera, il mouse e il monitor del proprio computer, ma soprattutto con la sua mente che analizza
le indicazioni esplicite che gli arrivano dal sito. E’ quindi stata prestata particolare attenzione al
fatto che gli indizi siano sufficienti e ben disposti all’interno di ogni pagina in modo da farlo risultare
il più usabile possibile.

5.12.2. JavaScript

Il JavaScript è uno fra i linguaggi di programmazione orientato ad oggetti più comunemente sfruttato negli
odierni siti web data la sua facilità di implementazione su pagine già preesistenti e le vastissime possibilità
applicative che esso offre.
L’utilizzo in alcune pagine del sito di questa tecnologia è stata adottata per delle questioni sia pratiche che
estetiche. Si è infatti fatto uso di un JavaScript freeware trovato su internet e chiamato “Lightbox v 2.04”.
Esso si preoccupa della gestione e visualizzazione delle gallerie di immagini in modo da alleggerirne
dapprima il caricamento iniziale della pagina stessa e successivamente rendere però anche più gradevole la
visualizzazione di tali immagini.

Il JavaScript Lightbox ingrandisce e permette di sfogliare le immagini di una galleria della pagina web,
ponendole al centro dello schermo, oscurandone lo sfondo e applicando sotto ad ogni immagine una
spiegazione testuale opzionale andando così a creare una galleria grafica dinamica che si lascia visitare con i
tasti freccia (destra o sinistra) della tastiera o direttamente con il mouse cliccando su apposite voci a
scomparsa e inserite all’interno del contesto di visualizzazione. Il tasto Esc o il semplice click del mouse al di
fuori del campo dell’immagine visualizzata chiude il JavaScript riportando il visitatore alla pagina
precedentemente visualizzata.

Questo JavaScript si compone di vari tipi di file da inserire all’interno della cartella in cui il sito viene creato:

 Per prima cosa all’interno della cartella “images” vengono inserite le immagini che andranno a
comporre la gallery e assieme a queste, anche tutte le varie immagini che verranno utilizzate dal
JavaScript per andare a creare il contesto di visualizzazione della gallery; quindi frecce, tasto di
chiusura e immagini di caricamento.

 Si deve poi provvedere a copiare un file di tipo stile CSS chiamato “lightbox” al cui interno sono
contenute tutte le informazioni di stile grafico e colore che verranno adottate dal JavaScript
utilizzato. Modificando manualmente e sapientemente questi parametri all’interno del file CSS si
può andare a variare l’aspetto grafico e quindi il risultato finale della galleria dinamica.

 Il passo successivo sarà quello di copiare i veri e propri file del JavaScript all’interno della cartella in
cui il sito è stato creato e caricato. Il file builder.js è quello che va a costruire la struttura della
gallery gestendo parametri quali la risoluzione del monitor utilizzata, il tipo di carattere impostato
ed i parametri sui colori da utilizzare passati tramite il file CSS. Il file effects.js è quello più
macchinoso e complesso a livello di codice e va a dar vita alle animazioni presenti all’interno della
gallery dinamica. Il file lightbox.js contiene il codice che si preoccupa di gestire la lista degli eventi e
di collegare fra loro tutti gli altri file rappresentando quindi una sorta di struttura scheletro dello
script. Il file prototype.js si preoccupa della gestione e manipolazione del JavaScript in base al tipo
di browser con cui lo si va a visualizzare. Il file scriptaculos.js si preoccupa invece di fornire
informazioni sulla versione del JavaScript anche in base al tipo di browser visualizzato.

56
 Ultimo passo risulta essere quello di inserire e posizionare all’interno della pagina interessata il
codice di caricamento dello script. Fra i tags <head> e </head> si provvederà ad inserire il seguente
codice:

<script type="text/javascript" src="js/prototype.js"></script>

<script type="text/javascript" src="js/scriptaculous.js?load=effects,builder"></script>
<script type="text/javascript" src="js/lightbox.js"></script>
<link rel="stylesheet" href="css/lightbox.css" type="text/css" media="screen">

Per rendere poi effettivo questo script alle immagini desiderate, esse dovranno essere inserite
all’interno del codice mediante la seguente modalità che non fa altro che applicare lo script
lightbox all’immagine voluta:

<a href="nome_immagine.jpg" rel="lightbox[nome_gallery]" title="titolo opzionale">immagine #1</a>

57
6. Conclusioni

Al termine di tutto il lavoro svolto fino a questo punto, si può affermare che l’obbiettivo inizialmente
prefissato, sia stato raggiunto. Lo sviluppo fisico del sito web, quello del data base e la progettazione
teorica della relativa applicazione per la sua gestione attraverso interfaccia web, è stato portato a termine
con successo. Ora il Dipartimento di Ingegneria Civile ed Ambientale dell’Università degli Studi di Trieste ha
a sua disposizione un sito web per la presentazione di uno dei suoi progetti con la possibilità di
implementare in futuro un data base e la relativa interfaccia web per la gestione dinamica di informazioni e
articoli a carattere scientifico.
Tutti gli obbiettivi intermedi a parte l’ultimo sono stati raggiunti e quindi si è:

• Realizzato il data base attraverso lo studio della lista dei requisiti raccolti
• Verificato il rispetto di tali requisiti in base alle funzionalità di gestione implementate sul data base
• Sviluppato l'interfaccia utente in base alle funzionalità richieste
• Sviluppato il sito web di presentazione del progetto
• Testing del sito web

Unico obbiettivo intermedio non ancora raggiunto è quello relativo all’installazione del sito sul server del
DICA e della sua pubblicazione sul web. L’obbiettivo non è stato ancora raggiunto però solo per una
questione relativa alle tempistiche visto lo scarso tempo a mia disposizione per lo sviluppo e il
completamento di tutti gli obbiettivi in concomitanza del periodo estivo con tutto ciò che esso ne
comporta.

Per questo progetto sono state realizzate 13 tabelle per un totale di 7 chiavi primarie e 49 attributi in essi
contenuti. Si sono realizzate e testate 50 stored procedure che da sole permettono la totale e completa
gestione della base di dati per un totale di oltre 100 operazioni svolte al loro interno e diverse centinaia di
righe di codice che esse sviluppano.
Per quello che riguarda l’interfaccia, si sono realizzate 9 esempi di possibili viste che da sole vanno a coprire
e a gestire tutte le situazioni possibili che l’applicativo si può dover trovare a gestire.
Il sito web è composto da 7 pagine al cui interno sono stati implementati i java script e la form per
permettere l’eventuale autenticazione di un utente con credenziali.

7. Sviluppi futuri

Eventuali sviluppi futuri potrebbero essere quelli di implementare effettivamente l’interfaccia ed il relativo
data base al sito web in modo da incrementare notevolmente la quantità offerta di informazioni che esso si
propone di mettere a disposizione dei semplici visitatori ma anche di chi ne fosse interessato per scopi
scientifici o collaborativi. Un altro scenario possibile sarebbe quello di espandere l’implementazione
dell’intero sistema anche per altri progetti al di fuori di GeoSNaV e quindi di andare a modificare la
piattaforma in tal senso.

Risulta inoltre già in programma lo sviluppo e l’ampliamento del sito web appena progettato per
l’inserimento di diverse pagine di presentazione di un progetto derivante da GeoSNaV e relativo a delle
rilevazioni GPS condotte su degli scavi archeologici ad Aquileia e condotti dal Dipartimento di Ingegneria
Civile dell’Università di Trieste. Le pagine prevedono la descrizione del progetto e delle rilevazioni condotte
con la pubblicazioni anche di mappe, dati ed immagini vettoriali derivanti da tali rilevazioni.
Non si esclude inoltre la probabile aggiunta di altri progetti simili a questo e legati in qualche modo al
progetto più generale GeoSNaV.

58
8. Bibliografia e fonti web

1. Prof. Maurizio Fermeglia, slide del corso Basi Di Dati (2009).

2. Prof. Fulvio Sbroiavacca, slide del corso Sistemi Informativi I (2007).
3. Prof. Leonardo Felician, slide del corso Sistemi Informativi II (2007).
4. Polillo Roberto (2004), Il check-up dei siti web. Valutare la qualità per migliorarla. Apogeo, Milano.
5. http://msdn.microsoft.com/it-it/library
6. http://it.wikipedia.org/wiki/Stored_procedure
7. http://database.html.it/guide/leggi/133/guida-sql-server-2005/
8. http://database.html.it/guide/leggi/40/guida-linguaggio-sql/
9. http://database.html.it/articoli/leggi/2874/primo-sguardo-a-sql-server-2008/
10. http://database.html.it/guide/lezione/3388/introduzione-a-sql-server/
11. http://groups.google.it/group/microsoft.public.it.sql/topics
12. http://www.webmasterpoint.org/sqlserver/04-php-sqlserver-stringa-connessione-database.asp
13. http://www.hostingsolutions.it/guide/mssql.php
14. http://www.goldenweb.it/manuale_php/ref.mssql.php
15. http://php.net/manual/en/book.mssql.php
16. http://forum.html.it/forum/showthread/t-544480.html
17. http://xhtml.html.it/guide/leggi/51/guida-html/
18. http://javascript.html.it/guide/leggi/175/guida-javascript-tecniche-avanzate/
19. http://www.scribd.com
20. http://www.shinynews.it/usability/1004-struttura.shtml
21. http://www.web-link.it/

59