Piccola storia dei database assolutamente incompleta
Probabilmente il più glorioso (ed a tutt' oggi utilizzato)
antenato dei database relazionali odierni può essere identificato con la sana e
vecchia agenda telefonica. in effetti penso che se guardiamo come è fatta
la nostra agenda scopriremo una notevole affinità con i sui parenti più
tecnologici attuali. Infatti è organizzata tramite un indice (la serie di
linguette sul fianco che ci permette di accedere più rapidamente a tutti i
nominativi che iniziano con una certa lettera) che gestisce una tabella
composta da colonne che identificano il tipo di dato sotto riportato (nome,
numero di telefono, a volte indirizzo) all' interno delle registrazioni
(vogliamo chiamarle con il termine inglese 'record'?) che , pur
differendo l' una dall' altra per i dati riportati al loro interno 'hanno
tutti la stessa struttura', cioè riportano le stesse informazioni nella
medesima maniera.
Il primo tentativo di cui io sono a conoscenza compiuto dagli
informatici per riversare questo tipo di oggetti in un 'coso'
trattabile dalle loro grosse calcolatrici corrisponde al nome di CSV (Comma
Separated Value), cioè un banalissimo file di testo dove ogni informazione
(numero di telefono di pino, nome di gino, indirizzo di tino) è separata dalle
altre tramite un carattere particolare (normalmente una virgola) ed ogni record
(vedi definizione spora riportata, cioè la riga della nostra agenda) è separato
dagli altri tramite un' altro carattere (normalmente il carattere di 'a
capo'). Ovviamente questo sistema era decisamente embrionale, in quanto
comunque per trovare all' interno di un file del genere una informazione
specifica era spesso necessario scorrerselo quasi tutto ed in modo poco pratico
per trovare quanto si ricercava.
la logica evoluzione del CSV fu l'ISAM (Indexed Sequential
Access Method), che differiva dal CSV solo per il fatto che i record non erano
'buttati dentro a casaccio' (cioè in ordine di inserimento), bensì
veniva definito un ordinamento (tipicamente nel caso della nostra agenda l'
ordine alfabetico sui cognomi) che veniva sfruttato sia in scrittura
('dove devo mettere il record del telefono di Anna?' 'sotto la
lettera A tra Anita ed Antonio') sia in lettura ('dove hai infilato
il numero di telefono di Pietro?' ' lettera P, tra Paolo e
Pinocchio') permettendo in questo modo di abbreviare incredibilmente i
tempi di ricerca di una data informazione. Per riuscire poi a gestire ancora
meglio il tutto si crearono anche delle specie di 'archivi
sussidiari', detti indici, in cui veniva registrato solo l' ordine dei
vari record senza tutte le altre informazioni, il che permetteva di andare a
svolgere le proprie ricerche in questo 'riassunto' in modo molto più
veloce (meno roba da leggere=ci metto di meno a leggerla) e poi 'puntare
diritti' sul database completo per leggere tutto il record una volta che
si sapeva dov'era
A questo punto parecchi matematici di notevole ingegno si
misero a cercare metodi per rendere ancora più veloce l' accesso alle
informazioni che ci servivano sfornando sistemi di ricerca dai nomi fantasiosi
come 'ricerca dicotomica' o ' a farfalla' (che non è nostro
interesse qui approfondire) , sviluppando così tutti quei sistemi oggi definiti
'Database non relazionali' (in contrapposizione ai database relazionali
che vedremo dopo) di cui forse i più famosi sono stati i database B-Trieve e
DBIII-like (clipper, DBIII, DBIV ecc)
con l'evoluzione di questi ultimi i database ebbero una
notevole diffusione e quindi iniziarono a nascere richieste di affidabilità e
di prestazioni sempre maggiori, con uno sviluppo teorico notevole dietro ad
essi, che permetteva a questo punto di affrontare diversi problemi, di cui di
seguito elenco quelli più conosciuti (forse da me: sicuramente un teorico dei
database potrà aggiungerne altri milioni). sia chiaro, alcuni di questi
problemi venivano egregiamente affrontati dai database non relazionali, ma
raramente tutti insieme ed in maniera affidabile
- La
ridondanza dei dati:
ergo 'ma non esiste proprio un modo per evitare di rimettere nel mio
database della contabilità duemila volte l' indirizzo del mio cliente
principale?'
- L'
uniformità dei dati
'oddio, come ho chiamato la Johns Coopers and Lybrand Incorporated l'
ultima volta? JCL? J.C.L. ? J.C.L Inc.? J.C.& L. Inc?'
- L'indipendenza
dalla piattaforma
'scusa Aristide, ti ricordi sul tuo sistema come devo fare per vedere
il contenuto di una tabella? perché su quello di Asdrubale devo fare così,
su quello di Antonio cosà e sul mio in un modo completamente diverso'
- La
sicurezza delle transazioni
'ARGH! stavo mettendo dentro al database tutte le fatture dell'
ultimo semestre quando è andata via la corrente ed adesso non so se l'
ultima me l' ha presa o no! cosa faccio, devo ricostruire l' intera
tabella delle fatture per essere certo che non ci siano valori doppi o
inseriti a metà??'
- La
possibilità di gestire correttamente un ambiente multiutente
'Mi spieghi perché io sono certo di avere inserito l' ordine per le
ultime dieci scatole di pirulazio a nome del mio miglior cliente e quelle
sono finite invece al peggior cliente di un' altro commerciale? eppure SO
di averle fermate al magazzino io per primo..'
Per risolvere tutti questi problemi in maniera soddisfacente
si è dovuto cambiare il modo di 'pensare' i database, portando così
alla nascita dei database relazionali
[ Picolo appunti ]
