Datenbanken sind zu einem der wichtigsten Hilfsmittel der Informationsverarbeitung geworden. Bislang beherrschen die Software-Datenbanksysteme die Szene. Seit wenigen Jahren aber sind an ihre Seite die Datenbankrechner getreten, bei denen spezielle Hardware und DB-Software zu einer Einheit verschmelzen.

Seit drei Jahrzehnten werden nach dem Konzept John von Neumanns programmgesteuerte Rechner entwickelt, denen universelle Betriebssysteme den Einsatz in fast allen Anwendungen ermöglichen, Aus ökonomischen Gründen wird dabei Hardware gefertigt, die höchste Effizienz nur bei solchen Applikationen liefert, die die verschiedenen Funktionen des Rechnersystems in einem gewissen Sinne gleichmäßig auslasten.

Diese Entwicklungsarbeit führt, vereinfacht ausgedrückt, zu großen logischen Einheiten mit wenigen Anschlußklemmen, die für spezielle Belastungen keineswegs dem Anforderungsprofil entsprechen.

Hinzu kommt die Struktur der gängigen Betriebssysteme, bei deren Entwicklung ebenfalls das Streben nach Universalität Pate stand. Vorgänge, die in dedizierten Systemen sich ständig wiederholen und den größten Teil der CPU-Zeit beanspruchen, müssen dennoch immer wieder aufwendige Entscheidungsbäume durchlaufen, deren übrige Alternativen (und damit deren sonstiges implementiertes Leistungsspektrum) nie zum Zuge kommen.

Dies alles trifft insbesondere für den Bereich der Datenbanken zu. Um einen guten "Durchsatz" zu erreichen, mußte über Jahre hinweg auf Mainframes ausgewichen werden. Es bildete sich gar die weitverbreitete Meinung, Datenbanksysteme seien nur etwas für Großrechner.

In den letzten Jahren sind eine Reihe von Datenbanksystemen auf den Markt gekommen, die mit Maschinen der kleinsten Klasse, den Mikros, auskommen. Sie können aber die hier vorgetragene Ansicht nur bekräftigen.

Was den kleinen Universellen an Hardware fehlt, müssen sie sich an "Zeitware" nehmen: Eine mäßig komplexe Abfrage in einem System von vielleicht 10 000 Sätzen verschafft dem Benutzer immer eine ausgiebige Kaffepause.

Ein Weg zu effektiveren Datenbanksystemen ist der Weg weg vom Universalrechner und hin zum dedizierten System. Anlagen, die in diesem Sinne auf das Management von Datenbeständen spezialisiert sind, werden heute durchweg als "Datenbankrechner" oder "Datenbankmaschinen" (database machines) bezeichnet. Sie sind zum einen Gegenstand von Forschung und Entwicklung (in Deutschland zum Beispiel ein DFG-geförderter Forschungsbereich an der TU Braunschweig), zum anderen aber durchaus auf dem Markt eingeführt.

Eine Reihe grundlegender Strukturen und Konzepte sind allen Datenbankrechnern gemeinsam. Eine standardisierte Performance-Messung für Datenbanken existiert nicht; somit ist der Vergleich zwischen Software-Datenbanken und Datenbankrechnern etwas schwierig. Bei konkreten Applikationen auf gleichem Datenmaterial konnten die dedizierten Systeme aber bislang ihre Vorzüge beweisen.

Entweder läuft auf einem Rechnertyp eine Software-Datenbank oder sie läuft nicht. Natürlich kann sie bis zu einem gewissen Grad an die Hardware angepaßt werden; dies gilt zum Beispiel im allgemeinen für Rechner der gleichen Familie.

Es gibt allerdings kein entsprechendes Softwaresystem, das sich auf Rechnern verschiedener Größenordnung "wohl fühlt": IMS auf dem PC ist genauso absurd wie dBase II: auf einem Mainframe.

Im Gegensatz dazu verträgt sich ein Datenbankrechner mit mehreren Host-Computern: Er ließe sich beispielsweise mit IBM Personal Computern und mit Rechnern der VAX-Familie koppeln. Mehr noch: Wie groß der Datenbankrechner selbst dimensioniert wird und wie groß die zu verwaltende Datenmenge ist, hängt nicht von der Größe des Host Computers ab. Er kann normalerweise - unabhängig vom angeschlossenen Host - Datenmengen bis in den zweistelligen Gigabyte-Bereich (1 Gigabyte = 1000 Megabyte) verwalten.

Der Einsatz von Mikros würde sich beispielsweise anbieten, Auskunftssystem aufgebaut soll, mit dem zwar große Datenmengen verwaltet und nach beliebigen Kriterien durchsucht und abgefragt werden, aber keine schwierigen Algorithmen abzuwickeln sind. So gibt es Anwendungen, bei denen Datenbanken mit Millionen von Sätzen zu verwalten sind, wobei als Hosts mehrere Mikrocomputer eingesetzt wurden.

Einen Minicomputer wird man als Host an einen Datenbankrechner dann koppeln, wenn man auf die Leistungsfähigkeit eines Betriebssystems nicht verzichten kann, andererseits aber nicht die Kosten und den Overhead einer Mainframe-Lösung haben mochte.

