Bislang ist nur ein Zehntel aller Unternehmensdaten in relatio- nalen DBMS-Produkten gespeichert. Dennoch bewegt sich die technische Entwicklung weiter; ihr naechstes Ziel sind objekt- orientierte Systeme. Eine Bruecke dorthin sollen bereits vorhandene Hybridsysteme bauen. Kai Padberg* gibt einen Ueberblick ueber die Geschichte der Daten-banktechnik.

Widerspruechlich sind die Meldungen ueber die technischen Entwicklungen im Bereich der Datenbanktechnologien. Vielen Marktuntersuchungen zufolge sind die relationalen Datenbanksysteme, speziell SQL Server, im Umfeld kommerzieller Anwendungen auf dem Vormarsch. Studien, deren Ergebnisse Anfang dieses Jahres veroeffentlicht wurden, haben allerdings ergeben, dass erst etwa zehn Prozent der Unternehmensdaten in relatio-nalen Datenbanken verwaltet werden.

Demzufolge liegen noch 40 Prozent der Daten mehr oder weniger unorganisiert in einfachen Dateien auf den Magnetplatten der Datenverarbeitungssysteme. Die verbleibenden 50 Prozent sind nach nichtrelationalen Datenbankmodellen abgelegt. Besteht hier auch noch Nachholbedarf, so ist es trotzdem angebracht, ueber die Einfuehrung und kommerzielle Nutzung objekt-orientierter Datenbanken nachzudenken, zumal der Weg dorthin schrittweise ueber relationale Datenbanken ohne Aufgabe bestehender Techniken erfolgen kann.

DB-Systeme dienen der organisierten Ablage

Denken wir zurueck: Welches sind die grundlegenden Aufgaben von Datenbanksystemen, warum wurden sie ueberhaupt eingefuehrt? Betriebliche Informationen sollten organisiert abgelegt werden - mit dem Ziel, dieses Archiv nach vorher festgelegten Methoden jederzeit wieder abfragen zu koennen, um Entscheidungen fundiert zu faellen.

Genauso wie organisatorische Massnahmen und Vorgehensrichtlinien beim Aufbau und der Anwendung eines papierenen Archivs notwendig sind, erfor-dert die Organisation elektronischer Datenbanken zwingend eine Abstimmung ueber verwendete Modelle. Einerseits muessen die Rechte der Anwender betreffs der Manipulation der abgelegten Informationen definiert werden (Zugriffssicherung), andererseits ist fuer konsistente Datenbestaende Sorge zu tragen (Transaktions- sicherung). Diese Datenbestaende werden von einem Server verwaltet, der die Anfragen der Klienten koordiniert und bearbeitet.

In den vergangenen Jahrzehnten haben sich die Datenhaltungstechniken von einfachen Dateisystemen ueber hierarchische Datenbanken, Netzwerk- und relationale Datenbanken weiterentwickelt hin zu objekt-orientierten Datenbanken. Immer mehr datenspezifischer und nicht anwendungsspezifischer Code konnte aus den Applikationen verbannt und in das Datenbanksystem integriert werden.

Die erste wesentliche Neuerung, die bei Datenbanken nach dem Netzwerkmodell gelang, war die Trennung von Anwendungs-code und den eigentlichen gespeicherten Daten beziehungs-weise dem physischen Zugriff auf diese.

Im zweiten Schritt, der bei dem relationalen Datenbankmodell vollzogen wurde, oblagen dem Datenbanksystem auch die Zugriffsmethoden und die Navigation. Demnach ist es ausschliesslich Angelegenheit des Datenbank-systems, ueber Zugriffswege auf die geforderten Daten zu entscheiden und eventuell Optimierungsstrategien einzusetzen.

Der Anwender formuliert nur noch die Abfrage der gewuenschten Informationen. Das Datenbanksystem stellt den "kostenguenstigsten" Weg zu den gewuenschten Informationen her und liefert Verknuepfungen bisher unzusammenhaengender Datenbestaende, um dem Anwender zuvor unbekannte Abhaengigkeiten zu praesentieren.

