Wer unterschiedliche Datenbanksysteme einsetzt, muss mit Problemen rechnen. Wie die Koelner Unternehmensberatung BC-Consult in ihrer Studie "Unabhaengigkeit von Datenhaltungssystemen" resuemiert, ist SQL keineswegs ein Garant fuer Kompatibilitaet. Bei einer Umstellung der Anwendungen fuehren die unterschiedlichen Philosophien der Hersteller zu erheblichem Mehraufwand - bis hin zur Neuprogrammierung.

Von Bruno Cirone*

Es gibt zwar verschiedene SQL-Normen (beispielsweise ANSI und ISO), die die Sprachelemente beschreiben, jedoch noch keine Norm, die festlegt, wie diese Syntax in Programme zu implementieren ist. Wie schwach die heutigen Normen sind, zeigt sich schon am Beispiel der Fehlermeldungen. Fehlermeldungen und Fehlernummern sind nicht genormt, allenfalls die "0" (kein Fehler) und "100" (Zeile nicht vorhanden) sind weitgehend ueblich. Die juengste SQL-Norm mit "SQL State" sorgt hier eventuell fuer Abhilfe.

Auch gleiche Syntax gewaehrleistet keine Kompatibilitaet. Dies ruehrt zum einen daher, dass die Datenbanksysteme auf unterschiedlichen Betriebssystemen und Maschinen laufen. Zum anderen existieren keine einschlaegigen Normen. Kompatibilitaet ist nicht einmal innerhalb der gleichen Datenbanksysteme (DBS) voll gewaehrleistet (beispielsweise bezueglich signifikanter Stellen bei numerischen Werten).

Die Laengenangaben fuer die einzelnen Spalten und Zeilen kann jeder Datenbankhersteller individuell festlegen. Bei einem System kann die maximale Groesse einer Char-Spalte 240 Bytes sein, bei einem anderen System hingegen bis 32 KB inklusive der Steuerbytes betragen.

Bei der Anzahl der zur Verfuegung stehenden Spalten verhaelt es sich aehnlich. So kann das eine Datenbanksystem 240 Spalten bereitstellen, waehrend bei dem anderen unbegrenzt viele Spalten definierbar sind. Die maximale Laenge einer Zeile variiert von 1962 Bytes bis zu 128 KB.

Es gibt keine Normen fuer Spalten- und Zeilenlaenge

Die Spaltendefinition von numerischen Werten ist besonders problematisch. Ein Produkt kann maximal 18 Stellen bearbeiten, ein anderes bis zu 64 Stellen. Die Genauigkeit hinter dem Komma betraegt bei dem einen System zehn Stellen, bei dem anderen 63. Zu jeder Sprachimplementierung kann der Hersteller eigene Zusaetze vereinbaren. Diese sind untereinander nicht kompatibel. Spezielle Datentypen wie TIME und DATE haben unterschiedliche Bedeutungen und Inhalte, die aber im Regelfall so ausgegeben werden, wie der Programmierer es wuenscht.

Waehrend das eine Datenbanksystem seine Zeitrechnung mit dem 1. Januar 1970 beginnt und von 4711 vor Christus bis 4712 nach Christus Sekunden, Tage, Monate und Wochen liefern kann, speichert ein anderes das Datum in der Form YYYYMMDD und die Zeit in einer separaten Spalte als HHHHMMSS. Werden nun auf diesen Feldern Operationen ausgefuehrt, so bringt dies nur bedingt kompatible Ergebnisse. Eine Kompatibilitaet koennte allenfalls erreicht werden, wenn man auf diese Zusaetze verzichtete.

Die Namensgebung der Objekte - zum Beispiel Tabellennamen, Spaltennamen oder Indexnamen - ist nicht genormt. Sonderzeichen, Umlaute, "ss" sowie Klein- und Grossschreibung sind bei einigen DBS mit Sonderfunktionen erlaubt.

Eine Sortierreihenfolge nach deutschen Regeln ist bei einigen DB- Systemen mit einem Zusatzprogramm moeglich. Andere koennen zwar auf den Betriebssystem-Ort zurueckgreifen, dieser kennt allerdings nur die Sortierreihenfolge nach ASCII.

