Die Frage nach der Relationalität eines Datenbanksystems stellt inzwischen für viele Käufer eine entscheidende Überlegung dar: Fast jeder DB-Anbieter erhebt heute den Anspruch, über ein solches Produkt zu verfügen; nur wenige erkennen, wie weit entfernt sie indes von ihrem Ziel sind. Ted Codd*, der "Vater des relationalen Modells", präsentiert 12 grundlegende Thesen zur Bestimmung eines RDBMS.

In den letzten Jahren erlebte der Markt für DBMS einen Umschwung zugunsten von Produkten, die das Datenbankmanagement mit einem relationalen Ansatz angehen. Fast alle Lieferanten geben inzwischen ihre DB-Systeme als relational aus. Diese Entwicklung war derartig umfassend, daß einige Anbieter nichtrelationaler DBMS schnell einige wenige relationale Eigenschaften hinzufügte. Nun preisen sie ihre Systeme als relational an, auch wenn sie nicht einmal die einfachen Anforderungen erfüllen, um als "minimal relational" eingestuft werden zu können.

Es kann als gesicherte Annahme gelten, daß diese Anbieter weder ausreichend Zeit noch Arbeitskraft investiert haben, um die für ein relationales DBMS benötigten Optimierungstechniken zu untersuchen. Aus diesem Hauptgrund fahren sie fort, den "Leistungsmythos" auszurufen - relationale DBMS müssen von der Leistung her schlecht sein, weil sie eben relational sind.

Eine Konsequenz des schnellen Marktumschwunges zum relationalen Ansatz besteht darin, daß die von Anbietern als relational verkauften DBMS ein breites Spektrum haben: Sie reichen von Produkten, die das relationale Modell mit substantieller Übereinstimmung unterstützen, bis zu solchen, die definitiv den Titel "relational" nicht verdienen, weil ihre Supporteigenschaften nur als Aushängeschild dienen.

Einige Anbieter behaupten, daß die Sprachen der 4. Generation alle nur denkbaren Produktivitätsvorteile bieten werden. Dieser Anspruch übersieht geflissentlich die Tatsache, daß die Mehrzahl dieser Sprachen nur wenig oder gar nichts für gemeinsam genutzte Daten tut. Zusätzlich gibt es keine anerkannte theoretische Grundlage für Sprachen der vierten Generation und noch nicht einmal eine anerkannte, präzise Definition.

Um zu bestimmen, wie relational ein System wirklich ist, müssen einige Kriterien angesprochen werden:

- Die Übereinstimmung des DBMS mit dem relationalen Modell

- Die Übereinstimmung des vorgeschlagenen ANSI-SQL-Standards mit dem relationalen Modell

- Schlußfolgerungen in Hinblick auf die Wahl eines DBMS-Produktes.

Es ist in jedem Fall überaus wichtig, daran zu denken, daß das relationale Modell drei Hauptteile beinhaltet: den strukturellen Teil, den manipulativen Teil und den Integritätsteil. Diese Tatsache wird häufig, oft aus Bequemlichkeit, vergessen.

In diesem Artikel werden Regeln dargestellt, mit denen jedes DBMS übereinstimmen sollte, das von sich behaupten will, voll relational zu sein, - ein Anspruch, den derzeit praktisch kein DBMS-Produkt wirklich erfüllt.

Der vorgeschlagene ANSI-Standard entspricht dem relationalen Modell nicht voll, da er weitgehend auf dem SQL-Kern beruht, der allgemein von zahlreichen Anbietern unterstützt wird. Außerdem wählt er einen statischen Ansatz auf Schemabasis für die Datenbankbeschreibung - ein Überbleibsel von Codasyl. Er spezifiziert also keine umfassende Datenuntersprache im Dual-Modus, die mächtigen, aber einfachen Zugang zu relationalen Datenbanken ermöglicht und einzigartig am relationalen Ansatz ist. Daher scheint die Übereinstimmung des vorgeschlagenen ANSI-Standards mit dem relationalen Modell sogar noch geringer als die einiger relationaler DBMS-Produkte.