Nicht notwendig ist die Speicherung der immens wachsenden Datenmenge auf einem einzigen Rechnersystem. Mehrere Datenbanken koennen mitein-ander in Verbindung gebracht werden, Abfragen lassen sich ueber diese verteilten Datenbestaende taetigen und Veraenderungen an diesen verteilten Datenbanken vornehmen; dies geschieht alles, ohne die Konsistenz der Informationen insgesamt zu verletzen.

Allerdings sind dazu aufwendige Mechanismen (Two-Phase-Commit) notwendig, die, lange angekuendigt, erst jetzt umsetzbar werden. Auch lassen sich verteilte Manipulationen bisher nur bei verteilten Datenbanken - unter Verwendung der Produkte jeweils eines Datenbankherstellers - vornehmen. Richtlinien, die Transaktionen ueber verteilte Datenbanken unterschiedlicher Hersteller betreffen, sind noch nicht weitreichend genug festgelegt.

Verteilte Abfragen sind State of the art

Verteilte Abfragen, auch ueber Datenbanksysteme verschiedener Hersteller, gelten heute als Stand der Technik und befinden sich im praktischen Einsatz. Verteilte Transaktionen werden voraussichtlich im kommenden Jahr in zunehmender Anzahl im Produktionsbetrieb vorzufinden sein.

Bisher ist es immer noch notwendig, dass gleichzeitig zu veraendernde Daten in einem Datenbanksystem auf einem Rechnersystem verwaltet werden. Auf andere Datenverarbeitungssyste-me auslagern laesst sich jedoch die gesamte Programmlogik, angefangen von immer wieder verwendeten Unterprogrammen (allgemeingueltiger Code) bis hin zur Benutzerschnittstelle, die heute im allgemeinen grafisch ausgefuehrt wird.

Der Datenbank-Server kann damit durch einen SQL-Server realisiert werden, ohne eine Auswahl fuer die angestrebte Be-nutzeroberflaeche vorwegzunehmen. Also ist fuer die Auswahl eines geeigneten Datenbank-systems nicht die Anwender-oberflaeche massgebend, sondern die rein datenbanktechnischen Merkmale, wie sie eingangs beschrieben wurden.

Die Verwendung von Werk-zeugen fuer die Oberflaechen-gestaltung, wie sie viele Daten-bankhersteller anbieten, kann zwar im Einzelfall zweckmaessig sein, ist jedoch nicht zwingend. Zur Verfuegung steht ein grosses Angebot entsprechender Ent-wicklungsumgebungen, die alle mit verschiedenen relationalen Datenbanksystemen zusammenarbeiten.

Der dritte Schritt bei der Evolution von Datenbanksystemen wird momentan vollzogen. Immer mehr quasi allgemeingueltiger Code wird in die Datenbank verlagert. Diese Codeanteile befassen sich im wesentlichen mit der Semantik der abzulegenden oder abgelegten Daten. Abhaengigkeiten der Daten untereinander werden geprueft ("referentielle Integritaet") sowie zulaessige Wertebereiche ("Domaenen") und anwendungsspezifische Eigenschaften der Daten ("anwen-derdefinierte Integritaet") sichergestellt.

Diese postrelationalen entwickeln sich fliessend weiter zu objektorientierten Datenbanken. Daten und der sie manipulierende Code werden gemeinsam in einer Datenbank abgelegt. Die so entstehenden Objekte sind gekennzeichnet durch ihren jeweiligen Zustand (die Menge der Daten, die das jeweilige Objekt beschreiben) und die diesen Zustand veraendernden Methoden (Code in der Datenbank).

Zustandsaenderungen (Datenmanipulationen) erfolgen gemeinhin automatisch als Reaktion auf die Zustandsaenderung eines anderen Objekts. Aende-rungen erzeugen Nachrichten an alle eventuell betroffenen Objekte, die sich nach ihren vorgegebenen Methoden wiederum selbst veraendern und dadurch neue Nachrichten aussenden koennen. Bei passiven objektorientierten Datenbanken sorgt der Anwen-dungsprogrammierer fuer die definitive Speicherung von Objekten in der Datenbank, aktive Datenbanken uebernehmen dies eigenstaendig.