Relationale Modelle fordern ihren Tribut

Die Funktionalität vieler Lösungen wird heute durch das Relationenmodell diktiert, sowohl bei Software-Datenbanken als auch bei DB-Maschinen. Die Erklärung ist einfach: Software-Datenbanksysteme belasten den Rechner, auf dem sie laufen ganz erheblich.

Dies gilt insbesondere für relationale Systeme, deren Mächtigkeit hinsichtlich Funktionalität unweigerlich ihren Tribut fordert. So wird beispielsweise eine VAX 11/780 durch ein relationales Software-Datenbanksystem so stark belastet, daß für die Anwendungsprogramme kaum noch Ressourcen bleiben.

Anders verhält es sich bei Einsatz eines Datenbankrechners: Er belastet den Host nicht zusätzlich, sondern entlastet ihn dadurch, daß alle Datenbankoperationen vom Host abgenommen und in ihm abgewickelt werden.

Ein Beispiel anhand einer Mitarbeiterdatei soll das verdeutlichen:

Hole mir die Daten derjenigen Mitarbeiter, sortiert nach Abteilung und fallenden Gehältern, deren Gehalt größer ist als das Doppelte des Durchschnitts der Gehälter der Jeweiligen Abteilung

Mit Hilfe der Sprachmittel einer Query-Language wird dieser

Wunsch so formuliert:

retrieve (mitarbeiter.all)

order by mitarbeiter.abt,

mitarbeiter gehalt:descending

where mitarbeiter.gehalt greater then

2 * avg(mitarbeiter.gehalt by mitarbeiter.abt)go

Bei diesem Beispiel sind Datensätze zu selektieren und nach Abteilungen zu gruppieren, es müssen Gehälter addiert und gezählt werden, um danach Durchschnittswerte zu ermitteln, es sind Werte zu vergleichen, Sätze zu extrahieren und zu sortieren.

Alles das erledigt ein relationales Datenbanksystem für den Benutzer, ohne daß er sich zu überlegen braucht, wie dies vonstatten geht. Es liegt auf der Hand, daß die dafür abzuwickelnden Schritte bei einem Software-Datenbanksystem komplett vom Anwendungsrechner zu erbringen sind und diesen daher enorm belasten.

Auch ein Datenbankrechner muß verständlicherweise alle Mitarbeitersätze "anfassen" und verarbeiten. Aber er gibt dem Host-Computer eben nur die fertigen Ergebnissätze zurück. Außerdem ist er mit Spezialprozessoren bestückt, die speziell für schnelles Datenmanagement entwickelt wurden.

Ein anderes Beispiel macht dies noch deutlicher: Will man alle Gehälter der DV-Abteilung um drei Prozent erhöhen, so geschieht dies komplett im Datenbankrechner, ohne daß der Host auch nur einen Datensatz "anfassen" müßte. Eine stärkere Entlastung der Anwendungsmaschine ist nicht denkbar: Der Rechner setzt ein Datenbankkommando ab, hat aber selbst mit dessen Durchführung nichts zu tun.

Hier wird das Prinzip vom Job-Sharing in Verbindung mit dem Prinzip der Spezialisierung verwirklicht. Daraus folgt, daß der Host-Computer für das Datenbank-Management nur einen Bruchteil des Speichers dessen braucht, was ein Software-Datenbanksystem konsumiert.

Datenbankrechner sind ein junger Produktzweig der Informationstechnologie; sie verwenden daher durchweg das Relationenmodell. Auf die hohen Anforderungen, die das relationale Modell an die Performance der Rechner stellt, sind die spezialisierten Maschinen zugeschnitten. Sie sind daher geeignete Hilfsmittel, wenn nicht nur große Datenmengen verwaltet werden müssen, sondern auch hohe Ansprüche an den Durchsatz gestellt sind.

Die hohe Performance wird hauptsächlich dadurch erzielt, daß ein Datenbankrechner aus einer speziell für das Datenmanagement konstruierten und daraufhin optimierten Hardware und einer ebenso speziell für hohe Durchsatzraten konzipierten Software besteht. Mehrere parallel und asynchron arbeitende Prozessoren teilen sich im Normalfall die Arbeit. Die Grundgeschwindigkeit ist so hoch, daß sie allen Erfordernissen gerecht wird.

Es ist naturgemäß schwierig, dies im einzelnen zu belegen. Aber es existieren eine Reihe von Faktoren, die sich oft nicht leicht standardisieren lassen. Man unterscheidet

- konfigurationsabhängige Faktoren (Hauptspeicherplatz, Anzahl der Plattencontroller, spezielle Hardware, verschiedene Interfaces zur Ein-/Ausgabe-Peripherie),

- datenabhängige Faktoren (Zahl der Relationen, der Attribute, der Tupel per Relation) und

- applikationsspezifische Faktoren (die Verteilung der Daten auf den Platten, Indizes, die Typen der Abfragen und Updates).

Gründliche Vergleiche müßten sämtliche der erwähnten Parameter über eine gewisse Skala variieren.

Dietmar Bothe ist Vertriebsleiter IDM der GEI-Gesellschaft für elektronische Informationsverarbeitung mbH, Aachen.