Relationale Datenbanksysteme weisen neben vielen Vorteilen wie Benutzerfreundlichkeit und Flexibilität auch erhebliche Unzulänglichkeiten vor allem im Bereich der Datenspeicherung auf. Nach einer allgemeinen Abhandlung der entstehenden Fragen versucht Wolfgang Zinke*, am Beispiel eines Datenbankkernsystems diese Punkte zu verdeutlichen.

Eines der Hauptprobleme, vor das sich Verwalter und Benutzer komplexer Datenbanken immer wieder gestellt sehen, läßt sich so skizzieren: Um die Handhabbarkeit der Datenbank zu verbessern, werden Basis-Datenbestände in Form einfacher Tabellen angelegt, auf die ein unproblematischer und schneller Zugriff möglich ist.

Daten, die getrennt voneinander gespeichert sind, aber gemeinsam benutzt werden, werden auf Anwendungsebene miteinander verknüpft ("joins"). Das ist die Grundidee des Relationenmodells, das wegen der Klarheit des Aufbaus und der Einfachheit der Handhabung heute von vielen Anwendern favorisiert wird.

Das Relationenmodell hat jedoch die immanente Schwäche, daß nur sehr einfache Integritätsbedingungen mit den ihm eigenen Sprachmitteln ausdruckbar sind. Der gleiche Satz von Bedingungen wird daher an verschiedenen Stellen der Anwendung abgeprüft. Aber in der Regel bleibt es nicht bei diesen Code-Redundanzen; es ist nur eine Frage der Zeit, bis die Integritätsprüfungen von verschiedenen Anwendern unterschiedlich formuliert werden. Der

Datenbestand ist dann nicht mehr integer und wird quasi zur Zeitbombe.

Relationale Datenbanksysteme basieren auf der "Normalisierung" der Daten, wobei die erste Normalform unter anderem besagt, daß eine Tabelle oder Relation nur aus einfachen Einträgen, sogenannten Attributen, bestehen darf. Die Daten komplexer Objekte sind an vielen verschiedenen Stellen in voneinander unabhängigen Tabellen abzulegen und müssen folglich erst über die Anwendung zusammengeführt werden.

Daraus resultiert eine weitere Schwäche des Relationenmodells: Für den Zugriff auf solchermaßen verstreut gespeicherte Daten sind viele Zugriffsoperationen, verbunden mit hohem Bedarf an Pufferspeicher, nötig. Das hat relationalen Datenbanksystemen den Ruf eingetragen, "Ressourcenfresser" und dabei nicht leistungsfähig genug zu sein.

Man begann daher in verschiedenen Forschungsgruppen, sich Gedanken zu machen über eine "denormalisierte" Speicherung der Daten, um den Komfort, den relationale Datenbanken bieten, mit sinnvollen Speicherungsmethoden verbinden zu können. Die Datenbankgruppe an der Technischen Hochschule in Darmstadt unter Professor H.-J Schek publizierte 1982 erstmals das sogenannte NF2-Modell.

Das Kürzel steht für "Non First Normal Form". Durch das Außerkraftsetzen der ersten Normalform wird es möglich, Daten, die regelmäßig in Joins gemeinsam benutzt werden, benachbart oder, man sagt auch, "geclustert" zu speichern. Dadurch wird die Zahl der Seiten, die aus dem physikalischen Speicher bei Verwendung eines derart abgelegten Objekts eingelesen werden müssen, erheblich reduziert.

Vier Formen der Datensemantik

Über diese Performance-Steigerung hinaus bieten Datenbanksysteme, die sich das NP2-Modell zunutze machen, gegenüber herkömmlichen Systemen mehr Möglichkeiten, die Datensemantik - bedeutungsabhängige Zusammenhänge zwischen Daten - bereits bei der Speicherung zu berücksichtigen. Dabei geht es um vier Arten von Beziehungen.

Zunächst einmal sind das Beziehungen vom "has-attribute"-Typ, wie sie in jedem Datenbanksystem vorhanden sind. Bei der relationalen Architektur wird eine Sammlung von Objekten, also ein Objekttyp, in Form einer Tabelle wiedergegeben. Jede Spalte enthält ein Attribut, während die Zeilen jeweils ein Tupel, ein einzelnes Objekt mit verschiedenen Attributen, repräsentieren.

Um die zweite Art von semantischen Beziehungen zwischen Daten zu veranschaulichen, mag als Beispiel die Aufgabenstellung dienen, ein Datenhaltungskonzept für ein Platzreservierungssystem von Eisenbahnen zu entwickeln. Als Objekttyp kommen dabei unter anderem Eisenbahnwagen vor, deren Attribute die Anzahl der Sitze, die Klasse, die Zuordnung Nichtraucher/Raucher etc. sind. Jedem Attribut wird ein Wertebereich, in der Fachterminologie Domäne genannt, zugeordnet. Auf diese Weise wird festgelegt, welche Eintragungen für die jeweilige Spalte zulässig sind, wie viele Sitze, welche Klassen es geben kann.