Die logische Trennung zwischen Datenhaltung und Daten-manipulation wird vollstaendig aufgehoben, obwohl eine physische Aufspaltung nach wie vor bestehen kann. Die jeweiligen Objektzustaende sind dauerhaft in der Datenbank festgehalten, so dass die zentrale Forderung der Persistenz erfuellt ist.

Die Verlagerung wesentlicher und allgemeingueltiger Codeanteile in den Datenbankkern ermoeglicht seine Implementierung als Datenbank- Server. Dessen Dienste koennen von verschiedenen Mitgliedern einer kooperativen Rechnerumgebung mit unterschiedlichen Rechnern, Betriebssystemen und Benutzeroberflaechen in Anspruch genommen werden. Die Einfuehrung objektorientierter Datenbanken ist nicht an bestimmte objektorientierte Programmiersprachen gebunden. Setzen sich auch die Anbieter dieser Compiler und Interpreter mit der Entwicklung von Datenbanksystemen auseinander, so erfinden sie das Rad zum zweiten Mal. Anbieter relationaler Datenbanksysteme verfuegen ueber hinreichende Kenntnisse, um den Anforderungen an eine Transaktionsverarbeitung gerecht zu werden.

Der hybride Ansatz verwendet die etablierten Methoden relationaler Datenbanksysteme sowohl zur Speicherung der Informationen als auch zur Transaktionssicherung. Einerseits wird der Sprachumfang des inzwischen weitreichend standardisierten SQL zu einem objektorientierten SQL (OSQL) erweitert, um Objekte samt ihren Methoden definieren zu koennen. Andererseits lassen sich Methoden in jeder sinnvollen Programmiersprache beschreiben, wenn dann eine Verbindung zu den zu manipulierenden Daten hergestellt wird. Dabei finden Programmiersprachen von Cobol ueber C bis hin zu Smalltalk Verwendung. Die Speicherung des Codes erfolgt neben den Daten in der ehemals ausschliesslich relationalen Datenbank.

Der Code ist nur noch einmal zu entwickeln

Auf diese Weise steht eine einfache und vorteilhafte Moeglichkeit zur Verfuegung, um allgemeingueltigen Code einmal zu entwickeln, in die Verwaltung der Datenbank zu uebergeben und bei spaeter notwendigen Anpassungen ausschliesslich hier zu aendern. Abgesehen von der kostenguenstigen Applikationserstellung und -pflege entfaellt eine wesentliche Fehlerquelle. Mehrfach implementierter Code kann sich naemlich asynchron weiterentwickeln und damit drastische Kosten generieren.

Die Art der Datenspeicherung relationaler Datenbanksysteme kann beim Uebergang auf objektorientierte Systeme erhalten bleiben. Existierende Datenbestaende und Anwendungen werden unveraendert weitergenutzt, da der Uebergang zur Objektorientierung eine Erweiterung, nicht Abloesung, bestehender Systeme bedeutet. Der Wandel erfolgt damit sukzessive und ohne Brueche.

Derartige Datenbanksysteme sind sowohl fuer kommerzielle als auch technische Anwendungen nutzbar. Sie sind verfuegbar und im praktischen Einsatz.

Der Lernaufwand fuer Programmierer und Administratoren hybrider Datenbanksysteme ist vertretbar, da diese auf relationalen Systemen aufbauen. Applikationsentwicklung und Verteilung sowie die Systemadministration lassen sich leichter abwickeln und kontrollieren, da sie logisch im Datenbank-Server zentralisiert sind. Dadurch werden eine hoehere Systemverfuegbarkeit sowie Kostenreduzierungen im Bereich der taeglichen Pflege und der Einfuehrung von Software-Updates erzielt.

* Kai Padberg ist Consultant fuer Informa-tionstechnologie im Unternehmensbereich Beratung, Schulung und Systemintegration der Hewlett-Packard GmbH in Ratingen.