Ein SQL-Statement zu denselben Elementen sollte auch bei unterschiedlichen Datenbanksystemen das gleiche Ergebnis liefern. Je nach Optimizer und Implementierung ist dies jedoch keineswegs immer gewaehrleistet. Zur Verdeutlichung dieses Problems folgendes Beispiel: Aus einer Tabelle soll eine Liste erstellt werden, die Artikel prozentual nach ihrem Umsatz bewertet.

Das SQL-Statement lautet:

SELECT A.ARTIKEL, A.UMSATZ, A.UMSATZ / (SUM (B.UMSATZ) /100)

FROM ART1 A, ART1 B

ORDER BY 3, 2, 1

GROUP BY 1, 2, 3

DB-A gibt aus:

Artikel Umsatz Prozent

123 5000,00 48,5

127 3750,00 36,5

...

10000,00 88,5

DB-B hingegen zeigt:

Artikel Umsatz Prozent

123 5000,00 50,0

127 3750,00 37,5

...

10000,00 100,0

Aehnliche Ergebnisse koennen bei Rundungsfehlern und unzureichender Genauigkeit entstehen. Bei vom Programmierer falsch definierten Sperren tauchen ebenfalls Probleme dieser Art auf, so zum Beispiel lange Laufzeiten einer Liste, waehrend innerhalb der Tabelle Zeilen weiterhin geaendert oder geloescht werden.

Alle Datenbanksysteme kennen den Dateninhalt "NULL", daher gibt es bei der Definition einer Tabelle auch stets die Moeglichkeit, "NOT NULL" zu definieren. Das bedeutet: Diese Spalte ist eine Pflichtspalte.

Bei einigen Systemen koennen Default-Inhalte definiert werden. Dadurch wird die betreffende Spalte zu einer NOT-NULL-Spalte. Bei der Ausgabe dieser Spalten stehen einige Anzeigemoeglichkeiten zur Wahl; doch zur Bearbeitung in einem Programm reduziert sich diese Flexibilitaet betraechtlich.

Dieser Hinweis, dass es sich um eine NULL-Spalte handelt, wird von jedem Datenbanksystem in einer Indikatorvariable festgehalten, die der Programmierer explizit erfragen und bearbeiten muss. Zusaetze, die eine sinnvollere Arbeitsweise ermoeglichen, sind bei einigen Systemen vorhanden, aber nicht portabel.

Komplexe Regeln sind nicht kompatibel

Einfache Regeln stehen bei allen Produkten zur Verfuegung. Gemeint sind hier beispielsweise Vorschriften wie: Numerische Werte nur in numerischen Spalten ablegen. Komplexere Regeln hingegen sind nicht kompatibel und werden je nach System unterschiedlich definiert: Bei dem einen definieren sie sich beim CREATE-TABLE-Kommando als Zusatz zu einer Spalte, beim anderen gibt es fuer die Regeldefinition eigene Befehle.

Integritaetsregeln sind im allgemeinen auf Zeilen und deren Tabellen anwendbar, und die entsprechenden Aktionen lassen sich innerhalb einer separaten oder auch derselben Transaktion durchfuehren. Zum Beispiel kann eine Regel lauten: Loesche alle Auftragspositionen, wenn der Auftrag selbst geloescht wird.

Ereignisse, die bei dem Ansprechen eines Feldes stattfinden sollen, heissen Trigger. Sie sorgen beispielsweise dafuer, dass ein Betrag nur dann um x Mark erhoeht wird, wenn das Auftragslimit nicht ueberschritten worden ist. Trigger werden von den Datenbanksystemen unterschiedlich implementiert und auch abgefragt. Einige Produkte ueberpruefen die Trigger als Unterroutine des Datenbankkerns. Dort wird die Datenkonsistenz von der Datenbank gewaehrleistet. Andere Systeme koennen nur innerhalb bestimmter eigener Komponenten die Trigger-Funktionalitaet aufrufen. Die Datenkonsistenz laesst sich daher nur mit programmtechnischen Mitteln ermoeglichen. Wieder andere Datenbanken kennen weder die Moeglichkeit, komplexere Regeln aufzubauen, noch stellen sie Trigger-Funktionalitaeten zur Verfuegung.

