Die Existenz des ISO-SQL-Standards verfuehrt zu der Annahme, relationale Datenbanksysteme seien mitsamt ihren Leistungsmerkmalen normiert. Doch definiert der Standard lediglich eine Sprachoberflaeche, was dem Hersteller Spielraum zur Implementierung eigener Architekturen eroeffnet. Selbst der Systemkatalog, integraler Bestandteil jedes relationalen Datensystems, wurde erst 1992 in Grundzuegen ISO-normiert. Darueber hinaus ist jeder Hersteller bestrebt , mit einer speziellen Syntax ein zusaetzliches Mass an Funktionalitaet bereitzustellen, um die Kundenbindung zu verstaerken. Die Folge: "Proprietaere Sprachimplementierungen mit unterschiedlichem Leistungsumfang machen die Rea- lisierung verteilter Datenbank- loesungen mit Systemen unterschiedlicher Hersteller zu einem Unternehmen, dem kein Erfolg beschieden sein kann." Auch das logische und physische Speicherkonzept, fuer die Leistungsfaehigkeit eines relationalen Datenbanksystems zentral verantwortlich (siehe Tabellen auf Seite 14), entzieht sich weitgehend der Normierung.

Unter dem Gesichtspunkt der Kosten fuer die Anwendungsentwicklung spielt die Integration des Datenbankkerns mit dem Data-Dictionary und den Anwendungskomponenten eine entscheidende Rolle. Sie ist bei CA-Open-Ingres sowie Adabas D von der Software AG am besten gelungen. Alle Objekte, auch Bildschirmmasken, Berichtsdefinitionen und Integritaetsregeln lassen sich dort speichern.

Neben diesen Vergleichskriterien bemueht sich die Studie auch um die Darstellung der Alleinstellungmerkmale. In Adabas D wird der Datenbestand durch eine eigene Speicherverwaltung in mehrere Datenbanken (Devspaces) unterteilt. Um auf einen Datenbereich zugreifen zu koennen, muss ein Kernel-Programm (serverdb) gestartet werden, das der Datenbank dediziert zugeordnet ist. Obwohl gleichzeitig verschiedene Kernels aktiv sein koennen, ist der Zugriff einer Applikation nur auf eine Datenbank moeglich.

Fuer den Anschluss an ein Client-System bedarf es wie bei Oracle ("SQL*Net") und Informix ("Informix Net") einer Netzkomponente, die bei Adabas D "Net Work" heisst. Allerdings ist die Unterstuetzung des Protokolls TCP/IP bereits vorkonfiguriert.

Adabas D laesst sich in verschiedenen SQL-Sprachmodi starten. Dabei besteht die Wahl zwischen ANSI-SQL und den Dialekten von Oracle oder DB2. Diese einstellbaren SQL-Modi sind die Staerke von Adabas D; denn damit kann auch Applikationssoftware, die fuer den Zugriff auf Oracle oder DB2/MVS konzipiert wurde, mit der Datenbank arbeiten.

Das Data-Dictionary ist mit den Mitteln, die SQL bietet, auswertbar. Da ausser den reinen Data-Dictionary-Daten im Systemkatalog weitere Informationen abgelegt werden koennen, auf die sich dann mit Werkzeugen oder Applikationen zugreifen laesst, steht dem Anwender eine zentrale Informationsbasis zur Verfuegung. Trotz des hohen technischen Standards bedarf es eines vergleichsweise geringen Pflege- und Administrationsaufwands, so dass die Kosten niedrig gehalten werden koennen.

Das Data-Dictionary von CA-Open Ingres kann mit SQL-Befehlen gelesen, aber nur durch speziell autorisierte Benutzer veraendert werden. Wie Adabas D laesst das Datensystem eine Aufteilung in verschiedene Datenbanken zu.

Allerdings kann ein zeitgleicher Zugriff auf die verschiedenen Bereiche nur unter Einsatz des CA-Produktes "Open Ingres/ Star" erfolgen.

