Viele Datenbanksysteme werden von ihren Herstellern als relational bezeichnet, d.h. sie basieren auf einem Relationalen Datenbankmodell. Welchen Kriterien eine per Definition entsprechende relationale Datenbank genügen müsste, soll hier kurz beschrieben werden.

Das relationale Datenbankmodell beruht auf Tabellen, Grundlage ist das Konzepte der Relation. Sie stellt eine mathematische Beschreibung einer Tabelle dar. Operationen auf diesen Relationen werden durch die relationale Algebra bestimmt.

Mindestanforderungen an eine relationale Datenbank

Die Grundlagen der Theorie der relationalen Datenbank wurden von Edgar F. Codd in den 1960ern und 1970ern gelegt und in seiner Arbeit A Relational Model of Data for Large Shared Data Banks beschrieben. Theoretisch basieren alle Operationen auf der relationalen Algebra.

Relationale Datenbanken sollten (mindestens) den folgenden Anforderungen genügen:

  • Alle Informationen müssen in Tabellen dargestellt werden. Nur so kann die gewünschte Flexibilität erreicht werden.
  • Die Daten müssen mindestens mit den folgenden Operationen bearbeitet werden können:
    • Projektion
    • Selektion
    • Kreuzprodukt oder Kartesisches Produkt
    • Umbenennung
    • Vereinigung
    • Differenz
  • Alle Beziehungen zwischen den Daten müssen explizit in den Daten selbst beschrieben werden.

Alle Anfragen, die z. B. mittels SQL an eine relationale Datenbank gestellt werden, werden vom Datenbankmanagementsystem auf diese Operatoren abgebildet, das heißt übersetzt. In der Praxis gibt es weitere Operatoren, wie zum Beispiel den Join-Operator, der jedoch ebenfalls nur eine Kombination aus Kreuzprodukt, Selektion und Projektion darstellt.

Die goldenen Regeln der Relationalität

Die Erfüllung dieser Mindestanforderungen genügt jedoch noch nicht, ein Datenbanksystem als relational zu klassifizieren. 1985 wurden von E. F. Codd zwölf Regeln veröffentlicht, die eine relationale Datenbank im strengen Sinne definieren.

Regel 1 (Darstellung von Information)

Alle Informationen in relationalen Datenbanken müssen logisch in Tabellen dargestellt sein, insbesondere

  • Daten
  • Definitionen von Tabellen und Attributen
  • Integritätsbedingungen und die Aktion bei deren Verletzung (siehe Regel 10)
  • Sicherheitsinformationen (z.B. Zugangsberechtigungen)

Regel 2 (Zugriff auf Daten)

Jeder Wert einer relationalen Datenbank muss logisch durch eine Kombination von Tabellenname, Primärschlüssel und Attributname (Spaltenname) auffindbar sein. Dies bedeutet, dass in einer Tabelle an jedem Schnittpunkt einer Zeile mit einer Spalte nur ein Wert stehen darf.

Regel 3 (Systematische Behandlung von Nullwerten)

Nullwerte stellen in Attributen, die nicht Teil eines Primärschlüssels sind, eine fehlende Information dar und werden durchgängig gleich, insbesondere unabhängig vom Datentyp des Attributes, behandelt. (Man kann also nicht in numerischen Feldern bei fehlenden Daten das Feld leer lassen, und bei Textfeldern das Zeichen — einfügen. Fehlende Informationen werden heute meist mit NULL bezeichnet.)

Regel 4 (Struktur einer Datenbank)

Die Datenbankstruktur wird in derselben logischen Struktur wie die Daten gespeichert, also in Tabellen. Dazu muss die Struktur aller Tabellen, die zu einer Datenbank gehören, in einer Tabelle (dem Katalog) zugänglich sein. Diese Forderung bedingt, dass sich eine Änderung im Katalog automatisch in einer geänderten Datenbankstruktur auswirkt!

Regel 5 (Die Abfragesprache)

Ein relationales System enthält mindestens eine befehlsgesteuerte Abfragesprache, die mindestens die folgenden Funktionen unterstützt:

  • Datendefinition
  • Definition von Views (logische Sichten der Datenbank, die der Benutzer aus den Attributen der Basistabellen erstellt und mit den gewohnten Operatoren manipulieren kann)
  • Definition von Integritätsbedingungen
  • Definition von Transaktionen (Eine Transaktion ist eine Folge von Befehlen, die eine Datenbank von einem konsistenten Zustand in einen anderen überführen. Eine Transaktion muss entweder vollständig durchgeführt oder, bei einem Abbruch, vollständig zurückgesetzt werden.)
  • Definition von Berechtigungen