Dennoch ließe sich dieser Standard so modifizieren, daß er mehr Übereinstimmung mit dem Modell bietet. Dahingehend sollte auf ANSI Druck ausgeübt werden. Tatsächlich wird den Anbietern empfohlen, ihre Produkte bald in dieser Hinsicht zu erweitern, damit die DBMS-Bedürfnisse der Kunden vollständiger unterstützt werden und die Anwender beträchtliche Ausgaben für die Wartung der Applikationssoftware vermeiden können.

Im folgenden werden 12 Regeln als Bestandteil eines Tests zur Bestimmung des relationalen Ansatzes angeführt. Diese Thesen sollen erklären, warum die vollständige Unterstützung des relationalen Modells dem Anwender nützt. Die relationalen Modelle wurden nicht um neue Anforderungen erweitert. Das anschließend aufgeführte Bewertungsschema soll zur Bestimmung dienen, inwiefern eine Übereinstimmung mit dem relationalen Modell gegeben ist.

Die Regeln 8 bis 11 spezifizieren und fordern vier verschiedene Typen der Unabhängigkeit, die darauf gerichtet sind, die Investitionen des Kunden in Anwendungsprogramme, Terminalaktivitäten und Training zu schützen. Die Regeln 8 und 9 - physikalische und logische Datenunabhängigkeit - wurden viele Jahre lang heiß diskutiert. Die Regeln 10 und 11 - Integritätsunabhängigkeit und Verteilungsunabhängigkeit - sind Aspekte des relationalen Ansatzes, denen noch nicht die gebührende Aufmerksamkeit gewidmet wurde, die aber wahrscheinlich genauso wichtig sein werden wie die Regeln 8 und 9. Diese Regeln beruhen auf einer einzigen fundamentalen These, die gleichsam als Fundament dient:

Für jedes System, das den Anspruch erhebt, relational zu sein oder das als solches angeboten wird, gilt: Das System muß in der Lage sein, Datenbanken vollständig mit Hilfe seiner relationalen Eigenschaften zu verwalten.

Diese Regel muß gelten, gleich ob das System irgendwelche nichtrelationalen Eigenschaften der Datenverwaltung unterstützt oder nicht. Kein DBMS, das diese Grundregel nicht erfüllt, ist wert, als relationales System eingestuft zu werden.

Eine Konsequenz dieser Regel: Jedes Produkt mit relationalem Anspruch muß Einfügen, Update und Löschen in der Datenbank auf der relationalen Ebene unterstützen (multiple Records zur gleichen Zeit). Eine andere Konsequenz ist die Notwendigkeit, die Informationsregel und die Regel des garantierten Zugriffs zu unterstützen.

"Multiple Records zur gleichen Zeit" beinhaltet als Spezialfälle die Situationen, in denen kein oder ein einzelner Record aufgefunden, eingefügt, auf den neuesten Stand gebracht oder gelöscht wird. Eine Relationstabelle kann also mit anderen Worten entweder keine oder eine Beziehungsreihe haben und dennoch eine gültige Relation sein.

Jede Bemerkung in den Handbüchern zu einem angeblich relationalen System, die die Anwender dazu auffordert, auf irgendwelche nichtrelationalen Eigenschaften zurückzugreifen, um "akzeptable Leistung zu erhalten", ist als Entschuldigung von seiten des Anbieters zu werten.

Bei Systemen, die als relational gepriesen werden, aber die Grundregel nicht erfüllen, liegt die Gefahr für Käufer und Anwender darin, daß sie alle Vorteile eines wirklich relationalen DBMS erwarten, aber nicht erhalten.

Die Informationsregel

Regel 1: In einer relationalen Datenbank sind alle Informationen explizit auf der logischen Ebene genau auf eine Art repräsentiert: als Werte in Tabellen.

