Anwenderansprueche sind an SQL-Systemen geschult Die Vorteile beider Techniken sollten sich kombinieren lassen Von Rudolf Munz*

01.10.1993

Objektorientierte DB-Systeme, die als Erweiterungen von Programmiersprachen entwickelt werden, laufen der bisherige Entwicklung der Datenbanktechnik zuwider. Den Anspruechen der Anwender genuegen nur Systeme, die die Vorteile der Objekt- orientierung mit denen der relationalen Datenbanken kombinieren. SQL-basierte Produkte haben hier derzeit noch die Nase vorn.

In der Praxis gehen heute fast alle Benutzer von SQL-Systemen so vor, dass sie neue Anwendungen nur noch SQL-basiert erstellen und die Abloesung ihrer alten Anwendungen im Zeitraum der naechsten fuenf bis zehn Jahre planen. Eine schrittweise, evolutionaere Weiterentwicklung der SQL-basierten Datenbank-Mangement-Systeme (SQL-DBMS) um objektorientierte Faehigkeiten ist deshalb fuer die Anwender leichter und schneller umzusetzen als eine revolutionaer neue, objektorientierte Nachfolgetechnik. Darauf hat sich jedes neue Verfahren einzustellen.

So muss auch Objektorien- tierung im Datenbankbereich als zusaetzliche Anforderung an SQL-Systeme gesehen werden. Ob- jektorientierung allein - ohne die Erfuellung vom Anwender erwarteter Kriterien - waere weniger statt mehr.

Der in Produkten ausgepraegte Stand der Datenbanktechnik wird heute durch SQL-DBMS-Produkte definiert. Verfechter neuer Datenbankansaetze muessen davon ausgehen, dass ihre Entwicklungen anhand der folgenden Erwartungskriterien bewertet werden: Zunaechst einmal wird jede Nachfolgetechnik der heutigen SQL-Systeme nur dann am Markt angenommen werden, wenn sie die Investitionen in SQL-basierte Anwendungen und SQL-Datenbestaende schuetzt. Volle SQL- Funktionalitaet ist also das mindeste, was diese Systeme bieten muessen.

Zweitens darf eine solche Nachfolgetechnik nicht nur die Funktionalitaet von SQL-DBMS-Produkten emulieren. Sie muss - bezogen auf die SQL-Funktionen - wenigstens dieselbe Performance erreichen wie die heutigen Systeme. Ausserdem sind wir inzwischen daran gewoehnt, dass jedes neue System portabel ist: Alle marktgaengigen und nicht herstellergebundenen SQL-Datenbanksysteme werden heute auf allen relevanten Betriebssystem-Plattformen angeboten.

Darueber hinaus wird Client-Server-Support erwartet. SQL-Systeme reduzieren dabei die Kommunikationszyklen zwischen Client und Server durch Remote SQL, Stored Procedures und Array-Befehle. Auch die transparente Verteilung von SQL-Kommandos auf mehrere Server ist bei heutigen Systemen bereits Standard.

Sogar erste Schritte zur ob- jektorientierten Funktionserweiterung finden sich in SQL-Systemen: Durch Stored and Triggered Procedures werden aus Teilen der Anwendungslogik Datenbankobjekte, die einfacher, weil zentral wartbar sind.

Davon abgesehen bringen SQL-Systeme heute eine reichhaltige Tool- Umgebung - Query-, 4GL-, Repository- und Praesentations-Komponenten - mit, die mit Sicherheit ebenfalls von einer Nachfolgetechnik erwartet wird. Schliesslich wird auch nach der Interoperabilitaet gefragt werden: Technisch am schlechtesten unterstuetzt, aber immer dringlicher gefordert wird die Zusammenarbeit von heterogenen SQL- Systemen. Wegen der zunehmenden Standardisierung dieses Bereichs (ODBC, DRDA und TP-XA) ist in den kommenden Jahren mit einer Verbesserung der heutigen Gateway-Techniken zu rechnen.

