*Dieter Jenz ist Geschäftsführer der Unternehmensberatung Jenz & Partner GmbH in Bad Homburg.

Ein detaillierter Leistungsvergleich der drei Datenbanksysteme unter Einbeziehung von DB2 kann ab September 1988 von der Unternehmensberatung Jenz & Partner in Homburg bezogen werden.

Die Wahl des richtigen Datenbanksystems ist vom betriebswirtschaftlichen Standpunkt aus oft schwerwiegender als die Entscheidung für ein Betriebssystem. Dieter Jenz* vergleicht drei der weitverbreitetsten relationalen Datenbank-Management-Systeme miteinander. Die referentielle Integrität fand er nirgends verwirklicht.

Seit 1982, als IBM mit SQL/DS das erste kommerzielle relationale Datenbanksystem für Mainframes unter (DOS/)VSE und VM(/CMS) freigab, wurde der Markt der Mikro-, Mini- und Mainframe-Systeme mit einer Fülle von Datenbanksystemen überschwemmt, die alle das Attribut "relational" für sich beanspruchten. Anwender, die sich für ein Datenbanksystem entscheiden wollen, müssen bei der Auswahl großen Aufwand treiben, um die verschiedenen Lösungen miteinander zu vergleichen und zu einer gesicherten Entscheidung zu gelangen - oder aber den Hochglanzprospekten und den Argumenten des geschicktesten Verkäufers Glauben schenken.

Die Entscheidung, welches Datenbanksystem eingesetzt werden soll, wiegt unter betriebswirtschaftlichen Gesichtspunkten schwerer als die Entscheidung für ein Betriebssystem. Sie zählt zu den wichtigsten Entscheidungen.

Jede Anwendung ist im wesentlichen an drei Eckpfeiler gebunden: an die Hardware, die Software (System- und Anwendungssoftware) sowie an die Technik der Softwareentwicklung (Methoden und Werkzeuge). In der Vergangenheit wurden bereits Anstrengungen unternommen, um eine herstellerunabhängige, einheitliche Betriebssystemschnittstelle zu schaffen (Unix).

Eine Standardisierung auf Betriebssystemebene allein, genügt jedoch bei weitem nicht den Anforderungen. So ist zum Beispiel die Schnittstelle zur Datenverwaltung mindestens ebenso wichtig. Abgesehen von konventionellen File-Systemen wurden die Standards und Quasi-Standards in diesem Bereich durch Codasyl (Netzwerk-Datenbanksysteme) beziehungsweise das relationale Modell von Codd sowie die Abfragesprache SQL gesetzt.

Unterstützt ein Softwarehersteller mit einem auf akzeptierten Standards entwickelten Produkt mehrere Betriebssysteme, bedeutet dies für den Anwender zunächst: Die Hardware und auch das Betriebssystem können weitgehend in den Hintergrund treten, wenn die Software portierbar ist. Der kritische Punkt liegt jedoch im Bereich der Softwareentwicklung. Dort setzt aufgrund weitgehend fehlender Standards die Herstellerbindung ein.

Codds Regeln immer noch Option

Konzentriert man sich auf die relationalen Datenbank-Implementierungen, so stehen die Begriffe "relationales Modell" und "SQL" im Mittelpunkt: Maßstab für den Grad der Übereinstimmung mit dem relationalen Modell sind die von Codd Anfang der siebziger Jahre definierten und weitgehend akzeptierten "Zwölf Regeln zur Beurteilung der Relationalität eines Datenbankprodukts". Derzeit ist jedoch kein Datenbankprodukt verfügbar, das alle Kriterien vollständig erfüllt.

Bei der Entwicklung relationaler Datenbankprodukte im IBM-Labor in San Jose entstand SQL als "relationale Sprache". Der 1986 vom ANSI-Komitee verabschiedete SQL-Standard entspricht weitgehend der SQL-Implementierung der IBM, weist jedoch einige signifikante Unterschiede auf.

Das Vorhandensein eines relationalen Modells und einer relationalen Sprache bedeuten noch nicht, daß alle Implementierungen relationaler Systeme vergleichbar sind: Zum einen werden im SQL-Standard offiziell zwei Implementierungsstufen unterschieden, nämlich Level 1 und Level 2, wobei ein Level-1-Programm nicht unbedingt korrekt in einer Level-2-Umgebung ablaufen kann.

