Ahmad Iqbal ist Geschäftsführer der Iqbal EDV-Systeme GmbH in Hollen.

Verglichen mit dem Alter der ersten hierarchischen Datenbanken liegen die relationalen Systeme fast noch in den Windeln. So hat Ahmad Iqbal denn auch eine Reihe von "Kinderkrankheiten" diagnostiziert: Vorschläge für eine Therapie liefert er jedoch gleich mit.

Es gibt kaum noch Zweifel, daß relationale Datenbanken den deutschen Markt für Datenbanksoftware beherrschen werden. Fast jede große Ausschreibung enthält die Anforderungen einer relationalen Datenbank als Grundvoraussetzung oder dringenden Wunsch. Universitäten oder technische Schulen setzen voraus, daß die Studenten mit Konzepten wie Normalisation oder Referenz-Integrität umgehen können. Die Bücher über Datenbanken konzentrieren sich jetzt auf relationale Architekturen, während vorher die Abhandlung von relationalen Konzepten auf ein oder zwei Seiten beschränkt war.

Zur gleichen Zeit nahm das Interesse an Sprachen der vierten Generation (4GL) rapide zu. Die Software-Anbieter fielen fast übereinander her, um ihre Produkte als Sprachen der vierten Generation darzustellen Das parallele Aufkommen von relationalen Datenbanken und 4GL wird von zwei miteinander in Beziehung stehenden Trends in der Datenverarbeitung vorangetrieben:

Zum einen gibt es ein fortwährendes Verlangen nach größerer Produktivität, was den Einsatz von Computern und die Dienstleistungen des EDV-Personals betrifft. Zum anderen macht die Übertragung der Verantwortung zum Endanwender Methoden notwendig, die dessen Ansprüchen gerecht werden.

Die Datenbanksysteme der vorigen Generation wurden wohl kaum entworfen, um diesen Trends zu entsprechen. Zu dieser Zeit wurde von einem Computer-Anwender fast schon per definitionem erwartet, daß er ein erfahrener Programmierer war. Für den, der sich mit den relationalen Systemen und den Sprachen der vierten Generation und deren Betonung auf einfacher Anwendung, Flexibilität und Produktivität beschäftigt, ist nicht schwer zu verstehen, warum es hier solch eine schnelle Veränderung gab.

Eine Technologie, die schnell eingeführt wird, hat mit Sicherheit Kinderkrankheiten. Viele der relationalen Lösungen machten dabei keine Ausnahme.

Die relationale Auffassung bietet ein leicht zu verstehendes Datenmodell und wird unterstützt durch Sprachen, die die Notwendigkeit von Rekursionen und Iterationen explizit vermeiden. Die Anwender müssen also nicht navigieren, um ihre Daten zu extrahieren.

Wie dem auch sei, es verbleiben zwei grundlegende Beeinträchtigungen, die sowohl Designer als auch Endanwender quälen: zum einen die Ineffizienz des Systems bei der Verarbeitung von mittelgroßen bis sehr großen Datenbanken, zum anderen die Komplexität der Datenmanipulation beim Versuch, Daten über mehrere Relationen hinweg abzufragen.

Die Frage des Leistungsvermögens relationaler Software wurde von "Gurus" wie Chris Date öffentlich diskutiert. Date hatte absolut recht mit seiner Behauptung: "Es gibt keinen wirklichen Grund, warum ein relationales System in seiner Leistung schlechter sein sollte als irgendein anderes System." Außerdem ist sicher richtig, daß die relationalen Systeme sich "in den nächsten paar Jahren" verbessern werden. Aber die Endanwender und das Personal für Management-Informationssysteme benötigen nicht später, sondern jetzt eine Lösung.

Ein weiteres Problem vieler relationaler Systeme ist der unhandliche "relationale Join", der am besten mit einem Beispiel verständlich gemacht werden kann: Stellen wir uns einen Auszug aus einer Personaldatenbank vor, in welcher die Laufbahnen und die regelmäßig gemessenen Leistungen der Angestellten auf ihren jeweiligen Arbeitsstellen aufgezeichnet werden

