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, moniert Ted Codd* in seinem Beitrag.
Einige Anbieter nonrelationaler DBMS haben schnell ein paar relationale Eigenschaften hinzugefügt - nur um ihre Systeme als relational anpreisen zu können, selbst wenn sie nicht einmal einfachen Anforderungen genügen, um als minimal relational eingestuft werden zu können.
Diese Systeme halten ihre Sprachen niedrigerer Ebene (ein einzelner Record zur Zeit) für den Benutzer offen, um entweder die Kompatibilität zu vorher entwickelten Anwenderprogrammen zu unterstützen oder weil der Anbieter sich auf den Standpunkt stellt, daß relationale Operatoren nur bei Abfragen anwendbar sind.
Solche Systeme versagen demgemäß bei der Unterstützung der Regel "keine Unterversionen" - eine schwere Buße, die für Kompatibilität bezahlt wird. Sowohl IDMS/R als auch Datacom/DB versäumen, die Regel "keine Unterversion" für Integrität zu unterstützen.
Anwender können ein System mit den neun strukturellen, den 18 manipulativen und den drei Integritätseigenschaften des relationalen Modells vergleichen, um eine detailliertere Bewertung von DBMS zu erhalten. Jede Eigenschaft läßt sich sowohl auf praktischer als auch auf theoretischer Ebene verteidigen.
Es folgen die neun strukturellen Eigenschaften:
S1. Relationen mit passend zusammengestellten Ausmaßen - oder entsprechende Tabellen mit nichtnumerierten Reihen, benamten Spalten, keinen Positionskonzepten und keinen sich wiederholenden Gruppen.
S2. Grundlagentabellen, die die gespeicherten Daten repräsentieren.
S3. Query-Tabellen - das Ergebnis eines jeden Abfragelaufes ist eine weitere Tabelle, die gespeichert und später bearbeitet werden kann.
S4. View-Tabellen - virtuelle Tabellen, die intern durch ein oder mehrere relationale Kommandos, nicht durch gespeicherte Daten repräsentiert sind. Die Definitionskommandos werden bis zu dem benötigten Ausmaß durchgeführt, wenn die Abbildung aufgerufen wird.
S5. Snapshot-Tabellen - Tabellen, die ausgewertet und in der Datenbank mit einem Katalogeintrag, in dem Datum und Zeit der Erzeugung sowie eine Beschreibung spezifiziert sind, gespeichert werden.
S8. Attribute - jede Spalte jeder relationalen Tabelle ist ein Attribut.
S7. Bereich - das Set von Werten, aus dem eine oder mehrere Spalten ihre Werte beziehen.
S8. Primärschlüssel - jede Banktabelle hat eine oder mehrere Spalten deren Werte jede Reihe dieser Tabelle eindeutig identifizieren. Der Primärschüssel sorgt für die einzigartige Fähigkeit des relationalen Modells zur assoziativen Adressierung, das heißt Software- und Hardwareunabhängige Implementation.
S9. Fremdschlüssel - jede Spalte in der Datenbank, die sich im gleichen Bereich befindet wie der Primärschlüssel irgendeiner Bankrelation. Der Fremdschlüssel spielt bei der Unterstützung der Bezugsintegrität eine wichtige Rolle, ohne Links in die Perspektive des Programmierers oder des Anwenders einzuführen.
Es ist wichtig, im Auge zu behalten, daß das relationale Modell nicht die Syntax einer bestimmten DBMS-Sprache vorschreibt. Statt dessen werden die manipulativen Fähigkeiten spezifiziert, die eine relationale Sprache besitzen sollte. Zur gleichen Zeit fordert das Modell nicht vom Anwender, den Datenbankverwalter um die Einführung irgendwelcher spezieller Zugangspfade zu bitten. Es stellt auch nicht die Forderung an den Benutzer, auf iterative Schleifen, Rekursion oder cartesianische Produkte zurückzugreifen.
Das Modell fordert ebenfalls nicht vom System ein cartesianisches Produkt als Zwischenergebnis zu generieren. In früheren Veröffentlichungen wurde diese Manipulationsfähigkeit auf zwei Arten ausgedrückt: algebraisch und auf Logik basierend. Beide Wege erweisen sich als gleich mächtig.
In diesem Artikel wird aus Erklärungsgründen die algebraische Methode benutzt, um die manipulative Kraft auszudrücken. Folgende manipulative Eigenschaften gibt es:
M1. Theta-Auswahl
M2. Projektion
M3. Theta zusammenfügen
M4. äußere Theta zusammenfügen
M5. trennen
M6. Vereinigung
M7. Intersektion
M8. Unterschied setzen
M9. äußere Vereinigung
M10. relationale Zuweisung
M11. Theta Auswahl-vielleicht
M12. Theta zusammenfügen-vielleicht
M13. äußere Theta zusammenfügen-vielleicht
M14. trennen-vielleicht
M15. Theta Auswahl semantic override (S/O)
M16. Theta zusammenfügen S/O
M17. äußere Theta zusammenfügen S/O
M18. trennen S/O
In der oben angeführten Liste steht "Theta" für irgendeinen der Vergleichsoperatoren: ist gleich, ist nicht gleich, größer als, kleiner als größer gleich, kleiner gleich.
Folgende Integritätseigenschaften des relationalen Modells müssen auch streng befolgt werden:
I.1 Ganzheitsintegrität
I.2 Bezugsintegrität
I.3 Anwender-definierte Integrität.
Die in I.3 angeführten Integritätseigenschaften sind Teil der umfassenden Datenuntersprache. Sie unterstützen den Auslöser- und Sammelansatz, um diejenigen Integritätsbeschränkungen zu definieren, die für die betreffende Datenbank spezifisch sind. Im Gegensatz dazu sind I.1 und I.2 auf alle relationalen Datenbanken anwendbar. Sowohl für SQL als auch für QBE wurden Beispiele dieser Erweiterungen, wenn auch noch nicht voll implementiert, veröffentlicht.
Um in der Mitte der 80er Jahre als vollständig relational zu gelten, muß ein DBMS alle 12 Grundregeln ebenso wie alle neun strukturellen alle 18 manipulativen und alle drei Integritätsregeln des relationalen Modells vollständig unterstützen - zusammengenommen 42 Eigenschaften. Der Begriff "Mitte der 80er Jahre" wird hier benutzt, da in den 90ern wahrscheinlich noch einige weitere Anforderungen hinzukommen dürften.
Eine einfache Methode der Einschätzung eines DBMS in Hinblick auf seine Übereinstimmung mit dem relationalen Modell bietet sich darin an, für jede Regel oder Eigenschaft, die das DBMS vollständig unterstützt, den Gesamtwert um eins zu erhöhen. Im anderen Fall ist der Beitrag zum Gesamtwert Null. Um eine prozentuale Übereinstimmungsschätzung für das System zu erhalten, wird der Gesamtwert verdoppelt.
Sollte ein DBMS tatsächlich einen Gesamtwert von 42 aus 42 erreichen, dann werden acht Punkte als Belohnung für echte Übereinstimmung addiert, bevor der Gesamtwert verdoppelt wird. Daher errechnet sich der Übereinstimmungsprozentsatz dann als 100.
Der resultierende Übereinstimmungsprozentsatz ist nicht sehr genau. Fällt er zwischen 10 Prozent und 90 Prozent, dann empfiehlt es sich, ihn zum nächsten Vielfachen von 10 Prozent zu runden. So wird vermieden, daß Genauigkeit durch Aufzeigen von mehr als einer signifikanten Stelle falsch repräsentiert ist.
Nach heutigem Standard ist 46 vom Hundert ein guter, aber verbesserungsfähiger Übereinstimmungsprozentsatz. Abbildung 2 zeigt die Bewertung von DB2, IDMS/-R und Datacom/DB nach allen Eigenschaften des relationalen Modells. Die 12 Regeln sind für sich genommen häufig bereits zu Vergleichszwecken ausreichend. Diese detailliertere Evaluation der drei Systeme dient in erster Linie der Erläuterung.
Der ANSI-Standard in der heute vorgeschlagenen Form ist aber unglücklicherweise recht schwach. Er versagt bei der Unterstützung zahlreicher Eigenschaften, die Anwender wirklich benötigen, wenn sie alle Vorteile des relationalen Ansatzes genießen wollen.
Der vorgeschlagene ANSI-Standard für relationale Systeme funktioniert wie ein Konvoi, der nur so schnell wie das langsamste Schiff vorwärtskommen kann. Der Standard beruht schwerwiegend auf dem SQL-Teil, der von mehreren Anbietern unterstützt wird.
Eine Auflistung der Hauptunterschiede zwischen dem ANSI-SQL und als Beispiel dem SQL, das in DB2 implementiert ist, zeigt, daß ANSI-SQL noch weniger mit dem relationalen Modell übereinstimmt als das SQL von Big Blue.
þDer ANSI-SQL-Entwurf spezifiziert keine Katalogtabellen und läßt den Einschluß von "Create"- oder "Grant"-Statements in Anwendungsprogrammen nicht zu. Statt dessen ist ein "Schema" erforderlich, das eine Berechtigungs-ID und eine Definitionsliste von Tabellen, Abbildungen und Privilegien bestimmt.
þANSI unterstützt kein "dynamisches SQL" - SQL-Statements, die zur Ausführungszeit berechnet werden.
þDas Set reservierter Worte ist in ANSI signifikant kleiner als in DB2.
þIn ANSI ist, so wie es sein sollte, das Attribut der "Einzigartigkeit" auf eine Spalte oder Spaltenkombination anwendbar, während es sich in DB2 auf einen Index bezieht.
Die ANSI-Version ist daher als Tool zur Bewertung von DBMS Produkten nicht geeignet. Die Anmerkungen zu DB2 treffen auch auf bestimmte andere Anbieterprodukte zu.
Einige Aspekte zum Thema ANSI:
þDer Verzicht auf Katalogtabellen war eine schlechte Entscheidung, der Katalog muß standardisiert werden. Die ANSI-Version sieht wie ein Überlebender des nicht-dynamischen Codasyl aus.
þEine andere schlechte Wahl war das Versäumnis, dynamisches SQL zu unterstützen. Diese Eigenschaft ist notwendig und wird angewandt.
þAnbieter relationaler DBMS-Produkte, die über den vorgeschlagenen ANSI-Standard hinausgehen, bringt das kleinere Set reservierter Worte in eine potentiell schwierige Situation. Mehrere Anbieter sind in diese Kategorie einzuordnen.
þDie ANSI-Behandlung des "Einzigartigkeitsattributes" ist gut gelöst. ANSI behandelt einen Index als rein Ausführungs-orientiertes Werkzeug, daher entstehen keine semantischen Konsequenzen, wenn eines fallengelassen wird.
Die Hauptkritik an dem vorgeschlagenen ANSI-Standard Level 1 und Level 2 für relationale Datenbanken besteht darin, daß einigen Bereichen nur unangemessene Aufmerksamkeit gewidmet wird. Die Eigenschaft der umfassenden Datenuntersprache im Dual-Modus, die SQL bereits besitzt, wird zum Beispiel zu wenig betont. Der gesamte Bereich der SQL-lmplementationen von großen Mainframes bis zu Mikros wird nicht angemessen angesprochen.
Schließlich sollte ANSI die jetzt unterstützte SQL-Version so erweitern, daß sie das relationale Modell einschließlich verteilten Datenbanken vollständig unterstützt. Es sollte wenigstens ein Richtungsstatement generiert werden, das den Anbietern gestattet, die Übereinstimmung ihrer Produkte zu verbessern, ohne daß Inkompatibilität mit einem zukünftigen Standard riskiert wird.
SQL-Erweiterungen, die diese Unterstützung bieten, lassen sich mit einiger Zuverlässigkeit im Detail prognostizieren. Jeder jetzt angenommene Standard sollte diese Erweiterungen in der Zukunft nicht unmöglich machen oder erschweren.
Jeder Käufer, der sich für die Anschaffung eines DBMS entscheidet, sollte drei Faktoren starkes Gewicht beimessen. Der erste Faktor sind die Leistungsanforderungen des Käufers, die oft in der Anzahl von Transaktionen, die pro Sekunde ausgedrückt sind. Eine andere wichtige Überlegung ist die durchschnittliche Komplexität jeder Transaktion. Käufer sollten die heutigen relationalen DBMS auf dieser Basis nur ausschließen, wenn die Leistungsanforderungen extrem hoch sind. Auch dann sollten die Käufer eigene Leistungstests entwerfen, statt sich auf die vom Anbieter entworfenen Tests oder vom Anbieter verkündeten Strategien zu verlassen.
Der zweite Faktor sind die reduzierten Kosten für die Entwicklung neuer Datenbanken und neuer Anwendungsprogramme. Relationale DBMS bieten eine signifikante Reduktion dieser Kosten, wenn sie mit Codasyl oder hierarchischen Ansätzen verglichen werden. Sprachen der vierten Generation stellen keinen Ersatz dar, auch wenn sie zusätzliche Produktivität anbieten könnten.
Der dritte Faktor ist der Schutz zukünftiger Investitionen in Anwendungsprogramme durch die Anschaffung eines DBMS mit einer soliden theoretischen Fundierung und zuverlässiger Unterstützung höherer Produktivität und Verteilbarkeit. Eine relationale Datenbank gewinnt in jedem Fall bei den Faktoren zwei und drei. In vielen Fällen kann sie auch bei Faktor eins siegen - trotz aller Leistungsmythen.
Dann stellt sich die Frage, welches relationale DBMS gewählt werden soll. Dieses System hat nicht nur ein DBMS mit einem guten Übereinstimmungsprozentsatz mit dem relationalen Modell zu sein, es muß auch zu späterer Zeit erweiterbar sein. Im Idealfall wird ein gutes DBMS bald auf 100prozentige Unterstützung erweitert werden, ohne die Käuferinvestitionen in Anwendungsprogramme logisch zu beeinträchtigen.
Bei übertriebenen Versprechungen eines Anbieters sollten Käufer vorsichtig sein - vor allem, wenn behauptet wird, das System sei "postrelational" oder wenn es heißt, die Wahl eines DBMS sei unwichtig. In Wirklichkeit kann die Kaufentscheidung für ein DBMS jetzt bestimmen, wie schnell sich die Organisation des Käufers an Veränderungen in der Zukunft anpassen kann.
Es wird für die Anbieter Zeit zu erkennen, daß alle Eigenschaften des relationalen Modells untereinander verbunden und voneinander abhängig sind. Fehlende Eigenschaften führen zu großen Lücken in der Integritätskontrolle und der Anwendbarkeit einer DBMS Implementation.
Derzeit sieht kein Konzept stark und praktisch anwendbar genug aus, um den relationalen Ansatz zu ersetzen. Vielmehr wird die Lebenszeit des relationalen Ansatzes viel länger sein als die von Codasyl, hierarchischen oder tabellarischen Ansätzen, da er auf einer solch soliden theoretischen Fundierung beruht.
Zwei weitere Gründe sprechen dafür, daß es für die Anwender relationaler DBMS viel leichter sein wird, auf irgendeinen zukünftigen Ansatz umzusteigen: Der relationale Ansatz besteht auf der expliziten Aufzeichnung der gesamten Information. Weiterhin steht der Ansatz in enger Verbindung mit der "First-order predicate"-Logik, auf der ein Großteil der Mathematik beruht.