Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

14.04.2000 - 

Appliances: Performance statt Flexibilität

Stehen hierarchische Datenbanken vor einem Comeback?

Das relationale Modell dominiert die Datenbankwelt. Es hat sich bewährt, eignet sich aber nicht für jedes Einsatzgebiet. Die neuen Appliances zum Beispiel benötigen sehr kompakte und schnelle Datenbanken, so dass hierarchische Systeme nach Meinung von Martin Teetz* vor allem in diesem Sektor vor einem Comeback stehen.

Seit Anfang der 80er Jahre sind relationale Modelle in Datenbank-Management-Systemen (DBMS) zu einem Standard in Sachen Datenbanktechnologie geworden, der meist nicht mehr hinterfragt wird. Relationale Datenbanken (RDBMS) sind heute in nahezu allen Einsatzgebieten und auf jeder Plattform anzutreffen: Von Großrechnern, wo vor allem Systeme wie DB2 oder Oracle dominieren, über Unix-Plattformen und NT-Server mit DBMS wie Sybase, Informix, SQL Server, SQL Base und ebenfalls Oracle, bis zu mobilen Notebooks, für die Hersteller wie Sybase oder Centura spezielle schlanke Systeme anbieten. Wo heute Datenbank draufsteht, ist meist die relationale Technologie drin.

OO-Datenbanken sind komplexWenn gelegentlich von Alternativen zum relationalen Datenbankmodell die Rede ist, dann sind in der Regel die objektorientierten oder die objektrelationalen Systeme gemeint. Diese finden zwar stets viel Zustimmung bei Experten, die Anwender realisieren damit jedoch nur in wenigen Ausnahmefällen praktisch relevante Projekte. Ihnen sind diese Systeme, die angeblich die komplexe Realität besser abbilden können als die "flachen" Tabellen des relationalen Modells, oft schlichtweg zu komplex. Ob die ODBMS jemals eine große Verbreitung finden werden, ist daher fraglich.

Alternativen gelten als etwas angestaubtEs gibt jedoch auch noch andere Alternativen zum relationalen Modell, die allerdings gemeinhin als etwas angestaubt gelten: hierarchische und Netzwerkdatenbanken. Dieser Einschätzung liegt jedoch ein Missverständnis zugrunde: Die Datenbanktechnologie ist nicht eine stetige Fortentwicklung vom Schlechteren zum Besseren, sondern die Entwicklung von verschiedenen Modellen für verschiedene Aufgabenstellungen. Die simple Gleichung "relational ist besser als hierarchisch und objektorientiert besser als relational" ist Unsinn. Jede dieser Technologien hat ihren passenden Einsatzbereich, der je nach Verfassung der IT-Landschaft mal größer und mal kleiner ausfällt. In der Anfangszeit der IT gab es überhaupt keine Datenbanken. Die Anwendungssoftware musste die Zugriffslogik auf die Daten noch selbst realisieren. Erst mit der wachsenden Zahl von Anwendungen und den immer größeren Datenmengen war eine Flexibilität erforderlich, die im DBMS durch die Trennung von Anwendung, Zugriffslogik und Datenbestand umgesetzt wurde.

Das hierarchische Datenmodell entstand aus sequenziellen Datensätzen, indem man Wiederholungsgruppen hierarchisch strukturierte. Die voneinander abhängigen Datensätze werden als Einheit behandelt. Der Zugriff auf einzelne Daten muss über den Suchschlüssel der obersten Ebene erfolgen, dabei muss die Anwendungssoftware den Zugriffspfad kennen. Ist diese Voraussetzung erfüllt, lassen sich sehr gute Zugriffsgeschwindigkeiten realisieren.

Das Modell kann vor allem Eins-zu-n-Strukturen gut wiedergeben, Beziehungen zwischen Datensätzen, die in verschiedenen "Ästen" oder Ebenen gespeichert sind, können jedoch nicht abgebildet werden. Damit sind teilweise erhebliche Redundanzen erforderlich, und das System wird relativ unflexibel.

Die Mainframe-Datenbank IMS ist eines der ältesten Datenbanksysteme und wird bei großen Anwendungen, beispielsweise in Banken, noch häufig eingesetzt. Das Modell hat neuerdings wieder große Aktualität erlangt, weil auch dem neuen Web-Standard Extensible Markup Language (XML) ein hierarchisches Konzept zugrunde liegt, so dass sich XML-Dokumente gut in einem hierarchischen Datenmodell abbilden lassen.

Das Netzwerkmodell stellt eine Verfeinerung des hierarchischen Modells dar. Hier lassen sich jedem Datensatz mehrere hierarchisch übergeordnete Datensätze zuweisen (n zu m). Damit erfordern die sich überschneidenden hierarchischen Zugehörigkeiten keine redundante Datenhaltung mehr. Der Zugriff auf Datensätze kann über verschiedene Datensätze erfolgen, der Zugriffspfad muss der Anwendung aber auch hier bekannt sein. Mit dem Netzwerkmodell lassen sich beispielsweise gut Stücklisten abteilen, bei denen ein Artikel unterschiedlichen Artikelgruppen zugeordnet sein kann.

