XML Bibliothek

Von relational über NF2 zu SQL3 und XML Datenstrukturen im Wandel

Autor: Rainer Krause

Nach langer Vorherrschaft relationaler Datenbanksysteme (RDBMS) gewinnen inzwischen neue, leistungsfähigere Datenmodelle an Bedeutung. Der Weg führt über post-relationale Strukturen (NF2) und objektrelationale Modelle (ORDBMS, SQL 3) zu einer universellen Datenbeschreibungssprache (XML). Diese Entwicklung folgt konsequent dem zunehmenden Bedarf, Strukturen und Bedeutungen der realen Datenwelt ohne Verluste darstellen und manipulieren zu können.

Der Defacto-Standard der Datenbanktechnologie der letzten Jahre ist das relationale Datenmodell. Erst mit dem Aufkommen objektorientierter und objektrelationaler Systeme hat sich der Blick für andere Modelle ein wenig geöffnet. Dabei stellt man oft erstaunt und enttäuscht fest, daß auch damit beileibe nicht alle Probleme der digitalen Datenhaltung gelöst sind –obwohl die Anbieter vollmundig versprochen haben, die komplexen Objekte seien genau das richtige Mittel, die ebenfalls komplexe reale Welt einzufangen. Tatsächlich geht es aber nicht darum, vom Flat-file bis zur Objekt-Datenbank die Realität immer besser abzubilden, sondern für oft sehr verschiedene Anforderungen die jeweils passende Lösung zu finden.

Einfach und universell: das relationale Datenmodell

Das relationale Datenmodell bietet für viele Anforderungen eine gute Lösung, die den Anwender aber in einigen Bereichen mit unüberwindbaren Problemen konfrontiert. Das relationale Modell definiert vergleichsweise einfache, wenn auch vielfältig kombinierbare Regeln:

• DDL (Data Definition Language) zur Beschreibung von Daten;
• CDL (Constraint Definition Language) zur Definition von Integritätsbedingungen;
• DML (Data Manipulation Language) zur Manipulation der Daten; die DML ist unter der Bezeichnung SQL bekannt.

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/Eigenschaften (Spalten), 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 (sogenannte Primär-Fremdschlüssel-Beziehungen).

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: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/zusammengesetzt sind (zum Beispiel eine Adresse) oder die mehr als einen Wert je Satz/Zeile einer Tabelle haben, können im relationalen Modell nicht direkt dargestellt werden. Vielmehr müssen auch hier Hilfs- bzw. 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.

In der historischen Entwicklung dienten die RDBMS zunächst 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 post-relationale Datenmodell

Ein post-relationales Datenmodell erlaubt hierarchisch geschachtelte Strukturen; Tabellen dürfen 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 (wie etwa die "Post-Moderne"), sondern ein logischer: das post-relationale 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 gleichermaßen 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" usw. der einen Tabelle "Mitarbeiter" kann je Mitarbeiter (Satz) mehrere Ausprägungen haben. Die Entität "Mitarbeiter" muß nicht zerlegt werden. Dinge, die zusammengehören, bleiben zusammen – Lokalität wird erhalten. Lokalität reduziert Verarbeitungsaufwand und erhöht damit die Verarbeitungsgeschwindigkeit.

So benötigen die "Auftragsdetails" eines "Auftragskopfes" 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. Lokalität kann so auch geschaffen 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" (der Kunden) als Untertabelle enthalten. Die "Auftragskopf"-Untertabelle kann 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/höheren 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. Sie hat mit Redundanzen und Anomalien nichts zu tun. 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 – was in der Praxis häufig der Fall ist, weil das Entity-Relationship-Modell ein viel genutztes Hilfsmittel der Systemanalyse ist.

Die Entitäten der realen Welt sind vielfach hierarchisch geschachtelt und strukturiert – das post-relationale Datenmodell trägt dem Rechnung. Die semantische Lücke zwischen realer Welt und DBMS wird in diesen Fällen etwas kleiner.

Mehrere Hersteller bieten DBMS mit post-relationalem Datenmodell an:

• InterSystems Corporation (http://www.intersys.com) mit Caché
• Ardent Software (http://www.ardentsoftware.com), entstanden aus UniData und VMARK Software, mit UniData
• Software AG (http://www.softwareag.com) mit Adabas

Datentypen und Funktionen: das objektrelationale Datenmodell

Die post-relationalen Datenmodelle haben das relationale Modell um hierarchische, geschachtelte Strukturierungsmöglichkeiten erweitert. Den Tabellen konnten aber weiterhin keine Verarbeitungsfunktionen zugeordnet werden. Daher war weder eine Datenkapselung möglich noch konnte Verarbeitunsglogik systematisch in das DBMS verlagert werden.

Die objektrelationalen Datenmodelle bieten durch benutzerdefinierbare Datentypen noch vielfältigere Strukturierungsmöglichkeiten und erlauben mittels benutzerdefinierten 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, muß dies aber nicht.

Erst mit dem Übergang zu gekapselten Datenstrukturen, die als Datentyp definiert werden können – sogenannten abstrakten Datentypen (ADT) oder auch Klassen – werden die Tabellen mit ihren Funktionen (Methoden) zu Objekten (als Ausprägungen von Klassen). Hier beginnt der Bereich der objektorientierten DBMS (OODBMS), bei denen zusätzlich hierarchische Beziehungen (Spezialisierung bzw. Generalisierung) zwischen Klassen gebildet und Methoden zwischen Klassen vererbt werden können.

Mit benutzerdefinierbaren Datentypen können hierarchische, geschachtelte Strukturen in noch größerer Vielfalt definiert werden:

• Eigenschaften können hierarchisch aufgebaut werden ("Adresse" strukturiert sich in "Straße", "PLZ", "Stadt")
• Eine Eigenschaft kann von folgenden Typen sein:

1. Menge (alle Elemente vom gleichen Typ, keine Mehrfachvorkommen, keine Reihenfolge)
2. Multi-Menge (alle Elemente vom gleichen Typ, Mehrfachvorkommen zulässig, keine Reihenfolge)
3. Liste (Elemente unterschiedlichen Typs zulässig, feste Reihenfolge, Zugriff nur auf erstes Element und Restliste)
4. Array (alle Elemente vom gleichen Typ, Mehrfachvorkommen zulässig, feste Reihenfolge, wahlfreier indizierter Zugriff)

• Eine Eigenschaft kann auf sehr große, binäre oder alphanumerische Objekte zeigen, die in einem separaten Behälter gespeichert sein können.

Die genannten Strukturierungskonstrukte sind in modernen Programmiersprachen (Modula, Eiffel, ADA, 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 tabellen-/datentypspezifischer Anwendungscode in das DBMS verlagert werden. Die Funktionen können direkt in SQL-Anfragen (SELECT.. FROM.. WHERE) verwendet werden. Die Wartung wird vereinfacht, Ausführungs- und Kommunikationskosten sinken.

Die DML erlaubt inzwischen auch rekursive Abfragen entlang rekursiver Beziehungen, ähnlich wie dies bei dem Entity-Relationship-DBMS Adabas Entire schon vor Jahren angeboten wurde.

Insbesondere IBM, Oracle und Informix bieten objektrelationale DBMS an. Jeder der Hersteller hat dabei andere Bestandteile des SQL 3-Standard-Vorschlages 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 guten Teil seines Nutzens. Verschiedene herstellerspezifische SQL 3artige Datenmodelle könnten eine Kompatibilität und damit den Betrieb von Anwendungen auf unterschiedlichen Datenhaltungen unmöglich machen.

OODBMS: volle Integration ins Objektmodell

Nachdem die Objektorientierung in den letzten Jahren auf allen Ebenen der Informationsverarbeitung, bei der Programmentwicklung nicht anders als bei Middleware, zum dominierenden Ansatz geworden ist, ist es nur konsequent, daß diese Technologie auch im Bereich der Datenbanken verfolgt wird. 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 ideale Bedingungen vorfinden, weil sie in einem einheitlichen Modell arbeiten können und nicht wie etwa bei den objektrelationalen Systemen Tabellen auf Objekte abbilden müssen, was in letzter Konsequenz doch immer wieder die Unverträglichkeit beider Ansätze reproduziert.

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 eng durch ihre Altlasten begrenzt: Solche haben sie nämlich nicht. Die Nutzung bestehender Daten von bestehenden Systemen ist zwar möglich, relativiert aber wieder den Vorteil der geschlossenen Modellwelt. Wenn für die OODBMS gelegentlich angeführt wird, sie könnten die reale Welt besser wiedergeben als die zweidimensionalen Tabellen, so gilt das zumindest nicht für die reale DV-Welt. OODBMS sind daher eine interessante Technik, die jedoch (noch) ohne praktische Relevanz ist.

Alle Strukturen: die universelle Beschreibungssprache XML

Die objektrelationalen und objektorientierten Datenmodelle bieten vielfältige Datenbeschreibungs- und Manipulationsmöglichkeiten, allerdings um den Preis eines übergroßen Sprachumfangs. Es drängt sich bereits die Vermutung auf, daß es auch mit dem kaum verabschiedeten und noch weniger realisierten SQL 3-Standard nicht gelingen wird, die weiter zunehmende Vielfalt an Daten in angemessener Weise zu beschreiben. Dies dürfte vor allem dann gelten, wenn die Art der Daten nicht mehr (nur) durch eine Große Anzahl von Sätzen (Ausprägungen, Records) vergleichsweise einfacher Bauart (Anzahl und Art der Eigenschaften/Felder) bestimmt wird, sondern durch immer andere, hochstrukturierte Daten, die eventuell nur in vergleichsweise geringer Anzahl zu verwalten und zu verarbeiten sind.

An Stelle einer Sprache wie SQL 3, die in einem Datenschema für jede Tabelle die zugehörige Satzstruktur definiert – mit der Erwartung, daß die Anzahl der Sätze je Tabelle im Vergleich zu der Anzahl an Tabellen sehr groß wird –, 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.

Tatsächlich kann die Selbstbeschreibung so weit gehen, daß auch die Regeln (Grammatik), nach denen der Datensatz beschrieben ist, in kompakter Form zu Beginn des Satzes selbst abgelegt sind. Damit kann jede verarbeitende Instanz zunächst die Bauvorschrift (Grammatik) des Satzes und dann den Datensatz selbst lesen und interpretieren. Dies eröffnet, insbesondere im Zusammenhang mit der Programmiersprache Java, interessante Möglichkeiten für Verteilung und dezentrale Verarbeitung von Daten.

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 Word Wide Web Consortium (W3C unter http://www.w3.org) 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-/Dokumentstrukturen können beliebig geschachtelt sein.
• Jedes Dokument/jeder Datensatz kann eine/seine Bauvorschrift (Grammatik), z.B. für eine Syntaxprüfung, enthalten.

In einem Datenmodell, dessen DDL XML ist, muß es auch eine DML geben. Ein erster Vorschlag für eine XML Query Language (XML-QL) liegt beim W3C vor (http://www.w3.org/TR/Note-XML-QL). Mit einer Sprache dieser Art wird eine sowohl inhalts- als auch strukturbasierte Suche und Aufbereitung von XML-beschriebenen Daten möglich sein.

Der Autor Rainer Krause ist Produkt-Marketing-Manager Datenbanksysteme bei der Software AG