Dettagli

Categoria: Informatica

Creato Martedì, 30 Agosto 2011 18:10

Ultima modifica il Sabato, 01 Novembre 2014 04:18

Scritto da Claudio Romeo

 

Introduzione all’uso di Base

Questo tutorial descrive l’uso basilare di Base. Il tutorial è basato su OpenOffice.org, ma vale anche per LibreOffice. Verifica le versioni usate e la compatibilità

Le basi di dati, o database, sono probabilmente le fondamenta di una società fortemente organizzata. Senza di esse, non potrebbero esistere servizi che prevedono l’invio di bollette, non si potrebbe fare la spesa al supermercato né si potrebbe navigare su Internet sfogliando pagine dinamiche.

La gestione dei database è perciò un’attività estremamente delicata, che richiede l’opera di professionisti qualificati e che va curata fin dalle origini: la progettazione di una base di dati è probabilmente una delle operazioni che possono avere le più grandi ripercussioni negative se non vengono effettuate a regola d’arte.

In questo articolo viene esaminata la prima fase di costruzione di un database mediante OpenOffice.org Base: la costruzione di tabelle e la loro messa in relazione. Coloro che sono totalmente digiuni dell'argomento trovano qui un glossario minimo.

Database a regola d'arte

Tra gli errori che più frequentemente vengono commessi da persone non esperte, due sono quelli tipici: l’uso di dati non atomici e l’introduzione di dati ridondanti.

Oltre a queste due norme che riguardano strettamente la qualità dei dati da memorizzare, ve n’è un’altra che interessa invece la struttura complessiva del database: quasi mai è opportuno costruire un’enorme tabella contenente tutti i dati, ma è preferibile costruire più tabelle e metterle in relazione tra loro. In altre parole, i database relazionali sono molto più semplici da gestire, anche se la loro costruzione richiede qualche sforzo in più.

C’è da dire che per le piccole necessità quotidiane non vale la pena perdere la testa nell’impiantare un database relazionale: un semplice foglio elettronico può essere più che sufficiente per memorizzare le spese di casa e condurre le analisi alla ricerca del sistema per far quadrare i conti. Non per nulla si dice che Excel è il gestore di database più usato al mondo...

Quando però le cose diventano più complesse, allora è meglio affidarsi a un vero gestore di database e non a surrogati estemporanei come un foglio elettronico o un elaboratore di testi. Il tipico esempio è l’emissione di fatture: è un’attività che effettivamente può essere svolta mediante Calc o Writer (o i loro corrispondenti Microsoft Excel e Word), ma se il giro di fatture inizia a essere a tre cifre all’anno, conviene usare uno strumento più potente. Allo stesso modo, l’uso di un gestore di database conviene anche per fini meno aziendali e più ludici: tenere in ordine la propria raccolta di film, di libri o di dischi, per esempio.

Prima di addentrarsi nell’esame delle funzioni di Base, il gestore di database di OpenOffice.org, è il caso di chiarire alcuni punti fermi teorici generali, in modo da essere in grado di costruire basi dati a prova di bomba.

Dati atomici

Il primo punto fermo della teoria dei database è che i dati devono essere atomici, o nucleari. Ovviamente, atomico va inteso nel significato originale di non divisibile, non in quello che ha a che fare con la radioattività.

Per esempio, un ipotetico campo chiamato Nome e indirizzo che richiedesse l’introduzione sia del nome della persona sia del suo indirizzo di residenza non sarebbe atomico: si tratta di due dati differenti, la cui natura è completamente diversa. Diverrebbe molto difficile ordinare l’elenco in base all’indirizzo, per esempio. In questo caso, sarebbe corretto usare due campi: un campo Nome e un campo Indirizzo.

In realtà, non sempre le cose sono così nette come potrebbe sembrare; l’atomicità del dato dipende talvolta dall’uso che si intende fare del database. Per esempio, in determinate situazioni un ipotetico campo Cognome e nome potrebbe essere considerato atomico, senza dover prevedere la suddivisione nei due campi Cognome e Nome. Una situazione di questo tipo si verifica per esempio nel database di fatturazione di un’azienda: quello che viene ricercato è infatti l’intera stringa con il cognome e il nome del cliente, o la sua ragione sociale se si tratta di un’altra azienda; in questo caso, il dato può essere considerato nucleare. Nel caso invece di un elenco telefonico, un’ipotetica ricerca potrebbe essere condotta su tutte le persone con un determinato cognome che vivono nella stessa città: è lampante che il dato (il cognome e il nome) deve essere disgiunto.

