Organizzazione di dati fenologici in un database relazionale: l'esempio della banca dati del Progetto Finalizzato Phenagri

Transcript

1 CAPITOLO 6 Organizzazione di dati fenologici in un database relazionale: l'esempio della banca dati del Progetto Finalizzato Phenagri A. Calì, G. Dal Monte 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.

2 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 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 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.

3 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.

4 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 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;

5 - 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 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).

7 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

8 correlate, memorizzate nel DB, e per effettuare le operazioni di aggiornamento, ricerca, elaborazione, estrazione e confronto richieste dall'utente 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 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.

9 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à

10 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 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.

11 Bibliografia 1994."Microsoft Access v Manuale dell'utente". Microsoft Corporation, 956 pp. Atzeni P., Ceri S., Paraboschi S., Torlone R., Basi di dati. Mc Graw- Hill, 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, Gardin L, Napoli R., Costantini E. A. C., "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, Gauthier, L., Guay, R., "Using object-oriented database management technology in agricultural decision support software". Canadian Agricultural Engineering Vol. 40, n 3, Jennings R.,1997. "La Grande Guida ACCESS 97". Jackson libri. 921 pp.