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

1. 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?"

2. 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?"

3. 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"

4. 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à??"

5. 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