La prima regola potrebbe perciò essere riassunta così: occorre valutare l’uso che si farà della base di dati e organizzare i dati stessi affinché siano atomici rispetto ad esso. Resta da aggiungere che in caso di dubbio la soluzione migliore è atomizzare tutte le volte: è sempre possibile aggregare i dati con relativa facilità, mentre spezzarli è richiede una fatica ben più improba.

Dati non ridondanti

La ridondanza dei dati è un’altra trappola insidiosa spalancata sotto i primi passi dei novizi. Una base dati organizzata correttamente non prevede campi doppi, destinati a contenere la stessa informazione. Se così fosse, oltre allo spreco di spazio su disco ci si esporrebbe al pericolo di discrepanza tra i dati stessi, magari a causa di un banale errore di battitura.

Ci si ricordi che è meglio avere una sola ricorrenza del dato, sbagliata, piuttosto che due, delle quali una giusta e una sbagliata. Questo apparente paradosso è in realtà molto semplice da intuire: se si scopre un dato sbagliato, è facile correggerle se è unica la sua posizione all’interno del database. Se il dato compare invece in più posizioni, diventa un incubo andare a pescare quella che ha bisogno della correzione.

Detto questo, alcune ridondanze sono abbastanza appariscenti. Per esempio, in un ipotetico database di un’associazione che riserva alcune attività solo agli iscritti maggiorenni, è inutile e potenzialmente dannoso contemplare sia il campo Data di nascita (che contiene la data di nascita e viene utilizzato per esaminare l’età media degli iscritti) sia il campo Maggiorenne (che è un campo di tipo Sì/no e serve solo a verificare se l’iscritto è abilitato alle attività riservate ai maggiorenni). Qualunque database è in grado di condurre ricerche del tipo “verifica se tra la data di nascita dell’iscritto e la data odierna sono passati più di diciotto anni” oppure del tipo “trovami tutti gli iscritti che a oggi hanno più di diciotto anni”. Occorre perdere un po’ di tempo per definire (una sola volta per sempre) le opzioni di ricerca, ma poi il lavoro lo fa il gestore di database. In compenso, non si deve scorrere ogni giorno l’elenco degli iscritti per verificare se qualcuno è diventato maggiorenne e modificare quindi il suo stato.

Altre ridondanze possono essere un po’ più nascoste. Nel caso della fatturazione, un dato essenziale è il prezzo imponibile del bene; su di esso grava poi l’importo dell’IVA, il cui ammontare è determinato dall’aliquota cui è soggetto il bene stesso. Ora, non è necessario predisporre nel database sia il campo dell’aliquota sia il campo dell’ammontare dell’IVA: quest’ultimo è un campo calcolato (prezzo del bene per aliquota dell’IVA), perciò è sufficiente predisporre il gestore del database a calcolare l’importo quando serve, senza memorizzarlo in modo permantente.

Incidentalmente, va notato che, poiché le aliquote IVA variano col tempo e coi governi, è però indispensabile che le fatture emesse vengano registrate in un’apposita tabella non modificabile, in modo che richiamando una fattura vecchia l’importo dell’IVA e l’importo totale non vengano ricalcolati mediante i nuovi parametri.

Relazione tra tabelle

Scomporre la base di dati in più tabelle messe in relazione tra loro è il sistema più semplice per renderla snella ed efficiente.

Si immagini/ un’ipotetica motorizzazione civile nel cui database vi siano i dati sia di tutti gli autoveicoli (modello, produttore, cilindrata, tipo di carburante, numero di posti eccetera) sia di tutti i possessori di veicoli (cognome, nome, indirizzo, data della patente e così via). Per associare a ogni proprietario di autoveicolo l’automezzo da lui posseduto occorrerebbe una tabella molto estesa; oltretutto, per ogni proprietario sarebbero riportati tutti i dati dell’automezzo, identici a quelli riportati negli altri proprietari di automezzi identici. Sarebbe uno spreco di spazio su disco e un esporsi a possibili errori: basterebbe infatti che in un caso si scrivesse Fait anziché Fiat e il database darebbe risultati non corretti.

Per evitare questi problemi basta associare a ogni modello di autoveicolo un codice. Nella tabella dei proprietari, anziché riportare tutti i dati del veicolo posseduto basta perciò riportare il codice dell’autoveicolo: semplice, lineare e a prova di errori.