Sogar Tabellennamen, Spaltennamen und Bereichsnamen sind als Zeichenstrings in Tabellen abgebildet. Tabellen mit solchen Namen sind normalerweise Teil des eingebauten Katalogs. Der Katalog ist demgemäß selbst eine relationale Datenbank und zwar eine, die dynamisch und aktiv ist, ferner die Meta-Daten repräsentiert (Daten, die den Rest der Daten im System beschreiben).

Die Informationsregel wird nicht nur aus Gründen der Anwenderproduktivität zwingend notwendig. Sie erleichtert es den SW-Anbietern vielmehr auch, zusätzliche Softwarepakete zu definieren (zum Beispiel Hilfen zur Anwendungsentwicklung, Expertensysteme und so weiter), die über ein Interface zum relationalen DBMS verfügen und per Definition gut im DBMS integriert sind.

Diese Pakete rufen Informationen ab, die bereits im Katalog existieren, und fügen dem Katalog bei Bedarf neue Information durch die einfache Handlung der DBMS-Benutzung hinzu. Ein weiterer Grund für das Bestehen auf dieser Regel liegt darin, die Aufgabe des Datenbankverwalters, die Datenbank in einem Zustand der allgemeinen Integrität zu halten, sowohl einfacher als auch effektiver zu gestalten. Nichts ärgert einen Datenbankverwalter mehr, als wenn er auf die Anfrage nach spezifischen Informationen in "seiner" Datenbank auch noch nach einer Woche Arbeitszeit die Antwort schuldig bleiben muß.

Regel des garantierten Zugriffs

Regel 2: Jedes Datum in einer relationalen Datenbank ist unter Gebrauch einer Kombination von Tabellenname, Primärschlüsselwert und Spaltenname garantiert logisch zugänglich.

Auf jedes Datum in einer relationalen Datenbank kann in einer großen Anzahl logisch verschiedener Wege zugegriffen werden. Es ist dennoch wichtig, wenigstens einen garantierten Weg zur Verfügung zu haben, der von der spezifischen relationalen Datenbank unabhängig ist; die meisten computerorientierten Konzepte wurden nämlich im relationalen Modell bewußt weggelassen.

Die Regel des garantierten Zugriffs stellt ein assoziatives Adreßschema dar, das typisch für das relationale Modell ist. Diese Regel ist in keiner Weise von der üblichen Computeradressierung abhängig. Das Konzept des Primärschlüssels bildet einen unverzichtbaren Teil davon. Systematische Behandlung von Null-Werten

Regel 3: Im Unterschied zu leeren Zeichenketten oder einer Kette von Leerzeichen sowie im Unterschied zu Null oder irgendeiner anderen Zahl werden Nullwerte in einem vollrelationalen DBMS unterstützt. So lassen sich fehlende oder nicht anwendbare Informationen auf systematische Weise und unabhängig vom Datentyp darstellen.

Um die Integrität der Datenbank zu unterstützen, muß es möglich sein, für jede Primärschlüsselspalte "Nullen nicht erlaubt" zu definieren. Dasselbe Postulat gilt für jede andere Spalte, wenn der Datenbankverwalter dies für eine angemessene Einschränkung der Integrität hält.

Frühere Techniken brachten die Definition eines Spezialwertes mit sich, um fehlende Information darzustellen. In einer relationalen Datenbank ist das höchst unsystematisch, da der Benutzer verschiedene Techniken für jede Spalte oder jeden Bereich anwenden müßte - aufgrund der hohen Sprachebene, die benutzt wird, eine schwierige Aufgabe.

Dynamischer Online-Katalog auf der Basis des relationalen Modells

Regel 4: Die Datenbankbeschreibung ist auf der logischen Ebene genauso repräsentiert wie gewöhnliche Daten. Daher können dazu berechtigte Benutzer die gleiche relationale Sprache für ihre Befragung anwenden, die sie für die regulären Daten benutzen.

Eine weitere Konsequenz besteht darin, daß jeder Anwender - ob Anwendungsprogrammierer oder Enduser - nur ein Datenmodell lernen muß. Diesen Vorteil bieten nonrelationale Systeme üblicherweise nicht an.