Zum anderen sind manche SQL-Implementierungen vor der Standardisierung entstanden und unterstützen aus Kompatibilitätsgründen Konstrukte, die nicht mehr dem Standard entsprechen. Darüber hinaus wurde eine Reihe zusätzlicher sinnvoller SQL-Konstrukte implementiert, die im Standard nicht enthalten sind (zum Beipiel "Alter"-Kommandos zur Änderung von Tabellendefinitionen).

Es gibt wohl kaum einen Anwender, der nicht eine durchgängige Oberfläche für die Datenhaltung unabhängig vom eingesetzten Betriebs- und Datenbanksystem - anstrebt. In einer dezentralen Umgebung würde ihn dies in der Tat in die Lage versetzen, Anwendungen weitgehend portabel zu entwickeln; und damit wäre er vom Datenbankhersteller unabhängig. In einem Unternehmen könnten Datenbanksysteme des gleichen oder verschiedener Hersteller auf unterschiedlichen Rechnern unter verschiedenen Betriebssystemen eingesetzt werden. Dabei, so die Wunschvorstellung, sollen alle Datenbankabfragen und Manipulationen mit identischen Konstrukten abgehandelt werden.

Identische Funktionen vom PC bis zum Mainframe

Derzeit existieren einige Datenbank-Implementierungen, die dem Anwender diese Durchgängigkeit versprechen, also in nahezu funktionsidentischen Versionen vom PC bis zum Supermini und Mainframe vorhanden sind. Teilweise verfügen sie auch über Gateways zu anderen Datenbankprodukten (meist DB2).

Zu den Datenbanksystemen, die diese Voraussetzungen im großen und ganzen erfüllen, zählen Informix (Mainframe-Implementierung nur in Teilbereichen), Ingres und Oracle. Die genannten Datenbanksysteme verfügen zudem über eine durchgängige Entwicklungsumgebung. Der Kaufpreis reicht von knapp DM 3000 in der PC-Version bis hinein in den Bereich sechsstelliger Beträge.

Innerhalb dieser Rahmenbedingungen ist für viele Entscheider wichtig, in welchem Umfang Kompatibilität zu DB2 besteht, um portable Anwendungen entwickeln zu können. Die IBM-Produkte DB2 und SQL/DS stehen derzeit nur auf Mainframes zur Verfügung, und der DB2-Subset für OS/2 wird noch eine Weile auf sich warten lassen.

Unterschiedliche Ansätze und Realisierungen

Informix wurde für den Minicomputer-Bereich entwickelt und nimmt für sich in Anspruch, Marktführer in Unix-Umgebungen zu sein. Die Wurzeln von Ingres finden sich im Hochschulbereich. Eine kommerzielle Implementierung erfolgte 1981 unter VAX/VMS. Relational Technology sieht Ingres als marktführendes relationales DBMS-Produkt im VAX/ VMS-Markt. Oracle ist ebenfalls seit mehreren Jahren auf dem Markt und verfügt - so die Werbebotschaft - über volle Kompatibilität zu DB2 beziehungsweise SQL/DS.

Die Produkte - mit Ausnahme von Informix - decken in verschiedenen Versionen, die in ihren Funktionen einander ähnlich oder identisch sind, den Leistungsbereich vom Personal Computer bis hin zum Mainframe unter MVS ab. Informix bietet im MVS-Bereich allerdings nur Zusatzprodukte zu DB2 an.

In ihrer physischen Implementierung unterscheiden sich die drei Produkte jedoch beträchtlich. Oracle folgt einem hierarchischen Speicherkonzept: Eine Datenbank besteht hier aus einer oder mehreren Partitions; das sind logische Einheiten, die aus mindestens einer physischen Datei bestehen. Eine Partition kann eine variable Anzahl von Tabellen enthalten, eine Tabelle residiert aber nur innerhalb einer Partition.

