Der Erfinder des relationalen Modells hat 1985 zwölf Regeln zu Protokoll gegeben, an denen man ablesen kann, ob ein DBMS das begehrte R auch wirklich verdient. Sie basieren sämtlich auf der Basisregel Null: Ein RDBMS muß fähig sein, Datenbanken vollständig durch seine relationalen Fähigkeiten zu verwalten.
Das bedeutet, daß es nicht ausreicht, wenn beispielsweise an ein hierarchisches System gewisse relationale Funktionen quasi angebaut werden, man aber immer noch auf nicht-relationale Elemente angewiesen ist, um die Produktion durchzuführen.
Regel 1: Alle Informationen in einer relationalen Datenbasis werden auf dem logischen Level explizit und ausschließlich als Werte in Tabellen repräsentiert. Dies gilt nicht bloß für die Daten, die den Benutzern zur Verfügung stehen, sondern auch für Systeminformationen, die im Katalog gespeichert werden. So wird eine wirklich umfassend einheitliche Darstellung für alle erreicht, die mit dem DBMS arbeiten müssen: Benutzer, Administratoren und Programmierer.
Regel 2: Auf jedes einzelne Datenelement (Tabelleneintrag) in einer relationalen Datenbasis kann mittels einer Kombination von Tabellenname, Primärschlüsselwert und Spaltenname logisch zugegriffen werden. Wichtig ist hier, daß der Zugriff völlig unabhängig von einer rechnerorientierten Adressierung und damit von der physischen Speicherung ist.
Regel 3: Um fehlende Informationen in einer systematischen Art darzustellen, und zwar unabhängig vom Datentyp, muß ein RDBMS NULL-Werte unterstützen.
NULL ist nicht mit 0 oder einer leeren Zeichenkette identisch, sondern bedeutet, daß für den betreffenden Tabellenwert kein sinnvoller Eintrag vorliegt - er ist (noch) undefiniert. Es muß natürlich möglich sein, bei der Tabellendefinition NULL für bestimmte Spalten zu verbieten. Dies ist zum Beispiel bei einem Primärschlüssel der Fall.
Heutzutage, das heißt in seiner Version 2 des relationalen Modells, fordert Codd übrigens zwei mögliche Werte für NULL: Einer gibt an, daß der betreffende Eintrag unbekannt ist, aber im Prinzip existieren kann, und der andere, daß ein Eintrag zu diesem Primärschlüsselwert nicht zugelassen ist, etwa bei der Spalte Heiratsdatum für Ledige.
Regel 4: Die Beschreibung der Datenbanken auf dem logischen Level wird wie gewöhnliche Daten repräsentiert, so daß autorisierte Benutzer sie mit derselben relationalen Sprache abfragen können.
Diese Regel, die einen dynamischen On-line-Katalog vorschreibt, ist sachlich bereits in Regel 1 enthalten.
Regel 5: Ein relationales System kann verschiedene Sprachen unterstützen. Aber es muß eine Sprache existieren, für die gilt:
1) Ihre Statements bestellen aus Zeichenketten in einer wohldefinierten Syntax;
2) Mit ihr können folgende Funktionen erfüllt werden:
- Datendefinition,
- VIEW-Definition,
- Datenmanipulation (interaktiv und durch Programm),
- integritätsregel-Definition,
- Autorisierung,
- Transaktionsgrenzen (begin, commit, rollback).
Solche Sprachen gibt es, etwa QUEL oder SQL, wobei sich letztere zu einem De-facto-Standard entwickelt hat. Daß SQL Mängel hat, nicht orthogonal und stark redundant ist, beim Programmieren einen anderen Umfang als im interaktiven Modus hat etc., steht auf einem anderen Blatt.
Regel 6: Alle VIEWS, die theoretisch manipuliert werden können, können durch das System manipuliert werden.
Diese Regel ist trennscharf. VIEW-Manipulationen wie DELETE, INSERT und UPDATE sind nicht in jedem der verbreiteten Produkte erlaubt.
Dies basiert darauf, daß nicht alle möglichen Manipulationen korrekt sind, sondern nur Solche, die sich eindeutig in eine zeitunabhängige Reihe von Manipulationen der zugrundeliegenden Baisistabellen zerlegen lassen.
Die Schwierigkeit, zwischen theoretisch korrekten und verfälschenden Manipulationen zu unterscheiden, wird von manchen Herstellern dadurch umgangen, daß VIEW-Manipulationen nur zugelassen werden, wenn der VIEW auf einer einzelnen Basistabelle beruht.
Regel 7: Die Möglichkeit, eine Tabelle oder einen VIEW als Operanden zu behandeln, existiert nicht nur für Lese-, sondern auch für Schreibzugriffe. In der Tat ist SQL eine gruppen- und keine satzorientierte Sprache. Dies wird besonders wichtig, wenn man verteilte DBMS betrachtet. Hier müßte pro Satz zwischen verschiedenen Rechnerknoten navigiert werden.
Regel 8: Benutzeraktivitäten und Anwendungsprogramme müssen nicht geändert werden, wenn Veränderungen an der physischen Speicherung beziehungsweise der Zugriffsmethode vorgenommen werden.
Physische Datenunabhängigkeit im Sinn dieser Regel ist bei den heute käuflichen Produkten meist gegeben.
Regel 9: Benutzeraktivitäten und Programme müssen nicht geändert werden, wenn informationserhaltende Veränderungen der Basistabellen irgendwelcher Art dies theoretisch erlauben.
Diese logische Datenunabhängigkeit unterstellt, daß die Anwendungen nicht direkt auf Basistabellen zugreifen. Dann würden deren Änderungen entsprechende Programmanpassungen notwendig machen, Man kann Applikationen statt dessen prinzipiell nur auf VIEWs zugreifen lassen. Nehmen wir an, Anwendung A verarbeite Tabelle T durch den VIEW T´. Wird T aus Performance-Überlegungen heraus auf zwei Tabellen T, und T2 aufgeteilt, so muß lediglich der VIEW T´ neu als Join von T1 und T2 definiert werden - ohne jede Änderung der Applikation läuft diese weiter, wenn das System Regel 6 (VIEW-Manipulation) unterstützt. Es gibt in der Praxis allerdings starke - und begründete - Vorbehalte gegenüber dem Ideal, durch VIEWs die Wartung der Anwendungen vermeiden zu können. Die meisten Änderungen an Basistabellen, die sich in der Produktion ergeben, machen nämlich auch die VIEWs unbrauchbar, die auf sie definiert sind.
Regel 10: Intetegritätsregeln, die einer bestimmten relationalen Datenbank angehören, müssen mit einer Subsprache definierbar und im Katalog des Systems ablegbar sein.
Dies ist wieder eine trennscharfe Regel. Es geht darum spezifische, sich aus dem konkreten Inhalt der DB ergebende Integritätsregeln nicht in der Anwendung, sondern im DBMS zu verwalten. Es ist indes keineswegs so, daß alle kommerziellen RDBMS eine solche Prozedurspeicherung erlauben.
Regel 11: Benutzeraktivitäten und Programme müssen nicht, geändert werden, wenn
1) eine Verteilung der Datenbasis auf mehrere Rechner vollzogen wird; und
2) wenn die Daten in einem bestehenden verteilten System neu verteilt werden.
Die so charakterisierte Verteilungstransparenz ist ebenfalls trennscharf und äußerst wichtig. Wenn man davon aus daß das Konzept eines verteilten DBMS in der Zukunft entscheidende Rolle spielen wird, dann ist es von enormer Bedeutung, daß ihre Einführung die Investitionen in bestehende Anwendungssysteme schützt und nicht de facto entwertet, da umfangreiche Anpassungen vorgenommen werden müssen.
Regel 12: Wenn ein relationales System eine satzorientierte Sprache unterstützt, kann diese nicht dazu benützt werden, die Integritätsregeln zu umschiffen. Hier geht es der Sache nach um nicht-relationale Systeme, die mit einer SQL-Schnittstelle erweitert werden. In diesem Fall wäre es höchst riskant, wenn die mit der gruppenorientierten Sprache definierten Integritätszwänge sozusagen satzweise ignoriert werden könnten.
Insgesamt sind, wenn man das heutige Produktspektrum betrachtet, vor allem die Regel 6, 10 und 11 bei der Einschätzung von großer Bedeutung. Die Regeln 1 bis 5 sowie 7 und (..) werden im Prinzip von den diversen SQL-Dialekten eingehalten. Regel 9 fällt mit 6 zusammen, und die Regel 12 schließlich kennzeichnet einen Spezial fall, nämlich ein um ein relationales Interface erweitertes konventionelles DBMS.