CAPITOLO 6
Organizzazione di dati fenologici in un
database relazionale: l'esempio della banca
dati del Progetto Finalizzato Phenagri
A. Calì, G. Dal Monte
6.1 - Introduzione
Le informazioni provenienti da una rete di rilevamento fenologico,
annotate di solito su schede di campagna, necessitano di una organizzazione per
poter essere utilizzate al meglio. E’ opportuno, allora, che tali informazioni
affluiscano in una banca dati (o database) che permetta una loro consultazione
facile e veloce.
Prima ancora di dedicarsi alla realizzazione della banca dati, però, é
fondamentale assicurarsi che le informazioni provenienti dalla rete siano il più
possibile omogenee nel tempo e nello spazio. Ciò vuol dire che, in tutti i siti di
rilevamento che compongono la rete, i rilievi devono avvenire secondo gli
stessi criteri (per es. utilizzo della stessa scala fenologica per la descrizione
delle fasi), e questi ultimi devono rimanere, per quanto possibile, invariati nel
tempo. Pertanto molta attenzione dovrà essere rivolta all’impostazione dei
protocolli di rilevazione e alla formazione del personale addetto. Lo sforzo
compiuto in questa fase è garanzia per una più spedita organizzazione della
banca dati e permette di avere un insieme di dati confrontabili, che aumenta il
suo valore con l’allungarsi della serie storica.
La maggior parte dei software attualmente disponibili per la realizzazione
di banche dati sono del tipo definito “relazionale” (RDBMS: Relational
DataBase Management System -Sistema di gestione di banche dati relazionali),
anche se comincia a suscitare interesse e a diffondersi un altro tipo di database,
definito "orientato agli oggetti" (OODBMS: Object-Oriented DataBase
Management System). I database relazionali sono caratterizzati dalla capacità di
mettere in relazione informazioni che si riferiscono ad argomenti diversi ma
collegati, ciascuno memorizzato separatamente. Tramite queste “relazioni”,
ogni gruppo di informazioni può essere memorizzato una volta sola, per poi
essere richiamato e collegato agli altri gruppi di informazioni tutte le volte che
ciò risulta necessario. I vantaggi che ne conseguono sono relativi al ridotto
tempo di immissione dei dati, al risparmio di memoria e ad una gestione dei
dati più veloce e flessibile.
6.2 - Progettazione del database
In base all’esperienza condotta nell’ambito del Progetto Finalizzato
Phenagri (P.F.), la fase di progettazione di un database (DB) relazionale vede i
seguenti passaggi fondamentali:
1. definizione dello scopo
2. definizione delle tabelle
3. definizione dei campi
4. definizione delle relazioni
5. verifica e revisione della struttura
6.2.1 - Definizione dello scopo
Definire lo scopo per il quale si vuole realizzare una banca dati significa
definire il tipo di dati da memorizzare e le domande alle quali, tramite questi
dati, si vuole dare risposta.
I dati dei rilievi agrofenologici, prodotti sia dal P.F. che all'esterno, raccolti
su diverse specie, località e anni, sono organizzati nel DB Phenagri per i
seguenti scopi:
a) confrontarli in modo ragionato, sia nel tempo (ad es. comportamento di una
stessa specie nelle diverse annate in uno stesso sito) che nello spazio ( ad
es. comportamento di una stessa specie nella stessa annata ma in località
diverse ), anche in parallelo con i dati meteorologici;
b) effettuare delle specifiche elaborazioni (ad es. durata in giorni
dell'intervallo tra due fasi, anticipi o ritardi rispetto alla norma, etc.);
c) validare i modelli di sviluppo delle colture;
d) trasporli in un GIS (Sistema Informativo Geografico).
In concreto l'obiettivo del DB è stato quello di permettere:
1. l'immissione e l'organizzazione, direttamente dalle schede di campagna, dei
dati rilevati;
2. la consultazione e l’estrazione dei dati secondo criteri opportuni;
3. il trasferimento dei dati fenologici ad altri software, quali i GIS, i modelli
fenologici di sviluppo delle colture e i fogli elettronici.
6.2.2 - Definizione delle tabelle
Per la corretta impostazione del DB è necessaria una analisi approfondita
dei dati da archiviare, al fine di stabilire gruppi di informazioni omogenee.
Ciascuno gruppo si deve riferire ad un tema specifico all'interno dell'argomento
generale trattato nel database.
I gruppi di informazioni omogenee sono organizzati in tabelle e i legami
logici che le uniscono (“relazioni”) costituiscono la struttura portante del
database, sulla quale si appoggiano gli altri elementi, come query, maschere,
report, etc..
I dati da memorizzare vengono inseriti nelle tabelle, tante quanti sono gli
argomenti su cui il database si articola. Una tabella è composta da righe e
colonne, similmente ai fogli elettronici: le righe costituiscono i “record” del
database e le colonne i “campi” ( Fig. 1 ).
Fig. 1: Esempio di tabella creata con il programma MS Access con “campi” (colonne) e
“record” (righe).
La corretta definizione delle tabelle, e delle relazioni che le uniscono,
rappresenta il “cuore” del DB stesso.
Se questo aspetto risulta ben progettato (non a caso si parla di
“architettura” del DB), le informazioni contenute nella banca dati saranno
facilmente disponibili per qualsiasi tipo di elaborazione.
Per il DB Phenagri, l’analisi dei dati ha evidenziato tre tipologie di
informazioni:
1. anagrafiche: relative alla localizzazione del sito di osservazione, alle sue
caratteristiche topografiche, geografiche e pedologiche, all’ente o persona
responsabile dei rilievi, alla stazione meteorologica di riferimento;
2. sull’unità elementare di osservazione (tesi): informazioni riguardanti il
materiale biologico (famiglia, specie, varietà) e le pratiche colturali (regime
irriguo, epoca di semina, ...);
3. sui rilievi: informazioni relative ai rilievi fenologici veri e propri e agli
argomenti correlati, come dati di laboratorio (pH, acido tartarico, acido
malico, contenuto in olio, etc.), dati agronomici (avversità, trattamenti,
produzione etc.) e dati meteorologici (temperatura massima, temperatura
minima, precipitazioni, etc.).
E’ importante sottolineare che, mentre il primo tipo di informazioni di
norma rimane fisso nel tempo, gli altri due gruppi sono variabili e quindi
soggetti ad aggiornamenti ed integrazioni.
Nel DB Phenagri le tabelle in cui i dati sono stati raggruppati sono nove, e
cioè: ENTE, SITO, STAZIONE_METEO, RILIEVI_METEO, TESI,
DATI_AGRONOMICI, REPLICA, RILIEVI_FENO, RILIEVI_ACCESSORI.
6.2.3 - Definizione dei campi
Stabilire i campi che devono entrare a far parte di ogni tabella significa
individuare preliminarmente quali sono gli attributi necessari per definire in
modo compiuto l'argomento a cui la tabella si riferisce.
Per il Progetto Finalizzato Phenagri, ad esempio, l'argomento "Ente
responsabile dei siti di rilievo fenologico", trattato nella tabella ENTE, viene
compiutamente descritto dai 10 campi visibili in figura 2.
E’ opportuno citare alcuni criteri da seguire per la definizione dei campi, e
cioè:
- devono essere effettivamente attributi relativi all’argomento trattato dalla
tabella;
- devono descrivere compiutamente in tutti i suoi aspetti l’argomento di ogni
tabella;
- devono essere distinti per ogni elemento di informazione, in modo da
suddividere il più possibile le informazioni: ad esempio, può essere
opportuno creare due campi distinti "NOME" e "COGNOME" piuttosto che
inserire i due elementi in un unico campo;
-
non devono contenere dati derivanti da calcoli, perché sarà il DB stesso ad
effettuare i calcoli quando necessario;
uno stesso campo non può essere contenuto in più tabelle.
Fig. 2: Struttura di una tabella creata con il programma MS Access.
6.2.4 - Definizione delle relazioni
Per garantire un corretto funzionamento del DB, ogni tabella deve
contenere almeno un campo che identifichi in modo univoco ciascun record
memorizzato in quella tabella; un campo soddisfa questa condizione se, per
ciascun valore assunto dal campo, esiste uno, ed uno solo, record con quel
valore.
Tra i vari campi che possono presentare queste caratteristiche è necessario
sceglierne uno e definirlo come “chiave primaria” di quella tabella: ciò servirà
per associare e raggruppare rapidamente dati provenienti da tabelle diverse. Ad
esempio, in una tabella che memorizzi informazioni su una categoria di
persone, il campo "nome" e il campo "cognome" non possono garantire, né
singolarmente né combinati tra di loro, l'univocità del loro contenuto. Il campo
"codice fiscale", invece, offre questa garanzia e rappresenta pertanto un campo
che può diventare “chiave primaria” della tabella di cui fa parte.
Se una tabella di un DB non contiene alcun campo o combinazione di
campi con le caratteristiche di chiave primaria, può risultare utile inserire un
campo ad hoc, tramite il quale si assegna un numero identificativo ad ogni
record di quella tabella. Questo è ciò che é stato fatto nel DB Phenagri: poiché
in alcune tabelle non risultavano presenti campi con le caratteristiche di
univocità richieste, si è deciso di aggiungere in ogni tabella un apposito campo
ID (identificativo) che contiene un numero progressivo per individuare in
maniera univoca ogni record di ciascuna tabella. Così l'ID_RilievoFeno, ad
esempio, è un campo che contiene un numero progressivo con il quale è
identificato ciascun rilievo fenologico non appena viene memorizzato nel DB.
Una volta scelte le chiavi primarie di ogni tabella del DB, si può dire di
aver completato la prima parte della progettazione, quella in cui si è esplicitato
dettagliatamente quali saranno gli argomenti del DB (tabelle), quali saranno gli
attributi di ciascun argomento (campi) e qual è l'attributo che identifica
l'argomento in maniera univoca (chiave primaria).
Fig. 3: Schema relazionale del DB Phenagri.
A questo punto si può passare alla fase successiva, quella in cui bisogna
individuare i rapporti che sussistono tra i diversi argomenti del DB, cioè
bisogna analizzare i dati di ciascuna tabella e stabilire le relazioni che
intercorrono tra le informazioni contenute nelle diverse tabelle del DB.
Con questa operazione vengono messe in connessione le tabelle l'una con
l'altra e vengono attivati i collegamenti tra le informazioni. Il software di
gestione del DB si servirà di queste relazioni per ricercare le informazioni
correlate, memorizzate nel DB, e per effettuare le operazioni di aggiornamento,
ricerca, elaborazione, estrazione e confronto richieste dall'utente.
6.2.5 - Verifica e revisione della struttura
Una volta definite le relazioni del DB, per completare il processo di
progettazione è necessario sia analizzare di nuovo nel dettaglio ogni singolo
elemento, sia dare uno sguardo d'insieme a quanto realizzato, per verificarne la
coerenza logica e funzionale. Per garantire l'efficacia di questa verifica è
opportuno controllare che il DB sia conforme a due criteri fondamentali,
l'”integrità” e la “normalizzazione”.
L'integrità del DB è garantita dal rispetto di due regole generali, valide
indipendentemente dal software utilizzato per la gestione del DB: l’integrità
dell'entità e l'integrità referenziale.
La prima stabilisce che una chiave primaria non può contenere valori nulli
né valori duplicati, mentre la seconda serve ad assicurare che le relazioni tra i
record delle tabelle correlate siano valide e che non vengano eliminati o
modificati per errore i dati correlati.
La normalizzazione di un DB è un processo che mira a raggiungere tre
scopi: eliminare informazioni ridondanti, incrementare l'integrità dei dati e
rendere il sistema più efficiente.
Una volta effettuata la revisione, si può considerare esaurita l'attività di
progettazione della struttura portante del DB.
6.2.6 - Interrogazione dei dati
Il vero scopo finale di una banca dati non è tanto quello di contenere ed
organizzare i dati, quanto, piuttosto, quello di fornire risposte adeguate alle
interrogazioni effettuate dagli utenti. La parte del DB dedicata a rendere
possibili le interrogazioni è la parte che finalizza e dà visibilità a tutto il lavoro
precedentemente realizzato; è, di solito, l’unica parte con la quale l’utente finale
ha un contatto diretto.
Da qui l’importanza di curarne la facilità di utilizzo e la flessibilità dei
criteri di ricerca dei dati di interesse.
Un DB ben progettato dal punto di vista logico permetterà un accesso
flessibile ai dati, rispondendo in maniera puntuale alle interrogazioni degli
utenti.
Lo strumento tramite il quale vengono effettuate le interrogazioni
all’interno di un DB viene definito, con il termine inglese, “query” (domanda,
interrogazione). Le query sono uno strumento fondamentale in qualsiasi sistema
di gestione di DB. Possono essere utilizzate, ad esempio, per selezionare gruppi
di specifici record, per raggruppare e successivamente visualizzare informazioni
provenienti da differenti tabelle.
Il DB Phenagri è stato impostato in modo da permettere l’interrogazione
parallela dei dati fenologici e dei corrispondenti dati meteorologici. Le
interrogazioni vengono costruite dall’utente all’interno di una maschera (Fig.
4), che lo guida nelle scelte da effettuare di volta in volta: i criteri di selezione
dei dati da consultare vengono inseriti tramite menù a tendina, scegliendoli tra
tutti quelli disponibili.
Il punto di partenza dell’interrogazione è costituito dalla scelta dell’ente
responsabile delle osservazioni in campo.
Fig. 4: Maschera di consultazione dati.
Poiché un ente può gestire più di un campo o azienda sede di rilievi fenologici,
è possibile scegliere l’azienda di interesse, tra quelle afferenti all’ente già
selezionato in precedenza. Se il sito prescelto è associato ad una stazione
meteorologica di riferimento, si attiverà nella maschera anche una sezione che
consentirà all’utente di scegliere, tra i dati meteorologici disponibili, quelli che
maggiormente interessano.
Successivamente è necessario indicare l’intervallo temporale (data di inizio
e data di fine) su cui effettuare la ricerca e una serie di informazioni (varietà,
epoca di semina, regime idrico e numero di pianta), che consentono di
individuare la tesi sperimentale della quale si vogliono esaminare i dati.
L’informazione sul numero della pianta è resa necessaria dal fatto che,
nell’ambito di Phenagri, il rilievo della fase fenologica non è relativo ad una
parcella o ad un appezzamento nel suo complesso, ma è relativo a singoli
individui scelti a caso all’inizio della campagna di rilevamento; di conseguenza,
l’utente può selezionare la pianta (o le piante) di cui vuole avere i rilievi
fenologici, oppure tutte le piante (il numero varia da 5 a 20 a seconda della
coltura).
Dopo che l’utente ha inserito tutte le opzioni previste, il DB visualizza il
risultato della interrogazione in due maschere separate, una per i dati fenologici
e l’altra per i dati meteorologici, all’interno delle quali è possibile:
effettuare una stampa dei dati visualizzati;
trasferire i dati su foglio elettronico Excel (l’indirizzo in cui viene salvato il file
con formato *.xls viene comunicato all’utente tramite un apposito messaggio).
Tornando alla maschera di interrogazione dati, con un apposito pulsante si
possono poi annullare le selezioni precedentemente effettuate e procedere così
ad una nuova interrogazione.
Note
Si riportano alcuni siti Internet che contengono informazioni e spiegazioni
per la realizzazione di un DB
http://www.athree.com/
http://support.microsoft.com/support/kb/articles/Q88/6/57.asp>
Nella realizzazione del DB Phenagri sono stati presi come riferimento le
strutture dei DB agrofenologici del Servizio Meteorologico Regionale
dell'Emilia Romagna e del Servizio Agrometeorologico Regionale della
Sardegna.
Bibliografia
1994."Microsoft Access v. 2.0. Manuale dell'utente". Microsoft Corporation,
956 pp.
Atzeni P., Ceri S., Paraboschi S., Torlone R., 1999. “Basi di dati”. Mc GrawHill, Milano, 620 pp.
Bechini L.,1999. “Le strutture di database come elemento del sistema di qualità
in agrometeorologia”. Atti del workshop nazionale di agrometeorologia AIAM
99 “Agrometeorologia e qualità dei dati”, 66-73.
Gardin L, Napoli R., Costantini E. A. C., 1996. "Architettura di un database
relazionale per un sistema informativo pedologico". Atti del Convegno
"Contributi della scienza del suolo allo studio e alla difesa dei territori montani
e collinari", Bollettino della società italiana di scienza del suolo, n° 8, dicembre
1996, 165-182.
Gauthier, L., Guay, R., 1998. "Using object-oriented database management
technology in agricultural decision support software". Canadian Agricultural
Engineering Vol. 40, n° 3, 219-226.
Jennings R.,1997. "La Grande Guida ACCESS 97". Jackson libri. 921 pp.