Indices werden innerhalb der Partition gespeichert, in der sich auch die Tabelle befindet. Durch die Definition von "Spaces" kann der Datenbank-Administrator wirkungsvoll Einfluß auf die Speicherplatzverwaltung und damit auf die Performance nehmen. Gegenüber den anderen Datenbanksystemen gibt Oracle dem Datenbank-Administrator die Möglichkeit, Tabellen zu "clustern": Relationen, die in einer sachlogischen Beziehung zueinander stehen, werden zum schnelleren Zugriff physisch benachbart gespeichert.

Ingres und Informix legen für jede Datenbank ein eigenes Directory an. Unterhalb des Directories wird für jede Relation eine eigene Datei erzeugt. Im Gegensatz zu den beiden anderen Datenbanksystemen, die ausschließlich "B-tree" kennen, unterstützt Ingres eine Reihe weiterer Speicherstrukturen (Hash, ISAM, HEAP und HEAPsort).

Für jede dieser Speicherstrukturen kann Datenkomprimierung spezifiziert werden. Abhängig von der Anwendungsstruktur wird so die Performance verbessert. Der Anwender kann mit einem vorhandenen Dienstprogramm jederzeit die Organisationsform einer Relation ändern. Die PC-Version unterstüzt zwar nicht alle Organisationsformen, konvertiert jedoch die in dieser Version nicht unterstützten - transparent für den Anwender - in die für die PC-Umgebung geeignetste Organisationsform.

Locking-Mechanismen ohne Beanstandung

Alle drei Datenbanksysteme verfügen Über ausreichende Locking-Mechanismen, sowohl auf der Tabellen als auch der Tabellenzeilenebene. Zumindest in der Multiuser-Version kann jeweils angegeben werden, ob - falls ein Lock temporär nicht verfügbar ist - gewartet werden soll oder nicht. Ingres bietet gegenüber den anderen Implementierungen zusätzliche Optionen für das Tuning im konkurrierenden Multiuser-Betrieb. Die Datenbanksysteme verfügen auch über Deadlock-Erkennung. Diese kann bei Ingres optional ausgeschaltet werden.

Ansi-SQL bietet auf Tabellenebene vier unterschiedliche Privilegien: "Select", "Insert", "Update" und "Delete". Sollen für eine Tabelle alle Privilegien gewährt werden, wird "all" angegeben. Die untersuchten RDBMS-Implementierungen haben hier verschiedenartige Ansätze.

DB2, Oracle und Informix unterstützen neben diesen Basis-Privilegien auch noch "alter" (zum Hinzufügen, Löschen beziehungsweise Ändern von Tabellenspalten-Definitionen) und "index" (zur Erstellung von Indices). Ingres unterstützt exakt die Privilegien des SQL-Standards, allerdings mit erweitertem Funktionsumfang. Das Datenbanksystem von Relational Technology bietet die Möglichkeit der Spezifikation von Tabellenspalten bei "select"; diese Funktion wird übrigens auch von Informix unterstützt.

Informix und Oracle kennen neben tabellenbezogenen Privilegien auch datenbankadministrative beziehungsweise benutzerklassenbezogene Privilegien ("Connect", "Resource" und "Datenbank-Administrator"). Damit ist es zum Beispiel möglich, die Benutzung von Datenbank-Utilities auf bestimmte Anwender einzuschränken.

Ingres gibt dem Anwender im Vergleich zu den beiden anderen Datenbanksystemen zusätzlich die Möglichkeit, Integritätsregeln explizit bezogen auf eine Relation zu definieren Jedoch nicht in der PC-Version). Bei DB2 und Informix ist dies ebenfalls möglich; zunächst muß allerdings eine View erzeugt werden.

Informix, Ingres und Oracle unterstützen die transaktionsorientierte Verarbeitung. Alle in der Datenbank durchgeführten Veränderungen können - abhängig von Parameterangaben - im Transaktionsjournal aufgezeichnet werden (Before- und After-Image-Journaling).

Als Besonderheit bietet Ingres sogenannte Savepoints. Diese ermöglichen in Verbindung mit dem "Abort"-Kommando das Zurücksetzen einer Transaktion bis zu dem angegebenen Savepoint, ohne die Transaktion zu beenden. Allerdings zeigen sich in den PC-Versionen Unterschiede: Oracle unterstützt nur Before-Image-, aber kein After-Image-Journaling. Informix bietet beides durchgängig, während Ingres in der PC-Version überhaupt kein Journaling erlaubt.