Nach der theoretischen Entwicklung der relationalen Datenbanksysteme zu Beginn der 70er Jahre wurden Anfang der 80er die ersten kommerziell nutzbaren Anwendungen umgesetzt. Anfangs handelte es sich noch um reine Mainframe-Anwendungen, für andere Welten fehlte damals noch die technische Grundlage. Der Vorteil dieser Systeme bestand darin, dass Abfragen relativ bequem mit SQL, also in einem standardisierten Sprachcode, formuliert werden konnten - zuvor musste jede Information durch aufwendige Programmierung abgerufen werden. Mit relationalen DBMS war es erstmals möglich, situationsspezifische Berichte schnell und einfach zu generieren. Unternehmen konnten so schneller auf Änderungen in ihrem Markt reagieren, weil wesentlich detailliertere Auswertungen möglich waren.

Im relationalen Modell werden bekanntlich die Daten in Tabellenstrukturen, die sich aus Spalten (Felder) und Zeilen (Datensätzen) zusammensetzen, gespeichert. Diese Tabellen dürfen keine redundanten Daten enthalten, so dass für jede Art von Informationen separate Tabellen angelegt werden müssen: für Kunden, Rechnungen, Rechnungspositionen etc. Die verschiedenen Tabellen sind untereinander nur über Primary-Key- und Foreign-Key-Felder verbunden. Aus den gemeinsamen Spalten verschiedener Tabellen lassen sich dann spezielle Indextabellen erstellen, über die zur Laufzeit schnell Relationen zwischen den Tabellen gebildet werden können: logische Beziehungen, die den gesamten Komplex unterschiedlicher Tabellen für den Anwender als einheitlichen Datenpool darstellen. Das hört sich nicht nur kompliziert an - es bedarf auch einer aufwendigen technischen Umsetzung. Aus diesem Grund kommt es sehr auf die Implementierung im jeweiligen DBMS an - ein weites Feld für den Wettbewerb der Anbieter von relationalen DBMS.

Das Modell hat Vor- und Nachteile: Zum einen ist es sehr flexibel, da die Zugriffswege nicht von vornherein fest programmiert werden müssen, sondern erst bei der Ausführung auf der Ebene des DBMS berechnet werden. Zum anderen begrenzt aber genau dieses Verfahren die Performance: Je mehr Tabellen beteiligt sind, desto komplexer sind die Berechnungen, die bei der Programmausführung immer wieder aufs Neue zur Verknüpfung der Daten vorgenommen werden müssen. Außerdem werden dabei hohe Ansprüche an Rechenleistung und Speicherkapazität gestellt.

Der kurze Überblick über die beiden technologischen Richtungen zeigt, dass beide ihre Vor- und Nachteile haben. Hierarchische und Netzwerksysteme sind in Sachen Datenzugriff immer noch unerreicht schnell. Nicht zufällig sind nach wie vor die schnellsten Datenbanksysteme nicht relationale, sondern hierarchische DBMS. Demgegenüber sind relationale DBMS unübertroffen in ihrer Flexibilität. Diese Unterschiede sind nicht Folge der mehr oder weniger guten Umsetzung des jeweiligen Konzepts, sondern grundlegender Natur. Mit gleichem Aufwand wird eine hierarchische Datenbank immer schneller auf Daten zugreifen, eine relationale wird Daten immer effizienter speichern können.

Ein wichtiger Faktor für die Dominanz der relationalen DBMS war ohne Zweifel die Entwicklung der Hardware. Ist ein DBMS einmal installiert und vernünftig dimensioniert, so wird es immer eine Zeit dauern, bis Engpässe praktisch sichtbar werden. Zu diesem Zeitpunkt standen zuletzt aber immer schon leistungsfähigere Prozessoren, schnellere und größere Platten bereit, die das Problem wieder auffangen konnten. Die RDBMS schluckten zwar immer mehr Performance, solange diese aber verfügbar ist, ist es effizienter, sie einzusetzen als über einen grundlegenden Wechsel der Technologie nachzudenken - mit kaum absehbaren Folgen.

Dass die Fortschritte der Hardwaretechnik demnächst an eine Grenze stoßen, ist derzeit nicht absehbar. Der Anstoß zur "Re-Vitalisierung" der hierarchischen DBMS - in einigen Bereichen waren sie ohnehin immer putzmunter - kommt daher auch aus einer ganz anderen Richtung. Die IT-Technik hat sich in letzter Zeit verstärkt ganz neue Einsatzgebiete erschlossen. Mikroprozessoren werden nicht nur immer leistungsfähiger, sondern auch immer kleiner und immer billiger. Sie finden sich daher nicht mehr nur in traditionellen Computersystemen, sondern in fast allen Geräten, ob im Haushalt wie Waschmaschinen, in Kleinstcomputern wie Handhelds oder Palmtops, in Telefonen, Spielautomaten, Kopiersystemen, PKWs, Uhren, Hifi-Anlagen und Waagen.