Das Unterscheiden macht noch Probleme

Solange es sich um gleichartige Objekte handelt, ist die Abbildung in einer relationalen Datenbank problemlos möglich. Damit nicht ausdruckbar ist jedoch die Unterscheidung zwischen verschiedenen Arten von Eisenbahnwagen wie etwa Sitz-, Speise- und Schlafwagen, um nur eine grobe Auswahl der verschiedenen Formen des generalisierten Typs Eisenbahnwagen zu geben.

Solche Spezialisierungen eines Objekttyps vom "is-a"-Typ mit unterschiedlichen Attributen in den einzelnen Spezialisierungen - ein Objekttyp als Unterklasse eines allgemeinen Typs - lassen sich im relationalen Modell nicht gut ausdrücken. Dort können die verschiedenen Eisenbahnwagenarten nur als voneinander unabhängige Objekttypen, die in keinerlei Verbindung miteinander stehen, abgelegt werden.

In anderen konventionellen Datenbanksystemen des hierarchischen oder Netzwerk-Typs bleibt diese Art von Beziehung ebenfalls unberücksichtigt. Einzig objektorientierte Datenbankkonzepte, die jedoch kommerziell noch nicht verfügbar sind, widmen sich derzeit verstärkt diesem Problem.

Die dritte Form der semantischen Datenmodellierung ist die Hierarchie. Dabei kann man unterscheiden zwischen Aggregationen - Zusammenfassungen von verschiedenen Attributen - und Gruppierungen, die aus gleichartigen Objekten bestehen. Um das Platzreservierungsbeispiel wieder aufzunehmen: Ein Eisenbahnwagen stellt eine Gruppierung dar, dessen Teilobjekte die Abteile und deren Teilobjekte wiederum die Sitze sind.

Man spricht in diesem Fall von fester Gruppierung, da, wenn der Wagen aus der Datenbank gelöscht wird, selbstverständlich auch die Abteile und die Sitzplätze verschwinden. Ein ganzer Zug mit seinen verschiedenen Wagen ist demgegenüber als lose Gruppierung aufzufassen: Die einzelnen Wagen bestehen ja weiter, nachdem der Zug aufgelöst wurde.

Die Semantik der hierarchischen Beziehungen wird sowohl von hierarchischen als auch von Netzwerk-Datenbanken unterstützt, nicht jedoch von relationalen Systemen. Denn gemäß der ersten Normalform können die in einer Relation abgelegten Objekte nicht aus Teilobjekten bestehen. Anders ausgedrückt: Im klassischen Relationenmodell ist es nicht möglich, den Tupeln Subtupel zuzuordnen. Das NF2-Modell ist demgegenüber sehr gut geeignet, um feste Gruppierungen von Objekten auszudrücken, da von einem Tupel beliebig viele verschachtelte Subtupel abhängen können.

Kernsystem für den Aufbau von Datenbanken

Kaum unterstützt werden bisher in Datenbanksystemen semantische Beziehungen von einer vierten Art - nach dem Muster des "Entity-Relationship-Modells". Mit dem Begriff "Entity" sind Objekttypen bezeichnet. "Relationships" sind Beziehungen zwischen Objekten. Eine Beziehung wird beschrieben als die Rolle, die ein Objekt im Verhältnis zu einem anderen Objekt spielt.

Die Integrität einer Datenbank, die sich in Bedingungen für die Beziehungen komplexer, in sich strukturierter Objekte zu anderen gleichrangigen, nicht in irgendeiner Form unter- oder übergeordneten Objekten manifestiert, wird bisher nicht befriedigend durch kommerziell verfügbare Datenbanksysteme unterstützt, auch nicht von Konzepten auf der Basis des NF2-Modells.

Einschränkend muß gesagt werden, daß die hier vorgestellten Probleme nur einen Ausschnitt aus der Problematik der semantischen Datenmodellierung zeigen.

Bei DBKSI handelt es sich um ein Kernsystem für Datenbanken, das Speicherungsstrukturen bereitstellt, mit denen man semantische Beziehungen ausdrücken kann. Durch die Schemabeschreibungssprache es Kernsystems werden Grundstrukturen auf Datenhaltungsebene bereitgestellt, in denen sich die ersten drei der oben vorgestellten Beziehungstypen reflektieren.

Diese Sprache unterstützt zunächst einmal wie alle Datenbanksysteme die Bildung von "has-attribute"-Beziehungen. Darüber hinaus ermöglicht das Kernsystem die Beschreibung von Spezialisierungen ("is-a"-Beziehungen) mut Hilfe des Choice-Sprachkonstrukts. Das heißt, in einem Objekttyp kann ein Attribut "Auswahlvariable" eingeführt werden, dem sich eine beliebige Anzahl von Spezialisierungen zuordnen läßt.

