Upload
lyanh
View
215
Download
0
Embed Size (px)
Citation preview
Univesita di Roma Tor Vergata
Ingegneria dell’Informazione - Ind. Sistemi
Sviluppo di un’applicazione web
per la gestione dei consuntivi scientifici dell’I.N.F.N.
Antonello Paoletti
Relatore:
Prof.ssa Berta Buttarazzi
Correlatori:
Dott.ssa Marina Candusso
Anno Accademico 2005 / 2006
La vita ed i sogni sono fogli di uno stesso libro.
Leggerli in ordine e vivere...sfogliarli a caso e sognare.
(Arthur Schopenhauer)
Ringraziamenti
Per chi ci ha creduto e chi ci crede tuttora.
Indice
Introduzione 6
1 L’istituto Nazionale di Fisica Nucleare 8
1.1 Attivita di ricerca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.1 Organizzazione amministrativa dell’ente . . . . . . . . . . . . . . . 10
1.1.2 I consuntivi scientifici . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.3 Sistema di gestione . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.4 Il servizio Dataweb . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.5 Soluzioni precedenti . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 L’interfaccia 15
2.1 Autenticazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Il menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Esperimenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Common Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.3 Sommari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.4 Modifica dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Funzionalita offerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.1 Brief report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.2 Inserimento dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.3 Collaborations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.4 More on the experiment . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.5 Milestones 2004 and Level of Completion(%) . . . . . . . . . . . . . 28
2.4.6 Milestones 2005 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.7 Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.8 Internationalization . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.9 Spin-off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2
INDICE 3
2.4.10 Fall-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3 Analisi ed Implementazione 39
3.1 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 Analisi degli User Requirements . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.1 Struttura delle precedenti schede di Consuntivo . . . . . . . . . . . 39
3.2.2 Nuove schede di Consuntivo: struttura proposta . . . . . . . . . . . 41
3.2.3 Modalita di accesso utenti . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.4 Produttivita scientifica comune a piu esperimenti / iniziative scien-
tifiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.5 Milestone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.6 Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.7 Grado di Internazionalizzazione . . . . . . . . . . . . . . . . . . . . 44
3.2.8 Spin-off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.9 Produttivita: Ricadute . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.10 Collaborazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3 Caso d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4 Struttura degli script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5 Funzioni utilizzate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.5.1 Presa dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.5.2 Inserimento dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.5.3 Cancellazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.6 Struttura dell’output HTML . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.6.1 Validazione W3C . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.6.2 Componente client-side . . . . . . . . . . . . . . . . . . . . . . . . . 54
4 Database 57
4.1 Database Management System . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.1.1 Definizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.1.2 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2 Database utilizzato dall’applicazione . . . . . . . . . . . . . . . . . . . . . 60
4.2.1 Entita e relazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3 Realizzazione del Database: Catalogo dei dati . . . . . . . . . . . . . . . . 63
4.3.1 Entita ActivityReport . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.2 Entita Collaborazione . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.3 Entita Commissione . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.4 Entita Esperimento . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
INDICE 4
4.3.5 Entita Internazionalizzazione . . . . . . . . . . . . . . . . . . . . . . 68
4.3.6 Entita Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.7 Entita Milestone . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3.8 Entita Ricaduta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3.9 Entita Settore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.3.10 Entita Spin off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.4 Esempi di inserimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.5 Struttura precedente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Elenco delle figure
1.1 Acceleratore di particelle Daphne . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Le strutture locali INFN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Personale I.N.F.N. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Organigramma INFN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5 Scala temporale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1 Accesso al sito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Terzo livello del menu: esperimenti . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Terzo livello del menu: common activities . . . . . . . . . . . . . . . . . . . 21
2.5 Terzo livello del menu: sommari in lettura . . . . . . . . . . . . . . . . . . 22
2.6 Terzo livello del menu: sommari in modifica . . . . . . . . . . . . . . . . . 24
2.7 Brief report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.8 Collaborations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.9 More on the experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.10 Milestone 2004 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.11 Milestone 2005 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.12 Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.13 Internationalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.14 Spin-off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.15 Fall-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.1 Use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2 Webserver con PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.3 HTML 4.01 compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4 Rapporto validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1 Logo di MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2 Motore di MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5
ELENCO DELLE FIGURE 6
4.3 Architettura 2-tier thin client . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.4 Diagramma E-R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5 ActivityReport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.6 Collaborazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.7 Commissione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.8 Esperimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.9 Internazionalizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.10 Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.11 Milestone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.12 Ricaduta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.13 Settore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.14 Spinoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.15 ActivityReport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.16 Collaborazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.17 Commissione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.18 Esperimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.19 Internazionalizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.20 Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.21 Milestone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.22 Ricaduta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.23 Settore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.24 Spinoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.25 Inserimento milestone nella vecchia applicazione . . . . . . . . . . . . . . . 89
Introduzione
Questo progetto si pone come obiettivo la realizzazione di un’applicazione web per la
gestione di informazioni sull’attivita di ricerca dell’Istituto Nazionale di Fisica Nucleare
(INFN). Scopo ultimo del lavoro e fornire un’interfaccia, fruibile da web, per la raccolta di
dati scientifici degli esperimenti, includendo tesi universitarie, pubblicazioni, conferenze,
risultati, previsioni e ricadute nel mondo industriale. I dati di consuntivo costituiscono
un importante riscontro per l’istituto, poiche evidenziano in dettaglio i risultati raggiunti
dai singoli esperimenti e forniscono una visione globale sui progressi della ricerca.
Il codice e stato completamente riscritto, a partire da una versione precedente, inte-
grando la vecchia interfaccia con nuove funzionalita e contenuti, tali da poter soddisfare i
requisiti utente, raccolti in precedenza e formalizzati in un documento. Lo sviluppo delle
pagine, la progettazione del nuovo database ed i vari test del sistema, hanno richiesto un
periodo di lavoro di due mesi, avviato a Gennaio 2005 con la raccolta dei requisiti. La
messa in opera e la successiva fase di presa dati, ha coinvolto le sedi locali dell’ente per
tutto il mese di marzo, con una deadline fissata al 31.
Sono state introdotte nuove modalita di inserimento delle informazioni, strutturando
in maniera piu ordinata l’interfaccia di presa dati e lo stesso database, riscritto ex-novo,
affinche potesse sfruttare appieno le potenzialita offerte da un Relational Database Ma-
nagement System (RDBMS). L’organizzazione dei dati e stata radicalmente cambiata,
grazie alla nuova struttura relazionale che ha permesso di raggruppare informazioni tra
loro omogenee ed ordinate, consentendo una maggiore facilita d’uso e di consultazione.
7
Capitolo 1
L’istituto Nazionale di Fisica
Nucleare
1.1 Attivita di ricerca
L’INFN e l’ente dedicato allo studio dei costituenti fondamentali della materia e svolge
attivita di ricerca, teorica e sperimentale, nei campi della fisica subnucleare, nucleare e
astroparticellare. Nella seconda meta degli anni ’50 l’INFN progetto e costruı il primo
acceleratore italiano, l’elettrosincrotrone realizzato a Frascati, dove nacque il primo Labo-
ratorio Nazionale dell’Istituto. La ricerca fondamentale in questi settori richiede l’uso di
tecnologie e strumenti di ricerca d’avanguardia che l’INFN sviluppa nei propri laboratori
e in collaborazione con il mondo dell’industria. In particolare il supporto informatico
ricopre un ruolo di rilievo nei confronti dell’attivita scientifica.
L’attivita dell’INFN si basa su due tipi di strutture di ricerca complementari: le
Sezioni e i Laboratori Nazionali. Le 19 Sezioni hanno sede in dipartimenti universitari
e realizzano il collegamento diretto tra l’Istituto e le Universita. I quattro Laboratori,
con sede a Catania, Frascati, Legnaro e Gran Sasso, ospitano grandi apparecchiature e
infrastrutture messe a disposizione della comunita scientifica nazionale e internazionale.
Il personale dell’INFN conta circa 2000 dipendenti propri e quasi 2000 dipendenti
universitari coinvolti nelle attivita dell’Istituto e 1300 giovani tra laureandi, borsisti e
dottorandi.
L’attivita scientifica e suddivisa in cinque grandi branche di ricerca, riguardanti le
principali aree tematiche della fisica. Ad ognuna di queste afferisce un numero variabile
di esperimenti dislocati su tutto il territorio nazionale. Ogni esperimento e rappresentato
8
CAPITOLO 1. L’ISTITUTO NAZIONALE DI FISICA NUCLEARE 9
Figura 1.1: Acceleratore di particelle Daphne
Figura 1.2: Le strutture locali INFN
CAPITOLO 1. L’ISTITUTO NAZIONALE DI FISICA NUCLEARE 10
Figura 1.3: Personale I.N.F.N.
da persone di rilievo o esperti nel campo, che dirigono e coordinano le attivita di ricerca
svolte nelle singole sezioni, in qualita di rappresentante nazionale. Il lavoro di un singolo
esperimento puo essere portato avanti con l’appoggio di una o piu sezioni, il cui coordi-
namento e gestito da un responsabile locale. All’interno di ogni sezione e laboratorio gli
esperimenti di uno stesso gruppo (branca di ricerca) sono soggetti alla linea decisionale
imposta dal coordinatore di gruppo.
1.1.1 Organizzazione amministrativa dell’ente
L’organo decisionale dell’Istituto e il Consiglio Direttivo, costituito dal Presidente e dalla
Giunta Esecutiva, dai quattro Direttori dei Laboratori Nazionali e da 19 Direttori delle
Sezioni, da rappresentanti del MIUR, del Ministero dell’Industria, del Cnr e dell’Enea.
L’attuazione delle decisioni del Consiglio compete, secondo i casi al Presidente alla Giunta,
ai Direttori di Laboratorio o di Sezione per l’organizzazione delle attivita a livello locale,
il tutto con l’ausilio dei dirigenti dell’Amministrazione Centrale.
L’attivita di ricerca necessita di mezzi e risorse da convogliare nelle singole rappresen-
tanze locali di ogni esperimento. Il Ministero dell’Economia sostiene le spese di ricerca
con finanziamenti corrisposti all’Istituto, sulla base di preventivi presentati dai rappre-
sentanti d’esperimento e convalidati da figure di garanzia interne ed esterne all’Istituto (i
referee).
CAPITOLO 1. L’ISTITUTO NAZIONALE DI FISICA NUCLEARE 12
In questo contesto si inquadra il dominio del problema: gestione coordinata e distri-
buita di dati scientifici ed economici in fase di preventivo, assegnazione e consuntivo.
Questi dati, forniti dai responsabili di esperimento in periodi prefissati, costituiscono la
base decisionale sulla quale valutare l’entita dei finanziamenti di cui ogni commissione
scientifica dispone. Le richieste di fondi sono distribuite durante l’anno durante apposite
sessioni con particolare rilievo per la sessione di luglio, in cui le commissioni scientifiche
accolgono e valutano la maggior parte delle richieste provenienti dai responsabili locali di
esperimento. Come per le richieste, le assegnazioni avvengono in diverse sessioni, anch’es-
se distribuite durante l’anno. La principale e tenuta nel mese di settembre per soddisfare
le proposte di spesa presentate a luglio per l’anno successivo e per redigere il bilancio
preventivo.
Figura 1.5: Scala temporale
1.1.2 I consuntivi scientifici
Successivamente alle fasi di richiesta ed assegnazione di fondi, gli esperimenti sono tenuti
a descrivere l’attivita svolta ed i risultati scientifici ottenuti, affinche sia possibile valutare
oggettivamente la produttivita della ricerca. In questa fase, definita di Consuntivo, i
responsabili nazionali d’esperimento stilano un rapporto di attivita, in cui descrivono i
risultati ottenuti nell’ultimo anno di ricerca e tutte le attivita connesse all’esperimento,
riguardanti pubblicazioni, tesi di laurea e conferenze.
La quantita di informazioni da gestire e notevolmente elevata, poiche l’INFN si com-
pone di 5 commissioni scientifiche a cui afferiscono un centinaio di esperimenti, attivi in
tutte le strutture locali, dislocate sull’intero territorio nazionale. Questo implica che un si-
stema di gestione informatica sia veloce, affidabile e facilmente raggiungibile da postazioni
remote.
CAPITOLO 1. L’ISTITUTO NAZIONALE DI FISICA NUCLEARE 13
1.1.3 Sistema di gestione
L’ampia diffusione del web, in questi ultimi anni, ha reso obsoleti molti sistemi proprietari
di accesso a banche dati, favorendo lo sviluppo di strutture aperte e scalabili per l’utilizzo
e la creazione di database. Si tratta di infrastrutture server a due o tre livelli, costituite da
un supporto di persistenza, (Database server) una componente applicativa ed un servizio
di presentazione (Web server). Questa base Hardware e Software costituisce, oggi il sup-
porto piu diffuso per la realizzazione di servizi ed applicazioni distribuite. In particolare,
per l’implementazione di un sistema di presa dati, per i consuntivi, si e scelto di utilizzare
una configurazione server largamente diffusa, basata su Apache, PHP e MySQL.
1.1.4 Il servizio Dataweb
Introduction E’ stato realizzato negli ultimi due anni presso il centro di Calcolo dei La-
boratori un sistema di web servers e database MySQL, finalizzato a migliorare la di-
stribuzione di informazioni scientifiche e amministrative all’interno dell’INFN. Di recente
questa attivita e evoluta in un vero e proprio servizio INFN denominato Servizio Coor-
dinamento Banche Dati Ricerca (DATAWEB). L’attivita principale di questo servizio
e’ il supporto alle commissioni scientifiche Nazionali per la realizzazione dei Preventivi,
Assegnazioni finanziarie e Consuntivi Scientifici. I dati raccolti durante queste tre fasi
principali vengono messi a disposizione in alcune sue parti sia agli uffici amministrativi
per la formazione del bilancio annuale, sia al grande pubblico specializzato e non per
quanto riguarda il contenuto scientifico. Di recente e diventato lo strumento principale
per la raccolta della documentazione al fine di redigere la documentazione per la valuta-
zione e la selezione dei prodotti dell’Istituto secondo quanto richiesto dal Ministero della
Ricerca Scientifica. In aggiunta il Servizio ha realizzato il sito per la formazione interna
INFN ed il sito per le procedure di Associazione Scientifica che coinvolge circa 3000 tra
professori,ricercatori, dottorandi e laureandi delle maggiori Universita’ Italiane. Una par-
te dell’attivita’ e’ dedicata anche alla raccolta della documentazione multimediale per la
realizzazione di database di immagini e video realizzati all’interno delle strutture INFN
che verranno usati per il sito dell’INFN dedicato al grande pubblico. Nel prossimo futuro
il sistema verra’ messo in comunicazione con il nuovo sistema informativo Centralizzato
della Oracle-Bull per una maggiore efficenza di scambio tra le informazioni scientifiche e
quelle amministrative.
CAPITOLO 1. L’ISTITUTO NAZIONALE DI FISICA NUCLEARE 14
1.1.5 Soluzioni precedenti
Il lavoro di tesi e stato inquadrato all’interno di un’attivita di reingegnerizzazione, volta
alla scrittura di un’applicazione ottimizzata per la presa dati e la consultazione. Lo scopo
finale che ci e prefissati, e quello di ottenere un prodotto simile all’applicazione in uso,
fino al 2003, ma radicalmente diverso dal punto di vista implementativo e di database,
soprattutto per la strutturazione dei dati inseriti. Il vecchio sistema, gia basato su un’in-
frastruttura web, aveva diverse mancanze e non permetteva di soddisfare molti requisiti
di usabilita (interfaccia) e di accesso ai dati, a causa di un database non strutturato con
criteri relazionali.
Capitolo 2
L’interfaccia
L’applicazione si compone di un numero di pagine web dinamiche, scritte in linguaggio
server-side, interfacciate ad un database relazionale per il salvataggio delle informazioni
inserite. Le funzionalita di presa dati e sommarizzazione sono suddivise fra i vari script
PHP, raggiungibili da un menu di navigazione sempre visibile sulla sinistra del browser.
La home page dell’applicazione e raggiungibile all’indirizzo web
http://www.infn.it/consuntivi/2004
da qualsiasi browser in grado di supportare javascript e la navigazione a frame. Questo
comporta la necessita di utilizzare client recenti poiche la componente di navigazione e
validazione dei dati inseriti fa uso di scripting client-side (javascript) per funzionalita di
controllo e gestione altrimenti non fruibili utilizzando il solo HTML.
2.1 Autenticazione
Ogni pagina presente nel subtree dell’applicazione viene servita dopo un processo di au-
tenticazione cui l’utente viene sottoposto al momento dell’accesso. Questo serve, innanzi
tutto, per vistare la consultazione e l’inserimento a persone estranee all’Istituto, ma anche
per differenziare l’offerta di funzionalita a seconda dell’utente che si autentica
La figura 2.1 mostra la finestra di dialogo aperta dal browser all’atto dell’accesso. Sono
previste diverse classi di utenti con privilegi di lettura e/o scrittura su singole porzioni di
dati o sulla totalita degli stessi:
• Amministratore: privilegi globali di lettura e scrittura;
15
CAPITOLO 2. L’INTERFACCIA 16
Figura 2.1: Accesso al sito
• Presidente di commissione: privilegi di scrittura sui dati riguardanti la propria
commissione e privilegi globali di lettura;
• Responsabile d’esperimento: privilegi di scrittura sui dati relativi al proprio esperi-
mento e privilegi globali di lettura;
• Visitatore: privilegi globali di lettura;
• CVI - International Evaluation Committee: privilegi di lettura, con viste par-
ticolareggiate sui dati, per la valutazione della ricerca ad opera di un comitato
internazionale
• CIVR - Comitato Italiano di Valutazione: privilegi di lettura, con viste parti-
colareggiate sui dati, per la valutazione della ricerca od opera di un comitato
italiano.
2.2 Home Page
Una volta autenticato, l’utente accede alla pagina principale. Questa e suddivisa in due
frame verticali, per ospitare il menu e la pagina web relativa alla sezione che si sta con-
sultando. Questa scelta permette di mantenere sempre in vista il menu rendendo la
navigazione fra le varie sezioni piu semplice ed immediata.
La figura 2.2 mostra la disposizione dell’area di lavoro, comune a tutti gli utenti
autenticati, con una pagina di benvenuto che presenta l’applicazione fornendo cenni e
suggerimenti sull’accesso e l’uso.
CAPITOLO 2. L’INTERFACCIA 18
2.3 Il menu
L’area di sinistra della schermata ospita il menu di navigazione che, esploso su tre livelli,
permette ai presidenti di commissione, ai responsabili ed ai visitatori di indirizzare la
propria navigazione attraverso la scelta della commissione, dell’esperimento e quindi della
funzionalita richiesta.
Si nota la prima differenziazione fra i link proposti che indirizzano la navigazione verso
una delle 5 commissioni scientifiche nazionali di cui si compone l’I.N.F.N. Ad ognuna di
queste afferiscono diversi esperimenti, in atto presso le sedi locali dell’istituto, dislocate
sul territorio nazionale
Il primo sottomenu si suddivide in 4 sezioni, visibili e fruibili a seconda dei privilegi
d’accesso posseduti dall’utente autenticato:
• Sommari : e una lista di report che riassumono la situazione globale della commis-
sione, riportando i dati inseriti da tutti i responsabili d’esperimento, differenziati
per voce.
• Modifica dati : mostra un prospetto, simile al precedente, mediante il quale gli utenti
con privilegi di scrittura (in questo caso solamente i Presidenti di commissione)
possono fare modifiche su tutte le voci compilate dai responsabili d’esperimento
• Esperimenti : ogni esperimento afferente alla commissione ha una propria pagina di
inserimento dati accessibile in scrittura al solo Responsabile
• Common Activities : permette di accedere alla maschera di compilazione per le voci
d’attivita comuni a collaborazioni fra due o piu esperimenti.
2.3.1 Esperimenti
Poiche la prima e la seconda categoria di link offrono una visione globale delle informa-
zioni inserite, mostreremo prima in dettaglio le operazioni di inserimento per i singoli
esperimenti.
Il terzo livello del menu elenca le funzioni messe a disposizione dei Responsabili
d’esperimento per quanto riguarda:
• Brief report : Rapporto annuale sull’attivita di ricerca portata avanti dall’esperi-
mento nell’anno 2004.
• Publications : Lista delle pubblicazioni afferenti all’esperimento presentate nell’anno
2004.
CAPITOLO 2. L’INTERFACCIA 20
• Talks : Lista delle conferenze afferenti all’esperimento tenute nell’anno 2004.
• Thesis : Lista delle tesi di laurea sviluppate nell’ambito dell’esperimento nell’anno
2004.
• Summary : Breve descrizione dell’esperimento (in lingua inglese), logo e collegamenti
al sito ufficiale
• Short Descr.: Breve descrizione dell’esperimento in lingua italiana
2.3.2 Common Activities
Il sottomenu relativo alle Common Activities include funzionalita simili applicate alle
collaborazioni fra due o piu esperimenti della stessa commissione scientifica
A differenza del precedente sottomenu, questo non include alcun tipo di descrizione
poiche le operazioni comuni a piu esperimenti riguardano esclusivamente pubblicazioni,
conferenze, tesi e collaborazioni con personale di altri istituti.
2.3.3 Sommari
Il sottomenu che segue presenta una serie di link a report, suddivisi per voce, che presen-
tano la situazione globale dei dati inseriti riguardo gli esperimenti della commissione.
La figura 2.5 mostra come il terzo livello del menu sia visibilmente piu consistente
rispetto allo stesso menu degli esperimenti o delle Common Activities. Molte voci presenti
all’interno di questo menu riguardano dati presenti del Brief report ampiamente descritta
nel capitolo seguente. I link permettono di raggiungere i seguenti sommari:
• Research Proj.: Resoconto dell’attivita di ricerca portata avanti della commissione
• Responsibles : Elenco dei responsabili d’esperimento
• Collaborations : Elenco delle collaborazioni avute con personale esterno o altre
istituzioni
• Exp. Location: Luoghi di svolgimento dei singoli esperimenti
• Goals : Risultati raggiunti dagli esperimenti
• Activity 2004 : Resoconto dell’attivita svolta dai singoli esperimenti
• INFN Contr.: Contributi in denaro corrisposti dall’Istituto per le attivita di ricerca
CAPITOLO 2. L’INTERFACCIA 23
• FTE count : Ricercatori Full Time Equivalent suddivisi per linea di ricerca
• Budget count : Percentuali di bilancio assegnate alle linee di ricerca
• Milestones 2004 : Risultati raggiunti dagli esperimenti nell’anno di consuntivo con
percentuale di successo
• Milestones 2005 : Risultati previsti dagli esperimenti per l’anno in corso
• Milestones average: Percentuali medie di raggiungimento delle milestone suddivise
per esperimento
• Milestones count : Conteggio delle milestone
• Leadership: Elenco dei ruoli di leadership
• Innovat.Instr.: Strumenti innovativi utilizzati dagli esperimenti per lo sviluppo di
apparecchiature
• Compet.Exper.: Esperimenti che competono sullo stesso obiettivo di ricerca
• Int. Committee: Comitato internazionale che ha il compito di supervisionare l’atti-
vita di ricerca dell’esperimento
• Publications : Pubblicazioni su riviste scientifiche uscite nell’anno di consuntivo
• Publications count : Conteggio delle pubblicazioni suddivise per linea di ricerca
• Publ. IF : Riviste scientifiche con relativo Impact Factor
• Publ. average: Conteggio e medie sugli autori delle pubblicazioni
• Tassonomia 1 : Classificazione delle ricadute della Attivita di Ricerca
• Tassonomia 2 : Ricadute della Attivita di ricerca verso altri esperimenti INFN
• Talks : Lista delle conferenze tenute nell’anno di consuntivo dagli esperimenti
• Talks count : Conteggio delle conferenze suddivise per linea di ricerca
• Thesis : Lista delle tesi discusse nell’anno di consuntivo dagli esperimenti
• Thesis count : Conteggio delle tesi suddivise per linea di ricerca
• Ages and durations : Durata degli esperimenti
CAPITOLO 2. L’INTERFACCIA 24
Figura 2.6: Terzo livello del menu: sommari in modifica
• Internationalization: Grado di internazionalizzazione
• Spin-off : Realta industriali di ricerca, in altre discipline e per l’INFN nelle quali il
sotto-prodotto puo essere utilizzato
• Fall-out : Classificazione delle ricadute della Attivita di Ricerca
2.3.4 Modifica dati
Alcune delle voci mostrate nel precedente sottomenu possono essere modificabili (per
l’accesso come Presidente di commissione o Amministratore) seguendo i link alla voce
Modifica Dati.
CAPITOLO 2. L’INTERFACCIA 25
2.4 Funzionalita offerte
Come descritto nel paragrafo precedente, le operazioni di inserimento dati, elencate nei
sottomenu, richiamano pagine web visualizzate nel frame di destra. Di seguito saranno
discusse in dettaglio le funzionalita offerte da ognuna di esse, seguendo l’ordine proposto
dal sottomenu relativo agli esperimenti.
2.4.1 Brief report
Il Brief report e un rapporto annuale compilato dal responsabile d’esperimento, riguardo
le attivita connesse alla ricerca, nell’ambito del campo di studi in cui opera l’esperimento.
La schermata e suddivisa in tre regioni:
• Intestazione: logo e nome dell’esperimento
• Area di validazione: le informazioni inserite di seguito necessitano della validazione
ad opera del presidente di commissione. E’ qui riportata la data e l’ora in cui e stato
validato l’intero consuntivo. Eventuali modifiche successive a tale data saranno
considerate non affidabili.
• Area di inserimento: qui si trovano le maschere di inserimento accessibili diretta-
mente o tramite link ad altre pagine
2.4.2 Inserimento dei dati
Le classi di utente con privilegi di scrittura sono in grado di modificare le informazioni
inserite nel Brief report agendo sui diversi punti di cui il rapporto si compone:
• Collaborations : collaborazioni con enti o istituti esteri, personale esterno o altre
sezioni I.N.F.N.
• Experiment Location: Luogo di svolgimento dell’esperimento (ed eventuale accele-
ratore utilizzato)
• Status : stato dell’esperimento
• First year of experiment financing : anno di inizio attivita e primo finanziamento da
parte dell’I.N.F.N.
• Experiment duration (years): durata prevista dell’esperimento
• National INFN Responsible: responsabile nazionale dell’esperimento
CAPITOLO 2. L’INTERFACCIA 27
• Goal of the Experiment : obiettivi finali che l’esperimento si propone di raggiungere
• More on the Experiment : Logo, descrizione e collegamento al sito ufficiale dell’espe-
rimento
• Physics activities during 2004 : descrizione dell’attivita svolta nell’anno di consun-
tivo
• Milestones 2004 and Level of Completion(%): milestone raggiunte nell’anno di
consuntivo con livello di completamento espresso in percentuale
• Milestones 2005 : milestone concordate per l’anno in corso
• INFN contribution to the experiment in terms of manpower and financial support :
contributo finanziario e di manodopera, corrisposto dall’I.N.F.N. per supportare le
attivita di ricerca
• Publication in refereed journals : numero di pubblicazioni edite nell’anno di consun-
tivo
• Conference talks : numero di conferenze tenute nell’anno di consuntivo
• Number of undergraduate and doctoral thesis on the experiment : numero di tesi
discusse nell’anno di consuntivo
• Leadership role in the experiment : ruoli di dirigenza dell’organico afferente all’espe-
rimento
• Innovative instruments : tecnologie innovative connesse al campo di studi dell’espe-
rimento
• Competing experiments : Esperimenti che competono nello stesso obiettivo di ricerca
• International committee which has reviewed the experiment : comitato internazionale
che ha il compito di supervisionare l’attivita di ricerca dell’esperimento.
• Internationalization: grado di internazionalizzazione dell’esperimento in termini di
collaborazioni con istituzioni estere
• Spin-off : Realta industriali di ricerca, in altre discipline e per l’I.N.F.N. nelle quali
il sotto-prodotto puo essere utilizzato
• Fall-out : Classificazione del tipo di sotto-prodotto che puo essere utilizzato nelle
diverse attivita (industria, INFN, altre discipline)
CAPITOLO 2. L’INTERFACCIA 28
Gran parte di queste informazioni sono accessibili direttamente dalla pagina principale
del Brief report, in cui e presente una maschera di inserimento o consultazione. Questi dati
possono essere inseriti, inviati e quindi validati. Per quanto riguarda le Collaborazioni, le
Milestone, le Leadership, il Grado di Internazionalizzazione, lo Spin-Off ed il Fall-out, il
discorso cambia, poiche si tratta di informazioni strutturate, piu complesse di una semplice
area di testo, che richiedono maschere di inserimento a parte, residenti su diverse pagine
web.
2.4.3 Collaborations
Il primo link presente nel Brief report rimanda alla pagina di inserimento delle collabora-
zioni con istituti o personale esterno all’I.N.F.N. Questa pagina e suddivisa in tre zone,
intestazione, area di consultazione e modifica, area di inserimento.
Per ogni record e necessario descrivere l’istituto, l’ente od il ricercatore con cui il
personale dell’esperimento ha collaborato. Qualora l’ente differisca da una delle sezioni
I.N.F.N, occorre definire la nazione in cui tale istituto opera, corredando infine il record
di eventuali note.
2.4.4 More on the experiment
Il secondo link raggiungibile del Brief report conduce alla maschera di inserimento mo-
strata in figura.
Questa pagina permette di inserire informazioni che descrivono l’esperimento senza
entrare nel dettaglio dell’attivita scientifica svolta. Qui il responsabile e in grado di
inserire una breve descrizione in lingua inglese, la URL al sito ufficiale dell’esperimento
ed il logo, utilizzato nelle pagine di questa applicazione. Sempre da questa pagina, e
possibile validare le informazioni inserite, senza bisogno di tornare al Brief report.
2.4.5 Milestones 2004 and Level of Completion(%)
I contributi finanziari che l’I.N.F.N. corrisponde, sono spesso subordinati al raggiungi-
mento di obiettivi parziali che i responsabili d’esperimento si propongono di raggiungere
entro date stabilite in fase di preventivo. Questi obiettivi, definiti milestone, costituiscono
una serie di tappe intermedie, attraverso le quali gli esperimenti perseguono gli obiettivi
proposti. Ognuna di queste milestone e costituita da una breve descrizione del risultato
previsto, una data di massima, entro cui tale risultato viene raggiunto, ed un livello di
successo, espresso in percentuale, concordato in fase di formazione del bilancio.
CAPITOLO 2. L’INTERFACCIA 32
La maschera di inserimento proposta in questa pagina e strutturata in maniera simile
alla pagina relativa alle collaborazioni, suddivisa anch’essa in tre regioni: intestazione,
area di consultazione e modifica, area di inserimento.
2.4.6 Milestones 2005
Questa maschera di inserimento e simile alla precedente, sia come struttura che come
tipologia di dati inseribili. L’unica differenza sta nel fatto che le milestone inserite qui
si riferiscono all’anno in corso e descrivono obiettivi non ancora raggiunti o per cui non
e possibile esprimere una percentuale di raggiungimento (se non come stima). Queste
milestone andranno ad integrare quelle inserite in fase di preventivo per la formazione del
bilancio 2006.
2.4.7 Leadership
Questa pagina permette di aggiungere o modificare nominativi di ricercatori che ricoprono
ruoli di responsabilita nell’esperimento. Le informazioni di cui ogni record si compone
sono il nome, la qualifica ed il settore di competenza. La struttura di questa maschera e
simile alle precedenti, con un’intestazione standard, un’area di visualizzazione e modifica
ed un’area di inserimento, a cui si aggiunge una quarta regione in cui e possibile esprimere
il numero di ruoli inseriti rispetto all’organico di cui dispone l’esperimento.
2.4.8 Internationalization
Il grado di internazionalizzazione, descrive l’impegno finanziario e scientifico dell’I.N.F.N.
per l’esperimento, in collaborazioni internazionali a cui partecipano altri istituti di ricerca.
L’area di inserimento, modifica e consultazione e posta sotto l’intestazione, rispettando
la struttura analoga alle altre pagine. Le informazioni inserite riguardano il numero di
ricercatori coinvolti e di pubblicazioni edite in collaborazioni estere, oltre alla percentuale
di spesa corrisposta dall’I.N.F.N per sostenerle.
2.4.9 Spin-off
Da questa maschera, i responsabili, sono in grado di esprimere considerazioni sull’utilizzo
di tecnologie o teorie, sviluppate nell’ambito dell’esperimento, all’esterno dell’istituto, ad
esempio in realta industriali o medicali, o in altri esperimenti.
L’area di inserimento e costituita da tre campi di testo riguardanti
• Risultati applicabili ad altri esperimenti
CAPITOLO 2. L’INTERFACCIA 37
• Risultati applicabili ad altre discipline
• Impatto sulla realta industriale e della ricerca
2.4.10 Fall-out
Gli obiettivi proposti da ogni esperimento possono avere ricadute nell’ambito della ricerca,
di realta industriali, medicali o riguardanti discipline a cui possono essere applicati. In
questa pagina, il responsabile puo specificare in dettaglio quali esperimenti I.N.F.N. o
quali realta esterne all’istituto potranno beneficiare dei risultati conseguiti, esprimendo
stime di applicabilita o giudizi sullo stato attuale di tali ricadute.
L’area di inserimento, consultazione e modifica, e suddivisa in quattro regioni, dove il
responsabile puo specificare:
• Il campo in cui avranno effetto le ricadute
• Le tecnologie ed i prodotti che ne possono derivare
• Risultati applicabili ad altre discipline
• Ricadute verso realta industriali specificandone il genere e lo stato dell’applicazione
in tale campo
• Attivita di ricerca interdisciplinare per altre applicazioni
Capitolo 3
Analisi ed Implementazione
3.1 Requisiti
L’attivita di sviluppo e stata preceduta da un periodo di raccolta requisiti, formalizzati
in un Preliminary draft riportato in appendice. Queste informazioni sono fondamentali
per la progettazione dell’interfaccia d’uso e del database, definendo tipologie di dati per
le diverse maschere di inserimento.
3.2 Analisi degli User Requirements
3.2.1 Struttura delle precedenti schede di Consuntivo
Le informazioni scientifiche di consuntivo compilate fino al 2003, disponibili sul sito uf-
ficiale dei consuntivi INFN (http://www.infn.it/consuntivi/) sono suddivise in 6 schede
principali: 1) Scheda Brief Activity Report, 2) Scheda Publications, 3) Scheda Conference
Talks, 4) Scheda Thesis, 5) Scheda Summary, 6) Scheda Breve Descrizione (in italiano).
La scheda Activity Report e composta dai seguenti punti:
• Collaboration - campo testo (non strutturato)
• Experiment Location - campo testo (non strutturato)
• Status - campo strutturato a selezione unica - Construction -
• Upgrading - Data Taking - Data Analysis
• National INFN Responsible - campo testo (non strutturato)
39
CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 40
• Goal of the Experiment - campo testo (non strutturato
• More on the Experiment - Web link alla URL contenente la
• Scheda Summary on the experiment contenente
- Home Page URL - campo testo (non strutturato)
- logo URL - campo testo (non strutturato)
- Summary on the Experiment - campo testo (non strutturato)
- Additional Information on the Experiment URLs - campo testo (non strutturato)
• Physics activities during 2003 - campo testo (non strutturato)
• Milestones 2003 and Level of Completion(%) - campo testo (non strutturato)
• Milestones 2004 - campo testo (non strutturato)
• General Planning for 2005 - campo testo (non strutturato)
• INFN contribution to the experiment in terms of manpower and financial support -
campo testo (non strutturato)
• Publication in refereed journals - campo testo (non strutturato)
• Conference talks - campo testo (non strutturato)
• Number of undergraduate and doctoral thesis on the experiment - campo testo (non
strutturato)
• Leadership role in the experiment - campo testo (non strutturato)
• Innovative instruments - campo testo (non strutturato)
• Competing experiments - campo testo (non strutturato)
• International committee which has reviewed the experiment - campo testo (non
strutturato)
• Scheda Publications Publications 2003 - unico campo testo (non strutturato)
• Scheda Conference Talks Conference Talks 2003 - unico campo testo (non struttu-
rato)
• Scheda Thesis Thesis 2003 - unico campo testo (non strutturato)
CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 41
• Scheda Summary on the experiment (cfr punto More on the Experiment sopra, nella
scheda Activity Report)
• Scheda Breve Descrizione (in italiano) Breve Descrizione dell’Esperimento - unico
campo testo (non strutturato)
L’assenza di struttura di alcune di queste informazioni nel database rende impossibile
l’estrazione automatica e la ricerca per chiavi delle informazioni memorizzate. Ne con-
segue una impossibilita di utilizzo di tali dati per qualsiasi fine statistico. In base allo
studio delle caratteristiche dei dati richiesti dalle valutazioni annuali e triennali, sorge
la necessita di stabilire una struttura, attraverso lo studio degli user requirements per
quei dati fondamentali e loro attributi, dai quali dovranno essere estratte informazioni
esatte in modo automatico mediante semplici query al Database. Per alcune di queste
informazioni non sara necessario procedere ad una analisi dettagliata e potranno essere
non strutturate.
3.2.2 Nuove schede di Consuntivo: struttura proposta
Verranno quindi, di seguito, analizzate solo le informazioni per le quali dovremo stabilire
una struttura . I punti contenuti nelle schede descritte rimarranno invariati, salvo l’ag-
giunta di alcuni campi che sono necessari per la valutazione scientifica a consuntivo di
alcune commissioni scientifiche. I campi da analizzare sono quindi i seguenti:
• 1. Publications
• 2. Conference Talks
• 3. Thesis (Laurea e Dottorato)
• 4. Scheda Activity Report :
- Milestones 2004 (effettive)
- Milestones 2005 (concordate)
- Collaborations
- Leadership role
- INFN contribution to the experiment in terms of manpower and financial support
Campi da aggiungere in questa scheda :
• Grado di Internazionalizzazione
CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 42
I campi seguenti (da aggiungere nella scheda) sono stati richiesti dalla csn5 e saranno
opzionali per le altre commissioni:
• Durata dell’esperimento
• Anni di vita dell’esperimento (0 se nuovo)
• Dati Spin-off :
- Results of special relevance for other INFN experiments
- Results of special relevance for other scientific disciplines
- Impact for applied research and industrial applications
• Dati Ricadute:
- Classificazione delle ricadute dell’Attivita di Ricerca (campo o prodotto)
- Ricadute dell’attivita di Ricerca (verso altri esperimenti, discipline, realta indu-
striali)
- Attivita di ricerca interdisciplinare esplicitamente finalizzata verso applicazioni
3.2.3 Modalita di accesso utenti
A differenza delle altre commissioni, la csn4 ha una diversa procedura per la compilazione
dei consuntivi. Questa viene fatta a cura dei coordinatori delle varie sezioni. Per consentire
cio e necessario diffenziare la modalita di accesso degli utenti del gruppo teorico rispetto
a quelle delle altre commissioni scientifiche. In particolare per la csn4 saranno definiti gli
accessi per struttura (Coordinatori) mentre per gli altri saranno definiti gli accessi per
esperimento (RN).
3.2.4 Produttivita scientifica comune a piu esperimenti / inizia-
tive scientifiche
Per alcune commissioni scientifiche (3, 4, 5) l’attribuzione esatta di alcuni lavori, come ad
es. le pubblicazioni, e impossibile. Vi sono infatti lavori che sono a cavallo di piu Inizia-
tive Specifiche od Esperimenti. E’ necessario quindi definire una sigla fittizia ’Common
Activity’ all’interno di una commissione, dove potranno essere inseriti i lavori che non
appartengono ad un unico esperimento/IS.
3.2.5 Milestone
Milestones effettive 2004. La compilazione deve essere effettuata in base allo stato di
raggiungimento effettivo delle milestones al 31 dicembre 2004. I dati iniziali nelle schede
CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 43
sono importati in automatico dal sistema dal database delle assegnazioni per il bilancio
2004. Per alcune commissioni scientifiche, i dati relativi alla percentuale effettivamente
raggiunta, dichiarata dal referee, per le milestones con data posteriore a quella della
riunione di settembre 2004, sono mancanti. I dati definitivi, per alcune commissioni, sono
contenuti nelle schede esperimento disponibili sul sito Web della commissione.
• Nome Esperimento: viene identificato automaticamente dall’applicazione Web al
momento dello user login
• Data: giorno, mese (anno automatico) concordato con il referee dell’esperimento
relativo al raggiungimento effettivo della milestone.
• Descrizione: dettaglio descrittivo della milestone compilato a cura del responsabile
nazionale.
• Percentuale raggiungimento: validata dal referee dell’esperimento a consuntivo,
dopo la chiusura del bilancio 2004.
Milestones concordate 2005. Sono state inserite nel database delle assegnazioni duran-
te le riunioni di settembre 2004 per il bilancio 2005. La compilazione iniziale nel database
e completamente automatica per gli esperimenti che hanno inserito i dati. Sono da com-
pilare invece dove i dati sono mancanti o incompleti. Anche per i dati importati in modo
automatico sara comunque necessario l’aggiornamento della situazione a consuntivo
• Nome Esperimento: viene identificato automaticamente dall’applicazione Web al
momento dello user login
• Data: giorno, mese (anno automatico) concordata dal responsabile di esperimento
con il referee per il raggiungimento della milestone nel 2005.
• Descrizione: dettaglio descrittivo della milestone 2005, concordata con il referee
dell’esperimento, compilato a cura del responsabile nazionale.
3.2.6 Leadership
La codifica completa dei ruoli di leadership risulta piuttosto complessa. Sono stati
suddivisi in 2 macro categorie, indicando, in quella di sola gestione, i principali.
• Nome Esperimento: viene identificato automaticamente dall’applicazione Web al
momento dello user login
CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 44
• Nome: Cognome e nome della persona che ricopre un ruolo di responsabilita rico-
perto nell’esperimento
• Tipo Ruolo: tipologia del ruolo di responsabilita ricoperto nell’esperimento, a scelta
tra:
- Ruolo di gestione
- Ruolo scientifico o equivalente
per il ruolo di gestione e possibile scegliere da una lista precompilata:
1. Spokesperson
2. Co-spokesperson
3. Project-Leader
4. Detector-Leader
5. Altro
Per i campi 4) 5) si attivera un ulteriore campo di inserimento di testo dove potra
essere inserito il nome del Detector o il dettaglio della tipologia del ruolo. Per il
ruolo scientifico o equivalente sara possibile inserire in un ulteriore campo di testo
la descrizione del ruolo ricoperto.
Sara inoltre necessario specificare anche il numero totale di ruoli di responsabilita
ricoperti nell’esperimento.
• N.Ruoli italiani : indica il numero totale di ruoli di responsabilita italiani/INFN
ricoperti nell’esperimento.
• N. Ruoli disponibili : numero totale di ruoli di responsabilita disponibili nell’esperi-
mento.
3.2.7 Grado di Internazionalizzazione
Nome Esperimento/IS : viene identificato automaticamente dall’applicazione Web al mo-
mento dello user login
• Impegno Finanziario: espresso in percentuale, indica la frazione d’impegno finan-
ziario INFN rispetto all’impegno totale della Collaborazione.
• N. totale Ricercatori : numero totale di ricercatori nella Collaborazione.
• N.firm.Ricercatori : numero di ricercatori che si firmano (anche) INFN nella Colla-
borazione.
CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 45
• N.Rubbl.Inter.: numero di pubblicazioni in Collaborazioni Internazionali.
• N.totale Pubbl.: numero totale di pubblicazioni.
3.2.8 Spin-off
La struttura per i dati sulla produttivita e mutuata da quella adottata per la CSNV
• Nome Esperimento: viene identificato automaticamente dall’applicazione Web al
momento dello user login
• Results of special relevance for other INFN experiments : campo di testo contente
la descrizione.
• Results of special relevance for other scientific disciplines : campo di testo contente
la descrizione.
• Impact for applied research and industrial applications : campo di testo contente la
descrizione.
3.2.9 Produttivita: Ricadute
La struttura per i dati sulla produttivita e mutuata da quella adottata per la CSNV
• Nome Esperimento: viene identificato automaticamente dall’applicazione Web al
momento dello user login
• Classificazione delle ricadute della Attivita di Ricerca:
- nel campo
- nuovo prodotto
in entrambi i casi deve essere selezionata la tipologia di campo o di caratteristica
del nuovo prodotto da una lista precompilata.
• Ricadute della Attivita di ricerca: viene indicato verso quali altri campi o esperimenti
avviene la ricaduta, - altri esperimenti INFN
- altre discpline
- realta industriali
Inoltre deve essere specificato se tale ricaduta e
- in atto
- in via di definizione
- potenziale
CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 46
- nessuna nei primi 2 casi e possibile specificare in campi di testo il nome del utente
target (esperimento, ente, ditta etc.)
• Attivita di ricerca interdisciplinare esplicitamente finalizzata verso applicazioni : in-
dicazione del campo specifico di applicazione da selezionare in una lista suddivisa
per macro categorie (mediche, beni culturali,industriali).
3.2.10 Collaborazione
La struttura per i dati sulla collaborazione e in parte mutuata da quella adottata per la
CSNIV.
• Nome Esperimento: viene identificato automaticamente dall’applicazione Web al
momento dello user login
• Istitituto/Collaboratore: nome dell’istituto(ricercatore) o laboratorio che collabora
con l’esperimento/IS. Nel caso di struttura o laboratorio INFN il nome potra essere
selezionato da una lista precompilata.
• Nazione: nazione estera dell’istituto(ricercatore) che collabora con l’esperimento/IS.
Non deve essere specificato se l’istituto o laboratorio e in Italia.
• Note: campo di testo contente una eventuale descrizione (opzionale).
3.3 Caso d’uso
L’attore di riferimento e il Responsabile nazionale d’esperimento, il quale accede ad un’in-
terfaccia di presa dati distribuita fisicamente su piu pagine web. Questo affinche sia pos-
sibile gestire, separatamente, informazioni di natura eterogenea che, pur essendo legate
strettamente fra di esse, devono essere consultabili separatamente. Il diagramma che se-
gue, mostra come l’interfaccia del report di attivita rimandi alle altre interfacce per la
consultazione e l’inserimento, secondo la gerarchia proposta in fase di analisi e mostrata
nel capitolo precedente:
3.4 Struttura degli script
Ogni pagina web, di cui si compone l’applicazione, e strutturata in maniera modulare,
permettendo di dividere su piu file le diverse funzionalita di cui fa uso ed evitando di
scrivere piu volte parti di codice comuni a piu script.
CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 47
Figura 3.1: Use case diagram
In particolare, le impostazioni relative alla connessione al DBMS, le tavole hash, la
traduzione dei parametri passati fra le pagine e le funzioni sono contenuti dentro file a
parte, inclusi al momento dell’avvio dello script.
Le pagine che si occupano di presa dati, poi, includono all’inizio ed alla fine, rispetti-
vamente un’intestazione ed un pie di pagina comuni a tutte le pagine dell’applicazione
I file di configurazione sono richiamati dal file
config.inc.php
in maniera da evitare inclusioni multiple all’interno di uno stesso file e rendere piu semplice
la costruzione di un modello (template) su cui basare tutte le pagine del sito:
<?
# includo il file di configurazione per
# la connessione al database, le tavole hash
# e le variabili di ambiente
include ("include/config.inc.php");
# includo il file delle funzioni di libreria
CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 48
include ("include/functions.inc.php");
# inizializzazione delle variabili
include ("include/init.inc.php");
?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<? include ("include/header.inc.php"); ?>
<? include ("include/footer.inc.php"); ?>
</body>
</html>
Questa versione base non prevede l’inclusione di un foglio di stile (CSS ) ne della
libreria di funzioni javascript utilizzate per applicazioni di HTML dinamico (DHTML).
L’esecuzione di una pagina, strutturata in questo modo, e a totale carico del webserver
che ne esegue il parsing, genera un output HTML e lo invia al browser, che lo mostra
senza eseguire linee di codice. La gran parte degli script rispecchia questo modello, poiche
non richiede elaborazioni client-side (controlli eseguiti dal browser dopo la ricezione della
pagina) ne effetti DHTML, come invece accade per la pagina del menu e per alcune
maschere.
In questo caso occorre includere un file di testo con le funzioni javascript da attivare
all’avvio della pagina o in presenza di particolari eventi, come la pressione di un pulsante.
L’inclusione avviene mediante l’inserimento di un TAG di scripting nella sezione HEAD
della pagina
<head>
<title></title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 49
<script src="include/functions.js" language="javascript" type="text/javascript">
</script>
</head>
3.5 Funzioni utilizzate
Le funzioni per il trattamento dei dati inseriti o caricati dal database sono, come gia detto,
raccolte e centralizzate all’interno di un unico file, costituendo una libreria raggiungibile
da ogni script con una semplice inclusione. Questo avvantaggia la scrittura del codice
da molti punti di vista, non solo della semplicita. In particolare, se una stessa funzione
fosse utilizzata da tanti script e necessitasse di una modifica, questo implicherebbe la
riscrittura di tutti i file in cui e contenuta, causando un’inutile dispendio di forze, a fronte
di un piccolo overhead a carico del webserver, per l’inclusione di un file esterno.
Sono state sviluppate delle funzioni di presa dati dal db, che si occupano di costruire le
query di selezione ritornando al programma chiamante le sole informazioni di cui necessita
la pagina. Questa sorta di middleware fra il database driver e la componente di presenta-
zione supplisce alla mancanza di un application server per l’elaborazione e, soprattutto,
l’interfacciamento al database. Pur non utilizzando un linguaggio ad oggetti, si e cercato
di orientare la gestione delle interazioni con il db facendo largo uso di funzioni Get e Set,
come se i result-set del database fossero degli attributi privati cui non e possibile accedere
direttamente. Un sistema a livelli di questo tipo e vantaggioso e scalabile, ma soprattutto
molto versatile, poiche un eventuale cambiamento del database driver non implicherebbe
alcuna modifica al presentation layer, ma solo alla componente di connessione e presa
dati.
3.5.1 Presa dati
La funzione di tipo Get e costituita da una segnatura a singolo parametro formale, poiche
tutte le informazioni per costruire la query sono strutturate all’interno di una tavola hash
strutturata come segue:
$params = array("tablename" => "",
"dbname" => "",
"link_id" => "",
"expname" => "",
"gid" => "",
"sez" => "",
CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 50
"ip" => "",
"remote_user" => "");
• tablename: il nome della tabella su cui agira la query
• dbname: il nome del database
• link id : l’id della connessione al DBMS server
• expname: l’esperimento
• gid : la commissione scientifica (o gruppo)
• sez : la struttura I.N.F.N.
• ip: l’indirizzo ip del computer client
• remote user : l’utente autenticato via HTTP
Per mostrare un esempio, riportiamo la funzione di presa dati utilizzata dalla pagina
per le informazioni relative allo spin-off:
function getSpinoff($params) {
# query di default che interroga solo sulla base del gruppo
$query =
"SELECT *
FROM ".$params["tablename"]."
WHERE gid=’".addslashes($params["gid"])."’";
# query estesa basata sul singolo esperimento
if ($params["expname"] != "")
$query .= " and sigla_exp=’".addslashes($params["expname"])."’";
# query inviata al database
$result = mysql_query($query, $params["link_id"]) or die(mysql_error($params["link_id"]));
# il result-set viene ritornato
CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 51
return(mysql_fetch_array($result));
}
La funzione costruisce, per prima cosa, una semplice query basata sul solo gruppo,
per poi estendere i criteri di selezione al nome dell’esperimento, se specificato nell’array
dei parametri, quindi invia la query e ritorna il result-set.
3.5.2 Inserimento dati
Analogamente, una funzione di tipo Set, utilizza una segnatura a tre parametri per iden-
tificare mediante tavola hash tutte le opzioni di cui necessita per interfacciarsi con il
database e costruire query di inserimento o aggiornamento dati. Il secondo parametro
e un’altra tavola hash contenente i valori da assegnare ai campi della tabella, mentre il
terzo, se presente, identifica univocamente il record da aggiornare. Quest’ultimo valore e
fondamentale per la funzione, per poter discriminare fra query di inserimento e query di
aggiornamento.
function setSpinoff($params, $values, $id) {
# Se non e specificato alcun record in particolare,
# l’id e nullo e la query sara di inserimento
if ($id == 0) {
$query =
"INSERT INTO ".$params["tablename"]."
SET sigla_exp = ’".addslashes($params["expname"])."’,
gid = ".$params["gid"].",
infn_exp = ’".addslashes($values["infn_exp"])."’,
discip_scient = ’".addslashes($values["discip_scient"])."’,
appl_res = ’".addslashes($values["appl_res"])."’,
ip = ’".$params["ip"]."’,
remote_user = ’".$params["remote_user"]."’";
}else{
CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 52
# Se l’id e non nullo e la query sara di aggiornamento
$query =
"UPDATE ".$params["tablename"]."
SET sigla_exp = ’".addslashes($params["expname"])."’,
gid = ".$params["gid"].",
infn_exp = ’".addslashes($values["infn_exp"])."’,
discip_scient = ’".addslashes($values["discip_scient"])."’,
appl_res = ’".addslashes($values["appl_res"])."’,
ip = ’".$params["ip"]."’,
remote_user = ’".$params["remote_user"]."’
WHERE sid = ".$id;
}
# Eseguo la query
mysql_query($query, $params["link_id"]) or die(mysql_error($params["link_id"]));
}
Come si nota, i nomi del database e delle tabelle non sono mai esplicitati come stringhe
costanti: questo costituisce un ulteriore vantaggio nella gestione delle connessioni al db
server poiche la modifica al nome di una tabella o dell’intero db, coinvolgera una ed
una sola modifica dal punto di vista dell’applicazione, che si preoccupera di valorizzare
correttamente le variabili, propagando i nomi.
3.5.3 Cancellazione
Un ultimo tipo di funzione per l’interfacciamento al database riguarda la cancellazione di
record dalle tabelle. Non sono molte le maschere che ne fanno uso, poiche molte tabelle
sono in relazione 1:1 con la tabella degli esperimenti e la cancellazione di un record ha senso
solo se subordinata alla cancellazione di un esperimento. Da cio si evince che le relazioni
1:n dovranno, invece, prevedere questa eventualita, come succede per la gestione delle
collaborazioni, delle leadership e delle milestone. Una funzione di tipo Del e strutturata
come segue:
function delCollaborations($params, $id) {
# costruisco la query sulla base del solo id, chiave primaria
CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 53
$query =
"DELETE
FROM ".$params["tablename"]."
WHERE cid = ".$id;
# eseguo la query
$result = mysql_query($query, $params["link_id"]) or die(mysql_error($params["link_id"]));
}
3.6 Struttura dell’output HTML
Ogni pagina e costituita da una struttura HTML statica, all’interno della quale e annegato
del codice server-side PHP. Il parsing di tale codice, ad opera del webserver, genera un
flusso di puro HTML, che va ad integrarsi con le linee non dinamiche ignorate dal parser
ed inviate direttamente al browser.
Figura 3.2: Webserver con PHP
La figura 3.2 mostra come il webserver interagisca con il modulo PHP per ottenere
codice HTML da restituire al browser, a cui questo processo e del tutto trasparente.
3.6.1 Validazione W3C
Cio che il browser riceve e puro codice HTML da interpretare e tradurre in schermate
grafiche. Questo implica che la generazione del flusso HTML rispetti delle regole di
semantica e, soprattutto, di sintassi, come e lecito attendersi da qualsiasi linguaggio, sia
esso compilato o interpretato. La famiglia di meta-linguaggi SGML, da cui deriva HTML,
utilizza file Document Type Definition (DTD) per la parte semantica e regole standard di
sintassi che restano invariate fra le varie versioni.
CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 54
Il DTD a cui fanno riferimento le pagine web di questa applicazione e stato rilasciato
dal W3C del C.E.R.N. per HTML versione 4.01 Transitional.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Questo significa che qualsiasi browser certificato per HTML 4.01 sara in grado di
interpretare e visualizzare correttamente le pagine web, indipendentemente dalla versione
o dal sistema operativo. Tutte le pagine sono sottoposte ad un processo di validazione,
mediante un servizio messo a disposizione dallo stesso C.E.R.N. in grado di certificare
on-the-fly la piena correttezza formale del codice ricevuto.
<a href="http://validator.w3.org/check/referer">
<img border="0"
src="http://www.w3.org/Icons/valid-html401"
alt="Valid HTML 4.01!" height="31" width="88">
</a>
Figura 3.3: HTML 4.01 compliant
Basta cliccare sull’immagine che appare in fondo ad ogni pagina per ottenere imme-
diatamente un rapporto sul codice della pagina stessa.
3.6.2 Componente client-side
Lo schema di una transazione fra webserver e browser prevede un ultimo passaggio, per
quanto riguarda la piena elaborazione di una pagina web e la successiva visualizzazio-
ne. Abbiamo visto come uno script PHP venga elaborato dal server per generare codice
HTML, sottolineando il fatto che questo aspetto e del tutto trasparente al browser, che
si comporta come un mero interprete di meta-linguaggi. Quest’ultimo passaggio, tipico
delle recenti versioni di HTML, prevede che una pagina sia in grado di modificare il pro-
prio stato (Behavior) anche dopo l’invio al client, poiche e il client stesso ad eseguire del
codice. Analogamente al PHP, questo codice, definito client-side, viene elaborato da un
interprete che interagisce con il browser per mostrare in tempo reale l’output generato da
un dato evento.
CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 56
Uno script puo includere sia codice server-side che codice client-side che codice HTML,
secondo la gerarchia di elaborazione che coinvolge il parser (PHP), il webserver, la virtual
machine (javascript) ed infine il browser (HTML).
Le applicazioni piu comuni di scripting client-side sono legate ad effetti DHTML (pa-
gine dinamiche) o controlli sui dati inseriti nelle form, eseguiti all’atto dell’invio. Questa
applicazione fa uso di entrambe le tipologie sia per lo sviluppo del menu che per le maschere
di inserimento. Quest’ultimo aspetto ha portato allo sviluppo di funzioni javascript anche
per limitare la quantita di dati inseribili nelle aree di testo, evitando cosı di sovraccaricare
il webserver, il database server ed in ultimo la rete.
Di seguito e riportato il codice javascript utilizzato nella pagina di inserimento relativa
allo spin-off, per limitare i dati inseribili ad una dimensione di 400 caratteri:
function textCounter(field, countfield, maxlimit) {
# Se i caratteri inseriti superano il limite,
# taglio quelli in eccesso
if (field.value.length > maxlimit) // if too long...trim it!
field.value = field.value.substring(0, maxlimit);
# altrimenti aggiorno il campo che mostra
# il numero di caratteri ancora inseribili
else
countfield.value = maxlimit - field.value.length;
}
Questa funzione viene attivata dall’attributo onKeyDown del TAG Textarea ogni qual
volta viene premuto un tasto.
<textarea name="SPINOFF[infn_exp]" cols="80" rows="4"
wrap="PHYSICAL" id="infn"
onKeyDown="textCounter(getElementById(’infn’), getElementById(’count1’), 400);"
onKeyUp="textCounter(getElementById(’infn’), getElementById(’count1’), 400);">
<?=$spinoff["infn_exp"]?>
</textarea>
Capitolo 4
Database
4.1 Database Management System
Un database e una collezione di dati che viene gestita e organizzata da un software spe-
cifico, il DBMS (Database Management System). Un DBMS e uno strato software che si
frappone tra utente e dati. Grazie a questo strato intermedio l’utente e le applicazioni
non accedono ai dati cosı come sono memorizzati effettivamente, ovvero, alla loro rappre-
sentazione fisica, ma ne vedono solamente una rappresentazione logica. Cio permette un
elevato grado di indipendenza fra le applicazioni e la memorizzazione fisica dei dati.
4.1.1 Definizione
Un DBMS, per essere considerato tale, deve avere determinate caratteristiche:
• Un DBMS e fatto per gestire grandi quantita di dati : convenzionalmente si puo in-
tendere che un gruppo di informazioni sia di grandi dimensioni quando questo non
possa essere contenuto tutto simultaneamente nella memoria centrale del compu-
ter. In generale un DBMS non dovrebbe porre limiti alle dimensioni, tranne quelle
imposte dai supporti fisici in cui devono essere memorizzate le informazioni.
• I dati devono poter essere condivisibili : l’idea che sta alla base dei sistemi di gestione
dei dati e quella di accentrare le informazioni in un unico sistema di amministrazione.
In questo senso e necessario che tali dati siano condivisibili da diverse applicazioni
e da diversi utenti.
57
CAPITOLO 4. DATABASE 58
• I dati devono essere persistenti e affidabili : i dati sono persistenti quando continua-
no a esistere dopo lo spegnimento della macchina con cui vengono elaborati; sono
affidabili quando gli eventi per cui si possono produrre alterazioni accidentali sono
estremamente limitati.
• L’accesso ai dati deve essere controllabile: dovendo trattare una grande mole di
dati in modo condiviso, e indispensabile che esistano dei sistemi di controllo degli
accessi, per evitare che determinate informazioni possano essere ottenute da chi non
e autorizzato, oppure che vengano modificate da chi non ne e il responsabile.
4.1.2 MySQL
MySQL e stato originariamente sviluppato dalla T.c.X. AB di Stoccolma per uso interno:
avevano bisogno di gestire database di grosse dimensioni in maniera estremamente veloce
e, non trovando nessun prodotto che facesse al loro caso, decisero di sviluppare una libreria
ISAM (Index Sequential Access Method) proprio per quello scopo.
Figura 4.1: Logo di MySQL
Nei primi anni ’90 la T.c.X. aggiunse un parser SQL alla propria libreria ISAM e fu
cosı che nacque MySQL come lo conosciamo noi oggi: un database relazionale che ha la
capacita di gestire tabelle di grosse dimensioni in modo estremamente veloce (la T.c.X.
afferma di utilizzare MySQL per gestire database le cui dimensioni sono dell’ordine di
centinaia di megabyte). La grande velocita di esecuzione di MySQL e frutto di una serie
di compromessi: non sono state implementate tutte quelle caratteristiche penalizzanti dal
punto di vista delle prestazioni.
Tra le features non implementate, spicca l’assenza della gestione delle transazioni e
delle viste su di una tabella, mentre e presente una gestione minimale dei lock (e possibile
mettere un lock soltanto su di una tabella e non sul singolo record della tabella). Sempre
per privilegiare la velocita d’esecuzione, molti comandi SQL presentano delle limitazioni:
il comando SELECT, ad esempio, non permette di effettuare delle sotto query utilizzando
in cascata piu comandi SELECT.
Nonostante tutto, alla T.c.X. lavorano sempre per aggiungere nuovi comandi SQL,
ampliare la sintassi di quelli esistenti ed implementare nuove caratteristiche, senza alcun
CAPITOLO 4. DATABASE 60
Figura 4.3: Architettura 2-tier thin client
un impatto negativo sulla velocita d’esecuzione. Un esempio di quanto appena affermato
e che la versione beta di MySQL supporta un nuovo gestore di tabelle a basso livello
(il Berkeley DB) che implementa una sofisticata gestione delle transazioni: anche se le
tabelle create da questo nuovo gestore non sono compatibili con l’implementazione attuale,
e comunque possibile utilizzare i due tipi di tabelle nella stessa query SQL, potendo cosı
godere dei vantaggi di entrambe. Di MySQL esistono distribuzioni contenenti i file binari,
pronti per l’installazione, e distribuzioni contenenti soltanto i file sorgenti.
4.2 Database utilizzato dall’applicazione
L’applicazione web dei Consuntivi 2004 utilizza un RDBMS con driver MySQL come
supporto di memorizzazione persistente. Trattandosi di un’architettura two tier non e
presente alcun livello applicativo fra il database layer ed il presentation layer costituiti
rispettivamente dal database server e dal web server.
4.2.1 Entita e relazioni
Il database e costituito da un numero di tabelle di entita, ottenute a partire dal raffina-
mento di un diagramma Entity-Relationship. Il nuovo db e stato progettato allo scopo di
ottimizzare la struttura gia presente, adattandola ai nuovi requisiti utente e rendendola
pienamente relazionale.
Di seguito sono riportate le tabelle di entita:
• Commissione: Ognuna delle 5 commissioni scientifiche nazionali ha un proprio re-
cord all’interno di questa tabella, in cui viene specificato il nome del presidente, il
suo indirizzo email ed una descrizione sull’attivita di ricerca della commissione.
• Esperimento: Questa tabella mantiene le informazioni relative agli esperimenti
I.N.F.N: partecipando ad una relazione n:1 con la tabella Commissione. Gli attribu-
ti di questa entita sono il nome dell’esperimento, il nome del responsabile nazionale,
il suo indirizzo email, la URL al logo e la URL alla home page
CAPITOLO 4. DATABASE 61
• Settore: Ogni esperimento conduce la propria attivita di ricerca all’interno di uno
specifico settore e questo si traduce in una relazione 1:n con l’entita Esperimento.
L’unico attributo di questa entita e il nome del settore
• Activity Report : Questa e la tabella d’entita principale, riguardo le informazioni
inserite sull’attivita scientifica svolta. E’ in relazione 1:1 con la tabella d’esperimento
ed ospita tutti i dati non strutturati inseribili direttamente dalla pagina dell’Brief
Report
• Collaborazione: In questa tabella sono salvati tutti i record relativi alle collaborazio-
ni avute, nell’ambito di un esperimento, con personale ed istituti esterni all’I.N.F.N o
strutture locali dell’istituto. Questa tabella e in relazione n:1 con la tabella d’entita
Esperimento
• Leadership: In questa tabella sono salvati tutti i record relativi ai ruoli di responsa-
bilita ricoperti dai ricercatori in un esperimento. Questa tabella e in relazione n:1
con la tabella d’entita Esperimento
• Milestone: Le milestone concordate o raggiunte da un esperimento sono salvate indi-
stintamente all’interno di questa tabella, con un attributo d’entita che le distingue.
Questa tabella e in relazione n:1 con la tabella d’entita Esperimento
• Internazionalizzazione: Questa tabella e utilizzata per salvare le informazioni relati-
ve alle collaborazioni internazionali in cui si inserisce un esperimento, esprimendo il
contributo finanziario e d’organico offerto dell’I.N.F.N. Questa tabella e in relazione
1:1 con l’entita Esperimento.
• Spin-Off : Entita che ospita tutti i dati relativi allo spin-off di un esperimento. Si
trova in relazione 1:1 con la tabella d’esperimento.
• Ricaduta: Qui sono specificati i campi che descrivono le future ricadute sul mondo
scientifico ed industriale, a partire dai risultati ottenuti da un esperimento.
Di seguito e riportato il diagramma Entita-Relazioni da cui si e partiti per ottenere
il database finale. Il gran numero di weak-entities e relazioni 1:1 ha fatto sı che molte
relazioni venissero inglobate all’interno delle stesse entita per evitare inutili e costose
operazioni di join nelle query di selezione.
CAPITOLO 4. DATABASE 63
4.3 Realizzazione del Database: Catalogo dei dati
Sulla base del modello E-R mostrato in figura 4.4, e stato creato il Database e le relative
tabelle, utilizzando front-end grafici e testuali di supporto alla progettazione. Sono di
seguito riportate le query SQL di creazione, e le relative tabelle create, mostrando in
dettaglio i tipi di attributo, le chiavi ed i vincoli.
4.3.1 Entita ActivityReport
CREATE TABLE ‘ActivityReport‘ (
‘sectid‘ int(3) unsigned NOT NULL default ’0’,
‘groupid‘ int(1) unsigned NOT NULL default ’0’,
‘expid‘ int(6) unsigned NOT NULL default ’0’,
‘linea\_ric\_code‘ int(2) default NULL,
‘linea\_ricerca‘ varchar(80) default NULL,
‘status‘ varchar(4) default NULL,
‘exp\_start‘ int(4) NOT NULL default ’0’,
‘exp\_duration‘ int(3) NOT NULL default ’0’,
‘lab\_beam‘ text,
‘goal‘ text,
‘activity‘ text,
‘infn\_contrib\_mp‘ text,
‘infn\_contrib\_bud‘ text,
‘infn\_contrib\_fte‘ int(5) default NULL,
‘infn\_contrib\_ric‘ int(5) unsigned default NULL,
‘inno\_instr‘ text,
‘esp\_compet‘ text,
‘int\_committee‘ text,
‘relazione\_comm‘ text,
‘summary‘ text,
‘descrizione‘ text,
‘n\_tot\_talks‘ int(5) NOT NULL default ’0’,
‘n\_ruoli\_infn‘ int(4) NOT NULL default ’0’,
‘n\_ruoli\_tot‘ int(5) NOT NULL default ’0’,
‘convalida‘ int(1) default NULL,
‘conv_date‘ date default NULL,
‘datamod‘ timestamp(14) NOT NULL,
CAPITOLO 4. DATABASE 64
‘ip‘ varchar(15) default NULL,
‘remote_user‘ varchar(80) default NULL,
PRIMARY KEY (‘sectid‘,‘groupid‘,‘expid‘)
) TYPE=MyISAM;
4.3.2 Entita Collaborazione
CREATE TABLE ‘Collaborazione‘ (
‘collid‘ int(6) unsigned NOT NULL auto_increment,
‘expid‘ int(6) unsigned NOT NULL default ’0’,
‘sectid‘ int(3) unsigned NOT NULL default ’0’,
‘groupid‘ int(1) unsigned NOT NULL default ’0’,
‘sezione‘ varchar(80) default NULL,
‘istituto‘ varchar(255) NOT NULL default ’’,
‘tipo‘ tinyint(1) NOT NULL default ’0’,
‘nazione‘ varchar(80) NOT NULL default ’’,
‘note‘ longtext NOT NULL,
‘data_mod‘ timestamp(14) NOT NULL,
‘ip‘ varchar(15) NOT NULL default ’’,
‘remote_user‘ varchar(80) NOT NULL default ’’,
PRIMARY KEY (‘collid‘,‘expid‘,‘sectid‘,‘groupid‘)
) TYPE=MyISAM AUTO_INCREMENT=6 ;
4.3.3 Entita Commissione
CREATE TABLE ‘Commissione‘ (
‘groupid‘ int(1) unsigned NOT NULL default ’0’,
‘presidente‘ varchar(30) NOT NULL default ’’,
‘email‘ varchar(50) NOT NULL default ’’,
‘descrizione‘ text,
PRIMARY KEY (‘groupid‘)
) TYPE=MyISAM;
4.3.4 Entita Esperimento
CREATE TABLE ‘Esperimento‘ (
CAPITOLO 4. DATABASE 68
‘expid‘ int(6) unsigned NOT NULL auto_increment,
‘groupid‘ int(1) unsigned NOT NULL default ’0’,
‘sectid‘ int(3) unsigned NOT NULL default ’0’,
‘sigla_exp‘ varchar(20) NOT NULL default ’’,
‘email_resp‘ varchar(50) NOT NULL default ’’,
‘logo‘ varchar(80) NOT NULL default ’’,
‘home_page_url‘ varchar(80) NOT NULL default ’’,
‘datamod‘ timestamp(14) NOT NULL,
‘ip‘ varchar(15) NOT NULL default ’’,
‘remote_user‘ varchar(80) NOT NULL default ’’,
PRIMARY KEY (‘expid‘,‘groupid‘,‘sectid‘)
) TYPE=MyISAM AUTO_INCREMENT=6 ;
4.3.5 Entita Internazionalizzazione
CREATE TABLE ‘Internazionalizzazione‘ (
‘expid‘ int(6) unsigned NOT NULL default ’0’,
‘sectid‘ int(3) unsigned NOT NULL default ’0’,
‘groupid‘ int(1) unsigned NOT NULL default ’0’,
‘tot_ric‘ int(5) NOT NULL default ’0’,
‘ric_firm‘ int(5) NOT NULL default ’0’,
‘pub_int‘ int(5) NOT NULL default ’0’,
‘tot_pub‘ int(5) NOT NULL default ’0’,
‘perc_imp_fin‘ int(3) NOT NULL default ’0’,
‘data_mod‘ timestamp(14) NOT NULL,
‘ip‘ varchar(15) NOT NULL default ’’,
‘remote_user‘ varchar(80) NOT NULL default ’’,
PRIMARY KEY (‘expid‘,‘sectid‘,‘groupid‘)
) TYPE=MyISAM;
4.3.6 Entita Leadership
CREATE TABLE ‘Leadership‘ (
‘lid‘ int(6) NOT NULL auto_increment,
‘sectid‘ int(3) unsigned NOT NULL default ’0’,
‘groupid‘ int(1) unsigned NOT NULL default ’0’,
CAPITOLO 4. DATABASE 71
‘expid‘ int(6) unsigned NOT NULL default ’0’,
‘nome‘ varchar(80) NOT NULL default ’’,
‘cognome‘ varchar(80) NOT NULL default ’’,
‘tipo_ruolo‘ varchar(80) NOT NULL default ’’,
‘incarico‘ varchar(80) NOT NULL default ’’,
‘settore_tipo‘ varchar(80) NOT NULL default ’’,
‘data_mod‘ timestamp(14) NOT NULL,
‘ip‘ varchar(15) NOT NULL default ’’,
‘remote_user‘ varchar(80) NOT NULL default ’’,
PRIMARY KEY (‘lid‘,‘sectid‘,‘groupid‘,‘expid‘)
) TYPE=MyISAM AUTO_INCREMENT=6 ;
4.3.7 Entita Milestone
CREATE TABLE ‘Milestone‘ (
‘milid‘ int(3) unsigned NOT NULL auto_increment,
‘sectid‘ int(3) unsigned NOT NULL default ’0’,
‘groupid‘ int(1) unsigned NOT NULL default ’0’,
‘expid‘ int(6) unsigned NOT NULL default ’0’,
‘data‘ date NOT NULL default ’0000-00-00’,
‘idass_mil‘ int(6) default NULL,
‘idmil_o‘ int(6) default NULL,
‘data_str‘ varchar(80) default NULL,
‘descrizione‘ varchar(255) NOT NULL default ’’,
‘percentuale‘ int(3) NOT NULL default ’0’,
‘commento‘ varchar(255) default NULL,
‘data_mod‘ timestamp(14) NOT NULL,
‘ip‘ varchar(15) NOT NULL default ’’,
‘remote_user‘ varchar(80) NOT NULL default ’’,
‘tipo_mil‘ int(1) unsigned default NULL,
PRIMARY KEY (‘milid‘)
) TYPE=MyISAM AUTO_INCREMENT=6 ;
4.3.8 Entita Ricaduta
CREATE TABLE ‘Ricaduta‘ (
CAPITOLO 4. DATABASE 74
‘sectid‘ int(3) unsigned NOT NULL default ’0’,
‘groupid‘ int(1) unsigned NOT NULL default ’0’,
‘expid‘ int(6) unsigned NOT NULL default ’0’,
‘ric_campo‘ varchar(80) NOT NULL default ’’,
‘nuovo_prod‘ varchar(80) NOT NULL default ’’,
‘altri_exp‘ varchar(80) NOT NULL default ’’,
‘exp1‘ varchar(80) NOT NULL default ’’,
‘exp2‘ varchar(80) NOT NULL default ’’,
‘altre_discip‘ varchar(80) NOT NULL default ’’,
‘osp1‘ varchar(80) NOT NULL default ’’,
‘osp2‘ varchar(80) NOT NULL default ’’,
‘industria‘ varchar(80) NOT NULL default ’’,
‘ind1‘ varchar(80) NOT NULL default ’’,
‘ind2‘ varchar(80) NOT NULL default ’’,
‘medicali‘ tinyint(4) NOT NULL default ’0’,
‘beni_cult‘ tinytext NOT NULL,
‘industriali‘ tinyint(4) NOT NULL default ’0’,
‘data_mod‘ timestamp(14) NOT NULL,
‘ip‘ varchar(15) NOT NULL default ’’,
‘remote_user‘ varchar(80) NOT NULL default ’’,
PRIMARY KEY (‘sectid‘,‘groupid‘,‘expid‘)
) TYPE=MyISAM;
4.3.9 Entita Settore
CREATE TABLE ‘Settore‘ (
‘sectid‘ int(3) unsigned NOT NULL auto_increment,
‘settore‘ varchar(200) NOT NULL default ’’,
PRIMARY KEY (‘sectid‘)
) TYPE=MyISAM AUTO_INCREMENT=6 ;
4.3.10 Entita Spin off
CREATE TABLE ‘Spin_off‘ (
‘sectid‘ int(3) unsigned NOT NULL default ’0’,
‘infn_exp‘ text,
CAPITOLO 4. DATABASE 77
‘groupid‘ int(1) unsigned NOT NULL default ’0’,
‘expid‘ int(6) unsigned NOT NULL default ’0’,
‘discip_scient‘ text NOT NULL,
‘appl_res‘ text NOT NULL,
‘data_mod‘ timestamp(14) NOT NULL,
‘ip‘ varchar(15) NOT NULL default ’’,
‘remote_user‘ varchar(80) NOT NULL default ’’,
PRIMARY KEY (‘sectid‘,‘groupid‘,‘expid‘)
) TYPE=MyISAM;
4.4 Esempi di inserimento
Sono di seguito riportati alcuni esempi di inserimento per mostrare la struttura finale dei
record, generati dall’applicazione in fase di presa dati. Si tratta di schermate tratte da
un front-end grafico basato su web, largamente diffuso ed open-source: PhpMyAdmin
4.5 Struttura precedente
La differenza principale fra il nuovo database, e quello in uso fino al 2003, sta nella
strutturazione di molti tipi di dato sulla base di un modello relazionale. Questo ha
permesso di modificare la cardinalita di molte relazioni da un modello 1:1 (dati aggregati
ed indistinguibili) ad uno 1:n (dati separati in record) favorendo una piu netta distinzione
fra le entita e semplificando la consultazione. Il modello di riferimento per il vecchio DB
era prettamente monolitico, con una singola tabella e tutte le relazioni (esclusivamente
1:1) incluse in essa. Dati che, ora, sono strutturati e relazionati a dovere, erano semplici
righe all’interno di un’area di testo rendendo praticamente impossibile o inaffidabile ogni
genere di statistica. Per fare un esempio, la nuova struttura di inserimento delle milestone
e basata su una tabella di entita in relazione n:1 con la tabella degli esperimenti ed esprime
in dettaglio (in campi separati) tutte le voci relative alla milestone. La vecchia struttura
aveva una pagina di inserimento di questo tipo:
Come mostrato in figura 4.25, non era assolutamente possibile distinguere la data,
dal testo, dalla percentuale di raggiungimento o addirittura una milestone dall’altra. Un
procedimento analogo e stato previsto anche per le collaborazioni, i ruoli di leadership,
le pubblicazioni, le tesi e le conferenze, snellendo la tabella principale di informazioni di
non diretta competenza con l’entita esperimento.