Sind SQL-Statements in puncto Syntax und Semantik gleich, so kann es trotzdem zu erheblichen, mehrere hundert Prozent betragenden Laufzeitdifferenzen kommen. Verantwortlich hierfuer ist die Qualitaet und die Strategie der Optimizer. Es kommt darauf an, inwieweit der Optimizer Hilfen, beispielsweise Indizes, in Anspruch nimmt, um das gesuchte Ergebnis zu ermitteln.

Nehmen wir folgendes SQL-Statement:

CREATE INDEX BETRAG

SELECT MIN (BETRAG), MAX (BETRAG)

FROMART1

Das Ergebnis lautet:

MIN(BETRAG) MAX(BETRAG)

100,00 5000,00

Die Laufzeit kann bei dem einen Datenbanksystem weniger als eine Sekunde, bei einem anderen eventuell mehrere Stunden betragen. Bei diesem Beispiel nutzt naemlich das eine Produkt die Hilfe eines Index, das andere nicht. Dies kann bei SQL-Statements mit Subquerys beziehungsweise mit Correlated Subquerys zu erheblichen Performance-Problemen fuehren. Betroffene Kommandos sind neben SELECT auch DELETE, UPDATE und INSERT.

Die Installation der Datenbanksoftware ist meist unproblematisch. Die gelieferten Medien (Band oder Disketten) werden in das Laufwerk eingelegt und danach ein Befehl fuer die Installation eingegeben. Die Installationsprozedur liest und installiert an den vorgesehenen Stellen die Software und nimmt die benoetigten Aenderungen in den System-Files vor. Im Regelfall braucht jedes Datenbanksystem einen eigenen User fuer die Installation und fuer den Datenbankbetrieb, um unter anderem als Eigentuemer der Dateien zu fungieren. User-Identifikation und Gruppenzugehoerigkeit sind zumeist vorgegeben; teilweise gibt es auch definierte Pfade fuer einzelne Dateien.

Die Konfiguration einer Datenbank ist jedoch bei jedem System unterschiedlich. Kein Produkt ist bei Anlage einer Datenbank kompatibel mit einem anderen. Bei dem einen gibt es zirka 20 Parameter fuer die Konfiguration einer Datenbank, bei dem anderen rund 350. Zudem nutzt jedes System unterschiedliche Namen fuer zum Teil aehnliche Parameter. Eine Konfiguration (mit Ausnahme einer Grundkonfiguration) muss durch eine DV-Fachkraft erfolgen, die sich mit dem speziellen Datenbanksystem gut auskennt. Der Platzbedarf fuer die zu speichernden Objekte wie Tabellen und Indizes ist recht unterschiedlich. Bei der Portierung der Daten kommen Differenzen von ueber 30 Prozent vor - teilweise sogar 100 Prozent und mehr.

Das Recovery nach einem Datenbankausfall ist nicht kompatibel. Der Datenbankprozess stellt bei einigen der untersuchten Systeme fest, ob alle Transaktionen abgeschlossen wurden und faehrt die nicht abgeschlossenen Transaktionen zurueck beziehungsweise die abgeschlossenen Transaktionen vor. Danach ist die Datenbank konsistent und kann wieder normal benutzt werden. Bei einem der Systeme muss hingegen ein Kontrollprogramm vor dem Start der Datenbank laufen. Dieses Programm stellt Inkonsistenzen fest und veranlasst danach ein Recovery.

Bei einem Totalausfall von Magnetplatten gibt es bei jedem System entsprechende Restore-Mechanismen. Die bauen die Datenbestaende aus den vorhandenen Sicherungen komplett neu. Die Philosophie der Sicherungen (wie?, wann?) ist bei jedem Datenbanksystem unterschiedlich.

Eine verteilte Datenbank besteht aus mindestens zwei gleichberechtigten DV-Systemen mit jeweils eigenem Datenbestand, der nach aussen (zum Programm) als eine Datenbank erscheint. Die Zugriffe sollten ohne die Kenntnisse des Datenlagerortes moeglich sein (Topologietransparenz). Keines der untersuchten Datenbanksysteme ist bezueglich des Verteilungsaspekts mit einem anderen kompatibel. Ein automatisches Two-Phase-Commit-Protokoll wurde nur bei drei dieser Produkte implementiert, das heisst, nur diese Systeme koennen lesende und schreibende Transaktionen unter einer Transaktionskontrolle verteilt ausfuehren.

