12 regole di Codd

Le 13 regole di Codd, o forme normali, sono un insieme di tredici regole (da 0 a 12) proposte da Edgar F. Codd, un pioniere del modello relazionale per le basi di dati, per definire i requisiti che un sistema per la gestione di basi di dati deve soddisfare per essere considerato relazionale, ovvero un RDBMS.

Codd scrisse questi criteri nell'ambito di un'iniziativa che serviva ad evitare che la sua definizione di database relazionale fosse resa meno restrittiva quando, nei primi anni ottanta, i venditori di database si affannarono per rimpiazzare i vecchi prodotti con un prodotto pseudo-relazionale. La regola 12 è nata proprio per contrastare questa tendenza: le regole sono infatti così rigide che anche i sistemi la cui unica interfaccia sia il linguaggio SQL non ne soddisfano alcune.

Le regole

• Regola 0: il sistema deve potersi definire come relazionale, base di dati e sistema di gestione.

Affinché un sistema possa definirsi sistema relazionale per la gestione di basi di dati (RDBMS), tale sistema deve usare le proprie funzionalità relazionali (e solo quelle) per gestire la base di dati.

• Regola 1: l'informazione deve essere rappresentata sotto forma di tabelle.

Le informazioni nel database devono essere rappresentate in maniera univoca, e precisamente attraverso valori in colonne che costituiscano, nel loro insieme, righe di tabelle.

• Regola 2: La regola dell'accesso garantito o delle chiavi primarie.

Tutti i dati devono essere accessibili senza ambiguità. Ogni singolo valore scalare nel database dev'essere logicamente indirizzabile specificando il nome della tabella che lo contiene, il nome della colonna in cui si trova e il valore della chiave primaria della riga in cui si trova.

• Regola 3: trattamento sistematico del valore NULL.

Il DBMS deve consentire all'utente di lasciare un campo vuoto, o con valore NULL. In particolare, deve gestire la rappresentazione di informazioni mancanti e quello di informazioni inadatte in maniera predeterminata, distinta da ogni valore consentito (per esempio, "diverso da zero o qualunque altro numero" per valori numerici), e indipendente dal tipo di dato. Queste rappresentazioni devono inoltre essere gestite dal DBMS sempre nello stesso modo.

• Regola 4: dizionario del modello relazionale.

La descrizione della struttura del database e degli oggetti che lo compongono deve avvenire ad un livello logico, tramite un dizionario di metadati, e questo dizionario deve essere accessibile agli utenti del Database con le stesse modalità e lo stesso linguaggio di interrogazione utilizzato per accedere ai dati.

• Regola 5: accessibilità dei dati.

Tutti i contenuti del database devono essere accessibili attraverso almeno un linguaggio relazionale (come ad esempio l'SQL) che abbia le seguenti caratteristiche:

1. abbia una sintassi lineare (ovvero le cui istruzioni possono essere semanticamente interpretate con una semplice lettura da sinistra verso destra)
2. possa essere utilizzato sia in forma interattiva che dall'interno di applicazioni
3. supporti operazioni di definizione e di manipolazione dei dati, le regole di sicurezza e i vincoli di integrità del database.

• Regola 6: aggiornamento delle viste di dati.

In un database relazionale si possono creare viste che forniscono l'accesso a specifici subset di informazioni. Laddove il contenuto in termini di dati di queste viste è concettualmente modificabile, lo deve anche essere nella pratica.

• Regola 7: manipolazione dei dati ad alto livello.

Da un database possiamo reperire informazioni multiple costituite da set di dati provenienti da più righe e/o più tabelle. Gli stessi set di dati, piuttosto che le singole informazioni, devono anche poter essere inseriti, aggiornati e cancellati.

• Regola 8: indipendenza dalla rappresentazione fisica.

La struttura logica di un database deve essere indipendente dalle strutture di memorizzazione fisica: modifiche al piano fisico (come i dati vengono memorizzati, su quali unità, con quale organizzazione, ecc.) non devono richiedere un cambiamento alle modalità di accesso al database.

• Regola 9: indipendenza dalla rappresentazione logica.

Le modifiche al livello logico (tabelle, colonne, righe, chiavi primarie, ...) non devono richiedere cambiamenti non giustificati alle applicazioni che utilizzano il database.

• Regola 10: i vincoli logici sui dati devono essere memorizzati nel Database.

I vincoli di integrità propri delle entità e delle relazioni, le regole di sicurezza e le restrizioni di accesso devono essere definiti nel dizionario del database e sono quindi separati dalle applicazioni che lo utilizzano. Deve quindi essere possibile modificare tali vincoli senza inutilmente interessare le applicazioni esistenti.

• Regola 11: indipendenza di localizzazione.

La distribuzione di porzioni del database su una o più allocazione fisiche o geografiche deve essere invisibile agli utenti del sistema. Le applicazioni esistenti devono continuare ad operare con successo quando i dati esistenti vengono ridistribuiti in modo diverso.

• Regola 12: regola di non sovversione.

Gli strumenti di accesso ai dati non devono poter annullare le restrizioni del database, per esempio aggirando i vincoli di integrità, le relazioni o le regole di sicurezza.

Queste regole sono state fissate nell'articolo di E. F. Codd, "Is Your DBMS Really Relational?", pubblicato sul magazine Computerworld nel 1985 (la prima parte il 14 ottobre e la seconda il 21 ottobre).