Progettazione di un sistema informativo per la valorizzazione e la

Università degli Studi di Bari 'Aldo Moro'
Dipartimento Interateneo di Fisica “Michelangelo Merlin”
Master II livello
“METODOLOGIE E TECNOLOGIE PER LO SVILUPPO DI INFRASTRUTTURE DIGITALI”
______________________________________________________________________
Progettazione di un sistema informativo per la valorizzazione e la gestione delle
informazioni relative ad una collezione di marmi antichi
Relatori: Ing. Alberto Scalise
Prof. Luigi Schiavulli
Formanda: Emanuela Delluniversità
A.A. 2013-2014
INDICE
INTRODUZIONE .................................................................................................................... 2
1. SISTEMI INFORMATIVI E SISTEMI INFORMATICI ................................................. 3
1.1 BASI DI DATI E DBMS ..................................................................................................... 4
1.2 PROGETTAZIONE DI BASI DI DATI .............................................................................. 6
1.3 FASI DELLA PROGETTAZIONE DI UNA BASE DI DATI..................................... 8
1.4 IL MODELLO ENTITÀ-RELAZIONE ........................................................................ 10
1.5 I MODELLI LOGICI ........................................................................................................ 13
1.6 MODELLI FISICI .............................................................................................................. 15
1.7 STRATEGIE DI PROGETTAZIONE ........................................................................... 15
2. LAMP ..................................................................................................................................... 16
2.1 APACHE ............................................................................................................................. 17
2.2 MySQL ................................................................................................................................. 17
2.3 PHP ...................................................................................................................................... 18
2.4 MYSQL WORKBENCH ................................................................................................... 19
3. PROGETTAZIONE DEL SISTEMA INFORMATIVO ............................................... 21
3.1 RICHIESTA DELLA COMMITTENZA........................................................................ 22
3.2 I REQUISITI UTENTE .................................................................................................... 23
3.3 UML ..................................................................................................................................... 26
3.4 ATTORI............................................................................................................................... 26
3.5 USE CASE ........................................................................................................................... 28
3.6 DIAGRAMMI DELLE ATTIVITÀ ................................................................................. 31
3.7 PROGETTAZIONE DATABASE RELAZIONALE .................................................. 32
TABELLA DELLE ENTITÀ ................................................................................................. 33
TABELLA DELLE RELAZIONI .......................................................................................... 34
MODELLO ENTITÀ-RELAZIONE.................................................................................... 35
MODELLO LOGICO ............................................................................................................. 35
MODELLO FISICO ................................................................................................................ 37
APPENDICE – SCRIPT MySQL ........................................................................................... 38
BIBLIOGRAFIA ...................................................................................................................... 48
INTRODUZIONE
Questa tesi rappresenta la fase conclusiva del master di II livello in “Metodologie e
Tecnologie per lo sviluppo di infrastrutture digitali”. Alle ottocento ore di lezioni frontali
sono seguite centoventi ore di stage svolte presso l'ENEA Centro di Ricerche di Brindisi.
Durante il tirocinio è stato possibile approfondire alcune delle materie trattate durante le
ore di lezione e nello specifico sui DBMS.
È stato possibile soffermarsi in particolare sugli aspetti attinenti alla progettazione di un
database relazionale e ripercorrere tutte le fasi necessarie per la realizzazione del progetto.
L'elaborato consiste in un sunto dell'attività svolta e degli argomenti trattati, in particolare
partendo dalle definizioni di sistema informativo e sistema informatico si passa alle
descrizione del ciclo di vita di un sistema informativo. Questo rappresenta il punto di avvio
del lavoro nel quale sono stati affrontati l'analisi dei requisiti, la fase di progettazione e in
parte quella di implementazione di un database relazionale per un'istituzione che richiede
tale progettazione per tutelare e valorizzare una collezione di marmi antichi e tutta una serie
di informazioni raccolte su di essa.
Nella prima parte dell'elaborato si ripercorrono gli aspetti teorici relativi ai principali
modelli impiegati nella progettazione di un database, ovvero quello concettuale, logico e
fisico e a seguire vengono illustrati i principali tool impiegati per la realizzazione del
database. Nella seconda parte viene illustrato il caso di studio preso in considerazione
facendo riferimento al linguaggio di modellazione UML. Il lavoro si conclude con la
presentazione dei modelli realizzati e quindi della struttura del database che rappresenta il
fulcro del sistema informativo progettato.
2
1. SISTEMI INFORMATIVI E SISTEMI INFORMATICI
In generale nello svolgimento di un'attività, sia che avvenga a livello individuale e sia
che coinvolga un'organizzazione di grandi dimensioni, risultano essenziali la disponibilità
delle informazioni e la capacità di gestirle in modo efficace. L’informazione è la principale
risorsa scambiata, selezionata ed elaborata nelle attività gestionali di coordinamento e
controllo di una generica organizzazione. Essa è una risorsa immateriale e non tangibile, ma
per esistere nel mondo reale, deve essere rappresentata in modo fisico e tale
rappresentazione in termini fisici è costituita dai dati. I dati rappresentano materiale
informativo non elaborato ma immediatamente disponibile per costruire i processi
comunicativi ma, presi singolarmente, non hanno alcun significato e affinché siano in grado
di fornire informazioni è necessario interpretarli e correlarli opportunamente. Per essere
utili i dati devono essere organizzati, archiviati e classificati in modo da essere facilmente
reperibili.
Il sistema informativo di un'organizzazione può essere definito come la
combinazione di risorse umane, risorse tecnologiche e procedure organizzate il cui compito
è quello di produrre e conservare le informazioni necessarie per perseguire gli scopi
dell'organizzazione stessa. L'esistenza di un sistema informativo è in parte indipendente
dalla sua automatizzazione e, per indicarne la relativa componente automatizzata, viene di
solito utilizzato il termine sistema informatico.
Uno dei principali compiti dei sistemi informatici è rappresentato dalla combinazione di
attività di raccolta, organizzazione e conservazione dei dati. In generale un sistema
informatico può essere definito come l’insieme degli strumenti informatici utilizzati per il
trattamento automatico delle informazioni, al fine di agevolare le funzioni del sistema
informativo. Per mezzo dei sistemi informatici i dati vengano conservati in modo
permanente sui dispositivi necessari per la loro memorizzazione, aggiornati per conoscere
rapidamente le loro variazioni e resi accessibili alle interrogazioni degli utenti. Nello
sviluppo di sistemi informatici vengono impiegate numerose tecnologie che vanno
utilizzate in modo combinato e tra queste si individuano i sistemi di gestione di basi di
dati1.
1
ATZENI P., CERI S., PARABOSCHI S., TORLONE R., Basi di dati Modelli e linguaggi di interrogazione, 2/ed.
McGraw-Hill, Milano, 2006, pp. 1-3.
3
1.1 BASI DI DATI E DBMS
Una base di dati è una collezione di dati utilizzati per rappresentare le informazioni
di interesse per un sistema informativo. Tali insiemi di dati costituiscono solo una delle
componenti di un sistema informativo che tipicamente include anche i programmi
applicativi, le interfacce con l'utente e altri programmi di servizio.
Un database management system (DBMS) è una collezione di programmi che
consente agli utenti di creare e mantenere un database, consiste quindi in un sistema
software general-purpose che facilita i processi di definizione, costruzione, manipolazione e
condivisione dei database tra i vari utenti e applicazioni. La definizione di un database
richiede la specificazione dei tipi di dati, delle strutture e dei vincoli dei dati da memorizzare
nel database. La costruzione del database è il processo di memorizzazione dei dati su un
supporto di memorizzazione che è controllato dal DBMS. Manipolare un database
comprende funzioni come: fare delle richieste al database per recuperare dati specifici,
aggiornamento del database e generazione di report dei dati. Infine la condivisione di un
database consente a più utenti e programmi di accedere al database contemporaneamente.
Un DBMS garantisce anche la sicurezza e l’integrità del database. Ogni transazione, infatti,
ossia ogni sequenza di operazioni che hanno un effetto globale sul database gode delle
cosiddette proprietà ACID:
• “A” sta per Atomicity (Atomicità), ossia se tutte le operazioni della sequenza terminano
senza riscontrare anomalie si ha il commit e la transazione è conclusa con successo, ma, se
anche solo una di queste operazioni fallisce, l’intera transazione è abortita (rollback);
• “C” sta per Consistency (Consistenza), ovvero ogni transazione, una volta conclusa, deve
lasciare il database in uno stato consistente;
• “I” sta per Isolation (Isolamento), ossia nel caso di esecuzione di transazioni concorrenti,
non ci deve essere influenzamento dell’una sulle altre;
• “D” sta per Durability (Durabilità), ovverossia gli effetti sul database prodotti da una
transazione terminata con successo sono permanenti, quindi non possono essere
compromessi da eventuali malfunzionamenti.
I DBMS sono caratterizzati da linguaggi per la gestione dei dati; le principali
tipologie di linguaggi sono le seguenti:
- DDL (Data Definition Language) necessario per definire e costruire le strutture
dei dati. Viene utilizzato per creare la struttura fisica del database e la definizione dei
sottoschemi relativi alle applicazioni definite nel programma;
4
- DML (Data Manipulation Language) è un linguaggio che serve per la gestione dei
dati contenuti nel database2.
I DBMS più diffusi sono i Relational Database Management System o RDBMS, che
offrono servizi di archiviazione e recupero dati basati sul modello relazionale dei dati
proposto da E. F. Codd nel 1970. Un RDBMS archivia le informazioni in tabelle di righe e
colonne.
Ciascuna colonna di una tabella di database contiene un tipo differente di
attributo, mentre ciascuna riga corrisponde a un singolo record. Il modello relazionale è un
concetto intuitivo di un database che può essere facilmente interrogato utilizzando un
meccanismo chiamato linguaggio di interrogazione (query language) per recuperare,
aggiornare e inserire i dati. Il meccanismo di interrogazione più comunemente usato è lo
Structured Query Language (SQL), che assomiglia al linguaggio naturale e che costituisce
una parte fondamentale nell’applicazione pratica del modello relazionale in un RDBMS.
In generale i sistemi di database relazionali forniscono un’indipendenza robusta dei
dati e l'astrazione di essi3.
2
ELMASRI RAMEZ A., NAVATHE SHAMKANT B., Sistemi di basi di dati. Fondamenti. Pearson Education Italia,
2007, pp. 30-32.
3
ATZENI P., CERI S., PARABOSCHI S., TORLONE R., Basi di dati Modelli e linguaggi di interrogazione, 2/ed.
McGraw-Hill, Milano, 2006, pp. 3-11.
5
1.2 PROGETTAZIONE DI BASI DI DATI
Progettare una base di dati significa definirne la struttura, le caratteristiche ed il
contenuto, ovvero si tratta di un insieme di operazioni durante le quali verranno assunte
molteplici decisioni strategiche per decidere quali sono le opportune metodologie da
impiegare per la realizzazione di un prodotto valido.
La progettazione di una base di dati costituisce solo una delle componenti del
processo di sviluppo di un sistema informativo complesso e va quindi inquadrata in un
contesto più ampio, quello del ciclo di vita dei sistemi informativi. Le fasi di vita di un
sistema informativo sono riportate in figura (Fig. 1).
Figura 1: Ciclo di vita di un sistema informativo
Studio di fattibilità: In questa fase si analizzano sommariamente i requisiti del sistema
informativo e si valutano le possibili scelte in termini tecnologici ed economici per la
realizzazione del sistema.
È uno studio atto a definire, in maniera per quanto possibile precisa, i costi delle varie
alternative possibili e a stabilire le priorità di realizzazione delle varie componenti del
sistema.
Raccolta e analisi dei requisiti: In questa fase vengono raccolte ed analizzate nel
dettaglio tutte le richieste del committente ed i requisiti che il sistema informativo deve
6
soddisfare. Si definiscono quali dati devono essere memorizzati e quali operazioni e
applicazioni occorre sviluppare per l’accesso e la gestione dei dati.
Progettazione: Sulla base dei requisiti espressi nella fase precedente in questa fase avviene
la progettazione del sistema in tutte le sue componenti, dalla base di dati ai programmi
applicativi.
Si divide generalmente in progettazione dei dati e progettazione delle applicazioni. Nella
prima si individua la struttura e l'organizzazione che i dati dovranno avere, nell'altra si
definiscono le caratteristiche dei programmi applicativi. Le due attività sono complementari
e possono procedere in parallelo o in cascata. Le descrizioni dei dati e delle applicazioni
prodotte in questa fase sono formali e fanno riferimento a specifici modelli.
Implementazione: In questa fase, sulla base delle specifiche progettuali, viene creata e
popolata la base di dati e vengono implementati i programmi applicativi.
Validazione e collaudo: In questa fase il sistema nel suo complesso viene sottoposto a
test di funzionalità e prestazionali. E’ la parte che si occupa di verificare il corretto
funzionamento e la qualità del sistema informativo, cercando di prevedere tutte le possibili
condizioni operative.
Funzionamento: In questa fase il sistema entra in produzione ed avvia i suoi servizi.
È necessario precisare che il processo non è quasi mai strettamente sequenziale in quanto
spesso, durante l'esecuzione di una delle attività citate, bisogna rivedere decisioni prese
nell'attività precedente. Si ottiene pertanto un ciclo di operazioni4.
4
ATZENI P., CERI S., PARABOSCHI S., TORLONE R., Basi di dati Modelli e linguaggi di interrogazione, 2/ed.
McGraw-Hill, Milano, 2006, pp. 199-202.
7
1.3 FASI DELLA PROGETTAZIONE DI UNA BASE DI DATI
Si è consolidata negli anni nell'ambito delle basi di dati una metodologia di progetto
articolata in tre fasi principali da effettuare in cascata che si fonda su un principio
dell'ingegneria: separare in maniera netta le decisioni relative a "cosa" rappresentare in una
base di dati (prima fase), da quelle relative a "come" farlo (seconda e terza fase). Le tre fasi
principali che si susseguono nella progettazione di una base di dati sono:
•
la progettazione concettuale;
•
la progettazione logica;
•
la progettazione fisica.
Nella progettazione concettuale e nella progettazione logica vengono utilizzati i modelli,
rispettivamente concettuale e logico, i quali forniscono gli strumenti per realizzare la
progettazione.
Nella progettazione fisica si decidono quali strutture dati utilizzare e come organizzare
fisicamente i dati al fine di rendere efficienti le operazioni.
La progettazione concettuale ha quale finalità quella di rappresentare le specifiche
informali della realtà di interesse in termini di una descrizione informale e completa, ma
indipendente dai criteri di rappresentazione utilizzati nei sistemi di gestione di basi di dati.
Il prodotto di questa fase viene chiamato schema concettuale e fa riferimento a un modello
concettuale dei dati. I modelli concettuali consentono di descrivere l'organizzazione dei dati
a un alto livello di astrazione, senza tenere conto degli aspetti implementativi. In questa
fase, infatti, si cerca di rappresentare il contenuto informativo della base di dati senza
preoccuparsi né delle modalità con le quali queste informazioni verranno codificate in un
sistema reale, né dell'efficienza dei programmi che faranno uso di queste informazioni.
L'input di questa prima fase è rappresentato dall’insieme delle specifiche sui dati e utilizza
un modello concettuale, in questo caso il modello Entity-Relationship (E-R), per produrre
uno schema concettuale della base di dati rappresentato mediante un diagramma grafico.
Tale diagramma, insieme ad altra documentazione, viene fornito come input alla
progettazione logica.
La progettazione logica consiste nella traduzione dello schema concettuale definito
nella fase precedente, nel modello di rappresentazione dei dati adottata dal sistema di
gestione di base di dati a disposizione e per fare ciò utilizza il modello logico relazionale. Il
prodotto di questa fase viene denominato schema logico della base di dati e fa riferimento a
8
un modello logico dei dati. Un modello di questo tipo consente di descrivere i dati
secondo una rappresentazione ancora indipendente da dettagli fisici, ma concreta perché
disponibile nei sistemi di gestione di base di dati.
Nella fase della progettazione fisica, lo schema logico viene completato con la
specifica dei parametri fisici di memorizzazione dei dati. Il prodotto di questa fase viene
denominato schema fisico e fa riferimento a un modello fisico dei dati. Tale modello
dipende dallo specifico sistema di gestione di basi di dati scelto e si basa sui criteri di
organizzazione fisica dei dati in quel sistema. In questa fase, anche tenendo conto degli
apparati hardware a disposizione, si definiscono quali strutture fisiche utilizzare per
l’implementazione della base di dati.
In generale, il risultato della progettazione di una base di dati non è solo lo schema
fisico, ma è costituito anche dallo schema concettuale e dallo schema logico. Lo schema
concettuale fornisce una rappresentazione della base di dati di alto livello, che può essere
molto utile a scopo documentativo, mentre lo schema logico fornisce una descrizione
concreta del contenuto della base di dati che, prescindendo dagli aspetti implementativi,
può essere utile come riferimento per le operazioni di interrogazione e aggiornamento.
A partire da requisiti rappresentati da documenti e moduli di vario genere, acquisiti anche
attraverso l'interazione con gli utenti, viene costruito uno schema Entità-Relazione che
descrive a livello concettuale la base di dati. Questa rappresentazione viene poi tradotta in
uno schema relazionale, costituito da una collezione di tabelle. Infine, i dati vengono
descritti da un punto di vista fisico (tipo e dimensioni dei campi) e vengono specificate
strutture ausiliarie, per l'accesso efficiente ai dati5.
5
ATZENI P., CERI S., PARABOSCHI S., TORLONE R., Basi di dati Modelli e linguaggi di interrogazione, 2/ed.
McGraw-Hill, Milano, 2006, pp. 202-206.
9
1.4 IL MODELLO ENTITÀ-RELAZIONE
Il modello Entità-Relazione è stato proposto nella metà degli anni ’70 come
strumento per la progettazione delle basi di dati da P. Chen e si è ormai affermato come
standard di riferimento nelle metodologie di progetto di basi di dati e negli strumenti di
ausilio alla progettazione di sistemi informativi. Tale modello prescinde dal sistema fisico
che verrà utilizzato per gestire la base di dati e prescinde dal modello logico con cui si
vogliono rappresentare i dati. Questo consente di concentrarsi sull’analisi delle specifiche
utente senza dover considerare i dettagli implementativi e le strutture fisiche (strutture dati)
e logiche (relazione e tabelle) che dovranno essere utilizzate per l’implementazione del
sistema.
Il modello E-R fornisce una serie di strutture, dette costrutti (Fig. 2), atte a descrivere la
realtà di interesse in una maniera facile da comprendere e che prescinde dai criteri di
organizzazione dei dati nei calcolatori. Questi costrutti vengono utilizzati per definire
schemi che descrivono l'organizzazione e la struttura delle occorrenze dei dati, ovvero, dei
valori assunti dai dati al variare del tempo.
10
Figura 2: Costrutti del modello E-R
I costrutti principali di questo modello sono: le entità, le relazioni e gli attributi.
Entità: Rappresentano classi di oggetti (fatti, cose, persone, per esempio) che hanno
proprietà comuni ed esistenza "autonoma" ai fini dell'applicazione di interesse. Ogni entità
viene rappresentata graficamente da un rettangolo con un nome all’interno che la identifica
univocamente.
Relazioni: Rappresentano legami logici tra due o più entità, significativi per l'applicazione
di interesse. In uno schema E-R, ogni relazione ha un nome che la identifica univocamente
e viene rappresentata graficamente mediante un rombo con il nome della relazione
all'interno, e da linee che connettono la relazione con ciascuna delle sue componenti.
Attributi: Descrivono le proprietà elementari di entità o relazioni che sono di interesse ai
fini dell'applicazione. Un attributo ha un nome, una cardinalità minima e massima, e
11
appartiene a un concetto di base, ovvero a una entità o a una relazione. Un sottoinsieme
degli attributi sono gli attributi composti, che si compongono di uno o più attributi.
Le cardinalità delle relazioni vengono specificate per ciascuna partecipazione di entità a una
relazione e descrivono il numero minimo e massimo di occorrenze di relazione a cui una
occorrenza dell'entità può partecipare. Dicono quindi quante volte, in una relazione tra
entità, un'occorrenza di una di queste entità può essere legata a occorrenze delle altre entità
coinvolte.
Per definire la cardinalità si utilizzano tre valori: zero, uno e il simbolo N (che indica
genericamente un intero maggiore di uno).
Il valore della cardinalità minima può essere zero o uno, nel primo caso si dice che la
partecipazione dell'entità relativa è opzionale, nel secondo si dice che la partecipazione è
obbligatoria.
Il valore della cardinalità massima può essere uno o molti (N), nel primo caso la
partecipazione dell'entità relativa può essere vista come una funzione (parziale se la
cardinalità minima vale zero) che associa a una occorrenza dell'entità una sola occorrenza
(o nessuna) dell'altra entità che partecipa alla relazione; nel secondo c'è invece una
associazione con un numero arbitrario di occorrenze dell'altra entità.
Per ciascuna entità di uno schema vengono specificati gli identificatori delle entità che
descrivono i concetti (attributi e/o entità) dello schema e permettono di identificare in
maniera univoca le occorrenze delle entità.
Le generalizzazioni rappresentano legami logici tra un’entità detta entità genitore ed una o
più entità dette entità figlie, in cui l'entità genitore generalizza e comprende tutte le sue
discendenti logicamente attinenti6.
Le specializzazioni definiscono un insieme di sottoclassi di un tipo di entità e questo tipo di
entità prende il nome di superclasse della specializzazione7.
6
ATZENI P., CERI S., PARABOSCHI S., TORLONE R., Basi di dati Modelli e linguaggi di interrogazione, 2/ed.
McGraw-Hill, Milano, 2006, pp. 206-220.
7
ELMASRI RAMEZ A., NAVATHE SHAMKANT B., Sistemi di basi di dati. Fondamenti. Pearson Education Italia,
2007, p. 78.
12
1.5 I MODELLI LOGICI
I modelli logici forniscono dei concetti che possono essere compresi dagli utenti
finali ma, allo stesso tempo, sono sufficientemente simili a quella che è l’organizzazione dei
dati all’interno di un calcolatore. Tra i modelli logici si distinguono:
• Il Modello Gerarchico
• Il Modello Reticolare
• Il Modello Relazionale
Il modello gerarchico è stato uno dei primi modelli utilizzati per la gestione di un
database. In questo modello per ciascun dato viene costituito un record formato da tutti i
suoi attributi, tra i quali viene poi scelta una chiave (che servirà da identificatore per i vari
record). Tale modello si basa su una struttura di tipo gerarchico, dove secondo uno schema
grafico ad albero si ritiene che ci siano dei dati che abbiano una posizione gerarchica più
elevata rispetto ad altri. Il limite maggiore di questo modello è dato proprio dalla rigidità
della struttura la quale molte volte non riesce a evitare delle ridondanze tra i dati.
Il modello reticolare può essere visto come la generalizzazione del modello
gerarchico anche se non si basa su una struttura ad albero e i record che contengono gli
attributi possono essere collegati in più modi mediante dei set. In questo modello viene
eliminato il problema della duplicazione dei dati.
Il modello relazionale che fu introdotto nel 1970 da Ted Codd e basa il suo
fondamento teorico nella teoria degli insiemi e nella logica dei predicati del primo ordine è
attualmente il modello di dati più diffuso. Esso rappresenta la base di dati come una
collezione di relazioni, le quali vengono poi rappresentate mediante delle tabelle. Ogni riga
(tupla) di queste tabelle rappresenta una collezione di valori di dati collegati, mentre ogni
colonna (attributo) sarà formato dallo stesso tipo di dati. Il tipo di dato che definisce i
valori possibili per una colonna è detto dominio.
Alcune delle caratteristiche principali del modello relazionale sono:
• Ogni riga della tabella è caratterizzata dallo stesso numero di colonne, ciascuna delle quali
corrisponde allo stesso tipo di attributo;
• L’attributo è un informazione che non può essere scomposta ulteriormente;
• Il valore di ciascun campo deve appartenere al dominio dei valori possibili di quella
colonna;
• Non ha significato l’ordine con il quale le tuple vengono introdotte nella tabella;
13
• Non possono esistere righe uguali, ognuna deve differenziarsi almeno per un valore da
tutte le altre.
Le tabelle nel modello relazionale possono essere collegate tramite tre tipi di relazione:
Uno a molti (1:N): E’ una relazione in cui ad ogni elemento di una tabella si possono far
corrispondere molti elementi di altre tabelle.
Molti a molti (N:N): Una relazione di questo tipo si ha quando a più record di una tabella
corrispondono più record di un’altra tabella e viceversa.
Uno a uno (1:1): In questo caso a ciascun record di una tabella corrisponde uno ed un solo
record di un'altra.
Le operazioni che possono essere svolte su una base di dati relazionale si possono
suddividere in interrogazioni ed aggiornamenti; le operazioni di aggiornamento sono
formate da inserimento, cancellazione e modifica dei dati. Quando vengono eseguite queste
operazioni non devono venire violati i vincoli specificati nello schema della base di dati
relazionale.
I vincoli del modello relazionale rappresentano le varie restrizioni sui dati che possono
essere specificate su uno schema di base di dati relazionale, e si possono distinguere in
vincoli di dominio, di chiave, e di integrità.
Vincoli di dominio: Definiscono che il valore di ogni attributo deve essere atomico e deve
appartenere al dominio dell’attributo stesso.
Vincoli di chiave: Stabiliscono che tutte le tuple che fanno parte di una stessa relazione
devono essere distinte; l’attributo che consente l’univocità a tutte le tuple di una stessa
relazione viene definita chiave primaria.
Vincoli di integrità della chiave: Dicono che la chiave primaria non può mai assumere il
valore nullo, dato che la chiave viene utilizzata per individuare e rendere univoche le varie
tuple. I vincoli di integrità chiave vengono stabiliti negli schemi delle singole relazioni.
Vincoli di integrità referenziale: Correlano, attraverso valori comuni, le informazioni
contenute in tabelle diverse8.
8
ELMASRI RAMEZ A., NAVATHE SHAMKANT B., Sistemi di basi di dati. Fondamenti. Pearson Education Italia,
2007, p. 78.
14
1.6 MODELLI FISICI
Sono i modelli con il livello di astrazione più basso, e definiscono concetti che
forniscono dettagli sui meccanismi di memorizzazione interna, i cammini di accesso e la
organizzazione dei file della base di dati. Nella fase di progettazione fisica vengono decise le
caratteristiche fisiche degli archivi, cioè l’insieme dei parametri fisici necessari per la
memorizzazione e la gestione dei dati su memoria di massa.
1.7 STRATEGIE DI PROGETTAZIONE
La fase di progettazione di una base di dati può avvalersi di vari tipi di strategie: strategia
top-down, strategia bottom-up, strategia inside-out, strategia mista.
La strategia top-down prevede che lo schema concettuale venga definito tramite
una serie di raffinamenti successivi. Si parte quindi da uno schema essenziale e grossolano
che viene definito schema iniziale, il quale deve comunque contenere tutte le specifiche
tramite pochi concetti molto astratti. Questo schema viene sottoposto poi ad una serie di
raffinamenti i quali serviranno per aumentare via via il dettaglio dei vari concetti esposti.
Il vantaggio di questa strategia è dato dal fatto che il progettista può dare origine ad uno
schema iniziale che contiene unicamente le specifiche dei dati trascurandone i dettagli,
riuscendo poi a sviluppare i vari concetti uno alla volta. Lo sviluppo del progetto mediante
questa strategia implica comunque una visione completa di tutte le componenti del sistema,
cosa che non è molto semplice quando si ha a che fare con basi di dati complesse.
Nella strategia bottom-up le specifiche iniziali vengono suddivise in parti via via
sempre più ridotte fino ad ottenere frammenti elementari della realtà di interesse. I vari
frammenti vengono quindi rappresentati da singoli schemi concettuali, i quali possono
consistere anche in concetti singoli. Lo schema concettuale finale verrà poi definito
mediante la fusione dei vari schemi così ottenuti. Questa strategia presenta il vantaggio di
adattarsi ad una decomposizione della realtà di interesse in componenti più semplici,
facilmente individuabili, il cui progetto può quindi essere affrontato da progettisti diversi.
Questa strategia si presta molto bene quindi a dei progetti di collaborazione o alla
suddivisione del lavoro all’interno di un gruppo. Lo svantaggio principale è dato dal fatto
che esso richiede delle operazioni di integrazioni di schemi concettuali diversi che possono
presentare delle difficoltà nel caso si abbia a che fare con schemi complessi.
15
La strategia inside-out può essere considerata come un caso speciale della strategia
bottom-up, dato che si individuano inizialmente i concetti principali, e si procede fino ad
arrivare ai concetti più lontani. Il vantaggio che questa strategia presenta è quello di non
richiedere passi di integrazione, di volta in volta sarà comunque necessario individuare i
concetti non ancora rappresentati individuando tutte le specifiche. Non sarà quindi
possibile procedere per livelli di astrazione come avviene nella strategia top-down.
La strategia mista cerca di combinare i vantaggi della top-down assieme a quelli
della bottom-up. Vengono suddivisi i requisiti in componenti separate come per la strategia
bottom-up, ma allo stesso tempo viene definito uno schema scheletro a livello astratto. Lo
schema sarà utile per avere una visione unitaria dell’intero progetto favorendo così le fasi di
integrazione degli schemi sviluppati separatamente. I vantaggi di questa strategia sono dati
dalla sua flessibilità, dato che si adatta bene ad esigenze contrapposte, suddividere il
problema in frazioni più semplici oppure procedere per raffinamenti successivi. La strategia
mista è sicuramente quella più usata, almeno per quanto riguarda i casi di una certa
complessità, dato che spesso è necessario cominciare la progettazione anche se non sono
ancora disponibili tutte le informazioni a riguardo9.
2. LAMP
Il termine LAMP è stato coniato nel 1998 da Michael Kunze sulle pagine di c’t, una
nota rivista di informatica in lingua tedesca. Tale acronimo deriva dalle componenti Linux,
Apache, MySQL e PHP, tecnologie fondamentali per la costruzione di applicazioni libere,
economiche e distribuite.
La piattaforma software LAMP è costituita da:
• il sistema operativo GNU/Linux;
• Apache, un web server molto diffuso;
• MySQL, un potente database relazionale;
• PHP un linguaggio di scripting .
In figura (Fig. 3) è rappresentato lo stack LAMP.
9
ATZENI P., CERI S., PARABOSCHI S., TORLONE R., Basi di dati Modelli e linguaggi di interrogazione, 2/ed.
McGraw-Hill, Milano, 2006, pp. 250-258.
16
Figura 3: Stack della piattaforma LAMP
Tutte queste tecnologie sono disponibili come software libero, quindi utilizzabili da
chiunque senza restrizioni, e nel loro complesso formano una vera e propria piattaforma di
sviluppo.
2.1 APACHE
L'Apache HTTP Server è una applicazione web server molto conosciuta per avere
svolto un ruolo chiave nella crescita iniziale del World Wide Web ed è sviluppato e
mantenuto da una comunità aperta di sviluppatori sotto la supervisione della Apache
Software Foundation. Più comunemente utilizzato su sistemi Unix-like, il software è
disponibile per una vasta gamma di sistemi operativi, tra cui Unix, FreeBSD, Linux, Solaris,
Novell NetWare, OS X, Microsoft Windows, OS/2, TPF, OpenVMS e eComStation.
Rilasciato sotto licenza Apache, Apache è un software open-source.
Apache permette la configurazione dei messaggi di errore, l’autenticazione basata su
DBMS, la negoziazione dei contenuti ed è inoltre supportato da diverse interfacce grafiche
(GUI).
2.2 MySQL
MySQL è un sistema open source di gestione di database relazionali ad alte
prestazioni, multithreaded e multiuser basato sull’architettura client-server. Con l’aumentare
17
delle potenzialità dei computer nel contenere enormi quantità di dati si è reso necessario lo
sviluppo di elaborati sistemi di gestione di basi di dati. MySQL si basa su “SQL”
(Structured Query Language), che rappresenta il linguaggio standard, definito dallo
standard ANSI/ISO SQL Standard, per l’accesso ai database relazionali in cui i dati sono
conservati su più tabelle collegate tra loro. MySQL è uno tra i più utilizzati e conosciuti
DBMS, grazie alle sue numerose qualità tra le quali spiccano la velocità, l’affidabilità e la
semplicità d’uso. Può funzionare su diversi tipi di piattaforma ed è utilizzabile da numerose
API (interfacce di programmazione). Dal punto di vista della sicurezza è estremamente
affidabile e flessibile e le password sono crittografate ad ogni connessione. Può gestire
database di grandi dimensioni i “client” si possono collegare al server MySQL utilizzando il
protocollo TCP/IP e supporta numerose lingue e insiemi di caratteri.
Esistono diversi strumenti per l'amministrazione di database MySQL, tra cui phpMyAdmin
(Fig. 4), il quale necessita di un Web Server Apache e il supporto del linguaggio Php e può
essere utilizzato attraverso un qualsiasi browser web.
Figura 4: Interfaccia phpMyAdmin
2.3 PHP
Il PHP (Hypertext Preprocessor) è un linguaggio di scripting creato nel 1994 da
Rasmus Lerdorf, progettato per la generazione dinamica di pagine web. Nei primi anni di
vita di Internet, un sito web era costituito essenzialmente da semplici pagine HTML, i
18
documenti erano raggiungibili mediante un indice generale e non vi era alcuna possibilità di
effettuare ricerche. Negli anni seguenti invece, la maggior parte dei siti sono stati
caratterizzati dalla presenza di una grande quantità di informazioni organizzate all’interno di
uno o più database in modo tale da essere consultate facilmente da particolari programmi
chiamati CGI (Common Gateway Interface) il cui compito è quello di fornire all’utente
finale una pagina HTML generata dinamicamente con i contenuti richiesti.
Attualmente, le CGI sono state quasi del tutto sostituite da due altri approcci per fornire
contenuti dinamici via web:
1. Active Server Pages – ASP (interpretato) o ASP.NET (compilato) della Microsoft;
2. Java Server Pages – JSP della Sun Microsystem.
Il Php è un linguaggio di programmazione open source interpretato (non necessita quindi
di essere compilato), utilizzato principalmente per la generazione di pagine web dinamiche.
Un file Php può contenere testo semplice, codice HTML, codice Javascript oltre che a
codice Php. Quando viene lanciato del codice Php (per esempio accedendo ad una pagina
web) questo viene eseguito sul web server contente il sorgente, che restituisce una pagina
HTML visualizzabile tramite un browser web dall’utente finale.
Mediante il linguaggio PHP è possibile interfacciarsi con i più diffusi database (Oracle,
Informix, SyBase, Microsoft SQL Server, MySQL, mSQL, PostGreSQL).
2.4 MYSQL WORKBENCH
MySQL Workbench è un tool grafico per la gestione di database e server MySQL
che consente di operare nelle seguenti aree funzionali (Fig. 5):

