Heute tritt wieder zunehmend ein altbekanntes Verständnis von Datenbanken in Erscheinung, das ihre Existenz nur innerhalb von Lösungsumgebungen sieht. Allerdings präsentiert sich dieser Ansatz im Vergleich zu früher mit einer wesentlichen Neuerung: Die Lösungsumgebung ist hier nicht vertikal und Host-orientiert, sondern organisatorisch und physikalisch horizontal strukturiert. Josef Hanschmidt

* gibt einen Überblick.

Daten sind im Unternehmen der Honig, von dem alle leben. Ihre Aktualität, Verfügbarkeit und Verwaltung zu sichern beziehungsweise zu optimieren, gilt deshalb als vornehmliches Unternehmensziel. Dementsprechend ist jede Diskussion um Datenbanken immer auf langfristige und strategische Perspektiven ausgerichtet.

Direkte Konsequenz dieser Situation ist die Tatsache, daß man über eine wesentliche Eigenschaft von Datenbanken niemals diskutiert: Selbstverständlich wurden früher und werden heute alle wichtigen, unternehmensübergreifenden Daten in einem zentralen Pool gehalten. Und sowohl aus technischen als auch aus organisatorischen Gründen (zum Beispiel Datenkonsistenz, oder Zugriffsschutz) dürfte sich daran wohl auch für die Zukunft nichts ändern.

Flexibler Zugriff und kurze Wege

Abseits dieser grundsätzlichen Position ist allerdings in der letzten Zeit viel in Bewegung geraten. Dabei geht es vor allem um die, Frage, wie denn die zentral gehaltenen Daten dem Benutzer letztendlich verfügbar gemacht werden sollen. Denn die klassische Kombination aus zentraler Datenbank hier und ebenfalls Host-basierter Anwendung dort verliert zunehmend an Befürwortern.

Die aktuellen Forderungen nach lokaler Intelligenz, durchgängiger Anwendungsumgebung und grafischer Unterstützung sind in einer strengen Top-down-Umgebung nicht realisierbar. Der Zug der Zeit geht daher eindeutig in Richtung Dezentralisierung. In relationalen Datenbanken soll der Zugriff auf die Daten flexibilisiert und die Datenhaltung selbst erweiterungsfähig beziehungsweise an neue Anforderungen anpaßbar gemacht werden. Gleichzeitig geht es darum, durch die physikalische Verteilung der Datenbanken vor Ort zu gewährleisten, daß möglichst kurze Datentransport-Wege zur Verfügung stehen.

Forciert wird diese Entwicklung aus zwei ganz unterschiedlichen Richtungen. Da ist zum einen jenes Konzept, bei dem die Datenbank um möglichst einfach zu bedienende Benutzeroberflächen ergänzt wird und so dem Anwender einen leistungsfähigen Direktzugriff quasi am Schreibtisch eröffnet. Das heißt, nicht mehr die Anwendung fordert die Daten von der "Black-Box"-Datenbank, sondern die Datenbank selbst wertet sich auf zur Anwendung.

Genau darin liegt aber auch die größte Schwäche dieses Konzepts. Zwar dürfte jede reine Datenbank-Anwendung aus einem Vergleichstest als klarer Sieger hinsichtlich Performance oder Flexibilität hervorgehen. Nur hat der Benutzer recht wenig davon. Denn er schlägt sich mit dem alltäglichen Problem herum, mehrere Anwendungen mit unterschiedlicher Oberfläche gleichzeitig zu beherrschen.

Und außerdem muß der Nutzer die gerade noch so schnell gewonnenen Daten in jene andere Anwendung (Textverarbeitung, Kalkulation, Statistik etc. ) transferieren, die die Daten eigentlich verwenden soll. All das kostet Zeit, führt zu Fehlern und Problemen.

Vor diesem Hintergrund tritt heute wieder ein altbekanntes Verständnis von Datenbanken in Erscheinung, das ihre Existenz schon immer nur innerhalb von Lösungsumgebungen gesehen hat. Dabei macht es keinen Unterschied, ob damit nun kommerzielle, technisch-wissenschaftliche oder Bürokommunikations-Anwendungen gemeint sind.

Allerdings präsentiert sich dieser Ansatz im Vergleich zu früher mit einer wesentlichen Neuerung: Die Lösungsumgebung ist hier nicht vertikal, hostorientiert strukturiert, sondern organisatorisch und physikalisch horizontal dezentralisiert.

Eine Art Zweiklassen-Gesellschaft

Konkrete Aussichten eröffnen hier vor allem übergreifende Bürokommunikations-Lösungen, die auf Abteilungsebene über Unix-basierte Konzepte heruntergebrochen werden. Sie können alle Anforderungen moderner Bürolösungen erfüllen, wenn sie nur die Möglichkeit haben, zum Stillen ihres Informationshungers die zentrale Datenbank anzuzapfen.

Das Ergebnis ist dann, aus Sicht der Datenhaltung, eine Art Zwei-Klassen-Gesellschaft mit einem Kurzzeit-Datenspeicher vor Ort und einem globalen Datenkonzept im Hintergrund. Diese Zwei-Klassen-Gesellschaft dürfte im Normalfall heterogen sein, also aus unterschiedlichen Systemen unterschiedlicher Hersteller bestehen. Und dafür muß hier im Vergleich zu reinen Datenbank-Anwendungen einiges an zusätzlichem Anpassungsaufwand investiert werden. Doch das machen die Vorteile für den Benutzer um ein Vielfaches wieder wett.

