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ò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 nel mantenimento 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à.