Die Frage lautet also: Wo wird sich die Objektorientierung durchsetzen? Relativ rasch geschieht das voraussichtlich bei Analyse-Modellierungs- und Design-Tools, also im CASE-Umfeld. Die Objektorientierung erlaubt naemlich eine natuerlichere Modellierung von Systemen als die bisher uebliche strikte Trennung von funktionsorientierter und datenorientierter Modellierung.

Auch im Programmiersprachen-Umfeld erleichtern objekt- orientierte Konstrukte die Erstellung und Maintenance komplexer Systeme, weil sie gute Strukturierungskonzepte wie abstrakte Datentypen (ADT) und deren Variantenbildung direkt unterstuetzen. Die Verwendung von objektorientierten Programmiersprachen garantiert jedoch nicht automatisch eine gute Systemarchitektur. Nach wie vor ist Erfahrung in der Konstruktion komplexer Softwaresysteme mehr wert als Tools.

Der Produktivitaetsgewinn beim Einsatz von objektorientierten Programmiersprachen wird in erster Linie innerhalb eines Projekts - durch die unterstuetzte Variantenbildung (Vererbung) von Objekten - erreicht. Ziele wie die projektuebergreifende Wiederverwendung von Objekten (Schlagwort Software-ICs) liegen noch in weiter Ferne.

Seit der Erfindung des Unterprogramms versuchen die Entwickler, Software wiederverwendbar herzustellen. Gelungen ist dies heute jedoch nur in Anwendungsgebieten, in denen es eine praezise Spezifikationssprache fuer die erstellte Software gibt, also zum Beispiel fuer Verfahren der numerischen Mathematik. Solange die einzig verlaessliche Spezifikationssprache fuer Softwaresysteme der Quellcode ist, kann es keine projektuebergreifende Wiederverwendung von komplexen Subsystemen geben.

Unabhaengig von der objekt- orientierten Technik gibt es jedoch bei den DV-Anwendern einen starken Trend zur Wiederverwendung von Software, der Hand in Hand mit dem Trend zu DV-Standards einhergeht. Mehr und mehr setzen sich neben Betriebssystem- und Datenbankstandards auch Anwendungsstandards (zum Beispiel Microsofts PC-Applikationen oder SAPs R/3) durch. Mit derartigen Softwareprodukten erfolgt eine Wiederverwendung von Software im grossen Stil - mit der Konsequenz, dass das Feld fuer firmenspezifische Individualentwicklung immer kleiner wird.

Zur Zeit basiert die Entwicklung von objektorientierten Datenbanksystemen auf einer Unterstuetzung objektorientierter Programmiersprachen in Richtung dauerhafter (persistenter) Objekte. Objektorientierte Datenbanksysteme lassen sich jedoch nicht erzeugen, indem Datenstrukturen aus C++ auf eine Platte ausgelagert werden.

Der damit verbundene Anspruch, durch einen Single Level Store die Datenbankprogrammierung zu vereinfachen, ist einfach nicht erfuellbar. Die Datenbankprogrammierung wird nicht deshalb kompliziert, weil explizite Lese- und Schreibbefehle noetig sind, sondern dadurch, dass Multiuser-Aspekte wie Sperren und Transaktionsgrenzen beherrscht werden muessen. Auch bei einem Single Level Store gibt es den Unterschied zwischen privaten und gemeinsam genutzten Daten sowie die Notwendigkeit, bei der Anwendungsentwicklung durch den Einsatz von Spezialkommandos die Multiuser-Faehigkeit sicherzustellen.

Eine andere Illusion der heute verfolgten objektorientierten Datenbankansaetze ist es, dass eine Datenmodellierung durch C++- Hauptspeicherstrukturen ein technischer Fortschritt sei. Seit etwa zwanzig Jahren ist aus Erfahrungen mit hierarchischen Datenbanksystemen und Codasyl-Systemen bekannt, dass die Verwendung von Pointern in der Datenmodellierung die Zugriffspfade zementiert und die Anwendungsprogrammierung in extremer Weise von der Existenz dieser Zugriffspfade abhaengig macht. Es hilft nichts, wenn die Entwickler dieselben Suenden, die sie frueher auf der Platte begangen haben, jetzt im Hauptspeicher feiern.