So klein und leistungsfähig die Prozessoren auch geworden sind, in solchen computerfernen Systemumgebungen herrscht absoluter Sparzwang. Der Arbeitsspeicher wird hier, wie in grauer IT-Vorzeit, nach KB gezählt; es gibt keine Festplatten, und es existieren weder ein Systemverantwortlich noch ein Administrator. Dennoch brauchen auch diese Systeme Datenbanken: Wenn sie nicht online sind, müssen sie Daten speichern, bis sie wieder ausgelesen werden können, und sie müssen Informationen für unterschiedliche Varianten der Programmausführung vorhalten. Für solche Aufgaben sind relationale DBMS meist nicht geeignet: Sie sind zu aufwendig und anspruchsvoll für diese Umgebungen. Andererseits wird die Flexibilität des relationalen Modells hier auch gar nicht benötigt, weil die Programmierer die Aufgaben der Geräte eng begrenzen können. Außerdem gibt es keine Anwender, die heute dies und morgen jenes von ihrer Datenbank wissen wollen.

Für derartige Geräte - Appliances oder Intelligent Devices - eignen sich daher meist andere Datenbankmodelle besser. In Netzwerkdatenbanken werden die Beziehungen zwischen den Sätzen verschiedener Tabellen nicht mit Indizes, sondern mit Pointern hergestellt. Diese werden schon beim Datenbankdesign festgelegt, also "fest verdrahtet". Der Zugriff auf Daten, das Navigieren in der Datenbank, kann auf diese Weise sehr schnell und ohne großen Speicherbedarf erfolgen. Der Pointer kennt den Zugriffsweg bereits, und das DBMS muss folglich beim Zugriff nichts berechnen. Zugleich wird Speicherplatz gespart, weil nicht für jede Tabelle separate Indexdateien angelegt werden müssen.

Optimal ist eine Kombination beider Verfahren. Während das Netzwerkmodell beim Lesen der Daten sehr schnell ist, lassen sich Schreibvorgänge und Datenbank-Updates besser mit der relationalen Technik vornehmen. Erste Hybrid-Systeme dieser Art sind bereits auf dem Markt. Sie können Informationen, die in den typischen Eins-zu-n-Beziehungen dargestellt werden, mit festen Pointern erreichen, während andere, die man in sortierter Reihenfolge oder mit wahlfreiem Zugriff benötigt, über Indizes zugänglich gemacht werden.

Verkauf von Appliances steigtVon diesen Appliances werden inzwischen bereits mehr verkauft als von normalen Computern, und die Aufgaben dieser Systeme werden immer anspruchsvoller. In den kommenden Jahren wird es daher auch mehr kompakte Datenbanken auf Appliances geben als Datenbanken, wie wir sie bisher kennen. Sofern nicht noch schnell etwas ganz und gar Neues erfunden wird, dürfte es damit auch mehr hierarchische Datenbanken geben als je zuvor. Dennoch: In den Unternehmensanwendungen werden Systeme, die auf dem relationalen Modell beruhen, weiter dominieren. Relationale DBMS werden auch in Zukunft das Herzstück zahlreicher Unternehmensanwendungen sein - jede Technologie hat ihren Platz.

* Martin Teetz arbeitet als Product Manager bei Centura Software in München.

Abb.1: Relationales Modell

Die Verbindung der Tabellen Kunden, Rechnungen und Posten erfolgt über Indizes, die in speziellen Indexdateien gespeichert sind. Dabei gibt es für jeden Kunden mehrere Rechnungen und bei jeder Rechnung mehrere Posten. Um die zu einem Kunden gehörenden Rechnungen zu finden, durchsucht das DBMS den Index der Rechnungstabelle nach der passenden Kundennummer und den Index der Positionstabelle nach der passenden Rechnungsnummer. Die Tabelle "Kunden" selbst kennt weder Rechnungen noch Positionen. Quelle: Centura

Abb.2: Netzwerkmodell

Für Kunden, Rechnungen und Posten sind im Netzwerkmodell in jeder Datenbanktabelle die Beziehungen zu den anderen Tabellen als Pointer fest eingebaut. Die Datenbank kann von einer Tabelle direkt auf die nächste zugreifen. Eine Technik, mit der sich Eins-zu-n-Strukturen sehr performant umsetzen lassen. Quelle: Centura

Abb.3: Kombiniertes Modell

Hier besteht für die Kundentabelle ein Index, mit dem ein flexibler, wahlfreier Zugriff auf die Datensätze erfolgen kann. Demgegenüber lassen sich die Beziehungen von den Kunden zu den Rechnungen und von diesen zu den Positionen über Pointer festlegen. Quelle: Centura