Introduzione

Un database è - genericamente parlando - un sistema di raccolta persistente di dati.

Esistono varie tipologie di database, ma quella che più ci interessa è il database relazionale.

Il perché è presto detto: se da una parte tutti i tipi di raccolta di dati sono legittimi (in relazione all'uso che se ne intende fare), i database relazionali sono quelli in cui la possibilità di un'articolazione dei dati consente di costruire modelli di raccolta dati complessi, in grado di essere aderenti alla realtà.

Partendo dalle cose semplici in questo articolo vedremo quali sono gli elementi che costituiscono un database relazionale e ne creeremo uno semplice, ma efficace.

Il database - nozioni di base

L'elemento di partenza di ogni database è la tabella: una tabella è un insieme di righe e colonne; ogni colonna contiene un dato relativo alla cosa che stiamo descrivendo; ogni riga corrisponde ad una istanza della cosa.

Se parlassimo di persone avremmo che ogni riga corrisponde ad una persona ed ogni colonna corrisponde ad una caratteristica della persona (altezza, peso  eccetera)

In termini di database ogni colonna è un campo, ogni riga un record.

Un database può essere composto di più tabelle. Ciò che rende un database relazionale è la presenza di legami fra le tabelle, di connessioni logiche, di relazioni, appunto.

L'analisi dei dati

Ovviamente una relazione fra tabelle deve avere un suo perché: in altre parole va creata solamente quando la struttura dei dati la rende necessaria, al fine di registrare correttamente le informazioni.

Appare quindi evidente che la prima operazione da fare sia quella di analizzare i dati con cui abbiamo a che fare e di ripartirli correttamente nelle varie tabelle: questo processo prende il nome di normalizzazione dei dati.

Detto in termini più semplici la normalizzazione dei dati è il processo con cui descriviamo i nostri dati.

Vediamolo in dettaglio quali sono i principi di base.

Prima forma normale (1NF)

Una tabella è in prima forma normale se

• non contiene dati ripetitivi

Questa è una regola fondamentale: se all'interno di una tabella abbiamo campi tipo NomeCampo1, NomeCampo2 ecc vuol dire che stiamo sbagliando qualcosa. In questo caso infatti ci servirà una seconda tabella ed una relazione con la tabella di partenza.

Un esempio può essere quello di una Ditta con molti impiegati.

Se si crea una tabella con campi:
Nome Ditta
Contatto 1
Contatto 2
Contatto 3

si ottiene una struttura ripetitiva, che viola la prima forma normale e che può crearci molti problemi. Ad esempio, cosa facciamo se dobbiamo inserire un quarto contatto? Come facciamo se vogliamo fare ricerche o resoconti sui contatti?

È chiaro che abbiamo sbagliato l'impostazione iniziale: oltre ad una tabella Ditte dovremo quindi creare anche una seconda tabella Contatti, la quale, collegata a Ditte, potrà contenere tutti i contatti che vogliamo, senza limiti.

Seconda forma normale (2NF)

Una tabella è in seconda forma normale se

• è in prima forma normale

• i campi contenenti i dati sono completamente dipendenti da una chiave primaria

Per chiave primaria si intende un valore, un codice, che identifica in maniera UNIVOCA quel determinato record; di solito si tratta di un numero di serie e può anche non essere visibile all'utente.

Terza forma normale (3NF)

Una tabella è in terza forma normale se

• è in seconda forma normale

• nessun campo contenente dati è indipendente da una chiave primaria

La norma è sostanzialmente speculare alla seconda, e la completa.

Sulla normalizzazione dei dati esiste una folta letteratura, in quanto può essere più o meno spinta, a seconda di quante “forme normali” vengono seguite. In genere si ritiene sufficiente seguire le prime 3 forme normali.

Un esempio pratico

Tornando quindi all’esempio iniziale, andiamo a vedere in un esempio pratico come una struttura normalizzata ci consente di creare un database relazionale che abbia la necessaria flessibilità per descrivere adeguatamente la realtà delle cose.

Iniziamo con una tabella Ditte, in cui ogni record è identificato da una chiave primaria.

Creiamo una seconda tabella, Contatti: in questa tabella abbiamo sia una chiave primaria (che serve sempre, ma che non useremo in questo esempio) ed un campo nel quale riportiamo il codice della Ditta cui appartiene la persona. Questo campo si chiama chiave secondaria, ed è quello che viene utilizzato come "destinatario" della relazione.

Con poche semplici mosse abbiamo realizzato il nostro database relazionale.

database relazionale esempio FileMaker Guru

In FileMaker

L'analisi dei dati che abbiamo visto prescinde dallo strumento con cui realizzeremo il database, dato che la stessa logica si può applicare a FileMaker come ad Oracle o ad altri database.

Nel file si può vedere un esempio realizzato con FileMaker.  Clicca qui per scaricare il file di esempio

Commenti

La normalizzazione dei dati è fondamentale, ma non è una religione. Si tratta di un metodo di analisi il cui risultato dipende anche dalle nostre necessità.

Ripartendo dall'esempio precedente, immaginiamo di dover gestire i recapiti dei nostri contatti: dobbiamo creare un campo Recapiti nella tabella contatti o una tabella Recapiti relazionata ai Contatti?

La risposta dipende da noi: SE (e solo SE) i recapiti sono una entità del nostro database andremo a creare la tabella relazionata. Questo avviene ad esempio se vogliamo stampare delle etichette o buste con l'indirizzo della persona, o se vogliamo creare una procedura che invia una email.

Se invece ci serve tenere traccia dell'informazione può essere sufficiente avere un campo in cui "ammucchiare" tutti i dati. Formalmente può sembrare la scelta errata, ma a livello pratico creare una tabella ad hoc può essere inutile.

Stiamo rinunciando a qualcosa? Forse sì, ma stiamo anche risparmiando qualcosa.  Ricordiamoci che l'adagio "there ain't no such thing as a free lunch" vale anche nel campo dei database. Creare una struttura relazionale costa in termini di costruzione, rende le ricerche più complicate e a volte più lente, le esportazioni più complesse e non solo. Quindi se non ne abbiamo bisogno, lasciamo tranquillamente stare.

Il grado di normalizzazione e di analisi dipende dal punto di vista dell'osservatore e dal grado di dettaglio che si vuole descrivere. Come esempio immaginiamo di dover creare un database col quale gestire i ricoveri di pazienti in ospedale.

Se il mio punto di vista è quello del Ministero della Salute, i dettagli mi interessano poco, saranno quindi sufficienti i dati utili a fare statistiche (sesso, durata del ricovero, esito).

Se il mio punto di vista è invece quello del medico che visita i pazienti tutti i giorni avrò bisogno di registrare molti più dati e quindi il grado di analisi sarà di molto superiore.

Conclusioni

I database relazionali consentono di creare dei sistemi di raccolta dati flessibili ed aderenti alle nostre necessità. Per costruirli bisogna analizzare bene i dati con cui abbiamo a che fare, e le funzionalità che vogliamo realizzare.

 

Vuoi approfondire le basi dello sviluppo dei database relazionali?

Scopri subito il nostro corso "Rimettiamo le Basi": https://www.filemakerguru.it/bologna-fmguru-rimettiamo-le-basi/

2 Commenti

  1. Articolo interessante anche se avresti potuto fare un breve cenno alla IV e V NF , poco utilizzate ma pur sempre esistenti.
    Avrei preferito un esempio visuale in filemaker per la creazione di relazioni , un video , una guida , è possibile ?

    Grazie

LASCIA UN COMMENTO

Please enter your comment!
Please enter your name here