Als wichtigster Punkt erscheint hier, daß der Anwender über alle Funktionen der lokalen Lösung hinweg eine einheitliche Bedieneroberfläche bekommt, egal ob nun Textverarbeitung, Kalkulation, Grafik oder eben Datenbank-Zugriff gefordert ist. Und auch die Präsentation der Daten in anderen Anwendungen erfolgt im gewohnten Umfeld, ohne die Notwendigkeit, daß der Benutzer die Datenbank-Strukturen, Abfragemechanismen und Integrationsfunktionen exakt kennen muß.

Die Datenbank selbst verschwindet für den Benutzer damit völlig von der Oberfläche. Die Hauptsache ist, daß sie die Forderung, nach Flexibilität (relational) und schnellem Zugriff (verteilt) erfüllt. Und sie hat eine Schnittstelle, aber die die Lösung die Datenbank ansprechen kann, um von dort Daten zu entnehmen beziehungsweise abzulegen: Structured Query Language (SQL).

SQL ist der klassische nicht-standardisierte Industriestandard, an dem heute kein Weg vorbeiführt. Wer eine moderne Datenbank erfolgreich im Markt placieren will, muß zumindest eine Teilmenge der in SQL definierten Zugriffskommandos unterstützen. Umgekehrt tut jede Anwendungslösung gut daran, Abfragen zur Datenbank in Form von SQL-Elementen durchzureichen. Die Gateway-Funktionalität, in die SQL als Zugriffssprache damit hineinwächst, ist eine der verläßlichsten Perspektiven jeder Datenhaltungs-Konzeption und dürfte langfristig eher noch zementiert werden.

Damit stehen, wiederum aus Sicht der Datenbank, die wichtigsten Pflöcke für die 90er Jahre: relational, verteilt, SQL-Interface. Hinzu kommt als Grundkonsens die Verfügbarkeit eines offenen Data Dictionary, das die Feldbeschreibungen der Daten der verwaltet.

Noch nicht so selbstverständlich, jedoch genauso absehbar, sind die korrespondierenden Leistungskriterien für Anwendungslösungen, die dem Anspruch auf optimale Nutzung der verfügbaren Datenbank-Fähigkeiten genügen wollen.

Erstes Merkmal ist hier die Durchsetzung von horizontal vernetzten Multi-User-Systemen, die jedem Anwender und jedem lokalen Domain eine weitestgehende Selbständigkeit geben, wobei sich trotzdem die übergeordnete Systemverwaltung von einer zentralen Stelle aus bewerkstelligen läßt. Diese Entwicklung wird vor allem gekennzeichnet durch den wachsenden Trend in Richtung Unix-basierter Büro-Automationslösungen.

Direkt damit verbunden ist zum zweiten die Forderung nach aktiver Integration mehrerer Anwendungen, also das Zusammenfassen verschiedener Informationsarten (Text, Kalkulationsblatt, Grafik, Datenbank-Information) innerhalb eines gemeinsamen Dokumentes. Dabei dürfen die einzelnen Elemente ihre ursprünglichen Eigenschaften nicht verlieren; es ist erforderlich, daß sie sich auch weiterhin in gewohnter Weise bearbeiten lassen. Keine Frage ist, daß in einem solchen Konzept alle Bearbeitungsfunktionen unter einer einheitlichen Oberfläche verfügbar sein müssen.

Des weiteren sollten alle Fragen des Datenimports und -exports durch programmierbare, lösungsinterne Mechanismen automatisierbar sein. Der Benutzer bekommt dann definierte, anwendungsspezifische Abfragemöglichkeiten zur Verfügung gestellt, die für ihn sehr einfach aufzurufen und zu aktivieren sind.

Der Folgeprozeß - also die Abfrage an den nachgeschalteten Datenbank-Client, die Regelung der gesamten Konsistenzproblematik, das Abstimmen der Ergebnisfelder mit denn Data Dictionary, das Überführen der Daten in Unix und schließlich in die lokale Datenbank der Lösung - alles das geschieht ohne Eingriffe des Benutzers. Wenn dabei ausnahmsweise dem "wissenden" Anwender die Möglichkeit gegeben werden kann, das SQL-Interface direkt interaktiv zu nutzen - umso besser.

Und last but not least kommt auch die lokale Datenhaltung auf Ebene des Anwendungssystems nicht ganz ohne spezifische Leistungsmerkmale aus. Wichtig ist hier zum Beispiel, möglichst viele Benutzer-Datenbanken nebeneinander definieren zu können, um zumindest für die Standardabfragen jederzeit schnellen Zugriff auf die benötigten Informationen zu haben.

Zudem sollten diese Arbeitsdaten besonders einfach logischen Operationen beziehungsweise Verknüpfungen unterworfen und für neue Auswertungen oder Weiterverarbeitungen verfügbar gemacht werden.

Ein Anwendungssystem mit entsprechenden Fähigkeiten liefert den Datenbanken genau das, was ihnen fehlt: eine Lösungsoberfläche. Vermittelt durch SQL verschwinden gleichzeitig die Gegensätze, zwischen zentraler Verwaltungs- und dezentraler Bearbeitungsnotwendigkeit der Datenbestände, zum Nutzen von Organisator und Anwender.

*Josef Hanschmidt ist Fachbereichsleiter Vertrieb Bürokommunikation bei der mbp Software & Systems GmbH, Dortmund