Cristian Cudizio - Appunti di storia dei database relazioniali

Home

Appunti di storia dei database relazioniali

Written by Administrator

Monday, 31 March 2008

L'alba dei database relazionali è collegata al famoso articolo di Edgar F. Codd "A relational model of Data for Large Shared Data Banks" del 1970. Questi appunti partono dal primo capitolo del libro "Oracle Insights.Tales of the Oak Table".

Il primo progetto significativo che ha cercato di mettere in pratica il modello descritto da Codd nel suddetto articolo si chiama "System R", iniziato nel 1973 nel labotorio di ricerca dell'IBM a San Jose. La storia è riassunta in questo breve articolo scritto per commemorare la morte di Codd il 18 aprile del 2003.
Il progetto System R aveva implementato il linguaggio SQL per interrogazioni, in senso stretto, in quanto inteso solo come linguaggio per reperire i dati e non come DDL. Il sistema necessitava di una precompilazione delle query, ma offriva anche la possibilità di usare query particolari per lo sviluppo rapido e il test che non necessitavano di tale precompilazione. Inoltre, cosa significativa, System R permetteva la ridefinizione o modifica della struttura dei dati "online", ovvero senza dover interrompere il servizio. Codd lavorò poi con Ray Boyce alla definizione della forma normale definita Boyce-Codd (BCNF) che era un ulteriore miglioramento rispetto alla terza forma normale (3NF).
Da System R, la cui documentazione era pubblica, Larry Ellison prese l'idea di fondare una società che producesse un RDBMS (da qualche parte ho letto che al tempo Larry Ellison lavorava all'IBM e stava fotocopiando suddetta documentazione); lo fece con l'aiuto di Bob Miner e Ed Oates. In questo modo nel 1979 Ellison battè sul tempo IBM rilasciando la prima versione commerciale di un sistema di database relazionale, che pare sia uscito gia come versione 2 per farlo apparire un prodotto più maturo di quanto non fosse.
L'IBM annunciò il suo primo prodotto, SQL/DS nel 1981 e riuscì effettivamente a rilasciarlo però nel 1983. Poco dopo IBM annunciò quello che diventerà un po' la bandiera di IBM, DB2
Un serio avversario di Oracle negli anni '80 pare essere stato Ingres, di Michael Stonebraker. Un'altro documento che vale la pena di leggere è questo.

Le dodici regole di Codd

Nel 1985, pare per limitare la confusione dovuta al fatto che molti vendevano dei prodotti come database relazionali che in realtà erano vecchi prodotti mascherati, Ted Codd pubblicò (non ho un riferimento serio,in alternativa c'è wikipedia, Ohio State University o PSOUG o questo) un elenco di 12 regole a cui un database relazionale doveva obbedire per poter essere chiamato tale. In realtà le regole sono tredici perchè c'è anche una regola zero.

Regola 0: "Foundation Rule"

A relational database management system must manage its stored data using only its relational capabilities.

Regola 1: "The Information Rule"

Tutti i dati devono essere presentati agli utenti in tabelle, chiamate da Codd "relazioni". Le tabella contengono righe (o tuple) ma non c'è alcun ordine su queste righe, ne in memorizzazione ne in estrazione. Tutte le righe di una tabella hanno esattamente le stesse colonne ed ogni colonna ha tre caratteristiche. Primo, ogni colonna deve contenere un tipo dato "scalare", cioè un solo valore alla volta; questo esclude gli "oggetti". Secondo una colonna non può avere sottocampi e infine il nome di una colonna deve essere univoco per una tabella.

Regola 2: "Guaranteed Access Rule"

Ogni elemento dei dati deve essere accessibile senza ambiguità. Questo significa, in un database relazionale puro, dare il nome della tabella, il valore della chiave primaria e il nome della colonna.

Regola 3: "Systematic Treatment of Null Values"

Una novità introdotta dai database relazionali è proprio il concetto di Null, ovvero di assenza di valore. Oracle ha la grave pecca di trattare in modo equivalente la stringa vuota e il null.

Regola 4: "Dynamic On-Line Catalog"

in questo Oracle non segue lo standard SQL, però è conforme, anzi atraverso le viste V$ va ben oltre

Regola 5: "Comprehensive Data Sublanguage"

Il database deve supportare almene un linguaggio chiaramente definito. SQL è uno di questi

Regola 6: "View Updating Rule"

siccome ogni query può essere classificata come vista (view) e quindi dovrebbe essere intercambiabile con una tabella, Codd stabilì che ogni operazione di manipolazione dei dati che può essere eseguita su una tabella deve essere eseguibile anche su una vista (o su una query). Questa regola può creare dei problemi, ad esempio su alcune join. Oracle ha introdotto i trigger "INSTEAD OF" per completare la conformità a questa regola.

Regola 7: "High-level Insert, Update, and Delete"

questa regola deriva dalle regole 5 e 6 e stabilisce che le operazioni INSERT, UPDATE e DELETE dovrebbero (should) essere supportate per qualunque insieme estraibile di righe. Oracle rispetta questa regola solo per operazioni su tabelle o viste aggiornabili come in :

UPDATE emps SET JOB='Data Executive' where JOB='DBA' and sal>1000;

INSERT INTO EXEC SELECT * FROM EMP WHERE LOWER(JOB) LIKE '%executive%';

DELETE FROM EMPS WHERE LOWER(JOB) LIKE '%executive%';

Regola 8: "Physical Data Independence"

Questa regola stabilisce che l'utente (chi scrive l'SQL) non deve aver bisogno di conoscere nulla riguardo i meccanismi fisici usati per immagazzinare ed estrarre i dati. Nelle DDL questo non è proprio soddisfatto.

Regola 9: "Logical Data Independence"

Questa regola stabilisce che l'utente (sempre chi scrive SQL) deve avere sempre la stessa vista dei dati anche se viene cambiata la struttura logica del database (la definizione delle tabelle). In qualche modo questo si può ottenere con delle viste, ma non pare proprio ideale.

Regola 10: "Integrity Independence"

DDL e quindi il dizionario dati, deve supportare la dichiarazione di vincoli che mantengono l'integrità del database durante gli aggiornamenti. In sostanza parliamo dei vincoli di integrità sui dati che controllano i dati immessi dagli utenti. Ad oggi Oracle soddisfa questa regola

Regola 11: "Distribution Independence"

Questa regola aggiunge una dimensione alla regola 8, stabilendo che per l'utente non deve dover sapere dove stanno effettivamente i dati, si tratta qualcosa di più di quello che già Oracle implementa attravarso i database link ed il meccanismo del "Two Phase Commit" (2PC), perchè qui si intende che anche una stessa tabella può avere dati distribuiti. Questo pone problemi nelmantenimento dell'integrità dei dati.

Regola 12: "Nonsubversion Rule"

Non ci devono essere metodi alternativi alla modifica della struttura del database attraverso il linguaggio insiemistico del database. Questo rende più facile il controllo delle regole sui dati. Un esempio di meccanismo che in Oracle non soddisfa questa regola è il "direct path" che permette di caricare dati senza far rispettare i vincoli di integrità.