Per far ciò è necessario che vengano create due tabelle (Proprietari e Autoveicoli) e che esse siano messe in relazione: che l’una contenga cioè un campo che punta direttamente a un campo dell’altra tabella; nel caso dell’esempio, è il codice del veicolo.

Una volta stabilita la relazione, diventa facile per il gestore del database estrarre i dati dell’autoveicolo posseduto da una determinata persona o cercare tutte le persone che possiedono veicoli a GPL.

La relazione tra tabelle è lo strumento in più che pone i gestori di database relazionali su un piano nettamente più alto rispetto ai fogli elettronici e, ovviamente, agli elaboratori di testo.

Avvio di Base e procedura guidata

Sulla falsariga di Microsoft Access, avviando Base viene contestualmente avviata una procedura guidata (Figura 1) che chiede come operare per aprire un database: se crearlo da zero, se aprirne uno esistente o se collegare un nuovo database di Base a una base di dati già esistente. In quest’ultimo caso si ha la possibilità di usare un database creato con altri gestori, tra cui Calc. Tuttavia in alcuni casi (Calc è tra questi), non sono permesse operazioni di modifica, ma solo di ricerche e di costruzioni di rapporti.

La mancanza della possibilità di modifica dei dati non è sempre una sciagura. Per esempio, può essere un modo per separare le operazioni (e gli utenti) di introduzione dei dati da quelle di ricerca e di rendiconto. In ogni caso, restando nel mondo del software libero, i formati di database che meglio si prestano ad essere gestiti con Base sono quello di Base stesso e (con alcuni limiti) quello di MySQL, il gestore di database professionale sviluppato anch’esso, come OpenOffice.org, da Sun.

I database di Microsoft Access non sono subito utilizzabili da Base per Mac né da Base per Linux: solo Base per Windows ha la possibilità di gestire file di Access. Esiste però la possibilità di importare (non di collegare) le tabelle di Access in Base per Windows e poi utilizzare il file di Base in ambiente Mac. Non è una soluzione sicura al 100%, ma dovrebbe funzionare.

Se non si ha alcuna dimestichezza con i database, con Base o con Access, è consigliabile fare un po’ di pratica usando la creazione guidata per realizzare velocemente qualcuno dei database proposti ed esaminarne poi la struttura. Il passo successivo potrebbe essere creare un database vuoto e costruire le tabelle da zero (in vista Struttura, secondo la terminologia di Base). Partendo da cose semplici si ha modo di fare esperienza senza troppa confusione.

Per esempio, scegliendo Crea un nuovo database e facendo clic sul pulsante Avanti viene visualizzata la finestra riportata nella Figura 2, che offre la possibilità di registrare il database. La registrazione di un database in OpenOffice.org non ha nulla a che fare con la memorizzazione su disco (operazione che verrà compiuta più avanti), ma significa che il database che si sta creando può essere automaticamente utilizzato come sorgente di dati da tutte le applicazioni OpenOffice.org; finché si tratta di database di prova, conviene deselezionare la casella. Le caselle Apri il database per la modifica e Crea nuove tabelle con la procedura guidata andrebbero invece selezionate: la prima fa sì che il database venga subito aperto per la modifica, mentre la seconda avvia una nuova procedura guidata per la creazione di tabelle predefinite.

La procedura guidata per la creazione delle tabelle (che può essere avviata anche in seguito, a database già realizzato) consente innanzi tutto di scegliere tra tabelle legate alla professione o all’uso personale e conseguentemente di selezionare sia la tabella tra quelle proposte sia i campi che la comporranno.

Per esempio, scegliendo la tabella Piante della categoria Personale, si possono scegliere i campi che faranno parte della tabella; per ogni campo è inoltre possibile impostarne le proprietà (Figura 3). Se si desidera, è anche possibile aggiungere altri campi, facendo clic sul pulsante + posto in fondo all’elenco.

Ogni tabella deve possedere una chiave primaria, cioè un campo o una combinazione di campi in grado di identificare univocamente i record (Figura 4). In altre parole, non è possibile che più record abbiano la chiave primaria con lo stesso valore.

La chiave primaria consente di stabilire correttamente le relazioni e di effettuare ricerche sensate. Il campo utilizzato come chiave primaria non deve essere necessariamente un campo in cui inserire dati significativi dal punto di vista umano: spesso la strada più comoda è usare un campo contenente un numero progressivo, inserito automaticamente da Base (Figura 5).

