Diese Regeln wurden von E.F.Codd formuliert und 1985¹⁾ publiziert. Sie beschreiben, was eine relationale Datenbank unterstützen muss, um tatsächlich relational zu sein. So, ohne weitere Einführung, tauchen wir hinein ins Evangelium der relationalen Datenbanken.

1: Informationsregel

Daten werden ausschliesslich auf einem Weg präsentiert. Als Werte innerhalb von Spalten innerhalb von Zeilen. Einfach, konsistent und versatil. Eine Tabelle (auch als Relation oder Entität bezeichnet) ist die logische Gruppierung von zusammenhängenden Daten in Zeilen- und Spaltenform. Jede Zeile (auch Datensatz oder Tupel genannt) beschreibt eine Sache und jede Zeile enthält Informationen über eine einzelne Sache in der Tabelle. Jede Spalte (auch Feld oder Attribut genannt) beschreibt eine einzelne Eigenschaft eines Objektes. Jeder Wert (Datum) ist definiert durch die Intersektion von Zeile und Spalte.

2: Garantierte Zugriffregel

Auf jeden Wert kann durch Angabe des Tabellennamens, Spaltennamens und Schlüssel zugegriffen werden. Auf diese Weise ist jeder Wert eindeutig identifizierbar und erreichbar.

3: Systematische Behandlung von NULL Werten

Eine vollkommen relationale Datenbank muss einen einheitlichen Ansatz zum Umgang mit fehlenden Informationen bieten. NULL wird stets als unbekannt interpretiert. NULL bedeutet kein Wert; die Abwesenheit eines Wertes. Da kein Wert eingegeben ist, ist dieser auch nicht bekannt. NULL ist nicht identisch mit einer leeren Zeichenfolge oder 0. Jeder Wert, NULL eingeschlossen, mit NULL verglichen, ergibt NULL.

4: Relationaler O­nlinekatalog

Zusätzlich zu benutzerdefinierten Tabellen enthält die Datenbank auch Daten über sich selbst.
Folgerichtig  existieren demnach zwei Arten von Tabellen:

• Benutzertabellen und
• Systemtabellen

Metadaten sind Daten, die die Struktur einer Datenbank beschreiben, ihre Objekte und wie diese miteinander verbunden sind. Der Katalog ist integraler Bestandteil der Datenbank und kann von authorisierten Benutzern auf die gleiche Art und Weise abgefragt werden. Andere Bezeichnungen für diese Systemtabellen sind Systemkatalog oder Data Dictionary.

5: Umfassende Datensprache

Codd Intention war es zumindest eine Sprache zu haben, um mit der Datenbank zu kommunizieren. Diese Sprache sollte Datendefinition, Datenmanipulation, Authentisierung, Integritätseinschränkungen und Transaktionsverarbeitung unterstützen. Verwendbar sowohl direkt als auch in Applikationen eingebettet.
Obwohl es nicht nur SQL als Datenbanksprache gibt, ist SQL der Standard.
wird. SQL ist eine lineare, nichtprozedurale oder deklarative Sprache. Sie erlaubt dem Benutzer auszudrücken, was er von der Datenbank will, ohne angeben zu müssen, wo die Daten liegen oder wie diese erhalten werden sollen.

6: Aktualisierbare Sichten

Wenn Daten dem Benutzer präsentiert werden müssen, darf eine relationale Datenbank nicht nur auf ihre Tabellen beschränkt sein. 'Sichten' sind virtuelle Tabellen oder Abstraktionen der
Quelltabellen. Sie reagieren wie Tabellen, mit der Ausnahme, das die Sicht dynamisch erzeugt wird, wenn die Abfrage ausgeführt wird. Die Definition einer Sicht dupliziert keine Daten, Sie sind bei Ausführung stets auf dem aktuellen Stand. Wenn Daten in einer Sicht geändert werden müssen, werden sie auch in der zugrundeliegenden Tabelle geändert. Dies ist aber nicht immer möglich. So existiert z.B. ein Problem wenn sich die Sicht auf einen Teil der Tabelle bezieht, welcher keinen Candidate Key einschliesst. Das könnte bewirken, das potentielle UPDATES die
Entitätenintegritätsregeln verletzen könnten. Einige Quellen im Internet schreiben hierzu, dass "Codd selber dies nicht vollständig verstand". Eine Begründung hierfür konnte ich aber nicht finden.

