MySQL è un RDBMS cioè un Database Server Relazionale. Questo significa che il funzionamento stesso di un database è basato sulla logica relazionale: in un database infatti si è soliti rappresentare la realtà per relazioni tra gli oggetti esaminati.
Facciamo l'esempio concreto della progettazione di un database per la catalogazione di una collezione di libri. L'elemento centrale del nostro database sarà proprio il libro che avrà alcune caratteristiche come il titolo, il prezzo, il numero di pagine, la casa editrice, l'autore; potremmo allora decidere di creare un'unica tabella con questi 5 campi. Ci accorgiamo presto però che questa soluzione non rappresenta lo stato dell'arte dato che a lungo andare avremo una tabella in cui lo stesso valore si ripete in un certo campo (ad esempio il campo editore). Per ottimizzare il database estraiamo quindi l'editore inserendolo in una tabella dedicata con un campo identificativo numerico che ci servirà per legare l'editore, che avrà una serie di attributi, al libro da lui edito.
Ecco che abbiamo introdotto il concetto stesso di relazione e iniziato a delineare il modello "E-R" (entità-relazione): in un database sono presenti diverse entità (libri, case editrici, autori) con attributi specifici (il titolo del libro, l'indirizzo della casa editrice, la biografia dell'autore) e chiavi di identificazione univoche (ad esempio un campo numerico incrementale, il codice ISBN del libro, il codice fiscale dell'autore).
Le entità sono poi legate tra di loro tramite relazioni che possono essere di tre tipi:
- Uno a uno
- Uno a molti
- Molti a molti
La comprensione delle relazioni è molto semplificata se si ha dimestichezza con il concetto di insieme e si immaginano le varie tabelle nè più nè meno che come una serie di insiemi i cui elementi (i record delle tabelle) possono essere legati tra di loro.
La relazione uno a uno
Le relazioni di questo tipo sono principalmente dettate dalla praticità più che dalla teoria del modello "E-R": si prestano bene a relegare gli attributi secondari di una data entità in una seconda tabella nella quale però ogni record è riconducibile ad un unico record della tabella principale e viceversa. Solitamente una relazione di questo tipo viene creata per alleggerire le operazioni sulla tabella principale, soprattutto se gli attributi dirottati verso la tabella di supporto sono presenti solo per un sottoinsieme della tabella principale. In questo ultimo caso il risparmio sarà anche in termini di spazio sul disco.
La realizzazione di questo tipo di relazione consiste nell'assegnare un identificativo (ID) univoco agli elementi presenti nella tabella principale (ad esempio come chiave primaria autoincrementante) e creare un analogo campo univoco nella tabella di supporto in cui sarà inserita la chiave della prima tabella. Con una query sarà possibile estrarre i dati di entrambe le tabelle; questa operazione sarà corretta anche concettualmente dato che entrambe le tabelle si riferiscono alla stessa entità.
Se i record della tabella di supporto sono solo un sottoinsieme della tabella principale è consigliabile costruire la relazione nella query di tipo SELECT tramite una LEFT JOIN che permette così di estrarre anche quelle righe della tabella principale che non presentano omologhi in quella di supporto. Un esempio pratico di questa relazione è dato da una tabella utenti legata ai dati provenienti da una pagina di profilazione molto lunga che solo alcuni utenti hanno compilato.
La relazione uno a molti
Veniamo invece alla relazione principale con cui ci troviamo di fronte spesso e volentieri: questa lega un elemento di una tabella A univocamente ad un elemento di una tabella B ma non viceversa. Per dirla in altri termini, partendo da un elemento della tabella A si arriva ad un solo elemento della tabella B mentre partendo da un elemento della tabella B si crea una situazione di confusione in quanto si trovano numerosi elementi della tabella A.
La realizzazione pratica consiste nell'aggiungere alla tabella B un campo identificativo univoco come ad esempio una chiave primaria autoincrementante e inserire il valore desiderato in un campo specifico della tabella A. Con una query è possibile estrarre contemporaneamente i dati da entrambe le tabelle per esempio per realizzare una scheda di presentazione di un libro in cui viene mostrato l'effettivo nome dell'editore e non il suo identificativo numerico.
Sono di questo tipo le relazioni "Elemento->Categoria di appartenenza", "Figlio->Padre", "Elemento->Creatore". Esempi pratici possono essere "Pittore->Corrente artistica", "Persona->Persona", "Libro->Casa editrice".
Interessante si rivela in questo caso la relazione Figlio->Padre in quanto entrambi gli elementi fanno parte della stessa entità (in questo caso l'entità "Persona"). Si ha allora una relazione autoreferenziale tra la tabella e se stessa. Casi del genere possono presentare annidamenti di un numero consistente di livelli. Generalmente questa struttura prende il nome di struttura ad albero per la forma che assume se viene schematizzata. L'esempio più eclatante è probabilmente fornito dalle directory sul web come Yahoo! in cui ogni categoria web discende da un'altra ed ha delle sottocategorie al proprio interno.
La relazione molti a molti
A volte però una relazione non è concettualmente tanto identificante da poter essere univoca in una direzione: ecco quindi che nascono le relazioni molti a molti. L'esempio pratico è dato nel nostro caso dei libri, dalla relazione tra libro e autori o tra libro e genere di appartenenza: un libro (specialmente se non si tratta di un romanzo) può essere stato scritto a più di due mani ed appartenere a più generi letterari contemporaneamente. Come si può intuire non è più possibile inserire nella tabella dei libri un campo "autore" in cui riportare l'identificativo dell'autore già che potrebbe essercene più di uno!
La soluzione consiste nel passare per una terza tabella di comodo che si occuperà di legare i record delle due tabelle tra di loro. Dovremo quindi assegnare un campo identificativo univoco alla prima tabella (ad esempio la tabella libri), fare lo stesso con la seconda tabella (autori) e infine creare una tabella di comodo composta da due soli campi che conterranno rispettivamente l'identificativo della prima e della seconda tabella. Per questo tipo di relazione non ha senso parlare in assoluto di tabella principale e di tabella secondaria visto che la relazione è molti a molti sia in un senso che nell'altro mentre ha senso parlare di tabella principale indicando quella che rappresenta concettualmente il centro del nostro sistema.
Non sarà sufficiente eseguire una sola query per estrarre i dati presenti relativi ad entrambe le tabelle. Sarà necessario estrarre prima i dati relativi alla tabella principale e solo in seguito eseguire una seconda query per estrarli dalla secondaria.
Uno strumento utile
Per concludere mi permetto di segnalare uno strumento molto utile nella progettazione di un database relazionale che permette di rendere immediatamente comprensibile la presenza di relazioni tra le tabelle evidenziandone anche il tipo: si tratta di DbDesigner. Permette inoltre di fare un reverse engineering di un database esistente per poter avere lo schema da cui partire per aggiungere ulteriori tabelle e relazioni.
Il programma è disponibile per piattaforme Windows o Linux ed è rilasciato sotto licenza GPL. Dopo un periodo relativamente breve di addestramento lo riterrete indispensabile per la progettazione dei vostri database.