Die mit dem relationalen Datenmodell erreichte Trennung von Logik und Physik der Daten sollte nicht leichtfertig aufgegeben werden. Auch in ob- jektorientierten Datenbanken muss es moeglich sein, neue Zugriffspfade zu definieren und zu nutzen, ohne existierende Anwendungen modifizieren zu muessen. Ebenso sollte es auch fuer objektorientierte Datenbanksysteme selbstverstaendlich sein, auf alle in der Datenbank abgelegten Informationen zugreifen zu koennen und nicht wegen fehlender Zugriffspfade (sprich: Pointer) bestimmte Auswertungen zu verhindern.

Zusammengefasst bedeutet dies, dass objektorientierte Datenbanksysteme nicht als Erweiterungen von objektorientierten Programmiersprachen entwikkelt werden sollten. Ansonsten besteht die Gefahr, die Entwicklung in der Datenbanktechnik der letzten 20 Jahre zu ignorieren.

Vielmehr muessen die Vorteile der Objektorientierung mit den Vorteilen relationaler Datenbanksysteme kombiniert werden. Dies ist durch eine evolutionaere Weiterentwicklung der heutigen SQL- DBMS-Produkte in Richtung Objektorientierung moeglich. Eine verhaltensmaessige Objektorientierung laesst sich erreichen, indem die SQL-Programmiersprache, die bei der Formulierung von Stored Procedures Einsatz findet, um objektorientierte Sprachelemen- te (Klassen, Vererbung, Polymorphismen) erweitert wird. Die so entstehenden abstrakten Datentypen (ADTs) koennen dann sowohl aus 3GL- wie auch aus objektorientierten Umgebungen heraus genutzt werden. In den OO-Umgebungen ist zudem eine weitere Verfeinerung der Datenbankklassen (ADTs) in Form von Subklassen denkbar.

Neben dieser verhaltensmaessigen Objektorientierung ist fuer ein SQL- DBMS aus Performancegruenden mit Sicherheit auch eine strukturelle Objektorientie- rung notwendig, die das relationale Datenmodell um komplexere Strukturen erweitert. Solche Strukturen haben zumeist einen intern hierarchischen Aufbau.

Praktisch bedeutet das, dass ein SQL-DBMS neben den heute ueblichen flachen Tupeln auch wieder Repeating Groups und mehrwertige Satzfelder in geeigneter Form unterstuetzt. Andernfalls werden komplex strukturierte Anwendungsobjekte ueber eine grosse Zahl von SQL-Tabellen verstreut abgelegt, und ein Zugriff erfordert zuviele Datenbankoperationen.

Sinn macht dieses Vorgehen nur, wenn fuer die Anwendungsobjekte auch ein Clustering unterstuetzt wird, das den Zugriff auf komplexe Objekte mit sehr wenigen Ein-Ausgabe-Operationen erlaubt. Dies kann beispielsweise dadurch erreicht werden, dass alle Zeilen, die ein Anwendungsobjekt beschreiben, zusammenhaengend abgespeichert werden - auch dann, wenn diese Zeilen zu unterschiedlichen Tabellen gehoeren.

Waehrend sich bereits alle SQL-Datenbanksysteme durch die Einfuehrung von Stored-Proce- dure-Sprachen in Richtung einer verhaltensmaessigen Objektorien- tierung bewegen, bleibt noch abzuwarten, wie schnell sie bei der strukturellen Objektorientie- rung nachziehen werden. Dass dies dringend erforderlich ist, steht ausser Frage.

Nur so kann der Anspruch bezueglich der Performance eingeloest werden. Eine blosse formale Objektorientierung ohne die entsprechende Leistung waere rein akademisch und keinesfalls marktgerecht.

*Dr. Rudolf Munz ist Geschaeftsfuehrer der SQL Datenbanksysteme GmbH in Berlin und Entwicklungsleiter fuer Entire SQL-DB der Software AG, Darmstadt.

Munz: Evolution statt Revolution