Datenbankstrukturen sollten möglichst die Unternehmensstrukturen abbilden. Nach dem hierarchischen und dem Netzmodell konnte sich vor allem die relationale Datenbank durchsetzen. Obwohl dieses Modell schon 20 Jahre alt ist, findet es noch viele Anhänger. René Purwin stellt die Vor- und Nachteile von hierarchischen, relationalen Datenbanken sowie des NF²- und Entity-Relationship-Modells dar.
Anwender haben ein Interesse an einem Datenbank-Management-System (DBMS) mit umfassender Funktionalität und möglichst flexiblem Zugriff. Aber im Geschäftsalltag steht die Forderung nach Datensicherheit im Mittelpunkt des Anforderungsprofils. Erwartet werden Sicherheitsmechanismen zur Verhinderung nicht autorisierter Zugriffe ebenso wie zuverlässige Recovery-Funktionen die das Unternehmen im Falle eines technischen Desasters vor Folgeschäden bewahren und die Ausfallzeiten minimieren.
Deshalb haben die Anwender eine begründete Scheu davor, bewährte sichere Datenbankmodelle sofort gegen die neuesten Entwicklungen einzutauschen. Nur vor diesem Hintergrund ist zu verstehen, daß seit einiger Zeit von theoretischer Seite heftig auf die Nachteile der relationalen Datenbanktechnologie hingewiesen wird, deren Konzept über 20 Jahre alt ist, während in der real, existierenden DV-Welt fleißig diese DBMS installiert werden.
Nur ein Modell in der Entwicklungskette
Nun hat das relationale Datenbankmodell natürlich nicht nur Nachteile, sondern auch Vorzüge, die ihm zu großer Anerkennung verholfen haben. Es stellt für viele Anwendungen zunächst eine ausreichende Funktionalität zur Verfügung, während es in anderen Fällen gar nicht oder nur unter Qualen verwendet werden kann. Dabei ist es nur ein Modell in einer Entwicklungskette, die sich seit dem Bestehen der kommerziellen Datenverarbeitung fortsetzt und die sicher künftig erweiterte und modifizierte Datenbankmodelle hervorbringen wird. Solche Entwicklungen lassen sich bereits jetzt absehen, etwa im Hinblick auf die Ojektorientierung, und teilweise auch schon in bestehenden DBMS realisieren.
Zunächst entstand das hierarchische Modell, in dem die Objekte des Geschäftslebens in jeweils eigene Dateien aufgenommen werden. Sollte also ein Lieferant zwei Adressen haben, etwa eine Rechnungs- und eine Lieferanschrift, so werden diese beiden Anschriften in unterschiedlichen Dateien abgelegt. Schon bei der Anlage einer hierarchischen Datenbank wird durch die Dateistruktur der Zugriffspfad für die später entstehenden Anwendungen vorgegeben. So erfordert die Abfrage, an welchem Termin ein Kunde einen bestimmten Artikel bekommen hat, das sequentielle Durchsuchen der Kundendatei, der Bestellungen und schließlich der Artikelstammliste.
Störend ist dabei weniger eine zu vermutende Langwierigkeit des Suchprozesses - hierarchische Datenbanksysteme sind häufig sogar besonders schnell im Zugriff -, sondern vielmehr die durch die Dateistruktur vordefinierten Zugriffspfade. Dadurch erweist sich dieses Modell als unflexibel, Ad-hoc-Abfragen sind praktisch nicht möglich. Damit läßt sich die Dynamik eines sich stets verändernden Unternehmens nur unzureichend nachbilden. Sollte die Forderung nach anderen bei der Anlage der Datenbank nicht berücksichtigten Zugriffen aufkommen, sind eine umfangreiche Reorganisation des Datenbestandes, die Anlage neuer Dateien etc. die Folge.
Die strenge Hierarchie hat auch Auswirkung auf die Betriebssicherheit eines solchen Datenbanksystems. So litten frühere Versionen an ungenügenden Recovery-Mechanismen. Die Zerstörung einer Datei bedeutete im schlimmsten Falle das Zerbrechen der Beziehungskette zwischen den Dateien und verhinderte ein erfolgreiches Recovery. Eine Erweiterung der hierarchischen DB-Modells ist das Netzwerkmodell. Hier können sich die Beziehungen zwischen den einzelnen Dateien wie die Äste eines Baumdiagrammes verzweigen.
Immerhin ist das Netzwerkmodell schon deutlich funktionaler als das starre hierarchische Modell, wird aber den heutigen Anforderungen an eine effiziente DV nicht mehr gerecht.
Auch hier sind die möglichen Beziehungen determiniert, und beliebige Querverbindungen lassen sich nur durch die Anlage von abweichend strukturierten Dateien mit den gleichen Daten herstellen. Solche redundanten, aber abweichend strukturierten Informationen können nur schwer mit vernünftigem Aufwand gepflegt werden.
Das relationale Modell wurde 1969 von Edgar Codd vorgestellt und hat seitdem an Bedeutung gewonnen. Codd entwickelte ein ausführliches mathematisches Modell. Während im Netzwerk- und im hierarchischen Modell die Zuordnung der Dateien vorbestimmt war, basiert das relationale Modell auf einer strikten Trennung der Daten von den Zugriffsmöglichkeiten. Die Relationen lassen sich in der Abfrage definieren, damit sind praktisch beliebige Verknüpfungen zwischen den Daten möglich. Die Objekte werden in atomisierter Form, also auf ihre Kernbausteine reduziert, abgelegt.
Normalisierung der Daten nötig
Diese können wie das zweidimensionale Arbeitsblatt einer Tabellenkalkulation in Spalten und Zeilen gegliedert werden. Das relationale Modell erfordert eine Normalisierung der Daten, am besten auf die dritte Normale Form, mindestens aber auf die erste Normale. Sie verlangt, daß in allen Spalten nur atomisierte Werte stehen, während die dritte Normale postuliert, daß alle Attribute (nicht die Schlüsselattribute) nicht-transitiv, vom Primärschlüssel abhängen.
Es zeigt sich, daß eine Erweiterung dieses klassischen relationalen Modells nötig ist. Mit ihm gehen nämlich einige Beschränkungen einher, die nicht nur aus dem Modell selbst, sondern auch aus der Standardabfragesprache SQL resultieren. Beispielsweise lassen sich hier keine rekursiven Operationen durchführen, die dann sinnvoll sind, wenn man gleiche Operationen auf eine große Zahl von Daten anwendet. Auch die Normalisierung birgt Nachteile, denn die Aufteilung der Objekte in kleinste Einheiten ist sicher kein Abbild der realen Welt und bringt neben anderem auch Performance-Probleme mit sich.
Eine schöne Analogie hat Robin Bloor von der britischen Unternehmensberatung Butler Bloor Ltd. gebracht: Die Normalisierung der Daten sei ungefähr so sinnvoll, wie ein Auto zu zerlegen, um es in Einzelteilen in die Garage zu bringen und vor dem Fahren wieder zusammenzuschrauben. Nun muß man nicht unbedingt folgern, daß deshalb die ganze relationale Theorie falsch ist und möglichst schnell über Bord geworfen werden sollte. Vielmehr gilt es, für jeden Anwender das passende, also das sein Umfeld modellierende Datenmodell zu finden, und das kann im konkreten Falle auch das relationale sein.
In Umgebungen, in denen unstrukturierte Daten verwaltet und zugriffsbereit gehalten wer den müssen, bietet sich das relationale Modell nicht an. Das gilt für Textinformationen, also die bei weitem häufigste Informationsform in Unternehmen, deren Normalisierung zwar möglich, aber nicht sinnvoll ist, weil sie nicht mehr bearbeitet werden können. Ausnahme hiervon bilden Forschungsprojekte etwa der Linguistik, wo die Atomisierung das angestrebte Ziel ist.
Bei der Normalisierung gehen die Kontextbeziehungen verloren und werden später durch willkürlich definierte Abfragebeziehungen ersetzt, die eine sinnvolle Rekonstruktion des Informationsgehalts kaum erlauben. Gerade bei der Textrecherche macht man ja von den eigentlichen Suchelementen, etwa den Primärschlüsseln, so gut wie keinen Gebrauch, sondern konzentriert sich vor allem auf eine Volltextrecherche. Hier ist es hilfreich, wenn nicht nur nach exakt vorgegebenen Wörtern, Satzteilen und Sätzen gesucht werden kann, sondern wenn sich Synonyme oder gar lautverwandte Wörter berücksichtigen lassen.
Die relationale Datenbank eignet sich schon aufgrund ihrer Konzeption nicht für solche Datenbankanwendungen. Ähnliches gilt für andere komplexe Datentypen, die sich nicht normalisieren lassen, ohne daß wesentlicher Informationsgehalt verlorengeht, oder deren Bearbeitung komplexe Prozeduren erfordert, also auch für geografische Daten etc.
Ein Superset, also eine allgemeinere Form des relationalen Datenmodells, ist das NF²-Modell, das eine Reihe wesentlicher Fortschritte aufweist, aber gleichzeitig das relationale Modell beinhaltet. Hier müssen die Objekte nicht mehr auf die erste Normale atomisiert werden, so daß wesentliche Beziehungen erhalten bleiben.
In der Praxis werden meist keine reinen Vertreter der jeweiligen Datenbankgattung verwendet, sondern mehr oder minder erweiterte Modelle realisiert. So gibt es auch auf dem NF² -Modell basierende DBMS, die eine erweiterte Funktionalität aufweisen.
Als besonders geeignet zur Modellierung komplexen Strukturen hat sich das Entity-Relationship-Modell (ERM) herausgestellt. Es wurde 1976 von Peter Chen vorgestellt und erlaubt auch rekursive Operationen etc. Im ERM unterscheidet man die Entities, die einzelne Objekte repräsentieren, von den Attributen, die als Eigenschaften der Entities definiert sind, und den Beziehungen zwischen den Entities.
Werden letztere kategorisiert, nennt man die entstehenden Gruppen Entity-Typen. Die Beziehungen zwischen Entities und/oder Entity-Typen können von praktisch beliebiger Komplexität sein. Außerdem sind die Beziehungen durch die Vererbung der Schlüsselattribute der zueinander in Beziehung stehenden Entities eindeutig gekennzeichnet.
Das ERM ermöglicht die Integration aller Daten und ihrer Relationen in einem konsistenten Modell. Natürlich ließen sich solche Modelle auch in einem rein relationalen Umfeld darstellen. In diesem Fall müßten jedoch komplexe Strukturen auf mehrere Tabellen aufgeteilt werden, die wiederum untereinander verbunden würden. Auf diese Weise entstände ein unvollständiges Datenmodell, das die Arbeit ineffizient macht.
Bei einem Vergleich zwischen ERM und relationalen Modell, drängt sich der Vergleich zwischen einem sauber gebundenen Buch und einer Lose-Blatt-Sammlung auf: Bei kleinen Datenbeständen, die streng strukturiert sind, wird auch die Anzahl fliegender Blätter zum Lesen ausreichen.
Bei größeren Datenbeständen und kompliziertem Inhalt geht im Blätterwald leicht der Überblick verloren, während man im Buch ständig eine Modellübersicht, nämlich das Inhaltsverzeichnis, zu Rate ziehen kann und keine Blätter durcheinandergeraten.
Das relationale Modell zerlegt die realen Objekte in ihre elementaren Bestandteile und legt diese in normalisierten Tabellen ab. Bei komplexen Objekten läuft das auf eine bestenfalls plumpe Repräsentation der Realität hinaus, im schlimmsten Falle hat das Modell gar nichts mehr mit der Wirklichkeit gemein. Das Entity-Relationship-Modell geht weit darüber hinaus und nähert sich der Komplexität der Realität. Die logische Fortentwicklung dürfte die objektorientierte Datenmodellierung sein. Die Objekte sind vollständige Abbildungen der Realität, also integre Einheiten, deren Eigenschaften und mögliche Beziehungen in sich definiert sind. Damit stellen sie eine vollständige Abbildung der Realität dar und sind auch autonom.
Objekte lassen sich nicht nur einfach handhaben, was vor allem dem Anwender zugute kommt, der sich nicht mehr mit dem Problem herumschlagen muß, wie er etwa die Beziehungen zwischen den Objekten definieren und abbilden soll, sondern sie sind auch universell verwendbar. Einmal definierte Objekte lassen sich immer wieder einsetzen.
Schon heute gibt es erste Ansätze, die Objektorientierung in DBMS einzubauen und somit einen nahtlosen Übergang in die Datenverarbeitung der kommenden Generation zu schaffen. Das größte Problem für den Anwender stellt sich nämlich in dem Moment, wo er an die Grenzen der Leistungsfähigkeit oder des Konzepts seines hierarchischen, Netzwerk-basierten oder relationalen DBMS stößt und sich Umstieg auf ein anderes System überlegen muß.
Die wertvollen Daten dürfen natürlich nicht verlorengehen und müssen in ein neues Datenmodell integrierbar sein. Da ist unzweifelhaft im Vorteil, wer schon heute auf ein System setzt, das möglichst viele Modelle integriert und auch für die Implementation der künftigen objektorientierten Modelle und Arbeitsweisen offen ist.
* René Purwin ist Referent DV-Fachpresse bei der Software AG in Darmstadt.