Eine relationale Datenbank würde diese Daten in drei Relationen speichern: zunächst in einer Angestellten-Relation, die durch die Angestellten-Nummer (A # ) eindeutig identifiziert wird, Daten wie Name und Geburtsdatum enthält, dann in einer Stellen-Relation für jede Stelle, die ein Angestellter innehatte, und schließlich in einer Leistungen-Relation, in der die Leistungsergebnisse für jede Stelle gespeichert werden.

Angenommen, wir brauchen einen Report mit den Einzelheiten jeder Leistungsermittlung, mit dem Angestellten, auf den sich diese Angaben beziehen, und mit der Stelle selbst. Dies würde eine relationale Verkettung über drei Relationen hinweg nach sich ziehen und in Standard-SQL durch die folgenden Zeilen ausgedrückt:

SELECT NAME,STELLE,ANFGEHALT,LEISTUNG FROM ANGESTELLTEN,STELLEN,LEISTUNGEN WHERE ANGESTELLTEN.A # = STELLEN.A # AND STELLEN.A # = LEISTUNGEN.A # AND STELLEN. STELLE = LEISTUNGEN.STELLE

Sogar in einer solch einfachen Anwendung ist die WHERE-Klausel, die bestimmt, welche Begriffe der Relationen miteinander verkettet werden, schon unhandlich. Für gewöhnlich erstreckt sich eine Anwendung über viel mehr Relationen; dann wird es um so schwieriger, die entsprechenden Angaben in Form der Abfragesprache zu spezifizieren - besonders für den Endanwender, der nur gelegentlich damit arbeitet.

Das Software-Design-Team des US-Anbieters SIR hat deshalb neue Techniken entwickelt, die die Möglichkeiten der relationalen Architektur erweitern und gleichzeitig versprechen, eine bessere Effizienz damit zu gewährleisten.

Die erste Design-Grundlage war die Erkenntnis, daß fast alle Datenbanken, ob sie nun aufgrund einer relationalen Spezifikation erstellt wurden oder nicht, wenigstens irgendein strukturelles Merkmal aufweisen. Das Datenwörterbuch erkennt diese Struktur, wann immer es mit Relationen zu tun hat, deren Primärschlüssel übereinstimmen, und benutzt automatisch diese Pfade, wenn SQL benutzt wird.

Pfade reduzieren Maschinen-Overhead

Diese Pfade reduzieren nicht nur den Maschinen-Overhead, sondern machen es dem Anwender auch leichter, die für eine Abfrage nötigen Angaben zu formulieren. Was unser voriges Beispiel angeht, so kann dieselbe Abfrage wie folgt ausgedrückt werden:

SELECT NAME,STELLE,ANFGEHALT,LEISTUNG FROM ANGESTELLTEN,STELLEN,LEISTUNGEN

Das System ist jetzt in der Lage, Begriffe mit identischem Namen in den Primärschlüsseln des Systems zu erkennen, und eine Reihe von systemdefinierten Pfaden zwischen diesen Begriffen aufzubauen. Wenn Relationen miteinander verkettet werden müssen, ist der Vorteil, der durch die Verwendung dieser Pfade erreicht wird, sogar noch größer.

Umwandlung bei Datenbank-Änderung

Die Pfade bieten auch den Vorteil einer automatischen erneuten Umwandlung, wenn die Datenbank geändert wurde. Analog zu den Systempfaden kann der Anwender auch selbst Pfade definieren; außerdem kann er die Pfad-Facility zu beliebiger Zeit an- und abschalten.

Die zweite Design-Grundlage gibt dem Datenbank-Designer die Möglichkeit, Daten zu logischen Entitäten zusammenzufassen. Dies gilt sogar, wenn die Daten in verschiedenen relationalen Tabellen abgelegt sind. Die Speicherung der zu den Entitäten gehörenden Daten kann dann in aufeinanderfolgenden Datenblöcken oder sogar in demselben Datenblock erfolgen. In unserem Beispiel repräsentiert die Angestellten-Entität einen natürlichen Verbund und diese Tatsache kann dazu benutzt werden, die Effizienz radikal zu verbessern.

Darüber hinaus kann der Anwender die aus der Datenbank extrahierten Daten manipulieren, ohne weitere Abfragen zu starten. Dies wurde durch die Implementation eines "Display-Prozessors" erreicht, der aktiviert wird, nachdem das Abfragesystem auf die Daten in der Datenbank zugegriffen hat.