Die Datenbank speichert jede Tabelle in einer eigenen Betriebssystem-Datei. Dabei stehen der Ingres-Datenbank im Gegensatz zu anderen Systemen mehrere Organisationsformen fuer die Tabellen und Indizes zur Verfuegung, so dass sich der jeweils optimale Zugriff waehlen laesst. Ausserdem koennen Entwickler SQL- Befehle und deren prozedurale Erweiterungen zu Prozeduren zusammenfassen und ausfuehren.

Darueber hinaus verfuegt Open Ingres ueber einen leistungsfaehigen Optimizer, so dass die Staerke des Systems vor allem in der Transaktionsverarbeitung liegt. Die Uebernahme durch Computer Associates sowie eine fast einjaehrige Verzoegerung bei der Release- Freigabe sorgten zunaechst fuer Unsicherheiten unter den Kunden, so dass Einbussen beim kommerziellen Erfolg hinzunehmen waren. Inwieweit das Auswirkungen auf die technische Weiterentwicklung haben wird, muss laut Jenz und Partner beobachtet werden.

Nachdem die Defizite der ersten Version behoben wurden, verfuegt nun auch IBMs DB2/6000 als zentrale Workstation-Plattform ueber ein umfangreiches Funktionsspektrum. Die Vorteile kommen hauptsaechlich im OLTP-Betrieb und beim Einsatz auf SMP-Systemen zum Tragen.

IBM DB2

DB2/6000 ist von vornherein auf die Verwaltung und den Zugriff auf mehrere Datenbanken eingerichtet und folgt darin dem ISO-SQL- Konzept. Referentielle Integritaetsregeln nach dem ANSI/ ISO- Standard werden in einer Ueberzahl unterstuetzt. Deshalb ist Anwendungscode zur Vermeidung von Konsistenzverletzungen und Tabellen mit fehlerhaftem Inhalt unnoetig. Die Ermittlung der Zugriffsstrategie erfolgt asynchron zur Ausfuehrung vor der Kompilierung. Dabei wird der generierte Zugriffsplan erst zur Laufzeit eingebunden. Auf diese Weise ist keine CPU-intensive Optimierung notwendig, ein hoeherer Durchsatz wird erreicht. Bei der Auswertung des Systemkatalogs mit Hilfe von SQL gibt es keine Einschraenkungen.

Informix Online

Bei der Datenbank "Informix Online" kann lediglich der Administrator auf die Daten der Systemtabellen zugreifen; er sollte jedoch keine Veraenderungen im Data-Dictionary vornehmen. Seine Staerken entwickelt Informix Online vor allem im Bereich Systemarchitektur, die sich besonders in der Nutzung von Mehrprozessorsystemen durch Parallelisierung der Bearbeitungsoperationen auswirkt. Dabei kann der Anwender den Datenbestand partitionieren (fragmentieren) sowie diverse Operationen parallelisieren auf getrennt verarbeitende Subeinheiten. Zudem bescheinigt die Studie dem System eine hohe Skalierbarkeit, so dass sich die Datenbank sowohl fuer den Batch- als auch fuer den OLTP-Betrieb eigne.

Oracle 7

Bei Oracle7 sind die Versionen untereinander am kompatibelsten. Das Einsatzspektrum deckt entscheidungsunterstuetzende Applikationen und wie bei Informix den OLTP- und Batch-Betrieb ab. Dabei koennen grosse Batch-Laeufe durch einen einstellbaren regelbasierten Optimizer unterstuetzt werden. Auch Oracle 7 erhaelt gute Noten fuer die Skalierbarkeit, allerdings mit einem Wermutstropfen. Die zu erwartende Systemlast muss moeglichst zuverlaessig abgeschaetzt werden, soll es nicht aufgrund notwendiger Konfigurationsaenderungen zu Betriebsunterbrechungen kommen. So erfordert etwa die Einrichtung weiterer Server-Prozesse einen erneuten Systemstart.