SQL Development

Data Modeling

Server Administration
19
Figura 5: Screenshot MySQL Workbench
Si tratta dunque di uno strumento visuale di progettazione per database, che integra
sviluppo SQL, gestione, modellazione dati, creazione e manutenzione di database
all'interno di un unico ambiente.
MySQL Workbench è una applicazione grafica che fornisce le stesse funzionalità del client
MySQL ma è più semplice da utilizzare. Questo strumento semplifica la progettazione e la
manutenzione del database, automatizza le attività laboriose e complesse e migliora la
comunicazione tra DBA e team di sviluppo. Consente ai data architect di visualizzare le
esigenze degli utenti, comunicare con le parti interessate e risolvere le problematiche a
livello di progettazione prima che sia effettuato un importante investimento in termini di
tempo e risorse (Fig. 6).
20
Figura 6: Progettazione grafica di un database in MySQL Workbench
MySQL Workbench offre funzionalità per il Forward Engineering dei database fisici. Un
modello di dati grafico può essere facilmente trasformato in un database fisico su di un
server MySQL. Tutto il codice SQL è generato automaticamente ed è eseguito
correttamente sin dall’inizio, eliminando il normale processo di scrittura manuale di codice
SQL complesso, tipicamente soggetto ad errori. MySQL Workbench consente, inoltre, di
eseguire il Reverse Engineering di un database esistente o di un pacchetto di applicazioni,
per comprenderne meglio la progettazione interna. MySQL Workbench non solo può
eseguire il Forward e Reverse Engineering dei database esistenti, ma può anche importare
script SQL per creare ed esportare modelli verso script DDL eseguibili in un momento
successivo.
3. PROGETTAZIONE DEL SISTEMA INFORMATIVO
Nel corso dello stage svolto presso l'ENEA Centro di ricerca di Brindisi è stato
possibile progettare una base di dati utile in un campo della ricerca dei Beni Culturali. Il
punto di partenza è consistito nella simulazione di una committenza che necessita di un
sistema informativo per raccogliere, gestire e rendere disponibili informazioni relative ad
una collezione di marmi antichi.
Il cuore di questo sistema informativo è rappresentato da un database relazionale nel quale
sono convogliate tutte le informazioni che si riferiscono agli oggetti contenuti nella
collezione.
21
A partire dalla richiesta del committente è stata eseguita un'analisi dei requisiti ed è stato
utilizzato l’Unified Modeling Language (UML) quale linguaggio di modellazione, per
definire le funzioni e le componenti principali del sistema informativo.
La fase successiva è stata quella della progettazione dello schema concettuale della base di
dati secondo una strategia top-down. A seguito di varie revisioni, lo schema concettuale è
stato poi tradotto nello schema logico e infine in quello fisico.
La progettazione del database è stata eseguita impiegando la piattaforma di sviluppo
MySQL Workbench, il modello logico è stato esportato su piattaforma LAMP che integra e
utilizza MySQL quale RDBMS, e sul quale sono state create tutte le strutture del database.
3.1 RICHIESTA DELLA COMMITTENZA
La committenza è rappresentata da un’istituzione che gestisce una realtà museale e
necessita di un sistema informativo allo scopo di valorizzare e tutelare una collezione di
marmi antichi. Tale necessità nasce dalla volontà di raccogliere e gestire tutte le
informazioni che gravitano attorno a questi oggetti di interesse storico-artistico e
archeologico.
La collezione è rappresentata da circa seicento esemplari di marmi e pietre ornamentali
ampiamente utilizzati in antichità ed è corredata da un catalogo che riporta in sequenza il
numero e la denominazione di ciascun campione.
La collezione rappresenta una raccolta di alcune delle principali tipologie di rocce utilizzate
in antichità, impiegate soprattutto per finalità decorative.
In generale, sulla base dei caratteri litologici che lo caratterizzano (quantità e dimensioni di
minerali presenti, tessitura e struttura), un campione può essere associato ad un particolare
litotipo (es. granito, breccia, conglomerato, alabastro etc.) che rappresenta una determinata
tipologia di roccia.
Non è possibile associare ciascun campione ad un particolare litotipo in quanto la
collezione presenta alcuni campioni di varietà ancora sconosciute.
Negli ultimi anni questa raccolta di marmi antichi è stata oggetto di studio e le ricerche
eseguite hanno interessato ambiti differenti.
Nello specifico hanno riguardato lo studio approfondito del catalogo e della collezione
stessa, la ricerca di altre collezioni simili presenti sul territorio nazionale ed estero, i
principali contesti nei quali i marmi antichi sono stati impiegati in passato e le informazioni
22
relative a beni di interesse storico-artistico, architettonico e archeologico nei quali le
principali tipologie di marmi antichi sono stati individuati.
Inoltre, sono stati eseguiti studi sulle provenienze e sulle principali cave utilizzate in
antichità per l'estrazione di marmi e pietre antiche, sugli aspetti commerciali e sulle
informazioni relative alle caratterizzazioni petrografiche e geotecniche, queste ultime
strettamente necessarie per l'identificazione e la classificazione degli oggetti di interesse.
L'obiettivo della committenza è quello di fornire uno strumento teso a valorizzare la
collezione di marmi presente nel museo, divulgare le informazioni raccolte negli anni
provenienti dalle ricerche eseguite nei vari ambiti e fornire un supporto valido al lavoro di
ricerca degli esperti. Inoltre, questo stesso strumento rappresenterà il punto di partenza per
la costruzione di un contenitore di informazioni continuamente ampliate dagli utenti esperti
del settore.
Il nucleo del sistema informativo sarà rappresentato da un database che deve contenere dati
di natura diversa: immagini, testi, link, dati scientifici. Per ciascun oggetto della collezione
possono sussistere molteplici tipologie di informazioni.
3.2 I REQUISITI UTENTE
In generale, la realizzazione di un qualsiasi manufatto, e quindi anche di un nuovo
sistema software, dovrebbe iniziare dalla raccolta dei relativi requisiti, a partire dai quali si
avvia il processo denominato “ciclo di vita del software”.
In primis è necessario raggiungere due obiettivi:
1. comprendere le esigenze che determinano la necessità di un nuovo sistema informatico o
dell’aggiornamento di quello esistente;
2. esaminare lo scenario del cliente con particolare attenzione alle risorse disponibili:
umane, tecnologiche (software utilizzati, connessioni, reti etc.) e anche di budget.
A partire da queste indagini è possibile redigere un primo documento focalizzato su quelli
che sono gli aspetti principali della richiesta e volto a chiarire il dominio del problema.
In questo caso la richiesta del cliente nasce dall'esigenza di organizzare e divulgare materiale
informativo garantendo un accesso semplice per gli utenti. Tutte le informazioni si
riferiscono ai campioni contenuti nella collezione che rappresentano il riferimento
principale del sistema. Il sistema informatico che ne deriva non sarà soggetto a frequenti
modifiche, si tratta prevalentemente di un sistema di consultazione e ricerca che deve
23
contenere una grande quantità di informazioni di natura diversa. Per tale ragione la
progettazione del sistema informativo si può distinguere in due parti:

Progettazione interfaccia utente

Progettazione del database
Per consentire un accesso alle informazioni semplice e di facile utilizzo si è deciso di
progettare un sito web. La progettazione di questa prima parte del sistema informativo ha
riguardato la modellazione del sistema utilizzando UML in termini di attori coinvolti, casi
d’uso e principali attività consentite.
L'interfaccia utente deve essere semplice e soddisfare le esigenze sia di utenti generici
nonché di utenti specialisti del settore che potranno interrogare la base di dati per ottenere
informazioni sulla collezione e sulle ricerche che interessano il mondo dei marmi antichi.
L'utente deve poter accedere sia ad informazioni generiche sulla collezione che ad
informazioni relative ad uno specifico campione.
Deve essere possibile ottenere una visione che tende dal generale al particolare:

COLLEZIONE (INFO TESTUALI)

LITOTIPI PRESENTI IN COLLEZIONE (INFO MULTIMEDIALE)

SINGOLO CAMPIONE (INFO MULTIMEDIALE E TESTUALE)
Tale strumento deve consentire la cooperazione tra gli utenti specialisti del settore
che devono poter aggiungere nuove informazioni in qualunque ambito.
La seconda parte della progettazione è focalizzata sulla progettazione del database
nel quale saranno raccolte tutte le informazioni. Nello specifico le informazioni relative ai
campioni comprendono:

INFO COMMERCIO/PROVENIENZA

INFO STORIA DELL'ARTE

INFO ARCHEOLOGIA

INFO CARATTERIZZAZIONE PETROGRAFICA

INFO CARATTERIZZAZIONE GEOTECNICA

INFO ANALISI E STUDI DI PROVENIENZA
L'utente rappresenta il principale fruitore delle informazioni relative alla collezione. Nella
richiesta della committenza si distinguono due tipologie di utenti e, per ciascuna di esse, è
specificata la natura delle informazioni alle quali queste possono accedere.
24
In un caso si tratta di informazioni più generiche relative alla collezione e nell'altro di
informazioni più specifiche, utili soprattutto per un utenza specializzata. Sulla base di tale
richiesta si parlerà in seguito di:

Utente occasionale

Utente esperto
Tale distinzione comporta un accesso al sistema suddiviso in due parti, in funzione della
tipologia di utente, pur se realizzato all'interno dello stesso sito web.
La prima parte è rappresentata da un'interfaccia disponibile nel web per tutti gli utenti, che
permette di realizzare una veduta d'insieme di tutta la collezione, dalla sua storia al luogo in
cui è conservata oggi, deve contenere un'area che contiene tutte le informazioni del
catalogo e le immagini relative a ciascun campione e un'area dedicata ai principali litotipi
presenti nella raccolta. Inoltre, il sito web deve contenere le informazioni relative al museo
e consentire di prenotare una visita della collezione.
L'accesso alla seconda parte dei contenuti presenti nel sistema informativo agli utenti
specialisti del settore è realizzato, all'interno del sito stesso, tramite una procedura di
registrazione.
Compilando il modulo per la registrazione, il sistema provvede ad inviare lo stesso
all'amministratore del sistema, il quale decide, sulla base delle competenze e necessità
dell'utente, se consentire o meno la registrazione dello stesso.
Accettata la richiesta, verranno inviati all'utente una username e password per eseguire il
login all'interno del sito web ed accedere all'area dedicata agli esperti del settore, nella quale
è presente anche un forum di discussione tra gli stessi.
In quest'area sarà possibile accedere a tutte le informazioni contenute nel database ed
eseguire operazioni di interrogazione e modifica a seconda dei permessi utente.
La prima parte del sistema consente quindi un accesso parziale alle informazioni contenute
nel database mentre, a seguito della
registrazione, l'utente può fruire di tutte le
informazioni contenute nella base di dati.
Il committente ha richiesto espressamente di utilizzare risorse open source per la
realizzazione del sistema informatico.
25
3.3 UML
UML, Unified Modeling Language, è un linguaggio per specificare, costruire,
visualizzare e documentare prodotti sia di sistemi software, sia di processi produttivi e altri
sistemi non strettamente software. Lo UML rappresenta una collezione di best practices di
ingegneria sviluppate per la modellazione di vasti e complessi sistemi permettendo, per
mezzo di un formalismo rigoroso, di illustrare idee, decisioni e soluzioni adottate. Tale
linguaggio dispone di tutti i meccanismi necessari per la specifica di qualsiasi dettaglio
ritenuto rilevante in ogni fase del ciclo di vita del software e quindi, in ultima analisi, per
produrre modelli accurati, precisi e non ambigui.
UML nasce dall'integrazione di tre diverse notazioni proposte negli anni '80 e nei primi
anni '90 da Booch, Jacobson e Rumbaugh e comprende vari tipi di notazioni e di
diagrammi, per specificare i diversi aspetti di un sistema software.
Questo linguaggio di modellazione è stato utilizzato per la descrizione delle componenti
principali della progettazione del sistema informativo e nello specifico gli attori, gli use case
e diagrammi di attività. Tali componenti servono a facilitare la comunicazione con gli utenti
futuri del sistema e con il cliente, e sono particolarmente utili a i le funzionalità necessarie
che il sistema deve avere.
Per lo sviluppo e la realizzazione dei grafici UML è stato utilizzata l'applicazione StarUML,
un software open source che offre un ventaglio di strumenti per la realizzazione di modelli
e progetti di sviluppo software.
3.4 ATTORI
Il primo passo per la progettazione del sistema informativo necessita della
definizione degli attori coinvolti nel sistema. Gli attori sono i soggetti, esterni al sistema,
che interagiscono con esso tramite messaggi (richieste, comunicazioni, risposte). Possono
essere sia persone reali che altri sistemi o eventi esterni ma non rappresentano
necessariamente persone fisiche, ma il loro ruolo. Questo significa che quando una persona
interagisce con il sistema in modi diversi, sarà rappresentata da diversi attori.
Gli attori vengono rappresentati graficamente nello UML con omini stilizzati (stick man),
anche definiti “scarabocchi”, con il relativo nome riportato alla base.
In questo caso di studio si individuano, nello specifico, quattro attori:
26
•
Utente occasionale (che è colui che raggiunge il portale magari partendo da un
motore di ricerca, ed è interessato a visionare la parte pubblica dello stesso,
acquisire i contatti, ecc.);
•
Utente esperto (che ha i diritti per interagire col back-end, ossia può caricare
informazioni nel database, può scrivere contributi in alcune pagine del portale,
ecc.);
•
Amministratore (che è responsabile della gestione del back-end e della GUI);
•
Sistema (back end).
Tra gli attori può sussistere una relazione di generalizzazione nel caso in cui più attori
presentino diverse e significative similitudini. In questo caso è possibile dar luogo a un
nuovo attore, talvolta astratto, atto a raccogliere le similitudini summenzionate che possono
così essere estese per mezzo di apposite relazioni di generalizzazione.
In generale un attore “specializzato” eredita il comportamento del “genitore” e lo estende
in qualche maniera.
Gli attori possono essere specializzati e connessi ad altri attori tramite relazioni di
generalizzazione. Attori specializzati usano le stesse funzionalità degli altri che
generalizzano ed eventualmente alcune funzionalità specifiche.
In questo caso di studio sia l'utente occasionale che il sistema sono anche UTENTI (che è
la massima astrazione). A loro volta, gli utenti esperti e l’amministratore sono utenti
occasionali, nel senso che possono fare tutto ciò che compete all’utente occasionale, in
aggiunta ad operazioni specifiche loro consentite (Fig. 7).
Figura 7: Attori e relazioni di generalizzazione
27
3.5 USE CASE
A ciascun attore è possibile associare determinate mansioni e attività definite come
casi d’uso.
I casi d’uso sono descrizioni delle interazioni tipiche tra gli utenti di un sistema e il sistema
stesso. In seguito ad un'interazione avviata da un utente, un sistema risponde eseguendo
una sequenza di azioni in grado di fornire all’attore stesso i risultati desiderati (per esempio
la produzione di un documento), e sono proprio tali interazioni che costituiscono gli use
case.
In relazione agli attori individuati nel precedente paragrafo è possibile associare a ciascuno
di essi determinati use case e ottenere i corrispettivi diagrammi.
L'utente, per comodità definito generico, può (Fig. 8):