7: High Level Setbasierte oder relationale Operationen müssen unterstützt werden

Eine relationale Datenbank muss grundlegende relational algebraische Operationen (Selektionen, Projektionen und Joins) als auch Set Operationen wie Union, Intersektion, Division und Differenz. Zeilen werden als Sets zur Datenmanipulation betrachtet. Set Operationen und relationale Algebra werden benutzt, um durch Operationen auf anderen Tabellen neue Relationen zu erzeugen.

8: Physikalische Datenunabhängigkeit

Die physikalische Schicht der Architektur wird auf die logische Struktur gemappt. Benutzer und Programme sind nicht von der physikalischen Struktur der Datenbank abhängig. Die Implementierung der physikalischen Schicht ist Aufgabe der Datenbank. Ein Programm, dass Daten aus einer relationalen Datenbank abfragt, braucht nicht zu wissen, wie diese Daten physikalisch gespeichert sind. Es sendet nur die Datenanforderung und überlässt den Rest der Datenbank. Applikationen sind logisch nicht betroffen, wenn sich die physikalische Speicherung oder die Zugriffsmethode ändert.

9: Logische Datenunabhängigkeit

Benutzer und Applikation sind weitgehend von der logischen Struktur der Datenbank. Die logische Struktur kann sich verändern, ohne dass Datenbank und/oder Applikation neu entwickelt werden müssen. Die Relation zwischen den Tabellen kann sich verändern, ohne dir Funktionalität von Applikation´und Ad-hoc Abfragen zu vermindern.

10: Integritätsunabhängigkeit

Um als relationale Datenbank betrachtet werden zu können, muss die Datenintegrität als interne Funktion in das DBMS implementiert sein. Dies ist nicht Aufgabe der Appilkation. Datenintegrität stellt die Konsistenz und Richtigkeit der Daten in der Datenbank sicher. Vereinfacht gesagt, hält sie den Müll aus der Datenbank fern. Veränderungen an Integritätseinschränkungen sollten keine Auswirkungen auf die Applikationsprogramme haben. Dies vereinfacht die Programme, ist aber nicht immer möglich.

11: Verteilungsunabhängigkeit

Applikationen sollten auch mit verteilten Datenbanken arbeiten können. Die Benutzer können Daten aus Tabellen von verschiedenen Servern per JOIN verbinden (verteilte Abfragen) sowie auch aus anderen relationalen DBMS (heterogene Abfragen). Die Benutzer brauchen nicht darauf zu achten, ob eine Datenbank verteilt ist oder nicht.

12: Nichtgefährdungsregel

Es darf keine Wege in die Datenbank geben, die es ermöglichen, Datenintegrität zu unterwandern. Das DBMS muss Datenmodifikationen durch Maschinenspracheneingriffe verhindern können.

Interessanterweise gibt es eine Regel 0 für RDBMS. Codd hat diese 1990 hinzugefügt.

"Jedes System, das beansprucht, eine relationale Datenbank zu sein, muss in der Lage sein, Datenbanken ausschliesslich durch seine relationalen Fähigkeiten zu verwalten. Ohne Rücksicht darauf, welche zusätzlichen Fähigkeiten dieses System noch unterstützen mag.

Ebenfalls in 1990 erweiterte Codd seine 12 Regeln auf 18. Die neuen Regeln schliessen
Katalogregeln, Datentypen (Domänen) und Authorisierung ein²⁾.

Codd selber musste die Tatsache einräumen, dass auf Grundlage der obigen Regeln (bis heute) kein vollständig relationales Datenbanksystem existiert. Dies hat sich seit 1990 nicht geändert. Um spezifischer zu sein, die Regeln 6, 9, 10, 11 und 12 scheinen schwer erfüllbar zu sein.

¹⁾Codd, E.F. "Is Your DBMS Really Relational?" and "Does Your DBMS Run By the Rules?" ComputerWorld, October 14 1985 and October 21 1985.
²⁾Codd, E.F. The Relational Model for Database Management, Version 2; Addison-Wesley; 1990.