Weitere Probleme wie verteiltes Recovery, verteiltes Sichern und verteiltes Operating sind heute noch nicht geloest. Einige Systeme koennen zur Zeit nur lokale Transaktionen ausfuehren. Die Datenbanken kommunizieren nicht miteinander und sind deshalb auch nicht mischbar. Kuenftige Entwicklungen bei Transaktionsmonitoren, zum Beispiel Tuxedo oder "X/Topen", koennen hier eventuell Abhilfe schaffen.

Im Client-Server-Betrieb nur ein Datenbestand

Im Gegensatz zu einer verteilten Datenbank existiert bei einem Client-Server-Betrieb nur ein zentraler Datenbestand, auf den von aussen ueber Leitungen zugegriffen werden kann. Im Regelfall sind Inhouse-Leitungen, zum Beispiel Ethernet, fuer den Datentransport vorzusehen, da oeffentliche Leitungen meistens zu langsam sind. Jedes DBS hat fuer die ordnungsgemaesse Abwicklung der Datenbankauftraege ein eigenes internes, nicht offengelegtes Protokoll. Ein Mischbetrieb ist daher nicht moeglich. Probleme der Konsistenz entstehen nicht, da keine Daten vor Ort gelagert werden. Fuer gelegentliche Abfragen ueber das oeffentliche Netz ist dieses Verfahren durchaus praktikabel.

Jedes Datenbanksystem hat eine eigene, nicht genormte 4GL. Keine dieser Entwicklungssprachen ist mit einer anderen kompatibel. Auch der Schulungsaufwand fuer eine Sprache ist erheblich und kann fuer keine andere 4GL genutzt werden. Die Hersteller haben innerhalb ihrer 4GLs spezielle Funktionen implementiert, die optimal mit dem jeweiligen Datenbanksystem kooperieren. Diese sind nicht kompatibel und im Regelfall nicht nachbildbar.

Unabhaengige 4GL-Produkte dagegen koennen mit verschiedenen Datenbanksystemen arbeiten. Allerdings ist deshalb eine genaue Kenntnis der darunterliegenden Datenbanksoftware keineswegs ueberfluessig. So lassen sich zum Beispiel einige Datentypen in bestimmten 4GL-Produkten nicht verwenden. Ausserdem sind auch die externen Entwicklungswerkzeuge nicht untereinander kompatibel, da sie wiederum eigene Sprachelemente und Philosophien verfolgen.

Verschiedene Datenbanksysteme fuehren einige Teile einer Transaktion zu unterschiedlichen Zeitpunkten aus. Daraus ergibt sich die Problematik, dass Programme zwar im Quelltext kompatibel sein, aber trotzdem zu unterschiedlichen Ergebnissen fuehren koennen. Bei dem nachfolgenden Beispiel handelt es sich um einen Auszug aus einem einfachen Programm. Hierbei soll eine Tabelle sequentiell gelesen werden. Ist mindestens eine Zeile vorhanden, so kann dieses Programm auf allen Datenbanken laufen. Existiert aber keine Zeile, so ist es wichtig zu wissen, hinter welchem Statement das DBS die entsprechende Fehlermeldung setzt.

Bei einigen Produkten macht die Mischung von Data Definition Language (DDL) und Data Manipulation Language (DML) Probleme. Die DDL wird benoetigt, um Objekte zu definieren (zum Beispiel Tabellen oder Views); mit der DML werden Daten innerhalb der Datenbank bearbeitet (beispielsweise Insert oder Update). Eines der untersuchten Systeme kann nicht DML und DDL innerhalb ein und desselben Programms verarbeiten. Andere Produkte setzen hinter die DDL-Anweisung intern ein "Commit Work" beziehungsweise integrieren diese Anweisungen normal in den Transaktionsschutz. Bei einem Rollback-Versuch ist es sehr wichtig zu wissen, bis wohin die Transaktion zurueckgesetzt wird.