Keine Übereinstimmung mit dem SQL-Standard

Alle untersuchten Produkte unterstützen den SQL-Sprachstandard, allerdings in unterschiedlicher Ausprägung. Sie folgen insofern dem "DB2-Standard", als sie alle Datenmanipulations-Operationen (wie "create table" und "create views") zulassen. Ingres liegt derzeit in der Implementierung des SQL-Sprachumfangs gegenüber den anderen Systemen noch etwas zurück.

Die kleinen Unterschiede zeigen sich bereits in der Unterstützung verschiedener Datentypen. Bei keinem der Datenbanksysteme ist eine völlige Übereinstimmung mit dem Standard festzustellen. Daß bestimmte Erweiterungen durchaus sinnvoll sind, ist andererseits keine Frage. Schließlich ist auch zu erwarten, daß der ANSI-Standard in dem einen oder anderen Punkt erweitert wird (zum Beispiel um die Unterstützung des Datentyps "date"). Oracle bietet zusätzlich die Definition bestimmter Datentypen in DB2-Notation.

Informix und Oracle unterstützen den "outer join", eine sehr sinnvolle, wenn auch nicht standardisierte Erweiterung. In der Praxis wird diese Konstruktion häufig benötigt, und zwar immer dann, wenn eine Tabellenzeile die "Join"-Bedingung nicht erfüllt, aber trotzdem vom Datenbanksystem übergeben werden soll.

Jedes der drei Datenbanksysteme unterstützt die SQL-Einbettung in konventionelle Programmiersprachen. Ingres und Oracle bilden die SQLCA von DB2 exakt nach, wenn auch nicht alle Felder sinngemäß gleich belegt sind. Ingres bietet darüber hinaus zusätzliche Möglichkeiten, beispielsweise, um die Optimizer-Ausführung unter bestimmten Bedingungen zu unterdrücken.

Außerdem erlaubt Ingres dem Anwender, mit einer den SQL-Aufrufen ähnlichen Syntax zu codieren; dadurch bietet das DBMS ein Maß an Portabilität, das mit manchen konventionellen Programmiersprachen (zum Beispiel Cobol) nicht zu erreichen ist. Die Gründe dafür liegen in der fehlenden Normung und den daraus resultierenden unterschiedlichen Implementierungsansätzen. Während Oracle bis auf die PC-Ebene die Programmiersprachen C und Cobol unterstützt, wird für Informix und Ingres dort lediglich eine C-Schnittstelle angeboten.

Änderungsaufwand ist ein wichtiges Kriterium

Auch bei einer sorgfältig vorgenommenen Datenstrukturierung und -normalisierung bleiben Änderungen der Datenstruktur nicht aus. Für den Anwender ist deshalb entscheidend, wie das Datenbanksystem derartige Änderungen unterstützt, welchen Aufwand er also erbringen muß, um eine Änderung der Datenbankstruktur durchzufahren. Auch in diesem Punkt unterscheiden sich die Implementierungen beträchtlich.

Ingres bietet dem Anwender derzeit keine Möglichkeit, nachträglich eine Tabellendefinition zu ändern. Will der Benutzer ein Feld hinzufügen, löschen oder ändern, muß er zuerst eine neue Relation definieren, in die anschließend alle Daten aus der alten Relation übertragen werden. Oracle und Informix ermöglichen sowohl nachträgliches Einfügen einer Tabellenspalte in eine existierende Relation als auch nachträgliches Ändern der Tabellenspaltengröße. Informix unterstützt darüber hinaus auch nachträgliches Löschen einer Tabellenspalte.

Bis dato existieren verteilte Datenbanksysteme nicht in voller Ausprägung; die gleichzeitige Veränderung mehrerer Tabellen in unterschiedlichen Datenbanken auf verschiedenen DV-Systemen ist noch nicht realisiert. Jedoch ist es möglich, Updates auf einer Remote-Datenbank auszufahren. Gleichwohl können mit Oracle und mit Ingres gleichzeitige Lesezugriffe auf verschiedene Datenbanken erfolgen. Mit Informix besteht diese Möglichkeit derzeit nicht.

Integration der Werkzeuge entscheidend