Eine weit verbreitete Abfragesprache hierfür ist SQL.

Regel 6 (Aktualisieren von Views)

Alle Views, die theoretisch aktualisiert werden können, können auch vom System aktualisiert werden. (Beispiel: Hat man zwei Spalten A und B mit Zahlen, so kann man sich eine weitere Spalte definieren, die A*B enthält. Ändert man einen Wert in dieser Spalte, so kann daraus nicht der Wert der Spalten A und B bestimmt werden, da im allgemeinen aus dem Produkt zweier Zahlen diese zwei Zahlen nicht bestimmt werden können. Dieses View kann also theoretisch nicht aktualisiert werden.)

Problem: Im Allgemeinen kann nicht entschieden werden, ob ein View theoretisch aktualisiert werden kann.

Regel 7 (Abfragen und Editieren ganzer Tabellen)

Abfrage- und Editieroperationen müssen als Operanden ganze Tabellen und nicht nur einzelne Sätze erlauben.

Regel 8 (Physikalische Unabhängigkeit)

Der Zugriff auf die Daten durch den Benutzer muss unabhängig davon sein, wie die Daten gespeichert werden oder wie physikalisch auf sie zugegriffen wird. Dies bedeutet, dass Anwendungen nur auf die logische Struktur des Systems zugreifen dürfen. (Beispiel: Die Daten dürfen auf einem Datenträger durchaus hierarchisch gespeichert sein. Nur die logische Struktur der Datenbank muss relational sein. Ändert der Datenbankverwalter die physikalische Struktur, darf der Anwender davon nichts mitbekommen.)

Regel 9 (Logische Unabhängigkeit der Daten)

Anwendungen und Zugriffe dürfen sich logisch nicht ändern, wenn Tabellen so geändert werden, dass alle Informationen erhalten bleiben (z.B. beim Aufspalten einer Tabelle in zwei Tabellen)

Regel 10 (Unabhängigkeit der Integrität)

Alle Integritätsbedingungen müssen in der Abfragesprache definierbar sein und in Tabellen dargestellt werden. Das System muss mindestens die folgenden Integritätsbedingungen prüfen:

  • Vollständigkeitsintegrität (Entity Integrity, Existential Integrity), d.h. ein Primärschlüssel muss eindeutig sein und darf insbesondere keinen Nullwert enthalten.
  • Beziehungsintegrität (Referentielle Integrität, Referential Integrity), d.h. zu jedem Fremdschlüsselwert existiert ein Primärschlüsselwert.

Regel 11 (Verteilung der Daten)

Anwendungen für eine nicht-verteilte Datenbank dürfen sich beim Übergang zu einer verteilten Datenbank logisch nicht ändern. (Beispiel: Wenn die oben beschriebenen Tabellen in einem Netzwerk auf zwei verschiedenen Rechnern gespeichert sind, darf sich bei der Anwendung nichts ändern, wenn die Tabellen irgendwann auf demselben Rechnern gespeichert werden.)

Regel 12 (Unterlaufen der Abfragesprache)

Unterstützt ein relationales Datenbanksystem neben der High-Level-Abfragesprache eine Low-Level-Abfragesprache, so darf diese die Integritätsbedingungen der High-Level-Sprache nicht unterlaufen. (Beispiel: Die Low-Level Abfragesprache darf z.B. nicht direkt auf die physikalischen Eigenschaften der gespeicherten Daten zugreifen.)

Anmerkungen:

  • Die zwölf Regeln dürfen bei der Beurteilung eines Datenbanksystems nicht gleich gewichtet werden. Daher bezeichnen viele Hersteller ihre Datenbank als relational, wenn sie nur einige der wichtigsten Kriterien erfüllt.
  • Ende 1990 veröffentlichte E. F. Codd ein Buch über relationale Datenbanken, in dem er die einstigen zwölf Regeln des relationalen Modells auf 333 Regeln differenziert. Dadurch wird die Relationalität einer Datenbank bis ins letzte Detail festgeschrieben.