Daraus folgt, daß berechtigte Benutzer den Katalog leicht zu einem ausgereiften, aktiven relationalen Data Dictionary erweitern können, falls de Anbieter dies versäumt hat.

Regel der umfassenden Daten-Untersprache

Regel 5: Ein relationales System kann verschiedene Sprachen und diverse Modi der Terminalbenutzung unterstützen. Es muß jedoch wenigstens eine Sprache geben, deren Statements über eine gut definierte Syntax als Zeichenstrings darstellbar sind.

Dabei muß die Unterstützung folgender Punkte gegeben sein:

- Datendefinition

- Definition der Benutzersicht

- Datenmanipulation

- Integritätsbeschränkungen

- Autorisierung

- Transaktionsgrenzen

Der relationale Ansatz ist absichtlich hoch dynamisch. Im Gegensatz zu nichtrelationalen DB-Systemen sollte es daher selten notwendig sein, die Datenbankaktivität zum Stillstand zu bringen. Deshalb ist es sinnlos, die oben aufgelisteten Dienstleistungen in unterschiedliche Sprachen zu trennen.

"Das ANSI Planning and Requirements Committee" verfaßte Mitte der 70er Jahre ein Dokument, in dem 42 unterschiedliche Interfaces und - potentiell - 42 unterschiedliche Sprachen für DBMS befürwortet werden. Diese Idee wurde allen Anschein nach glücklicherweise fallengelassen.

Update-Regel für Abbildungen

Regel 6: Alle Abbildungen, die theoretisch auf den neuesten Stand gebracht werden können, sind auch durch das System zu verändern.

Eine Abbildung kann theoretisch dann einem Update unterzogen werden, wenn mit Hilfe eines zeitunabhängigen Algorithmus eine einzelne Serie von Veränderungen der Bankrelationen eindeutig bestimmbar ist, die genau die geforderten Veränderungen in der Abbildung zur Folge haben wird. In dieser Hinsicht muß "Update" so verstanden werden, daß Einfügen und Löschen genau wie Modifikation eingeschlossen sind.

Einfügen, Update und Löschen auf hoher Ebene

Regel 7: Die Fähigkeit, eine Bankrelation oder eine abgebildete Relation als einzelnen Operanden zu behandeln, bezieht sich nicht nur auf das Wiederfinden, sondern auch auf Einfügen, Update und Löschen von Daten.

Diese Anforderung gibt dem System viel mehr Raum für die Optimierung der Effizienz seiner Handlungen zur Ausführungszeit. Sie läßt das System bestimmen, welche Zugangspfade beschritten werden, um den effizientesten Code zu erhalten.

Dieses Postulat kann auch wichtig sein, wenn über eine verteilte Datenbank eine effiziente Transaktionsverarbeitung erreicht werden soll. In diesem Fall ist den Anwendern normalerweise daran gelegen, Kommunikationskosten zu sparen, indem die Notwendigkeit, für jeden Record aus entfernt angeschlossenen Stellen eine separate Anfrage zu übersenden, entfällt.

Physikalische Datenunabhängigkeit

Regel 8: Anwendungsprogramme und Terminalaktivitäten bleiben logisch unberührt, wann immer Veränderungen von Speicherrepräsentationen oder Zugangsmethoden erfolgen.

Das DBMS muß eine klare, scharfe Grenze zwischen den logischen und semantischen Aspekten auf der einen und den physikalischen und leistungsbezogenen Aspekten auf der anderen Seite unterstützen. Anwendungsprogramme dürfen sich nur mit den logischen Aspekten befassen.

Nichtrelationale DBMS bieten keine vollständige Unterstützung dieser Regel.

Logische Datenunabhängigkeit

Regel 9: Anwenderprogramme und Terminalaktivitäten bleiben logisch unberührt, wenn in den Datentabellen informationserhaltende Veränderungen irgendeiner Art gemacht werden, die theoretisch Ungleichheit zulassen.

Hierzu zwei Beispiele:

- Zum einen die Aufteilung einer Tabelle in zwei Tabellen, entweder nach Reihen unter Benutzung des Reiheninhalts oder nach Spalten unter Benutzung des Spaltennamens, wenn Primärschlüssel in jedem Ergebnis erhalten bleiben;

- zum anderen das Zusammenfügen zweier Tabellen zu einer einzigen.

Um diese Dienstleistung wann immer möglich anbieten zu können, muß das DBMS in der Lage sein, Einfügungen, Updates und Löschungen in allen Abbildungen zu verarbeiten, die theoretisch möglich sind. Diese Regel läßt die dynamische Veränderung des logischen Datenbankdesigns zu, wenn sie zum Beispiel die Leistung verbessert.

Die Regeln zur physikalischen und logischen Datenunabhängigkeit gestatten Designern von relationalen DBMS, Fehler in ihren Konzepten ohne schwerwiegende Verluste aufzufangen. Nichtrelationale Systeme sind in dieser Hinsicht nicht so komfortabel.

Integritätsunabhängigkeit

Regel 10: Spezifische Integritätseinschränkungen für eine bestimmte relationale Datenbank müssen in der relationalen Datenuntersprache definiert und im Katalog gespeichert werden können, nicht in den Anwenderprogrammen.

Zusätzlich zu den beiden Integritätsregeln (Ganzheitsintegrität und Bezugsintegrität), die auf jede relationale Datenbank zutreffen, besteht ein klarer Bedarf, weitere Integritätseinschränkungen definieren zu können. Diese Limitationen spiegeln entweder Geschäftspolitik oder Behördenvorschriften wider. Unter der Voraussetzung, daß das relationale Modell getreu widergespiegelt ist werden zusätzliche Integritätsbeschränkungen in der Datenuntersprache auf hoher Ebene definiert. Die Definitionen werden im Katalog gespeichert, nicht in den Anwendungsprogrammen.

In einer relationalen Datenbank werden Informationen über nicht ausreichend identifizierte Objekte nie aufgezeichnet. Spezifischer finden die folgenden beiden Integritätsregeln bei jeder relationalen Datenbank Anwendung.

- Ganzheitsintegrität

Keine Komponente eines Primärschlüssels darf einen Nullwert haben.

- Bezugsintegrität

Für jeden unterschiedlichen Fremdschlüsselwert in einer relationalen Datenbank, der nicht Null ist, muß ein passender Primärschlüsselwert aus dem gleichen Bereich vorhanden sein.

Ändern sich Geschäftspolitik oder Behördenvorschriften, müssen mit großer Wahrscheinlichkeit die Integritätsbeschränkungen verändert werden. Dies läßt sich bei einem voll relationalen DBMS üblicherweise dadurch erreichen, daß eines oder mehrere der im Katalog gespeicherten Integritäts-Statements verändert werden. In vielen Fällen sind weder Anwendungsprogramme noch Terminalaktivitäten logisch betroffen.

Nichtrelationale DBMS unterstützen diese Regel nur selten als Teil eines DBMS-Systems. Sie sind statt dessen von einem Dictionary-Paket abhängig, das nicht unbedingt immer vorhanden ist und sich einfach umgehen läßt.

Verteilungsunabhängigkeit

Regel 11: Ein relationales DBMS verfügt über Verteilungsunabhängigkeit.

Verteilungsunabhängigkeit bedeutet hier, daß das DBMS über eine Datenuntersprache verfügt, die zuläßt, daß die Anwendungsprogramme und Terminalaktivitäten logisch unberührt bleiben:

- Wenn der erste Fall von Datenverteilung eintritt, wenn also das ursprünglich installierte DBMS nur nichtverteilte Daten verarbeitet,

- wenn Daten zurückverteilt werden, wenn also das DBMS verteilte Daten behandelt.

Es ist zu beachten, daß die Wortwahl der Definition sorgfältig getroffen wurde, damit sowohl verteilte als auch nichtverteilte DBMS Regel 11 vollständig unterstützen können.

SQL/DS und DB2 der IBM sowie "Oracle" von Oracle Corp. und Ingres von Relational Technology, Inc. unterstützen diese Regel voll.