Für Informix und Ingres werden auch Datenbankserver-Lösungen angeboten. Datenbankserver können zentral das Locking übernehmen, und damit entlasten sie den Anwendungsrechner von dem Problem, die Datenkonsistenz beim gleichzeitigen Zugriff mehrerer Anwender aufrechtzuerhalten. Darüber hinaus kann der Datenbankserver den Wiederanlauf kontrollieren sowie den Datenschutz zentral überwachen.

In einer Requester-Server-Umgebung beziehungsweise Task-to-Task-Verbindung wird die Abarbeitung der Query vom Datenbankserver beziehungsweise Back-end vollständig übernommen. Nur die den Quer-Kriterien entsprechenden Tabellenzeilen werden auf den Anwendungsrechner übertragen. Daraus resultiert neben einer erhöhten Stabilität des Netzwerks durch das geringere Übertragungsvolumen auch eine höhere Performance.

Für alle drei Datenbankprodukte werden eine Reihe ergänzender Werkzeuge zur Anwendungsentwicklung angeboten - zumindest ein Maskengenerator und ein Berichtsgenerator. Für den Anwender ist entscheidend, wie diese Werkzeuge integriert sind.

Das bei allen betrachteten Datenbanksystemen vorhandene Data-Dictionary nimmt eine zentrale Rolle ein; seine Aufgabe ist es, alle Objekte, also auch Masken und Report-Definitionen zu speichern. Integration bedeutet jedoch auch, daß Felddefinitionen bei der Maskenerstellung automatisch aus dem Data-Dictionary entnommen werden - zusammen mit den dort spezifizierten Definitionen für gültige Werte, Wertebereiche und Integritätsregeln.

Das ist nicht immer der Fall, beispielsweise nicht bei dem Datenbanksystem RdB von Digital Equipment. Dieses DBMS unterstützt teilweise referentielle Integrität sowie Integritätsregeln auf Tabellenebene in Kombination mit TDMS, das keinen Zugriff auf die Definitionen des Data-Dictionary ermöglicht. Deshalb müssen alle Integritätsregeln in TDMS nochmals definiert werden, woraus für den Anwender ein erhöhter Wartungsaufwand resultiert. Grundsätzlich ist die Integration bei den hier betrachteten Produkten nicht immer überzeugend gelungen.

Informix verfügt über eine Sprache der vierten Generation, die alle notwendigen Befehle zur Datendeklaration, zur Ein-/Ausgabe und zur Programmsteuerung umfaßt. Diese Sprache ist völlig formatfrei - wie zum Beispiel die Programmiersprache C. Die Technik der Fehlerbehandlung entspricht im wesentlichen der, die bei "embedded SQL" verwendet wird.

Kein Masken-Editor in der Werkzeugkiste

Wie in konventionellen Programmiersprachen können Programmhierarchien gebildet werden. Zwischen dem aufrufenden und dem gerufenen Modul ist ein Datenaustausch möglich. Außerdem stehen dem Anwender auch Befehle für Cursor-Operationen zur Verfügung, mit denen sich zu einem Zeitpunkt jeweils eine Tabellenzeile verarbeiten läßt. Außerdem werden dynamische SQL-Statements unterstützt (vergleiche "Dynamic SQL" bei DB2); Informix kennt allerdings keine SQLDA. Unter bestimmten Bedingungen kann der Benutzer auch die mit einem speziellen Dienstprogramm definierten Integritätsregeln prüfen.

Leider ist in der Informix-Werkzeugkiste kein Maskeneditor vorhanden. Sobald die generierte Default-Maske nicht ausreicht - und das ist eigentlich immer der Fall muß mit dem Systemeditor weitergearbeitet werden. Masken werden deshalb auch nicht in das Data-Dictionary eingetragen. Dafür bietet Informix dem Anwender einen Menü-Generator, mit dem er sowohl statische als auch dynamische Menüs erzeugen kann.

Im Vergleich zu Informix ist bei Ingres ein höheres Maß an Integration festzustellen. Für Masken steht ein Maskeneditor zur Verfügung. Der Kontrollfluß der Anwendung kann mit Hilfe der 4GL-Sprache von Ingres realisiert werden. Die kompilierte Version des "Programms" wird ebenfalls im Systemkatalog eingetragen und nach jeder Änderung vor der nächsten Ausführung automatisch rekompiliert.