Zu den Besonderheiten von Oracle 7 zaehlt, dass zum Installationszeitpunkt ein Systemkatalog mit einer Reihe von Views und Tabellen fuer die Default-Datenbank erstellt wird. Die Tabellen gehoeren dem Benutzer SYS und stehen nur dem Datenbankadministrator zur Verfuegung. Fuer jeden weiteren Datenbankbereich wird explizit ein zusaetzlicher Systemkatalog angelegt. Dort koennen sowohl datenbank- als auch anwendungsspezifische Informationen hinterlegt werden. Eine Veraenderung der Tabellen im Systemkatalog sollte allerdings auf wenige Faelle beschraenkt bleiben.

Sybase SQL Server

Alle Datenbanken bis auf den SQL Server von Sybase unterstuetzen ein Two-Phase-Commit-Protokoll, das fuer einen synchronen Schreibzugriff bei Transaktionen, die ueber die lokale Anwendung hinausgehen, verantwortlich ist. Fuer entsprechende Funktionalitaeten muss bei Sybase auf den "Replication Server" zurueckgegriffen werden.

Bei der Installation eines Sybase-Systems werden zunaechst vier Datenbereiche angelegt. Die Master-Datenbank enthaelt Informationen, die das Gesamtsystem betreffen, wie die Login-Namen berechtigter Benutzer. Die "Model-Datenbank" dient als Muster fuer alle weiteren vom Administrator anzulegenden. Die darin enthaltenen Informationen werden in die neuen Datenbanken uebertragen. Die "Sybsystemprocs" ist fuer die zentrale Ablage der Systemprozeduren vorgesehen. In der Tempdb werden Zwischenergebnisse sowie Objekte und Tabellen von zeitlich begrenzter Lebensdauer hinterlegt. Systemtabellen lassen sich zwar mit Hilfe von SQL-Befehlen lesen, jedoch nur umstaendlich veraendern. Zudem ist es durch Integritaetsregeln moeglich, Abhaengigkeiten zwischen den Relationen zu erkennen.

Die ausgewaehlten Datenbanksysteme

Im einzelnen zieht die Studie "Relationale Datenbanken. Ein Produktvergleich" folgende Datenbanksysteme heran:

-"Adabas D", Version 6.1, fuer das die Software AG mit niedrigem "Cost of Ownership" ueber die gesamte Einsatzdauer wirbt,

-"CA-Open Ingres", Version 1.1, mit einer starken Konzentration auf verteilte Datenbanken,

-"IBM DB2/6000", Version 2, die AIX-Portierung innerhalb der DB2- Familie,

-"Informix Online", Version 7.1, mit einer starken Installationsbasis im Unix-Bereich,

-"Oracle 7", Version 7.2, vom Mainframe bis zum PC verfuegbar, und

-"Sybase SQL Server", Version 1.1, ein Produkt, das recht frueh das Client-Server-Prinzip implementiert hatte.

Auswahlkriterien

Mit der Aufnahme in den Produktvergleich von Jenz und Partner genuegen alle Systeme weitgehend den Anforderungen an relationale Datenbanken, die Edgar Codd Anfang der siebziger Jahre formulierte. Ausserdem ist damit gewaehrleistet, dass die Datenbanken fuer mehrere Hardwareklassen und Betriebssysteme zur Verfuegung stehen. Dabei ist die Vormachtstellung von DB2/MVS im Mainframe- Bereich unbestritten. Daneben laeuft nur noch Oracle unter MVS, konnte aber bisher noch keinen signifikanten Marktanteil erringen.

Alle anderen Datenbanksysteme laufen zumindest unter zwei Betriebssystemen. Dabei wird Unix in verschiedenen Derivaten generell unterstuetzt. Auch bieten die meisten Hersteller inzwischen Versionen fuer Windows NT und fuer das Netz- Betriebssystem Netware von Novell an.

Zu den Aufnahmekriterien in die Studie zaehlen auch die Unterstuetzung von Client-Server-Architekturen fuer den Einsatz in Netzen und von SQL, zumindest von ISO-SQL-Standard 89, Level 1. Weitere Bedingungen waren ein herstellereigenes, flaechendeckendes Servicenetz in Deutschland, die ausreichende wirtschaftliche Potenz des Herstellers sowie ein genuegendes Angebot an Applikationssoftware.