allora cosa sono questi famigerati Database relazionali? il concetto che sta alla base è , come spesso succede nell' informatica, molto meno "strampalato" di quello che si pensa: invece di fare un' enorme tabella in cui è contenuto TUTTO il database si divide lo stesso in tante tabelle che contengono dati logicamente correlati e per metterle insieme si usano delle relazioni tra l' una e l' altra tabella. vediamo di fare un qualche esempio per capirci meglio.
Per il nostro esempio prenderemo in esame il database di una piccola gestione di una videoteca di famiglia.Vogliamo tenere registrati tutti i film che abbiamo in modo da sapere su di essi le seguenti informazioni:
1. il titolo
2. il regista
3. l' attore protagonista
4. l' attrice protagonista
5. l' anno di uscita nelle sale del film
6. il tipo di supporto
7. se l' ho in casa o se l' ho prestato a qualcuno
8. a chi l' ho eventualmente prestato: nome, cognome e numero di telefono
9. il genere del film
10. se nostra figlia di 5 anni può vederlo o non è proprio il caso
11. un breve riassunto della trama
nel modo "classico" avremmo realizzato un' unica "tabellona" più o meno di questo tipo:
| Videoteca | ||||||||||||
| cod | titolo | regista | attore | attrice | anno | supporto | PrestNome | PrestCogn | PrestTel | Genere | VM18 | trama |
| là dove scorre il fiume | Redford | DeNiro | Stone | DVD | Dramma | no | xxx | |||||
| Proposta indecente | Spielberg | Redford | Pfeiffer | VHS | Gigi | Salvioli | sexy | si | yyy |
in questo modo abbiamo registrato poche informazioni e di difficile uso. proviamo allora a ragionarci sopra e vediamo che vogliamo in realtà registrare 3 diversi tipi di dati, nella fattispecie:
a questo punto prendiamo in mano un database relazionale e creiamo non una ma tre tabelle:
| Cassette | ||||||||||
| CodCass | Titolo | CodReg | CodAtt1 | CodAtt2 | Anno | Supporto | CodPrest | Genere | VM18 | trama |
| là dove scorre il fiume | DVD | dramma | no | xxx | ||||||
| Proposta indecente | VHS | Sexy | SI | yyy |
| Personaggi del cinema | |||
| CodPers | Cognome | Nome | VintoOscar |
| Redford | Robert | si | |
| DeNiro | Robert | si | |
| Stone | Sharon | no | |
| Spielberg | Stephen | si | |
| Pfeiffer | Michelle | no |
| Amici | ||||
| CodAmico | Cognome | Nome | Telefono | Indirizzo |
| non prestata | ||||
| Salvioli | Gigi | via Garibaldi 5 | ||
| Persiceto | Gennaro | via Mazzini 6 |
in questo modo, oltre ad inserire molti più dati abbiamo già risolto due dei problemi citati sopra: inseriremo una sola volta Robert de Niro per tutte le volte che vorremo usarlo in punti differenti del nostro database ed avremo sempre la certezza di chiamarlo Redford, Robert e non r.redford,robertredford, Robert Redford ecc...
in compenso abbiamo un problema : come faccio a capire che la cassetta di proposta indecente l' ho prestata a Gigi Salvioli e non ad un fantomatico signor 1 ? risposta: tramite delle relazioni
una delle cose che dovrebbe saltare immediatamente all' occhio guardando le tabelle dell' esempio è il fatto che ogni record ha un suo codice univoco (spesso chiamato "chiave primaria" ) che identifica lui e solo lui (non ci sono né possono essere due personaggi del cinema con CodPers=1) e che tali codici vengono richiamati all' interno della tabella delle cassette: si può quindi dire che ho stabilito una relazione tra i campi della tabella cassette CodReg, CodAtt1 e CodAtt2 e il campo CodPers della tabella personaggi del cinema, così come ho stabilito una relazione tra CodAmico della tabella Amici e CodPrest (risolvendo peraltro il fastidio di avere caselle vuote per indicare che la cassetta è in mio possesso). in questo modo tramite un apposito sistema di definizione delle relazioni si possono creare database estremamente complessi ma di consultazione abbastanza semplice. con una appropriata gestione degli indici sulle tabelle inoltre si può ottenere un tempo di accesso ai dati decisamente soddisfacente