DBMS-Probleme werden kontrovers diskutiert:

Kritik am relationalen Datenbank-Modell

16.12.1988

Die Achillesfersen heutiger relationaler Datenbanksysteme, unter anderem die Schwierigkeit für den Anwender, realitätsnahe Abfragen zu formulieren, versuchte Wolfgang Zinke in seinem Beitrag "Der Datenbestand kann zur Zeitbombe werden" (CW Nr. 46 vom 11. November 1988, Seite 10) zu analysieren. CW-Leser Johann Christoph Freytag* bezeichnet Zinkes Ausführungen als "technisch unklar und teilweise falsch". Im folgenden Beitrag setzt sich Freytag mit Zinkes Aufsatz auseinander.

Der Artikel diskutiert verschiedene Aspekte und Probleme des relationalen Modells, die wenig miteinander zu tun haben und einer sorgfältigeren Analyse bedürfen. Da eine detaillierte Auseinandersetzung mit diesem Artikel aus Platzgründen nicht möglich ist, beschränke ich meine Kritik und Kommentare im folgenden auf einige wichtige Punkte:

Die Behauptung "Das Relationale Modell hat jedoch die immanente Schwäche, daß nur sehr einfache Integritätsbedingungen mit den ihm eigenen Sprachmitteln ausdrückbar sind", ist grundweg falsch. Mag sein, daß viele relationale DBMS keine mächtigen Möglichkeiten anbieten, beliebige Integritätsbedingungen zu formulieren. Deshalb werden diese noch lange nicht vom relationalen Modell ausgeschlossen. Im Gegenteil, die Datenbankforschung hat sich in den letzten 15 Jahren mit dem Problem auseinandergesetzt und dieses als integralen Bestandteil des Modells angesehen. Daß die meisten relationalen Systeme noch keine allgemeinen Integritätsbedingungen zulassen, hat Gründe, die die Effizienz der Auswertung betreffen. Ein System, das relativ mächtige Integritätsbedingungen zu läßt, ist SYBASE (dies heißt aber noch lange nicht, daß SYBASE diese auch in effizienter Form in sein System integriert).

Die Entwicklung des NF2-Modells hat wenig mit den im Artikel angegebenen Gründen zu tun. Hauptmotivation des NF2-Modells ist es viel mehr, ein an Konzepten reicheres Modell als das (traditionelle) relationale Modell auf der logischen Ebene (um bei der Sichtweise des Autors zu bleiben) anzubieten, nämlich Attributwerte beliebiger Komplexität zuzulassen. Mit anderen Worten, Attributwerte können auch "relationenwertig" sein, das heißt der Wert eines Attributes ist wiederum eine Relation beliebigen Typs. Damit ist eine Schachtelung von Relationen in beliebiger Tiefe möglich.

Pointer unterstützen Relationen-Schachtelung

Die Forschungsgruppe um Professor Schek in Darmstadt hat sich zum Ziel gesetzt, dieses (logische) Modell auf der physischen Ebene mit neuen Konzepten zu unterstützen, die die Effizienz der Implementation dieses Modells garantieren. Dabei wird nicht das Prinzip des "clustering" verwendet (dies existiert beispielsweise auch in DB2), sondern es werden vielmehr physische Pointer benutzt, die das logische Konzept der Relationenschachtelung auf der physischen Ebene "implementieren" (unterstützen). Es ist aber durchaus denkbar, das NF2-Modell auch mit "flachen" (herkömmlichen) Relationen zu implementieren (möglicherweise mit schlechterer Performance bei der Auswertung von Anfragen. Dies ist aber noch nicht bewiesen).

Viele der vom Autor angesprochenen Probleme werden auch vom NF2-Modell und seiner Implementation nicht gelöst. Das grundlegende Problem, mit dem relationale Datenbanksysteme und das relationale Modell zu kämpfen haben, liegt in der sehr begrenzten Möglichkeiten, Strukturinformationen auszudrücken und diese dem DBMS zugänglich zu machen. Dazu gehören die vom Autor angesprochenen Konzepte wie "has-attribute", oder "is-a", die aus dem Bereich der semantischen Datenmodellierung (konzeptuelle Ebene) stammen.

Dieser Nachteil, der zunächst nur die konzeptuelle/logische Ebene betrifft, ist von Praktikern und Forschern im Datenbankbereich längst erkannt worden. Schon E.F. Codd hat das relationale Modell Ende der 70er Jahre (!) mit dem Artikel "Extending the Relational model to Capture More Meaning" (ACM Transactions on Database Systems, Vol. 4, No. 4, Dezember 1979, Seiten 397-434) beträchtlich erweitert. Das NF2-Modell ist ein weiterer Beitrag in diese Richtung.

Weit vielversprechender sind meiner Meinung nach jedoch die Anstrengungen im Bereich objektorientierter Datenbanken, die in den vergangenen zwei bis vier Jahren schon zu ersten Produkten auf dem amerikanischen Markt geführt haben (zum Beispiel das System GemStone von Servio Logic, das die objektorientierte Programmiersprache Smalltalk um eine Datenbankkomponente erweitert). Dieser Ansatz versucht, ein neues Modell (nämlich das von allgemeinen Objekten) anzubieten, in dem allgemeine Strukturierungsmerkmale und Beziehungen zwischen Objekten formuliert und einem System mitgeteilt werden können. Damit wird eine Trennung zwischen konzeptueller und logischer Ebene hinfällig.

Allerdings ist zur Zeit noch keine generelle Übereinstimmung zu erkennen, welches die grundlegenden Merkmale eines objektorientierten DBMS sind. Außerdem sind noch viele Fragen, die dieses neue Modell (Anfragesprache /Optimierung usw .) aufwirft, offen und bedürfen weiterer Forschung nach Lösungen, um dieses Modell effizient zu implementieren.

Aus den genannten Gründen wird deutlich, daß eine klarere Kritik des relationalen Modells notwendig ist, um - wie es in diesem Artikel versucht wurde - bessere Alternativen oder Erweiterungen zum relationalen Modell zu entwickeln und diese in Systemen anzubieten. Jedoch werden viele der vom Autor genannten Kritikpunkte am relationalen Modell auch vom NF2-Modell nicht beseitigt.