Le proprietà dei campi delle tabelle possono essere modificate anche in un secondo momento, purché le tabelle siano vuote o non contengano dati incompatibili con le nuove impostazioni.

Dopo aver creato la prima tabella del database, si può ripetere la procedura guidata e creare altre tabelle. Oppure si possono creare nuove tabelle a mano, agendo in vista Struttura e partendo da zero.

La finestra principale di Base è organizzata in tre riquadri: Database, Attività e quella specifica dell’elemento selezionato nel riquadro Database. Nel caso dell’esempio della Figura 6, il terzo riquadro è Tabelle.

Il riquadro Database offre subito un’indicazione precisa su come Base gestisca i database. Gli elementi fondamentali sono le tabelle, che contengono i dati. Le ricerche sono istruzioni per estrarre dalle tabelle solo i dati corrispondenti a determinati valori. I formulari sono interfacce più comode delle tabelle nude e crude (o delle ricerche) per visualizzare e filtrare i dati. I rapporti sono infine elenchi di dati estratti da tabelle o da ricerche e presentati in forma generalmente aggregata, in un documento Writer o Calc.

Il riquadro Attività elenca le operazioni che è possibile compiere sugli elementi selezionati nel riquadro Database.

Il terzo riquadro elenca invece gli elementi del tipo selezionato nel riquadro Database che sono già stati creati. Nell’esempio della già citata Figura 6, vi è una sola tabella, chiamata Piante.

Dopo questa panoramica sulla creazione delle tabelle e sugli elementi fondamentali di un database, è opportuno esaminare un po’ più in profondità sia il concetto stesso di tabella sia l’uso delle tabelle in Base. Poi verranno presi in considerazione anche gli altri elementi di Base.

Le tabelle e le viste

La componente fondamentale di un database sono le tabelle. Un database può essere costituito da una sola tabella o da più tabelle messe in relazione.

La prima tabella di un database può essere realizzata insieme con il database stesso mediante la procedura guidata vista in precedenza. Altre tabelle possono essere create richiamando la procedura guidata facendo clic sul comando Usa procedura guidata per la creazione di tabelle, nel riquadro Attività.

Facendo invece clic sul comando Crea tabella in vista struttura, viene richiamata la finestra già riportata nella Figura 5, che consente di definire manualmente i nomi dei campi e le loro proprietà. Ovviamente, a differenza di quanto visibile nella figura, all’inizio la tabella è completamente vuota. Per creare un campo basta scriverne il nome nella prima riga libera della colonna Nome campo. Facendo clic nella cella adiacente, nella colonna Tipo campo, si apre un elenco da cui scegliere il tipo di dato che il campo deve contenere (Figura 7).

Questa operazione è delicatissima; è infatti necessario scegliere con cura il tipo di campo, valutando soprattutto l’uso che se ne farà e lo spazio occupato su disco. Per esempio, se il dato è un valore numerico che sarà sottoposto ad aggregazione o ad altre operazioni matematiche, per forza andrà scelto uno dei tipi numerici e in campi di questo tipo non potranno essere inseriti testi. I tipi principali sono numero, testo e data, ognuno delle quali ha diversi sottotipi. Per avere un’idea più precisa di ogni sottotipo, si può consultare la pagina di Wikipedia che si trova all’URL http://it.wikipedia.org/wiki/Tipo_di_dato_%28database%29.

Nella parte inferiore della finestra sono elencate le altre proprietà del campo, che variano secondo il tipo.

Ci si ricordi che ogni tabella deve avere un campo chiave. Per definirlo, basta fare clic destro sull’intestazione della riga del campo scelto e selezionare poi dal menu contestuale la voce Chiave primaria.

Nel riquadro Attività vi è anche la voce Crea vista. Una vista è una tabella che raccoglie campi da tabelle diverse, in modo da offrire una visione focalizzata sui campi di maggior interesse. Una vista può anche essere la base di partenza per la creazione di ricerche o di rapporti. Tuttavia non sempre i dati di una vista possono essere modificati: per esempio, se nella vista non sono stati riportati i campi con digitazione necessaria di una tabella, i dati non sono modificabili.

Le relazioni

