Etliche Jahre galt das relationale Datenmodell als Nonplusultra bei der Entwicklung von Datenbanken. Diese Technik bietet für viele Anforderungen eine gute Lösung, konfrontiert aber in einigen anderen Bereichen den Anwender mit unüberwindlichen Problemen. Das relationale Modell definiert vergleichsweise einfache, wenn auch vielfältig kombinierbare Regeln. Dazu gehört die Data Definition Language (DDL) zur Beschreibung von Daten, die Constraint Definition Language (CDL) zur Definition von Integritätsbedingungen, die Data Manipulation Language (DML) oder auch SQL zur Manipulation der Daten.
DDL, CDL und DML sind die drei charakteristischen Elemente jedes Datenmodells. Jedes Datenhaltungssystem kann in seinem Verhalten durch ein Datenmodell beschrieben werden. So kennt die DDL des relationalen Modells erstens nur vordefinierte, unstrukturierte Datentypen, zweitens nur unstrukturierte Attribute beziehungsweise Eigenschaften, deren Werte von einem der genannten Typen sein müssen und die zu Relationen (Tabellen) zusammengefaßt werden, und drittens eigenschaftslose Beziehungen zwischen genau zwei Relationen. Die Beziehungen werden über Attribut-Wertepaare der beteiligten Tabellen dargestellt.
Für eine Beziehung zwischen mehr als zwei Tabellen muß eine Hilfstabelle eingeführt werden. Dies gilt ebenso für eine Beziehung, die zusätzliche Eigenschaften hat. Auch für sogenannte N-zu-M- oder Viele-zu-viele-Beziehungen muß eine Hilfstabelle eingeführt werden. Das relationale Modell kennt für keinen dieser Fälle ein direktes Konstrukt.
Eigenschaften, die hierarchisch strukturiert sind, zum Beispiel eine Adresse, oder die mehr als einen Wert je Zeile einer Tabelle haben, lassen sich im relationalen Modell allerdings nicht direkt darstellen. Vielmehr müssen auch hier Hilfs- beziehungsweise Zusatztabellen eingeführt werden.
Wann immer die Daten einer logischen Einheit (Entität) auf mehrere Tabellen verteilt werden müssen, die über Primär-Fremdschlüssel-Beziehungen untereinander verbunden sind, müssen diese Tabellen während der Verarbeitung durch eine Anwendung mittels DML-Anweisungen (Join) wieder zeitaufwendig miteinander verknüpft werden.
Anfangs dienten RDBMS vor allem der bequemen und schnellen Auswertung und Analyse von Datenbeständen, die sich meist in den schwer zugänglichen Datenhaltungssystemen der Mainframes befanden. Verarbeitungsgeschwindigkeit war für diese Anforderung kein kritischer Punkt. Und auch das Arbeiten mit Ergebnismengen, die heute oft erst durch die Anwendungen aufgelöst werden, war unter diesem Aspekt eher erwünscht als problematisch.
Mehr Strukturen: Das postrelationale Modell
Ein postrelationales Datenmodell erlaubt hierarchisch geschachtelte Strukturen; Tabellen dürfen dabei weitere Tabellen enthalten. Weil dies über die erste Normalform des relationalen Modells hinausgeht, werden solche Systeme auch als Non-First-Normal-Form-Systeme (NF2) bezeichnet. "Post" ist dabei kein historischer Begriff, sondern ein logischer: Das postrelationale Datenmodell beseitigt einige Einschränkungen, die das relationale aus den erwähnten Gründen machen muß. Mit geschachtelten Tabellen wird Ausdrucksfähigkeit im Datenbankschema gewonnen, der Verarbeitungsaufwand für komplexere Entitäten verringert sich, und zugleich erhöht sich die Verarbeitungsgeschwindigkeit.
Für die "Fremdsprachen", "Gehälter" oder "Telefonnummern" eines "Mitarbeiters" muß keine separate Tabelle mehr angelegt und verarbeitet werden. Die Eigenschaft "Fremdsprachen" der Tabelle "Mitarbeiter" etwa kann je Mitarbeiter mehrere Ausprägungen haben. Die Entität "Mitarbeiter" muß dabei nicht zerlegt werden.
So benötigen die "Auftragsdetails" eines "Auftragskopfs" keine separate Tabelle, sondern können zu einer Untertabelle der einen "Auftragskopf"-Tabelle gemacht werden. Dinge, die eventuell noch in der Modellierung getrennt waren, aber zusammengehören und auch zusammen verarbeitet werden, können zusammengeführt werden.
Allgemein kann jede Eins-zu-viele-Beziehung auf nur einer geschachtelten Tabelle abgebildet werden, wenn die Ausprägungen (Sätze) der Entität auf der Viele-Seite nicht ohne einen zugehörigen Satz auf der Eins-Seite existieren können. Im Beispiel existieren "Auftragsdetails" nicht ohne einen "Auftragskopf". Auch eine wiederholte Schachtelung ist möglich und kann sinnvoll sein. Eine "Kunden"-Tabelle kann die "Aufträge" als Untertabelle, die "Auftragskopf"-Untertabelle die "Auftragsdetails" als weitere Untertabelle enthalten.
Die erste Normalform des relationalen Modells verbietet geschachtelte Strukturen, also Tabellen in Tabellen. Und obwohl die zweite und alle weiteren Normalformen die erste Normalform zur Voraussetzung haben, dienen sie doch ganz unterschiedlichen Zwecken. Die höheren Normalformen vermeiden Redundanz und verhindern Anomalien bei Einfüge-, Aktualisierungs- und Löschoperationen. Die erste Normalform ist eher eine charakteristische, grundlegende Eigenschaft des relationalen Modells. Das bedeutet, auch in einem Modell, das nicht der ersten Normalform folgt, können die höheren Normalformen erfüllt werden. Tatsächlich werden die höheren Normalformen praktisch automatisch erfüllt, wenn das Datenbankschema aus einem Entity-Relationship-Schema abgeleitet wird.
Mehrere Hersteller bieten DBMS mit postrelationalem Datenmodell an. Dazu gehören die Intersystems Corp. mit "Caché", die Ardent Software, entstanden aus Unidata und Vmark Software, mit "Unidata" und die Software AG mit "Adabas".
Die postrelationalen Datenmodelle haben das relationale Modell um hierarchische, geschachtelte Strukturierungsmöglichkeiten erweitert. Den Tabellen ließen sich aber weiterhin keine Verarbeitungsfunktionen zuordnen. Daher war weder eine Datenkapselung möglich, noch konnte Verarbeitungslogik systematisch in das DBMS verlagert werden.
Die objektrelationalen Datenmodelle bieten durch benutzerdefinierbare Datentypen noch vielfältigere Strukturierungsmöglichkeiten und erlauben mittels benutzerdefinierter Funktionen die Zuordnung von Verarbeitungslogik zu Datentypen. Auch dabei bleiben die Tabellen als Ausprägungen von Datentypen noch ungekapselt, der Zugriff kann über die definierten Zugriffsfunktionen erfolgen.
Erst mit dem Übergang zu gekapselten Datenstrukturen, die sich als Datentyp definieren lassen - sogenannten abstrakten Datentypen (ADT) oder auch Klassen -, werden die Tabellen mit ihren Funktionen (Methoden) zu Objekten. Hier beginnt der Bereich der objektorientierten DBMS (OODBMS), bei denen zusätzlich hierarchische Beziehungen wie Spezialisierung oder Generalisierung zwischen Klassen gebildet und Methoden zwischen Klassen vererbt werden können.
Diese Form von Strukturierungskonstrukten sind in modernen Programmiersprachen wie Modula, Eiffel, ADA oder Java schon lange bekannt. Mit der Einführung in DDLs wird wiederum eine semantische Lücke zwischen Programmiersprachen oder Anwendungen und der Datenhaltung geschlossen. Mit benutzerdefinierbaren Funktionen kann nämlich tabellen- sowie datentypspezifischer Anwendungscode in das DBMS verlagert werden. Die Funktionen lassen sich anschließend direkt in SQL-Anfragen verwenden.
Objektrelationale DBMS werden heute vor allem von den Herstellern IBM, Oracle und Informix angeboten. Jeder hat dabei andere Bestandteile des SQL-3-Standards individuell realisiert. Tatsächlich ist zu befürchten, daß dies ein gewichtiges Manko des SQL-3-Standards sein wird. Die Sprachbeschreibung ist zu umfangreich, kein Hersteller wird auch nur annähernd die gesamte Sprache realisieren. Außerdem ist zu erwarten, daß sich die einzelnen Implementierungen noch mehr voneinander unterscheiden werden, als dies heute schon bei SQL 2 der Fall ist. Damit verliert der Standard SQL einen Gutteil seines Nutzens. Verschiedene herstellerspezifische SQL-3-artige Datenmodelle könnten eine Kompatibilität und damit den Betrieb von Anwendungen auf unterschiedlichen Datenhaltungen unmöglich machen.
OODBMS: Interessant, aber nicht relevant
Die Objektorientierung hat in den letzten Jahren auf allen Ebenen der Informationsverarbeitung Einzug gehalten. Dies gilt auch für den Bereich der Datenbanken. Damit ist auch schon der größte Vorteil dieser Systeme angesprochen: Sie lassen sich sehr gut in Objektmodelle integrieren, so daß beispielsweise C++- und künftig wohl auch Java-Entwickler in einem einheitlichen Modell arbeiten können. Andererseits sind die OODBMS im Vergleich zu den RDBMS noch lange nicht ausgereift. Zwar gibt es vor allem im technischen Bereich entsprechende Lösungen, im kaufmännischen ist ihre praktische Bedeutung jedoch noch unbedeutend. OODBMS sind daher eine interessante Technik, die jedoch noch ohne praktische Relevanz ist.
Die objektrelationalen und objektorientierten Datenmodelle bieten vielfältige Datenbeschreibungs- und Manipulationsmöglichkeiten, allerdings um den Preis eines übergroßen Sprachumfangs. Anstelle einer Sprache wie SQL 3, die in einem Datenschema für jede Tabelle die zugehörige Satzstruktur definiert, könnte eine Sprache treten, die es erlaubt, jeden "Satz" mit einer Selbstbeschreibung auszustatten und dann in gewissermaßen strukturlosen Behältern zu speichern. Dies wäre ein komplett neuer Ansatz für Datenbanken. Eine Flut von immer neuen, anders strukturierten Tabellen würde vermieden - theoretisch wäre genau ein Behälter ausreichend -, und die Datensätze könnten beliebig komplex strukturiert sein - eine entsprechende Sprache vorausgesetzt. Solchermaßen beschriebene Datensätze wären gewissermaßen von ihrer eigenen Beschreibung durchzogen und damit für vielfältige maschinelle Verarbeitungen erschlossen.
Die Extensible Markup Language (XML) ist eine solche universelle Datenbeschreibungssprache. XML basiert wie HTML (Hypertext Markup Language) auf der Standard Generalized Markup Language (SGML). SGML ist seit langem für Definition, Austausch und Verwaltung sehr großer und komplexer Dokumentenbestände im Einsatz. XML ist die kleinere, praktikablere Variante von SGML. Die Standardisierung wird vom World Wide Web Consortium (W3C) vorangetrieben. Von HTML unterscheidet sich XML in drei wesentlichen Punkten:
-Neue Tags - also Datenauszeichnungen, die eine Bedeutung beinhalten - können jederzeit vom Benutzer definiert werden.
-Daten- und Dokumentstrukturen können beliebig geschachtelt sein.
-Jedes Dokument beziehungsweise jeder Datensatz kann eine Bauvorschrift (Grammatik) etwa für eine Syntaxprüfung enthalten.
In einem Datenmodell, dessen DDL XML ist, muß es auch eine DML geben. Mit einer Sprache dieser Art wird eine sowohl inhalts- als auch strukturbasierte Suche und Aufbereitung von XML-beschriebenen Daten möglich sein.
Was ist XML?
XML ist eine universelle Konvention zur Beschreibung von Daten auf Basis von SGML und geht weit über den bislang im Web hauptsächlich verwendeten HTML-Standard hinaus. Anders als HTML ist XML in der Lage, Daten nicht nur nach formalen Kriterien wie Überschrift oder Textkörper zu strukturieren, sondern auch nach inhaltlichen Gesichtspunkten. Um den ganz unterschiedlichen Inhalten des Web Rechnung zu tragen, ist XML dabei so flexibel, daß die jeweiligen inhaltlichen Strukturmerkmale von Benutzergruppen selbst definiert werden können. So wäre es beispielsweise denkbar, daß Meteorologen für den Austausch von Wetterdaten eigene Tags wie etwa "Temperatur", "Luftdruck" oder "Windstärke" festlegen und diese Definitionen in entsprechenden Templates ablegen. XML-fähige Anwendungen könnten dann derartige Web-Seiten direkt verarbeiten, also beispielsweise Wetterdaten automatisch per Web auswerten. XML bietet die Möglichkeit, vom Browser aus direkt auf XML-fähige Server zuzugreifen und Informationen zu recherchieren, die vom XML-Server aus verschiedenen Informationstypen oder auch aus vorhandenen relationalen Daten zusammengesetzt werden. Den gleichen Service kann auch eine Anwendung nutzen. Beide nutzen die URL-Adresse für die Verbindung zum gewünschten XML-Server. Klassische Anwendungen können weiterhin parallel dazu laufen und auf ihre SQL-Daten zugreifen.
*Rainer Krause ist Produkt-Marketing-Manager Datenbanksysteme bei der Software AG in Darmstadt.