Accedere alle informazioni contenute nelle varie sezioni del sito web

Eseguire una ricerca nel database che contiene le informazioni

Richiedere informazioni per visitare la collezione

Inviare una richiesta per accedere alla sezione riservata agli esperti del settore
Figura 8: Use case utente generico
L'utente esperto può (Fig. 9):

Registrarsi nella sezione riservata per ottenere le credenziali di accesso

Richiedere il recupero delle credenziali

Accedere alla sezione riservata
28

Eseguire una ricerca nella sezione riservata

Partecipare al forum di discussione

Inviare una richiesta per modificare e/o aggiungere informazioni nel database
Figura 9: Use case utente esperto
L'amministratore (Fig. 10):

Crea e carica i dati nel database e lo gestisce

Interviene in caso di malfunzionamenti del sistema

Gestisce il processo di login

Autorizza l'ingresso di un utente generico nella sezione riservata

Autorizza le modifiche da parte degli utenti esperti del database

Aggiunge le informazioni degli utenti esperti nel database
29
Figura 10: Use case amministratore
Il sistema deve (Fig. 11):

Consentire l'accesso alle informazioni

Recuperare le informazioni richieste

Ricercare le informazioni nel database

Rispondere alle richieste di informazioni da parte dell'utente

Recuperare le credenziali di accesso dell'utente esperto

