OpenOffice & MySql - Il mondo dei Database
By Filippo Cerulo - Soft.Com Sas
22 maggio 2005

Tecnica Esiste una "definizione" molto precisa dei database relazionali. Questo significa che un Database, per poter essere correttamente definito "relazionale", deve soddisfare una serie di regole che qui sarebbe lungo ed improduttivo descrivere. Secondo alcuni MySql, siccome non possiede TUTTE queste caratteristiche, NON E' a rigore un Database relazionale. Questo però a noi interessa davvero poco....

Progettiamo un Database

Abbiamo quindi definito la Tabella come l'unità logica di un Database. Ovviamente possiamo avere Database composti da una sola Tabella, ma direi che sono casi particolari. Ora siamo perciò di fronte al nostro amato PC e vogliamo cominciare a creare il nostro primo Database; la prima cosa da fare è quindi... un bel passo indietro.

Infatti l'approccio più sbagliato che possa esistere è partire con la struttura di un Db senza averci prima ben riflettuto... magari davanti ad un bel foglio bianco e con una cara e vecchia penna in mano. Voglio dire che in generale è fondamentale "progettare" il Database PRIMA di mettere la manine sulla tastiera, ed allora il saggio consiglia che bisogna porsi in anticipo le seguenti domande:

1. di quante e quali unità logiche (tabelle) deve essere composto il mio Db?
2. per ogni tabella, quali informazioni (campi) devo comprendere?
3. per ogni campo di ogni tabella, che tipo di informazioni devo archiviare?
4. quali sono i campi su cui sarà necessario eseguire un ordinamento?
5. che relazioni ci sono tra le varie tabelle?
6. che "operazioni" desidero eseguire su ogni tabella?

Avrete quindi capito che, siccome "chi ben comincia etc. etc.", rispondere a queste domande all'inizio del lavoro ci eviterà problemi nel seguito. Questo non significa che in corso d'opera non si potranno fare variazioni, ma cambiare la struttura di Db complessi quando già è iniziato il caricamento dei dati è davvero complicato. Inoltre, non prevedere qualche piccolo dettaglio può portare a risultati pericolosi, vi ricordate l'affare dell'anno 2000?

La Tabella

Una Tabella, abbiamo visto, è composta da Campi. Possiamo pensare al Campo come l'intestazione di colonna di una lista, ma in realtà è molto di più di una descrizione. In genere, infatti un Campo incorpora numerose "proprietà", cioè "caratteristiche" che una volta impostate, determineranno in modo preciso il tipo di informazione che quel Campo può contenere.

Esaminiamo un po' più in dettaglio queste caratteristiche:

• Il "nome" è in genere la descrizione dell'informazione (ad es. "numero di Telefono"). Non ci sono molti vincoli sul nome, vi consiglio però di non sceglierlo troppo lungo, ma allo stesso tempo abbastanza esplicativo. Nel nostro caso andrebbe ad es. bene NumTel. Se il Db comprende più Tabelle con lo stesso campo (se ho, ad esempio, la Tabella Clienti e quella Fornitori) e non sono in relazione tra loro, può essere utile anteporre al nome del campo un indicativo della Tabella, ad es. "CNumTel" e "FNumTel". In genere si possono usare gli "underscore" (Num_Tel) ma io lo trovo poco pratico.
• Il "tipo" indica la tipologia della informazione da archiviare nel campo. Le tre categorie principali sono stringa, numero e data/ora. All'interno di ogni categoria possiamo scegliere molte ulteriori tipologie, ed inoltre esistono "tipi" particolari (come "binario" o "timestamp") non riconducibili facilmente agli altri.
• La "lunghezza" misura l'occupazione fisica massima (in byte, di solito) che vogliamo assegnare all'informazione contenuta nel campo. Per le stringhe si indicano i caratteri (ad es max 30 caratteri per il campo "nome"), per i valori numerici il discorso è un po' più complesso (lo vedremo in seguito), per data/ora esistono formati standard con diverse occupazioni di memoria a seconda dell'intervallo dei valori che si vuole comprendere.
• "Ammetti null" è un segnalatore che indica se è possibile archiviare nel campo anche valori nulli (a prima vista può sembrare inutile, invece la scelta è assai importante)
• "Valore predefinito" è il valore che dovrà assumere in automatico il campo all'immissione di una nuova riga. Ad esempio, se la maggior parte dei nostri clienti è della provincia di Milano, potremmo volere che il campo Provincia sia riempito dalla stringa "MI". Se non si specifica niente, il campo assume il valore null. Per i campi numerici è particolarmente importante assegnare come valore predefinito lo zero (come vedremo tra poco).
• "Chiave" oppure "Indice" stabilisce se il campo debba essere indicizzato e se l'indice è univoco (vedere il paragrafo successivo "Indici")

Queste proprietà del campo si ritrovano quasi identiche in praticamente tutte le varietà di Db Server. Ogni prodotto, poi, implementa "aggiunte" magari non standard, ma egualmente importanti. Ora descriveremo più in dettaglio come MySql gestisce le tipologie di informazione (i tipi di campo) che possono interessarci in funzione dei nostri scopi, rimandando al manuale dell'applicazione chi volesse approfondire l'argomento.

Tips E' possibile cambiare la struttura delle Tabelle di un Db MySql anche DIRETTAMENTE da OpenOffice, anche se vedremo che l'operazione non è particolarmente conveniente rispetto all'uso di MySql Control Center