Cristian Cudizio on the WEB

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.

< Prev		Next >