Belegt wurde diese Behauptung folgendermaßen: SQL-Programme, die zur Verarbeitung nichtverteilter Daten geschrieben wurden, liefen korrekt mit den verteilten Versionen dieser Daten. Das verteilte Ingres-Projekt an der University of California in Berkeley zeigte die gleichen Fähigkeiten für die Quel-Sprache von Ingres auf.

Es ist wichtig, eine Unterscheidung zwischen verteilter Datenverarbeitung und verteilten Daten zu treffen. Im einen Fall wird den Daten Arbeit (zum Beispiel Programme) übertragen, im anderen werden Daten "an die Arbeit" übermittelt. Viele nichtrelationale DBMS unterstützen zwar verteilte Verarbeitung, nicht aber verteilte Daten. Die einzigen Systeme, die das Konzept unterstützen, alle verteilten Daten lokal erscheinen zu lassen, sind relationale DBMS.

Im Fall eines verteilten relationalen DBMS kann eine einzelne Transaktion verschiedene im Remote-Modus angeschlossene Stellen betreffen. Dieser Vorgang wird nicht offen abgewickelt - das System muß unter Umständen an verschiedenen Stellen Wiederherstellungsprozesse durchführen.

Jedes Programm oder jede Terminalaktivität behandelt das gesamte Datenaufkommen, als ob es vollständig an der Stelle vorhanden wäre, wo das Anwendungsprogramm oder die Terminalaktivität ausgeführt wird.

Ein vollständig relationales DBMS, das keine verteilten Datenbanken unterstützt, läßt sich so erweitern, daß es diese Unterstützung bietet. Dabei bleiben Anwenderprogramme und Terminalaktivitäten sowohl zum Zeitpunkt der anfänglichen Verteilung als auch später, wenn Rückverteilungen vorgenommen werden, unbeeinträchtigt.

Es gibt vier wichtige Gründe, warum relationale DBMS diesen Vorteil genießen:

- Flexibilität der Zerlegung bei der Entscheidung, wie die Daten verwendet werden,

- Fähigkeit, relationale Operatoren wieder zusammenzufügen, wenn die Ergebnisse von an verschiedenen Stellen durchgeführten Untertransaktionen kombiniert werden,

- ökonomische Übertragung aufgrund der Tatsache, daß nicht für jeden aufzufindenden Record von irgendeiner remote angeschlossenen Station eine Anfragebotschaft gesandt werden muß,

- Analysierbarkeit der Absicht, bedingt durch die sehr hohe Ebene relationaler Sprachen, für eine Optimierung der Ausführung.

Regel "keine Unterversionen"

Regel 12: Verwendet ein relationales System eine Low-level-Sprache, kann diese niedrige Ebene nicht genutzt werden, um die Integritätsregeln und -beschränkungen, die in der relationalen Sprache höherer Ebene ausgedrückt sind, zu unterlaufen oder zu umgehen.

Im relationalen Ansatz ist die Bewahrung der Integrität von der logischen Datenstruktur unabhängig gemacht, um Integritätsunabhängigkeit zu erreichen. Ein "wiedergeborenes" System kann dieser Regel nur extrem schwer gehorchen, da ein solches System bereits ein Interface unterhalb des relationalen Einschränkungsinterfaces unterstützt. Anbieter von "wiedergeborenen" Systemen scheinen diesem Problem noch nicht die gebührende Aufmerksamkeit gewidmet zu haben.

*Dr. Ted Codd ist der Gründer und Leiter der amerikanischen Seminar- und Beratungsorganisation Relational Institute. Während seiner Zeit bei IBM entwickelte er in den Jahren 1969 und 1970 das relationale Modell und war verantwortlich für die Erstellung der relationalen Algebra, für die Definition der ersten drei Normalformen sowie für die Entwicklung eines natürlichsprachigen Interfaces zu relationalen Systemen. IBM-Fellow Codd wurde 1981 mit dem ACM Turing Award ausgezeichnet und gehört der National Academy of Engineering an.