Beim Neudesign moderner Datenbankapplikationen stehen Entwickler zugleich interessanten Herausforderungen und neuen Möglichkeiten gegenüber. Einerseits gibt es keine Altlasten zu bewältigen, andererseits sind aber weitreichende strategische Entscheidungen zu treffen, die sich im späteren Projektverlauf kaum noch revidieren lassen. Im folgenden soll dieser Designprozeß systematisch durchleuchtet werden, um alternative Lösungswege aufzuzeigen und Entscheidungshilfen zu geben.
Sind Aufgabe und Funktionsumfang der neuen Applikation erst einmal definiert, steht die Entscheidung über den grundlegenden Ansatz zur Datenmodellierung an. In aller Regel werden Entwickler hierbei zwischen dem relationalen Modell und einem objektorientierten Ansatz wählen.Spätestens mit dem Aufkommen des PC hat sich die IT-Welt dem benutzerzentrierten Paradigma verschrieben. Entsprechend ging seither die Entwicklung der relationalen Technologie dahin, Anwendern von ihren Desktops aus einen einfachen Zugriff auf zentrale Unternehmensinformation zu bieten. Das relationale Modell beschreibt alle Daten anhand eines standardisierten Formats, nämlich als flache Tabellen mit Zeilen und Spalten.
Das ermöglicht den Einsatz einer einfachen Abfragesprache, der Standard Query Language (SQL). Mit ihr können Anwender einfache Daten abfragen und Auswertungen durchführen, ohne allzu großes Detailwissen über die Strukturen der Daten besitzen zu müssen. Daher wird das relationale Modell gern für Anwendungen eingesetzt, bei denen große, einfach strukturierte Datenmengen anhand weniger Selektionskriterien zu untersuchen sind.
Komplexe transaktionsverarbeitende Anwendungen weisen allerdings ein anderes Muster des Datenzugriffs auf. Hier greifen viele Anwender gleichzeitig auf relativ kleine Mengen miteinander verknüpfter Daten zu, um diese zu ändern. Solche Anforderungen bedeuten im relationalen Modell den Zugriff auf zahlreiche Tabellen und die permanente Notwendigkeit, Joins (Verknüpfungen anhand von Schlüsselfeldern) zwischen ihnen durchzuführen.
Während im relationalen Modell die Datenstrukturen bewußt abstrahiert werden (man spricht von der "Normalisierung"), versucht das objektorientierte Modell, alle Strukturen so komplex zu beschreiben, wie sie in der zu beschreibenden realen Welt tatsächlich existieren. In Objektklassen werden alle Eigenschaften und Methoden zusammengefaßt, die ein Objekt beschreiben und mit ihm umgehen.
Objekteigenschaften können einfachen Datentypen wie Zeichenkette, Zahl, Datum etc. angehören oder komplexe, vom Programmierer festgelegte Advanced Data Types (ADT) verwenden. Objekte sind weiterhin - schon in einem nur etwas komplexeren Modell - in andere eingebettet oder enthalten Zeiger auf diese. Schließlich kommen Eigenschaften mit jedem dieser Datentypen wiederholt vor, man spricht dann von einer Collection.
Objekttechniken im relationalen Modell?
Objektmethoden enthalten einen Code, mit dem andere Objekte interagieren können. Sie tun dies mittels Nachrichten (Messages), die ein Objekt unter Angabe von Parametern zur Ausführung einer Methode auffordern. Dieses antwortet seinerseits mit einem Ergebnis. Je nach Datenbankumgebung können die Methoden in unterschiedlichen objektorientierten Programmiersprachen geschrieben sein, wobei sich mehr und mehr Java durchsetzt.
Objektklassen fassen gleichartige Objekte mit ihren Eigenschaften und Methoden zusammen. Sie sind in Hierarchien strukturiert, innerhalb derer von der Ober- zur Unterklasse ein als Vererbung bezeichneter Prozeß stattfindet. Er sorgt dafür, daß die in der Oberklasse definierten Eigenschaften und Methoden automatisch allen Unterklassen zur Verfügung stehen. Ist auch der Polymorphismus implementiert, lassen sich Objekte in der Unterklasse verändern oder überschreiben, ohne daß Anwendungen dadurch so beeinträchtigt würden, daß man mit ihnen nicht weiterarbeiten könnte.
Als Versuch, die Vorteile des relationalen mit denen des Objektmodells zu vereinen, ist der objektrelationale Ansatz zu verstehen. Je nach Hersteller implementiert er ein Objektmodell auf der Basis der jeweiligen klassischen relationalen Datenbank.
Dadurch fällt der Wechsel relationaler Applikationen in eine objektorientierte Welt verhältnismäßig leicht. Allerdings ist keines dieser Objektmodelle vollständig; meist fehlen zumindest Charakteristiken wie Vererbung und Polymorphismus.Es gibt einige Kriterien für eine Entscheidung zwischen den Grundmodellen. Einfach strukturierte Massendaten mit vorwiegend lesendem Zugriff legen das relationale Modell nahe. Für die Abbildung komplexer Geschäftsmodelle ist hingegen eher das Objektmodell geeignet. Gleiches gilt beim Ziel der Transaktionsverarbeitung für viele Anwender. Zur Abbildung komplexer Geschäftsabläufe und/oder zur Transaktionsverarbeitung für viele Anwender bei weiterer Nutzung der vorhandenen relationalen Anwendungen ist der objektrelationale Ansatz die erste Wahl.Steht das Datenmodell fest, gilt es die Anwendungsarchitektur zu wählen. Hierzu unterteilt man die Aufgaben einer Anwendung in die klassischen drei Schichten oder "Tier": die Benutzer-Schnittstelle (User Interface = UI), die Anwendungslogik (Business Logic = BL) und die Datenbankschicht (Database = DB).
In der Vergangenheit waren Anwendungen häufig in einer Zweischichtenarchitektur mit sogenannten "Fat Clients" konzipiert. Hierbei gibt es einen Datenbank-Server, der die Aufgaben der DB-Schicht wahrnimmt, und Desktop-Clients, die für die gesamte Anwendungslogik und die Benutzer-Schnittstelle zuständig sind. Die meisten Decision-Support-Systeme basieren noch auf dieser Architektur, bei der große Mengen von Daten vom Datenbank-Server gelesen und auf dem Client ausgewertet werden.
In einer dreischichtigen Architektur ist zwischen Datenbank-Server und Desktop-Client ein Applikations-Server geschaltet. Er ist für die Ausführung der Anwendungslogik zuständig und kann Daten unterschiedlicher Datenbanken und Server integrieren. Das mindert den Netzwerkverkehr und befreit die Clients von der Last der Applikationen. Somit lassen sich "Thin Clients" einsetzen - bis hin zum Network-PC, der nur noch über einen Web-Browser verfügt und damit den Administrationsaufwand minimiert.
Auch zur Anwendungsarchitektur gibt es Auswahlkriterien. Eine konstant kleine Anzahl von Clients und/oder der Zugriff auf nicht mehr als eine Datenbank erfordert lediglich eine Zweischichtenarchitektur. Wenn es um mehr geht, kommt nur eine Dreischichtenarchitektur in Frage: dann nämlich, wenn Skalierbarkeit und hohe Performance sowie die Integration von Daten aus mehreren Datenbanken wichtig sind. Eine Dreischichtenarchitektur braucht auch jeder, der Thin Clients verwenden will.
Der Aufbau des Repository (oft auch als Data Dictionary bezeichnet) muß sich naturgemäß stark an den bereits getroffenen Entscheidungen über Datenmodell und Anwendungsarchitektur orientierten. Ein relationales Konzept erfordert in jedem Fall eine Tabellendefinition, ein objektorientiertes eine Klassenhierarchie. Entsprechend benötigen bei einer Zweischichtenarchitektur Datenbank-Server und Clients Zugriff auf das Repository, während in einer Dreischichtenarchitektur der Applikations-Server hinzukommt.
Trotz dieser Erfordernisse ergeben sich noch eine Reihe von Aspekten, die zu beachten sind. So wird kaum eine objektorientierte Anwendung ohne die Möglichkeit des SQL-Zugriffs auf die Datenbestände auskommen. Nur wenn hier das Repository zusätzlich zur Klassenhierarchie auch die Möglichkeit einer Tabellendefinition bietet, ist der Anwender in der Lage, Reports oder Ad-hoc-Abfragen mit den klassischen SQL-Tools auszuführen. Optimal sind Repositories mit "Unified Data Architecture", die eine automatische Erzeugung von Tabellen aus Klassen und umgekehrt beherrschen.
Ebenfalls wichtig sind die Übernahme vorhandener Datenmodelle und die Verwendbarkeit von Standardwerkzeugen zur Datenmodellierung. Will man vorhandene relationale Datenmodelle übernehmen oder mit relationalen Modellierungs-Tools arbeiten, muß das Repository die Data Definition Language (DDL) von SQL verarbeiten können. Entsprechend ist die Unterstützung der Standards der Object Database Management Group (ODMG) und eine UML-Schnittstelle (Unified Modelling Language) sinnvoll, um in der objektorientierten Welt mit Tools wie "Rational Rose" zusammenzuarbeiten. Auch hier gilt: Je mehr Paradigmen das Repository unterstützt, desto größer ist später die Freiheit von Entwickler und Anwender.
Die Auswahl des Repository sollte sich also an Datenmodell und Anwendungsarchitektur ausrichten. Vorhandene Datenmodelle sollten sich importieren lassen. Die Unterstützung verschiedener Zugriffe und mehrerer Paradigmen (mindestens SQL und OO) ist ein wesentliches Kriterium. Nicht zuletzt sollte man den Pflegeaufwand für das Repository beachten.
Schließlich sind noch einige Entscheidungen zu treffen, die die Verteilung und Pflege der Anwendung beeinflussen. Entwickelt man Software für einen einzigen Kunden, kann man natürlich individuell arbeiten. Für VARs oder Softwarehäuser allerdings, die ihre Lösungen zahlreichen Kunden anbieten wollen, muß ein möglichst großes Einsatzspektrum das Ziel sein.
Zunächst einmal bedeutet dies Plattformunabhängigkeit, also die Unterstützung möglichst vieler Hardware- und Betriebssystemarchitekturen durch die ausgewählten Komponenten. Wenigstens Windows 95/98 und Win- dows NT, die wichtigsten Unix-Implementationen sowie Open-VMS sollten abgedeckt sein, um Anwender in den unterschiedlichsten Bereichen bedienen zu können.
Ein weiteres Kriterium ist die Skalierbarkeit - also die Frage, wie klein die kleinste und wie groß die größte wirtschaftlich sinnvolle Konfiguration aller beteiligten Komponenten sein darf. Optimal ist eine Skalierbarkeit vom Einzelplatz-PC (zumindest für Demoversionen der Software) bis zu unternehmensweiten Netzen mit Tausenden von Arbeitsplätzen. Um diese zu erreichen, sind ausgefeilte Caching-Techniken auf dem Datenbank- und Applikations-Server vonnöten, speziell auch im Hinblick auf die bei großen Konfigurationen geforderte Ausfallsicherheit und den unterbrechungsfreien Betrieb.
Schließlich ist die Frage zu klären, ob die neue Anwendung auch auf Datenbankplattformen laufen kann, die beim Kunden bereits vorhanden sind. Diese Datenbankunabhängigkeit ist immer dann erforderlich, wenn vorhandene Kundendaten in die Applikation einbezogen werden sollen oder eine neue Applikation ihre Daten älteren Modulen zur Verfügung stellen soll. Der einfachste Weg ist es, wenn die eingesetzte Datenbank über eine Gateway-Funktionalität verfügt, die native Zugriffe bei Bedarf automatisch an fremde Datenbanken weiterleitet.
Auswahlkriterien, die über die zukünftige Nutzbarkeit eines Datenbanksystems entscheiden, sind also Plattformunabhängigkeit, Skalierbarkeit und Datenbankunabhängigkeit, gegebenenfalls durch Gateway-Funktionalität. Diese Faktoren bestimmen, wie sich Anwendungen verteilen und pflegen lassen.
Die Frage der Entwicklungs- und Zugriffsparadigmen stellt die Weichen für jede moderne Anwendungsentwicklung. Will ein Anwender seine Entscheidungsfreiheit für die Zukunft nicht unnötig einschränken, sollte er bei der Auswahl der eingesetzten Produkte darauf achten, daß sie möglichst viele unterschiedliche Ansätze ohne Paradigmenbrüche unterstützen.`'
Michael Ihringer ist Marketing-Manager der Intersystems Deutschland GmbH in Darmstadt. E-Mail: ihringer@intersystems.de