Inviare una richiesta di accesso alla sezione riservata

Inviare una richiesta di modifica del database

Gestire il forum di discussione

Gestire gli account utente
30
Figura 11: Use case sistema
3.6 DIAGRAMMI DELLE ATTIVITÀ
I diagrammi delle attività (Activity Diagram) sono essenzialmente dei grafi nei quali
vengono rappresentate le attività del processo, l'ordine in cui queste devono essere eseguite
e gli eventuali punti di decisione.
L’Activity rappresenta una specifica attività che deve essere svolta all’interno della funzione
ed è rappresentata da un rettangolo smussato con una descrizione dell’attività, questa è
relazionata alle altre con delle frecce e tutta la sequenza è racchiusa tra i due simboli di
inizio e fine processo.
L'uso di questi diagrammi di attività consente di mettere in rilievo la sequenzialità e la
concorrenza degli step di cui si compone una particolare procedura e possono essere
utilizzati anche per dettagliare un determinato algoritmo. Nella figura (Fig. 11) è riportato
un esempio di activity diagram relativo ad un utente esperto che vuole aggiungere delle
informazioni al database. Si tratta di documenti molto utili nella esposizione al cliente del
progetto e delle funzionalità del sistema.
31
Figura 12: Acitivity diagram che consente di aggiungere informazioni nel database
3.7 PROGETTAZIONE DATABASE RELAZIONALE
A partire dalla richiesta del committente è stato progettato un database relazionale
che costituirà il contenitore di tutte le informazioni relative alla collezione. Sono state
definite quindi le entità e le relazioni che consentono di organizzare le numerose
informazioni, le cardinalità di ciascuna relazione, gli attributi e gli identificatori di ciascuna
entità. Nelle due tabelle che seguono sono mostrate tutte le componenti principali del
modello ER ed una descrizione relativa a ciascuna entità e relazione.
Le entità stato, regione, provincia, comune potrebbero essere in futuro utili per
inserire/recuperare informazioni relative alle georeferenziazione di cave, di beni di interesse
storico-artistico e architettonico e di siti archeologici. Seguono il modello entità-relazione
del database, il modello logico con la specifica delle foreign key e quello fisico modellato in
MySQL Workbench. Infine in appendice è riportato il codice SQL generato
automaticamente e utilizzato per la creazione del database sul server MySQL in LAMP.
32
TABELLA DELLE ENTITÀ
ENTITÀ
DESCRIZIONE
CAMPIONE
Raccoglie i dati relativi ai Id_CAMPIONE
campioni della collezione o di Nome_Campione_Catalogo
altre collezioni
Numero_Campione_Catalogo
Immagine_Campione
Etichetta
Nome_Collezione
Note
Contiene i dati sulle principali Id_LITOTIPO
tipologie di rocce presenti nella Nome_Litotipo
collezione
Descrizione_Litotipo
Raccoglie i dati necessari per la Id_CARATT_PETROGRAFICA
classificazione petrografica dei Immagine_Sezione_Sottile
campioni
Descrizione_Microscopica
Descrizione_Macroscopica
Classificazione_Petrografica
Osservazioni
Raccoglie i dati relativi alle Id_CARATT_GEOTECNICA
proprietà
geotecniche
dei Descrizione
campioni
Dilatazione_termica
Resistenza_usura
Resistenza_flessione
Resistenza_compressione_monoassiale
Coefficiente_imbibizione
Durezza
Raccoglie l'elenco di analisi che Id_TIPO_ANALISI
si possono eseguire su ciascun Nome_Analisi
campione
Raccoglie i dati relative a Id_ANALISI
ciascuna analisi eseguita
Nome_Analisi
Immagine_Analisi
Dato
Unità_di_misura_Dato
Protocollo_Analisi
Discussione_Risultati_Analisi
Raccoglie i dati relativi alla cava Id_CAVA
di provenienza dei marmi
Tipo_Località (Italia, Estero)
Latitudine
Longitudine
Nome_Cava
Descrizione_Cava_Rotte_Commerciali
Immagine_Rotte_Commerciali
Immagine_Cava
Bibliografia
Raccoglie le informazioni sui Id_ST_ARTE
principali beni di interesse Nome_Bene_Storico_Artistico
storico-artistico
ed Riferimenti_Catalografici
architettonico in cui sono Tipo_Località (Italia, Estero)
presenti le varie tipologie di Descrizione_Bene_Storico_Artistico
marmi antichi
Bibliografia
Raccoglie le informazioni sui Id_ARCHEOL
principali siti archeologici in cui Nome_Sito_Archeologico
sono presenti le varie tipologie Riferimenti_Catalografici
di marmi antichi
Tipo_Località (Italia, Estero)
Descrizione_Sito_Archeologico
Bibliografia
Raccoglie i dati di provenienza Id_STATO
Nome_Stato
Raccoglie i dati di provenienza Id_COMUNE
Nome_Comune
Raccoglie i dati di provenienza Id_PROVINCIA
Nome_Provincia
Raccoglie i dati di provenienza Id_REGIONE
Nome_Regione
LITOTIPO
CARATT.
PETROGRAFICA
CARATT.
GEOTECNICA
TIPO ANALISI
ANALISI
CAVA
ST. ARTE
ARCHEOL.
STATO
COMUNE
PROVINCIA
REGIONE
ATTRIBUTI
IDENTIFICATORE
Id_CAMPIONE
Id_LITOTIPO
Id_CARATT_PETROGRAFICA
Id_CARATT_GEOTECNICA
Id_TIPO_ANALISI
Id_ANALISI
Id_CAVA
Id_ST_ARTE
Id_ARCHEOL
Id_STATO
Id_COMUNE
Id_PROVINCIA
Id_REGIONE
33
TABELLA DELLE RELAZIONI
RELAZIONE
DESCRIZIONE
ENTITÀ COINVOLTE
Raggruppa
Descrive
Associa i campioni ai litotipi
Collega un campione ad una
caratterizzazione petrografica
Collega un campione ad una
caratterizzazione geotecnica
Associa il campione al tipo di analisi
svolte su di esso
Associa il campione ai dati delle
analisi svolte su di esso
Associa ciascun tipo di analisi ai dati
delle stesse
Associa un campione ad un sito
archeologico
Collega un campione ad un bene di
interesse storico-artistico o
architettonico
Associa un campione ad una cava
Collega una cava ad un comune
italiano
Collega una cava ad uno stato estero
Collega un comune alla provincia di
appartenenza
Collega una provincia alla regione di
appartenenza
Collega un bene di interesse storicoartistico o architettonico allo stato
estero di appartenenza
Collega un bene di interesse
archeologico allo stato estero di
appartenenza
Associa un bene di interesse storicoartistico o architettonico al comune
italiano di appartenenza
Associa un bene di interesse
archeologico al comune italiano di
appartenenza
LITOTIPO-CAMPIONE
CAMPIONE-CARATT. PETROGRAFICA
1:N
1:N
CAMPIONE-CARATT. GEOTECNICA
1:N
CAMPIONE-TIPO ANALISI
1:N
CAMPIONE- ANALISI
1:N
ANALISI-TIPO ANALISI
N:M
CAMPIONE-ARCHEOL.
N:M
CAMPIONE-ST. ARTE
N:M
CAVA-CAMPIONE
COMUNE-CAVA
1:N
1:N
STATO-CAVA
PROVINCIA-COMUNE
1:N
1:N
REGIONE-PROVINCIA
1:N
STATO-ST. ARTE
1:N
STATO-ARCHEOL.
1:N
COMUNE-ST. ARTE
1:N
COMUNE-ARCHEOL.
1:N
Definisce
Indagato
Indagato
Indagato
Individuato
Identificato
Estratto
Collocata
Collocata
Si trova
Si trova
Ubicato
Ubicato
Ubicato
Ubicato
CARDINALITÀ
34
MODELLO ENTITÀ-RELAZIONE
35
MODELLO LOGICO
36
MODELLO FISICO
37
APPENDICE – SCRIPT MySQL
SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET
@OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,FOREIGN_KEY_CHECKS=0;
SET@OLD_SQL_MODE=@@SQL_MODE,SQL_MODE='TRADITIONAL,ALLOW_INVALID_DAT
ES;
-- ------------------------------------------------------ Table `DATABASE_COLLEZIONE`.`LITOTIPI`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `DATABASE_COLLEZIONE`.`LITOTIPI` (
`idLITOTIPI` INT NOT NULL ,
`Nome Litotipo` VARCHAR(45) NULL ,
`Descrizione Litotipo` TEXT NULL ,
PRIMARY KEY (`idLITOTIPI`) )
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `DATABASE_COLLEZIONE`.`CAMPIONE`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `DATABASE_COLLEZIONE`.`CAMPIONE` (
`idCAMPIONE` INT NOT NULL ,
`Nome Campione Catalogo` VARCHAR(50) NULL ,
`Numero Campione Catalogo` INT NULL ,
`Immagine Campione` BLOB NULL ,
`Etichetta` TINYINT(1) NULL ,
`Nome Collezione` VARCHAR(50) NULL ,
`Note` VARCHAR(45) NULL ,
`LITOTIPI_idLITOTIPI` INT NOT NULL ,
PRIMARY KEY (`idCAMPIONE`, `LITOTIPI_idLITOTIPI`) ,
INDEX `fk_CAMPIONE_LITOTIPI1_idx` (`LITOTIPI_idLITOTIPI` ASC) ,
CONSTRAINT `fk_CAMPIONE_LITOTIPI1`
FOREIGN KEY (`LITOTIPI_idLITOTIPI` )
REFERENCES `DATABASE_COLLEZIONE`.`LITOTIPI` (`idLITOTIPI` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `DATABASE_COLLEZIONE`.`REGIONE`
38
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `DATABASE_COLLEZIONE`.`REGIONE` (
`idREGIONE` INT NOT NULL ,
`Nome Regione` VARCHAR(45) NULL ,
PRIMARY KEY (`idREGIONE`) )
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `DATABASE_COLLEZIONE`.`PROVINCIA`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `DATABASE_COLLEZIONE`.`PROVINCIA` (
`idPROVINCIA` INT NOT NULL ,
`Nome Provincia` VARCHAR(45) NULL ,
`REGIONE_idREGIONE` INT NOT NULL ,
PRIMARY KEY (`idPROVINCIA`, `REGIONE_idREGIONE`) ,
INDEX `fk_PROVINCIA_REGIONE1_idx` (`REGIONE_idREGIONE` ASC) ,
CONSTRAINT `fk_PROVINCIA_REGIONE1`
FOREIGN KEY (`REGIONE_idREGIONE` )
REFERENCES `DATABASE_COLLEZIONE`.`REGIONE` (`idREGIONE` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `DATABASE_COLLEZIONE`.`COMUNE`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `DATABASE_COLLEZIONE`.`COMUNE` (
`idCOMUNE` INT NOT NULL ,
`Nome Comune` VARCHAR(45) NULL ,
`PROVINCIA_idPROVINCIA` INT NOT NULL ,
PRIMARY KEY (`idCOMUNE`, `PROVINCIA_idPROVINCIA`) ,
INDEX `fk_COMUNE_PROVINCIA1_idx` (`PROVINCIA_idPROVINCIA` ASC) ,
CONSTRAINT `fk_COMUNE_PROVINCIA1`
FOREIGN KEY (`PROVINCIA_idPROVINCIA` )
REFERENCES `DATABASE_COLLEZIONE`.`PROVINCIA` (`idPROVINCIA` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- -----------------------------------------------------
39
-- Table `DATABASE_COLLEZIONE`.`STATO`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `DATABASE_COLLEZIONE`.`STATO` (
`idSTATO` INT NOT NULL ,
`Nome Stato` VARCHAR(45) NULL ,
PRIMARY KEY (`idSTATO`) )
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `DATABASE_COLLEZIONE`.`CAVA`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `DATABASE_COLLEZIONE`.`CAVA` (
`idCAVA` INT NOT NULL ,
`Tipo Località` TINYINT(1) NULL ,
`Latitudine` DOUBLE NULL ,
`Longitudine` DOUBLE NULL ,
`Nome Cava` VARCHAR(45) NULL ,
`Descrizione Cava Rotte Commerciali` TEXT NULL ,
`Immagine Rotta Commerciale` BLOB NULL ,
`Immagine Cava` BLOB NULL ,
`Bibliografia` VARCHAR(45) NULL ,
`CAMPIONE_idCAMPIONE` INT NOT NULL ,
`COMUNE_idCOMUNE` INT NOT NULL ,
`STATO_idSTATO` INT NOT NULL ,
PRIMARY KEY (`idCAVA`, `CAMPIONE_idCAMPIONE`, `COMUNE_idCOMUNE`,
`STATO_idSTATO`) ,
INDEX `fk_CAVA_CAMPIONE_idx` (`CAMPIONE_idCAMPIONE` ASC) ,
INDEX `fk_CAVA_COMUNE1_idx` (`COMUNE_idCOMUNE` ASC) ,
INDEX `fk_CAVA_STATO1_idx` (`STATO_idSTATO` ASC) ,
CONSTRAINT `fk_CAVA_CAMPIONE`
FOREIGN KEY (`CAMPIONE_idCAMPIONE` )
REFERENCES `DATABASE_COLLEZIONE`.`CAMPIONE` (`idCAMPIONE` )
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_CAVA_COMUNE1`
FOREIGN KEY (`COMUNE_idCOMUNE` )
REFERENCES `DATABASE_COLLEZIONE`.`COMUNE` (`idCOMUNE` )
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_CAVA_STATO1`
40
FOREIGN KEY (`STATO_idSTATO` )
REFERENCES `DATABASE_COLLEZIONE`.`STATO` (`idSTATO` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `DATABASE_COLLEZIONE`.`ST_ARTE`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `DATABASE_COLLEZIONE`.`ST_ARTE` (
`idST_ARTE` INT NOT NULL ,
`Riferimenti Catalografici` VARCHAR(45) NULL ,
`Nome Bene Storico Artistico` VARCHAR(45) NULL ,
`Tipo Località` TINYINT(1) NULL ,
`Descrizione Bene Storico Artistico` TEXT NULL ,
`Bibliografia` VARCHAR(45) NULL ,
`STATO_idSTATO` INT NOT NULL ,
`COMUNE_idCOMUNE` INT NOT NULL ,
`COMUNE_PROVINCIA_idPROVINCIA` INT NOT NULL ,
PRIMARY KEY (`idST_ARTE`, `STATO_idSTATO`, `COMUNE_idCOMUNE`,
`COMUNE_PROVINCIA_idPROVINCIA`) ,
INDEX `fk_ST_ARTE_STATO1_idx` (`STATO_idSTATO` ASC) ,
INDEX `fk_ST_ARTE_COMUNE1_idx` (`COMUNE_idCOMUNE` ASC,
`COMUNE_PROVINCIA_idPROVINCIA` ASC) ,
CONSTRAINT `fk_ST_ARTE_STATO1`
FOREIGN KEY (`STATO_idSTATO` )
REFERENCES `DATABASE_COLLEZIONE`.`STATO` (`idSTATO` )
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_ST_ARTE_COMUNE1`
FOREIGN KEY (`COMUNE_idCOMUNE` , `COMUNE_PROVINCIA_idPROVINCIA` )
REFERENCES `DATABASE_COLLEZIONE`.`COMUNE` (`idCOMUNE` ,
`PROVINCIA_idPROVINCIA` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `DATABASE_COLLEZIONE`.`ST_ARTE_has_CAMPIONE`
-- -----------------------------------------------------
41
CREATE TABLE IF NOT EXISTS `DATABASE_COLLEZIONE`.`ST_ARTE_has_CAMPIONE` (
`ST_ARTE_idST_ARTE` INT NOT NULL ,
`ST_ARTE_STATO_idSTATO` INT NOT NULL ,
`ST_ARTE_COMUNE_idCOMUNE` INT NOT NULL ,
`ST_ARTE_COMUNE_PROVINCIA_idPROVINCIA` INT NOT NULL ,
`CAMPIONE_idCAMPIONE` INT NOT NULL ,
PRIMARY KEY (`ST_ARTE_idST_ARTE`, `ST_ARTE_STATO_idSTATO`,
`ST_ARTE_COMUNE_idCOMUNE`, `ST_ARTE_COMUNE_PROVINCIA_idPROVINCIA`,
`CAMPIONE_idCAMPIONE`) ,
INDEX `fk_ST_ARTE_has_CAMPIONE_CAMPIONE1_idx` (`CAMPIONE_idCAMPIONE` ASC) ,
INDEX `fk_ST_ARTE_has_CAMPIONE_ST_ARTE1_idx` (`ST_ARTE_idST_ARTE` ASC,
`ST_ARTE_STATO_idSTATO` ASC, `ST_ARTE_COMUNE_idCOMUNE` ASC,
`ST_ARTE_COMUNE_PROVINCIA_idPROVINCIA` ASC) ,
CONSTRAINT `fk_ST_ARTE_has_CAMPIONE_ST_ARTE1`
FOREIGN KEY (`ST_ARTE_idST_ARTE` , `ST_ARTE_STATO_idSTATO` ,
`ST_ARTE_COMUNE_idCOMUNE` , `ST_ARTE_COMUNE_PROVINCIA_idPROVINCIA` )
REFERENCES `DATABASE_COLLEZIONE`.`ST_ARTE` (`idST_ARTE` , `STATO_idSTATO` ,
`COMUNE_idCOMUNE` , `COMUNE_PROVINCIA_idPROVINCIA` )
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_ST_ARTE_has_CAMPIONE_CAMPIONE1`
FOREIGN KEY (`CAMPIONE_idCAMPIONE` )
REFERENCES `DATABASE_COLLEZIONE`.`CAMPIONE` (`idCAMPIONE` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `DATABASE_COLLEZIONE`.`ARCHEOL`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `DATABASE_COLLEZIONE`.`ARCHEOL` (
`idARCHEOL` INT NOT NULL ,
`Riferimenti Catalografici` VARCHAR(45) NULL ,
`Nome Sito Archeologico` VARCHAR(45) NULL ,
`Tipo Località` TINYINT(1) NULL ,
`Descrizione Sito Archeologico` TEXT NULL ,
`Bibliografia` TEXT NULL ,
`COMUNE_idCOMUNE` INT NOT NULL ,
`COMUNE_PROVINCIA_idPROVINCIA` INT NOT NULL ,
42
`STATO_idSTATO` INT NOT NULL ,
PRIMARY KEY (`idARCHEOL`, `COMUNE_idCOMUNE`,
`COMUNE_PROVINCIA_idPROVINCIA`, `STATO_idSTATO`) ,
INDEX `fk_ARCHEOL_COMUNE1_idx` (`COMUNE_idCOMUNE` ASC,
`COMUNE_PROVINCIA_idPROVINCIA` ASC) ,
INDEX `fk_ARCHEOL_STATO1_idx` (`STATO_idSTATO` ASC) ,
CONSTRAINT `fk_ARCHEOL_COMUNE1`
FOREIGN KEY (`COMUNE_idCOMUNE` , `COMUNE_PROVINCIA_idPROVINCIA` )
REFERENCES `DATABASE_COLLEZIONE`.`COMUNE` (`idCOMUNE` ,
`PROVINCIA_idPROVINCIA` )
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_ARCHEOL_STATO1`
FOREIGN KEY (`STATO_idSTATO` )
REFERENCES `DATABASE_COLLEZIONE`.`STATO` (`idSTATO` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `DATABASE_COLLEZIONE`.`ARCHEOL_has_CAMPIONE`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `DATABASE_COLLEZIONE`.`ARCHEOL_has_CAMPIONE` (
`ARCHEOL_idARCHEOL` INT NOT NULL ,
`ARCHEOL_COMUNE_idCOMUNE` INT NOT NULL ,
`ARCHEOL_COMUNE_PROVINCIA_idPROVINCIA` INT NOT NULL ,
`ARCHEOL_STATO_idSTATO` INT NOT NULL ,
`CAMPIONE_idCAMPIONE` INT NOT NULL ,
PRIMARY KEY (`ARCHEOL_idARCHEOL`, `ARCHEOL_COMUNE_idCOMUNE`,
`ARCHEOL_COMUNE_PROVINCIA_idPROVINCIA`, `ARCHEOL_STATO_idSTATO`,
`CAMPIONE_idCAMPIONE`) ,
INDEX `fk_ARCHEOL_has_CAMPIONE_CAMPIONE1_idx` (`CAMPIONE_idCAMPIONE` ASC) ,
INDEX `fk_ARCHEOL_has_CAMPIONE_ARCHEOL1_idx` (`ARCHEOL_idARCHEOL` ASC,
`ARCHEOL_COMUNE_idCOMUNE` ASC, `ARCHEOL_COMUNE_PROVINCIA_idPROVINCIA`
ASC, `ARCHEOL_STATO_idSTATO` ASC) ,
CONSTRAINT `fk_ARCHEOL_has_CAMPIONE_ARCHEOL1`
FOREIGN KEY (`ARCHEOL_idARCHEOL` , `ARCHEOL_COMUNE_idCOMUNE` ,
`ARCHEOL_COMUNE_PROVINCIA_idPROVINCIA` , `ARCHEOL_STATO_idSTATO` )
REFERENCES `DATABASE_COLLEZIONE`.`ARCHEOL` (`idARCHEOL` ,
`COMUNE_idCOMUNE` , `COMUNE_PROVINCIA_idPROVINCIA` , `STATO_idSTATO` )
43
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_ARCHEOL_has_CAMPIONE_CAMPIONE1`
FOREIGN KEY (`CAMPIONE_idCAMPIONE` )
REFERENCES `DATABASE_COLLEZIONE`.`CAMPIONE` (`idCAMPIONE` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `DATABASE_COLLEZIONE`.`ANALISI`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `DATABASE_COLLEZIONE`.`ANALISI` (
`idANALISI` INT NOT NULL ,
`Nome Analisi` VARCHAR(45) NULL ,
`Immagine Analisi` BLOB NULL ,
`Dato` DECIMAL NULL ,
`Unità di misura dato` TEXT NULL ,
`Protocollo Analisi` TEXT NULL ,
`Discussione Risultati Analisi` TEXT NULL ,
`CAMPIONE_idCAMPIONE` INT NOT NULL ,
`CAMPIONE_LITOTIPI_idLITOTIPI` INT NOT NULL ,
PRIMARY KEY (`idANALISI`, `CAMPIONE_idCAMPIONE`,
`CAMPIONE_LITOTIPI_idLITOTIPI`) )
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `DATABASE_COLLEZIONE`.`TIPO_ANALISI`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `DATABASE_COLLEZIONE`.`TIPO_ANALISI` (
`idTIPO_ANALISI` INT NOT NULL ,
`Nome Analisi` VARCHAR(45) NULL ,
`CAMPIONE_idCAMPIONE` INT NOT NULL ,
`CAMPIONE_LITOTIPI_idLITOTIPI` INT NOT NULL ,
PRIMARY KEY (`idTIPO_ANALISI`, `CAMPIONE_idCAMPIONE`,
`CAMPIONE_LITOTIPI_idLITOTIPI`) )
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `DATABASE_COLLEZIONE`.`CARATT_GEOTECNICA`
44
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `DATABASE_COLLEZIONE`.`CARATT_GEOTECNICA` (
`idCARATT_GEOTECNICA` INT NOT NULL ,
`Descrizione` TEXT NULL ,
`CAMPIONE_idCAMPIONE` INT NOT NULL ,
`CAMPIONE_LITOTIPI_idLITOTIPI` INT NOT NULL ,
PRIMARY KEY (`idCARATT_GEOTECNICA`, `CAMPIONE_idCAMPIONE`,
`CAMPIONE_LITOTIPI_idLITOTIPI`) ,
INDEX `fk_CARATT_GEOTECNICA_CAMPIONE1_idx` (`CAMPIONE_idCAMPIONE` ASC,
`CAMPIONE_LITOTIPI_idLITOTIPI` ASC) ,
CONSTRAINT `fk_CARATT_GEOTECNICA_CAMPIONE1`
FOREIGN KEY (`CAMPIONE_idCAMPIONE` , `CAMPIONE_LITOTIPI_idLITOTIPI` )
REFERENCES `DATABASE_COLLEZIONE`.`CAMPIONE` (`idCAMPIONE` ,
`LITOTIPI_idLITOTIPI` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `DATABASE_COLLEZIONE`.`CARATT_PETROGRAFICA`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `DATABASE_COLLEZIONE`.`CARATT_PETROGRAFICA` (
`idCARATT_PETROGRAFICA` INT NOT NULL ,
`Osservazioni` TEXT NULL ,
`Classificazione Petrografica` VARCHAR(45) NULL ,
`Descrizione Macroscopica` TEXT NULL ,
`Descrizione Microscopica` TEXT NULL ,
`Immagine Sezione Sottile` VARCHAR(45) NULL ,
`CAMPIONE_idCAMPIONE` INT NOT NULL ,
PRIMARY KEY (`idCARATT_PETROGRAFICA`, `CAMPIONE_idCAMPIONE`) ,
INDEX `fk_CARATT_PETROGRAFICA_CAMPIONE1_idx` (`CAMPIONE_idCAMPIONE` ASC) ,
CONSTRAINT `fk_CARATT_PETROGRAFICA_CAMPIONE1`
FOREIGN KEY (`CAMPIONE_idCAMPIONE` )
REFERENCES `DATABASE_COLLEZIONE`.`CAMPIONE` (`idCAMPIONE` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `DATABASE_COLLEZIONE`.`ANALISI_has_TIPO_ANALISI`
-- -----------------------------------------------------
45
CREATE TABLE IF NOT EXISTS `DATABASE_COLLEZIONE`.`ANALISI_has_TIPO_ANALISI` (
`ANALISI_idANALISI` INT NOT NULL ,
`ANALISI_CAMPIONE_idCAMPIONE` INT NOT NULL ,
`ANALISI_CAMPIONE_LITOTIPI_idLITOTIPI` INT NOT NULL ,
`TIPO_ANALISI_idTIPO_ANALISI` INT NOT NULL ,
`TIPO_ANALISI_CAMPIONE_idCAMPIONE` INT NOT NULL ,
`TIPO_ANALISI_CAMPIONE_LITOTIPI_idLITOTIPI` INT NOT NULL ,
`CAMPIONE_idCAMPIONE` INT NOT NULL ,
`CAMPIONE_LITOTIPI_idLITOTIPI` INT NOT NULL ,
`Data` DATETIME NOT NULL ,
PRIMARY KEY (`ANALISI_idANALISI`, `ANALISI_CAMPIONE_idCAMPIONE`,
`ANALISI_CAMPIONE_LITOTIPI_idLITOTIPI`, `TIPO_ANALISI_idTIPO_ANALISI`,
`TIPO_ANALISI_CAMPIONE_idCAMPIONE`,
`TIPO_ANALISI_CAMPIONE_LITOTIPI_idLITOTIPI`, `CAMPIONE_idCAMPIONE`,
`CAMPIONE_LITOTIPI_idLITOTIPI`, `Data`) ,
INDEX `fk_ANALISI_has_TIPO_ANALISI_TIPO_ANALISI1_idx`
(`TIPO_ANALISI_idTIPO_ANALISI` ASC, `TIPO_ANALISI_CAMPIONE_idCAMPIONE` ASC,
`TIPO_ANALISI_CAMPIONE_LITOTIPI_idLITOTIPI` ASC) ,
INDEX `fk_ANALISI_has_TIPO_ANALISI_ANALISI1_idx` (`ANALISI_idANALISI` ASC,
`ANALISI_CAMPIONE_idCAMPIONE` ASC, `ANALISI_CAMPIONE_LITOTIPI_idLITOTIPI` ASC)
,
INDEX `fk_ANALISI_has_TIPO_ANALISI_CAMPIONE1_idx` (`CAMPIONE_idCAMPIONE` ASC,
`CAMPIONE_LITOTIPI_idLITOTIPI` ASC) ,
CONSTRAINT `fk_ANALISI_has_TIPO_ANALISI_ANALISI1`
FOREIGN KEY (`ANALISI_idANALISI` , `ANALISI_CAMPIONE_idCAMPIONE` ,
`ANALISI_CAMPIONE_LITOTIPI_idLITOTIPI` )
REFERENCES `DATABASE_COLLEZIONE`.`ANALISI` (`idANALISI` ,
`CAMPIONE_idCAMPIONE` , `CAMPIONE_LITOTIPI_idLITOTIPI` )
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_ANALISI_has_TIPO_ANALISI_TIPO_ANALISI1`
FOREIGN KEY (`TIPO_ANALISI_idTIPO_ANALISI` ,
`TIPO_ANALISI_CAMPIONE_idCAMPIONE` ,
`TIPO_ANALISI_CAMPIONE_LITOTIPI_idLITOTIPI` )
REFERENCES `DATABASE_COLLEZIONE`.`TIPO_ANALISI` (`idTIPO_ANALISI` ,
`CAMPIONE_idCAMPIONE` , `CAMPIONE_LITOTIPI_idLITOTIPI` )
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_ANALISI_has_TIPO_ANALISI_CAMPIONE1`
FOREIGN KEY (`CAMPIONE_idCAMPIONE` , `CAMPIONE_LITOTIPI_idLITOTIPI` )
46
REFERENCES `DATABASE_COLLEZIONE`.`CAMPIONE` (`idCAMPIONE` ,
`LITOTIPI_idLITOTIPI` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;
47
BIBLIOGRAFIA
ELMASRI RAMEZ A., NAVATHE SHAMKANT B., Sistemi di basi di dati. Fondamenti. Pearson
Education Italia, 2007.
ATZENI P., CERI S., PARABOSCHI S., TORLONE R., Basi di dati Modelli e linguaggi di
interrogazione, 2/ed. McGraw-Hill, Milano, 2006.
VETTI TAGLIATI L., UML e Ingegneria Del Software, Dalla Teoria Alla Pratica, Hops, Milano,
2003.
http://www.mysql.it/
http://www.wiscorp.com/
http://php.net/
http://www.apache.org/
48