La creazione di tabelle non è, tutto sommato, operazione difficile. Non lo è neppure la messa in relazione di due tabelle, una volta capito il meccanismo. Innanzi tutto va chiarito che i campi delle due tabelle usati per la relazione devono essere dello stesso tipo, in modo da escludere possibili errori. Nel tipo di relazione più comune (chiamato uno a molti), uno dei due campi è una chiave primaria e l’altro no; ciò che a un valore unico in una tabella possono corrispondere più record nell’altra tabella. Nel caso dell’ipotetica motorizzazione, un codice di autoveicolo corrisponde a un autoveicolo solo, ma più persone possono possederne uno.

Tra i database di esempio di OpenOffice.org Base ve n’è uno che, per quanto la sua funzione sia ormai obsoleta, serve bene allo scopo di far comprendere la messa in relazione tra due tabelle. È il database per l’archiviazione delle fotografie, che si basa sulle tabelle Fotografie e Pellicole. Il motivo per cui è obsoleto è evidente: si riferisce a un archivio fotografico dell’era analogica e non prende in considerazione alcun parametro della tecnologia digitale; inoltre, le pellicole sono ormai solo un ricordo dei fotografi con i capelli sulla via del grigio. Però il concetto rimane valido.

Nell’esempio, si dà per scontato che sia stato creato un database contenente le tabelle Fotografie e Pellicole. Per creare una relazione tra le due tabelle occorre innanzi tutto impartire il comando Strumenti > Relazioni e aprire così la finestra riportata nella Figura 8.

Se è la prima volta che la finestra viene aperta, viene anche aperta contestualmente la finestra Aggiungi tabelle, che permette di scegliere le tabelle da mettere in relazione: basta selezionarne una per volta e fare clic sul pulsante Aggiungi. Al termine, bisogna chiudere la finestra Aggiungi tabelle.

Le tabelle scelte appaiono ora nella finestra delle relazioni, come mostrato nell’esempio della Figura 9.

Ora è necessario mettere in relazione il campo chiave di una tabella con il corrispondente campo dell’altra tabella. Nell’esempio, si tratta del campo IDPellicola della tabella Pellicola con il campo IDPell della tabella Fotografie.

Per far ciò è sufficiente trascinare il campo IDPellicola sul campo IDPell. Dopo questa semplice operazione, le due tabelle sono legate da una connessione, indice dell’esistenza di una relazione (Figura 10).

Ora occorre salvare la relazione, facendo clic sul pulsante Salva; quindi si può chiudere la finestra delle relazioni.

Le relazioni tra tabelle possono essere usate per rendere più comprensibili (dal punto di vista umano) i moduli del database per l’inserimento e il recupero dei dati, cioè i formulari e i rapporti. Per esempio, è vero che ogni tipo di pellicola è identificato univocamente dal campo IDPellicola, un campo numerico, ma è anche vero che un mero codice numerico è ben più difficile da interpretare per un uomo rispetto a una descrizione testuale.

È sufficiente che la tabella sia dotata, oltre che di un codice numerico, di un campo con una descrizione testuale. Nell’altra tabella, quella con la relazione a molti, si può scegliere la descrizione testuale e Base provvede automaticamente a inserire invece il codice numerico, che fa risparmiare posto su disco.

La tecnica per realizzare questo procedimento coinvolge strumenti (le ricerche e i formulari) che vanno al di là dell’ambito di questo articolo, tuttavia è opportuno darne un assaggio: è ciò che trovate nel paragrafo "Un piccolo esempio".

Prima però, lasciatevi mettere in guardia: le relazioni possono contenere trappole nascoste. Per conoscerle e poterle evitare, date un'occhiata al box "I vizi nascosti delle relazioni".

Un piccolo esempio

Per seguire meglio l'esempio, potete scaricare il file Elenco_Film.odb, un piccolo database casereccio nato per catalogare la collezione di film in DVD. Il database si basa sulla tabella Film e sulle due tabelle di supporto Collane e Formati; queste ultime sono state create al solo scopo di rendere più compatta la tabella principale, inserendo solo un numero ma visualizzando una descrizione alfanumerica. È possibile studiare la struttura delle tabelle esaminandole direttamente dal file, mentre la Figura 11 mostra le relazioni tra di esse.

Grazie a queste relazioni è stato possibile costruire un formulario che permetta di introdurre il codice collana e il codice formato scegliendoli da un elenco testuale (Figura 12) e che traduca automaticamente tale scelta nel corrispondente codice numerico.

Lo scopo di questo articolo era fornire le basi per una buona costruzione delle tabelle mediante OpenOffice.org Base. Nella seconda parte del tutorial si esaminerà meglio il processo di costruzione delle ricerche, dei formulari e dei report.