In dem folgenden Beispiel werden temporaere Tabellen angelegt: Tabelle A enthaelt Zeilen mit positiven, Tabelle B Zeilen mit negativen Betraegen. Diese Betraege wurden aus einer Ursprungstabelle in die temporaeren Tabellen hineinkopiert. Bei einem Fehler empfielt es sich, alle Informationen zu loeschen, inklusive der bis dahin angelegten Tabellen.

Beginn einer Transaktion

1 EXEC SQL CREATE TABLE A (POSITIV NUMERIC(10,2))

2 EXEC SQL CREATE TABLE B (NEGATIV NUMERIC(10,2))

3 EXEC SQL INSERT A AS SELECT BETRAG

WHERE BETRAG >= 0

4 EXEC SQL INSERT B AS SELECT BETRAG

WHERE BETRAG < 0

Ende einer Transaktion

Bei einem Ausfall zwischen 3 und 4 sind bei einigen Datenbanksystemen die Tabellen schon erstellt, aber noch leer. Bei einem anderen Produkt hingegen wird alles zurueckgesetzt; das heisst, es existieren auch keine Tabellen mehr.

Savepoints und Logical Unit of Work beschreiben die gleiche Arbeitsweise. Bei einem Savepoint handelt es sich um eine Markierung, auf die sich innerhalb der Transaktion Bezug nehmen laesst. Es ist somit moeglich, innerhalb einer Transaktion nur einen Teil von ihr zurueckzusetzen und danach fortzufahren. Einige Datenbanksysteme bieten diese sinnvolle Ergaenzung zu den normalen Transaktionen an. Die Funktionsweise sieht folgendermassen aus:

Beginn einer Transaktion

Savepoint A

update

delete

Savepoint B

insert

update

Savepoint C

delete

update

FEHLER ?

JA, dann rollback to savepoint B

NEIN, weiter

Ende einer Transaktion

Zudem benutzt jedes Datenbanksystem eigene Systemkataloge, um Informationen ueber die Objekte zu verwalten. Diese Kataloge koennen abgefragt und nach verschiedenen Gesichtspunkten wie Plattenplatzbenutzung oder Zugriffsrechte analysiert werden. Der Zugriff gestaltet sich unterschiedlich. Einige Systeme erlauben ihn mit normalen SQL-Statements, andere nur mit speziellen Kommandos. Nicht kompatibel sind Tabellen, Informationen, Terminologien etc. Eine Auswertung dieser Kataloge erfordert also gute Kenntnisse des speziellen Produkts.

Das Fazit unserer Untersuchung lautet: Kein Datenbanksystem ist mit einem anderen kompatibel. Bei sehr diszipliniertem Arbeiten mit internen Richtlinien, die individuell zu definieren waeren, ist eine Kompatibilitaet von bis zu zirka 70 Prozent erreichbar.

Bei gleicher Syntax verhalten sich die Programme unterschiedlich, zum Beispiel in bezug auf ihr Sperrverhalten. Liefern die SQL- Statements dasselbe Ergebnis, so koennen doch betraechtliche Zeitunterschiede auftreten. Auch die integrierten 4GL-Umgebungen sind nicht kompatibel.

Weder die Client-Server-Architekturen noch die Verteilungsansaetze lassen sich miteinander mischen. Auch die jeweiligen Transaktionen (einschliesslich Savepoints und Logical Unit of Work) verhalten sich unterschiedlich.

"Reservierte Woerter" gehoeren ebenfalls zu den Bereichen, wo Probleme bei der Uebernahme von Programmen entstehen. Dasselbe gilt fuer eine Reihe von Datentypen: Nicht portiert werden koennen beispielsweise "TEXT", "IMAGE", "LONG", "BLOB" etc. Zudem koennen die Datentypen bei unterschiedlichen Datenbanksystemen verschiedene Laengen annehmen, zum Beispiel CHAR (240) und CHAR (255).

Auf der Detailebene setzen sich die Inkompatibilitaeten fort. Wegen der Komplexitaet der Produkte koennen jedoch nicht einmal die Hersteller selbst die gesamte Funktionalitaet ihrer Datenbank- Releases ueberpruefen. Im uebrigen ist es muessig, nachzuweisen, dass die Systeme eigentlich noch inkompatibler als inkompatibel sind.

*Bruno Cirone leitet die Koelner Unternehmensberatung BC-Consult.