Diese werden dann jede für sich durch einen Objekttyp beschrieben. Hierarchische Beziehungen werden auf zweierlei Art unterstützt. Bei Beschreibung von Aggregationen tritt an die Stelle eines Attributs ein Platzhalter für einen Objekttyp, der dann wieder eine Sammlung von Attributen enthält.

Beziehungen von der Art Gruppierung unterstützt DBKSI mit dem Set-Sprachkonstrukt, indem es die Option bietet, entsprechend dem NF2-Modell einfache Attribute durch relationenwertige Attribute zu ersetzen. An den Stellen des Schemas, wo ein atomares Attribut stehen kann, wird dann ein Verweis auf einen Objekttyp eingetragen, der Bezug nimmt auf eine Menge von beliebig vielen gleichartigen Teilobjekten.

Mit Choice-Variablen, Platzhaltern und Set-Variablen sind Grundstrukturen für die Datenmodellierung gegeben. Durch das Referenzierungssystem lassen sich Objekte beliebiger Schachtelungstiefe beschreiben. In der Schemabeschreibungssprache nicht berücksichtigt sind jedoch die Aspekte der Datenmanipulation und -integrität. Dafür Lösungen zu entwickeln, ist dem Anwendungsprogrammierer überlassen.

Komfortable Datenhaltung von komplexen Objekten

Er kann sich die für seine Zwecke geeigneten Zugriffs-primitive selbst entwickeln. Das Kernsystem bietet die Möglichkeit, im Schema der Datenbank Informationen über Attribute oder Objekttypen abzulegen, die auf höherem Niveau ausgewertet aber von DBKSI hinsichtlich Transaktionskontrolle, Recovery etc. mitverwaltet werden.

Auf diese Weise ist es dem Benutzer möglich, von einem höheren Niveau aus Informationen in das Schema hineinzubringen, um sich beispielsweise ein eigenes Data-Dictionary aufzubauen. Dadurch ergeben sich auch neue Perspektiven der Datenhaltung unter anderem für wissensbasierte Systeme, in denen Beziehungen zwischen strukturierten Objekten nach dem Entity-Relationship-Modell zum Ausdruck zu bringen sind. Informationen über die Semantik zwischen Objekten lassen sich im Schema ablegen und mitverwalten.

DBKSI versteht sich als eine Betriebssystemerweiterung, die mit allen gängigen Betriebssystemen zusammenarbeitet und folgende Eigenschaften aufweist:

- Mehrbenutzerfähigkeit,

- Ein-/ Ausgabe auf komplex strukturiertem, dynamisch erweiterbarem externem Speicher,

- Datenbankgrundoperationen wie Selektion und Projektion,

- Verwaltung eines Datenbankschemas zur Beschreibung komplexer Objekte,

- automatischer Wiederanlauf nach Fehlern.

Auf eine kurze Formel gebracht läßt sich sagen: DBKSI macht es möglich, auf die gleiche Weise mit komplexen Objekten umzugehen, wie in herkömmlichen Systemen mit einfachen Objekten umgegangen wird. Sogenannte Non-Standard-Anwendungen, die komplexe und unterschiedlich strukturierte Objekte zu verwalten haben und daher bisher ohne eine echte Datenbank auskommen mußten, sind unter anderem:

- Textverarbeitung und Information Retrieval,

- Bild- und Sprachverarbeitung,

- Prozeßdatenverwaltung,

geographische, kartographische und geodätische Anwendungen - wissenschaftliche Anwendungen (Versuchsdatenerfassung und

-auswertung),

- Entwurf und Fertigung (CAD/CAM).

Das Konzept eines Datenbankkernsystems erscheint für die Verwendung in Non-Standard-Anwendungen besonders geeignet. Denn Kernsysteme enthalten die wesentlichen Vorzüge von Datenbanksystemen wie Transaktionsorientierung, Wiederanlauffähigkeit und Mehrbenutzerfähigkeit, ohne daß sie unnötigen Ballast mit sich führen.

Die im Vergleich zu konventionellen Datenbanksystemen niedrig angesetzte Schnittstelle läßt andererseits auch einen starken Einfluß und damit Optimierungsmöglichkeiten durch die Anwendung zu. Die Verknüpfung von DBKSI mit den höheren Ebenen eines Datenbanksystems erfolgt entweder durch Einbinden in den Code der Anwendung oder über eine Kommunikationsschnittstelle.

Eine solche Schnittstelle ist etwa dann zu bevorzugen, wenn das Kernsystem die Datenhaltung für mehrere Anwendungen besorgen soll.