Wie bei Informix ist es möglich, Daten auf Gültigkeit zu prüfen. Integritätsregeln, die bereits mit dem SQL-Kommando für eine Tabelle festgelegt wurden, werden jedoch bei Ingres automatisch übernommen.

Um Listen zu erzeugen, bietet Ingres verschiedene Möglichkeiten: Es können sowohl Default-Reports generiert als auch Berichte mit Report by Forms (RBF) interaktiv erstellt werden; RBF steht jedoch in der PC-Version nicht zur Verfügung. Als dritte Möglichkeit ist der Report-Writer mit seiner Kommandosprache einsetzbar.

Oracle fehlt eine 4GL-Sprache. Dafür stellt SQL*Forms im Gegensatz zu den anderen Produkten wesentlich mehr Möglichkeiten zur Verfügung. Neben dem Maskeneditor bietet SQL*Forms dem Anwender die Möglichkeit, "Trigger" zu definieren. "Trigger" führen SQL-Prozeduren an bestimmten Punkten aus. Prozeduren bestehen aus SQL-Kommandos und aus anderen Instruktionen (zum Beispiel Zuordnungen und Manipulation von Zeichenketten).

Bei Informix und Ingres werden dagegen "if..then..else"-Konstrukte zur Steuerung verwendet. Wie bei den anderen Produkten, kann der Anwender auch Integritätsregeln definieren und deren Einhaltung prüfen.

Jedes der betrachteten Datenbankprodukte hat seine spezifischen Stärken und Schwächen. Keines der Produkte ermöglicht eine wirkliche Durchgängigkeit vom Mainframe bis zum PC. Ein weiteres Problem ist, daß Umlaute teilweise nicht korrekt behandelt werden.

Ändern sich gültige diskrete Werte oder Wertebereiche, so kann es notwendig sein, Datenprüfroutinen an mehreren Stellen zu pflegen. In den Anwendungs-Entwicklungs-Umgebungen werden Validierungsmöglichkeiten geboten; diese sind jedoch wirkungslos, wenn man sich auf "embedded SQL" beschränkt.

Wer wirklich portabel entwickeln will, ist jedoch aufgrund fehlender Normung bei Sprachen der vierten Generation auf "embedded SQL" angewiesen. Damit begibt er sich zwangsläufig in die Niederungen konventioneller Programmiersprachen der dritten Generation mit allen ihren Nachteilen.

Innerhalb der herstellereigenen Entwicklungsumgebungen ist es möglich, den Entwicklungsaufwand gegenüber der konventionellen Lösung drastisch zu reduzieren. Der Preis dafür ist jedoch die Bindung an den Hersteller; ein späterer Übergang auf ein anderes Produkt ist nur noch mit großem Aufwand zu bewerkstelligen.

Wichtigste Leistungsanforderung ist sicher die referentielle Integrität, die jedoch derzeit von keinem dieser Produkte unterstützt wird. Referentielle Integritätsregeln entlasten die Anwendungsprogrammierung, haben aber auch verständlicherweise eine negative Auswirkung auf die Performance.

Unter Performance-Gesichtspunkten kann eine Entscheidung für ein Datenbanksystem in einer Multiuser-Umgebung nur anhand der aktuellen Anwendungsumgebung getroffen werden. Bei komplexen Betriebssystemen entscheidet die Einbettung in das Gesamtsystem über die Zuteilung von Ressourcen und damit über den Durchsatz. Dem Systemspezialisten bleibt es vorbehalten, mit geeigneten Tuningmaßnahmen den Durchsatz dem jeweils erreichbaren Optimum anzunähern.

Kartographie der Datenströme

Sozusagen das Nervensystem des DBMS: das Data-Dictionary. COMPUTERWOCHE hat in dieser Marktübersicht versucht, die am weitesten verbreiteten Produkte zusammenzustellen. Bemerkenswert ist Immerhin, daß rund ein Viertel der 22 erfaßten Data-Dictionaries bereits unter Unix läuft. Leider blieb IBM die Antworten auf den wiederholt zugesandten Fragenkatalog schuldig. Die Redaktion weist ausdrücklich darauf hin, daß alle hier veröffentlichten Daten auf Informationen von seiten der Anbieter beruhen.