Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

09.05.1986

Anbieter müssen noch viel Aufklärungsarbeit leisten:DB-Einsatz heißt weit mehr als Image-Pflege

Relationale Datenbank-Management-Systeme sind zeitgemäß und repräsentieren derzeit den aktuellen Stand der DB-Technologie. Dennoch darf man sich nicht darüber hinwegtäuschen lassen, daß zwischen dem Anspruch des Codd'schen Modells und der Qualität des derzeitigen Softwareangebotes im Markt eine große Lücke klafft.

Bei konsequenter Analyse und Untersuchung der im Markt angebotenen Datenbanksoftware ist sehr schnell festzustellen, daß nur eine Minderheit die Kriterien des "relationalen Modells" ausreichend erfüllt. Dabei ist noch viel Aufklärungsarbeit notwendig, um den Unternehmen und DV-Organisatoren aufzuzeigen, daß der Einsatz modernster Datenbanktechnologie keine Imagepflege, sondern aktiver Beitrag zur Effizienzsteigerung der Informationsverarbeitung und somit ein zwingender Beitrag zur Steigerung der Wirtschaftlichkeit und Wettbewerbsfähigkeit eines Unternehmens repräsentiert.

Modernes IBMS vereint verschiedene Technologien

Moderne Datenbanktechnologie stützt sich jedoch nicht nur auf das relationale Modell, sondern vereint darüber hinaus wesentliche Technologien, die ebenfalls in den 70er Jahren entwickelt wurden. Es handelt sich hierbei um die von Ansi/Sparc entwickelte 3-Schema-Architektur sowie die von führenden Softwareherstellern entwickelte Directory-Technologie. Um die Möglichkeiten und Vorteile von Datenbanktechnologien, die auf diesen Konzepten basieren, besser einschätzen zu können, hier einige wesentliche Erläuterungen zum Verständnis dieser

Technologien:

Dank der Aufklärungsarbeit von Ted Codd und Chris Date in den vergangenen Monaten (siehe hierzu auch COMPUTERWOCHE Nr. 15, 16 und 17, jeweils Seite 12) sind die Eigenschaften wirklich relationaler Datenbank-Management-Systeme nun doch transparenter geworden. Sie lassen sich in drei Basiskriterien herunterbrechen, die nach Darstellung der Autoren auf einen ersten Blick erkennen lassen, ob es sich um ein wirklich relationales DBMS handelt oder nicht:

Abbildung der Daten in Form von Tabellen

Diese Eigenschaft ist nicht neu, sondern wurde auch in der Vergangenheit bereits von Datenbank-Management-Systemen bereitgestellt, welche Techniken der invertierten Liste zugrunde liegen hatten. Der Anspruch aus dem relationalen Modell stellt sich jedoch insofern höher dar, als daß dem Anwendungsprogramm lediglich eine Sicht zu den Daten und nicht zu den Dateien bereitgestellt wird. Konsequenterweise hat also ein Anwendungsprogramm, gleich, in welcher Sprache es entwickelt wird, keinerlei Bezug zu Dateinamen, Indexnamen und Datenbanknamen, welche Aufschluß über Herkunft und Zugriff zu den Daten beinhalten würden.

Relationale Operationen

Es gibt bis heute kein einziges DMBS, welches alle 18 relationalen Operationen unterstützt. In der Tat legen selbst die Autoren hierauf nicht den größten Wert, sondern fordern zunächst einmal die Erfüllung der drei Basisoperationen "select", "project" und "join". Entscheidend ist dabei, daß diese Operationen vom DBMS und nicht vom Anwendungsprogramm durchgeführt werden. Nur dadurch ist gewährleistet, daß die Herkunft der Daten auch im Hinblick auf ihre Basisrelationen dem Anwendungsprogramm verborgen bleiben, um die gewünschte Datenunabhängigkeit im Anwendungsprogramm selbst zu erreichen.

Dabei ist darauf zu achten, daß dem Anwendungsprogramm nach wie vor der gesamte Datenmanipulationsumfang, also Einfügen, Löschen und Andern, erhalten bleibt. Selbstverständlich bleibt es dem Anwendungsprogramm überlassen, darüber hinaus weitere Selektionen, Projektionen und Verbindungen (joins) mit den abgeleiteten Daten (logische Benutzersichten) durchzuführen. Das Auflegen einer Sprache der vierten Generation über das Datenbank-Management-System allein kann diesem Anspruch nicht genügen.

Integritätsregeln

Ein Informationssystem steht und fällt mit der Qualität und Aktualität der Daten. Nicht zuletzt deshalb kommt der Fähigkeit des Datenbank-Management-Systems, die Integrität und Konsistenz der Daten selbständig zu gewährleisten, eine besondere Bedeutung zu. Integritätsauflagen an die Daten können vielfach sein. Um sich jedoch als voll relationales DBMS im Sinne von Codd und Date zu qualifizieren, muß das System zumindest die beiden folgenden Regeln beinhalten:

a) Entity-(Objekt)-Integrität

Diese Regel gewährleistet, daß bei jedem Einfügungs- oder Änderungsprozeß die als Pirmärschlüssel qualifizierten Attribute (Datenfelder) gefüllt sind. Dadurch wird sichergestellt, daß alle Informationen, die in das Datenbank-System eingestellt werden, unter Verwendung ihrer logischen Schlüssel auch wiedergefunden werden können. Gleichzeitig sorgt das DBMS dafür, daß keine doppelten Eintragungen in einer Tabelle existieren können.

b) Referentielle Integrität

Spätestens an dieser Stelle scheiden sich nun Spreu und Weizen relationaler Datenbank-Management-Systeme, da diese Eigenschaft nur von einer Minderheit bereitgestellt wird. Die Regel selbst besagt, daß das DBMS gewährleisten muß, daß die Beziehungen der Relationen untereinander immer integer bleiben.

Aus praktischer Sicht bedeutet dies, daß zum Beispiel beim Einfügen einer Auftragszeile vom DBMS selbständig überprüft wird, ob der zugehörige Auftrag sowie der Artikel im System vorhanden sind. Die gleiche Prüfung im umgekehrten Sinne erfolgt beim Löschen eines Auftrags, was dann vom DBMS abgewiesen werden muß, wenn noch zugehörige Auftragszeilen vorhanden sind.

Datenintegrität vorrangig

Dabei muß gewährleistet sein, daß diese Eigenschaft auch dann erhalten bleibt, wenn die darunterliegende physische Datenstruktur keine physischen Verbindungen der Relationen aufweist, zum Beispiel bei Verkettungstechniken in IMS, DL/ 1, "Total" oder anderen Systemen unter Verwendung eingebetteter Pointer, ausgelagerter Pointer (Indexe), File-Coupling-Techniken oder sonstiger physischer Verbindungstechniken.

Voraussetzung für diese Eigenschaft des DBMS ist, daß ihm die Daten nicht nur in Form von Relationen, Attributen und Sätzen bekanntgemacht wird, sondern daß darüber hinaus die Attribute auch als Primär-Schlüssel und Fremdschlüssel beschrieben werden. Diese Eigenschaft darf aus folgenden Überlegungen heraus nicht unterschätzt werden: Der operationale Bereich von Anwendungssoftware kann in verschiedenen Unternehmen sehr hohe Ansprüche an die Integrität der Daten stellen. Hier stellt sich ganz einfach die Frage, ob die Verantwortung für die referentielle Datenintegrität vom Anwendungsprogramm, also v(...) Programmierer, oder vom Datenbank-Management-System übernommen werden soll.

Überblick fällt schwer

Auch in der modernen Welt der Informationsverarbeitung stellt sich die kritische Frage, ob bei zunehmender Verlagerung von Anwendungsentwicklungstätigkeiten, wenn auch nur für bestimmte Aufgaben, der Endbenutzer jemals das Verständnis aufbringen wird, für die referentielle Integrität der Daten selbständig Sorge zu tragen. Dabei sollte nicht unterschätzt werden, daß bei modernen Informationssystemen die sich durch sämtliche Unternehmensbereiche hindurchziehen, weitaus mehr Objekte (Relationen) anfallen und somit der Überblick über deren Beziehungen und Abhängigkeiten untereinander selbst einem "gestandenen" DV-Mann mittlerweile recht schwer fällt.

Auch darf der Aspekt der Wartung nicht aus dem Auge verloren werden, denn bei geschäftspolitischen Veränderungen ist das Nachvollziehen neuer Abhängigkeiten zwischen Objekten im einen Falle die Angelegenheit von Programmänderungen und im anderen Falle vom Datenbeschreibungsteil des Datenbank-Management-Systems.

Datenbank-Management-Systeme können mit aktiver Unterstützung einer integrierten Meta-Datenbank, wie sie auch zur Verwaltung der referentiellen Integrität notwendig ist, die inhaltliche oder semantische Integrität der Daten sicherstellen. In der Praxis findet man heute oft Fähigkeiten des DBMS dahingehend, daß mit Hilfe des Domain-Konzeptes auch die einzelnen Inhalte der Attribute vom DBMS geprüft werden.

In diesem Bereich ist noch ein großes Entwicklungspotential gegeben, welches unter Berücksichtigung der Abhängigkeiten von Objekten und Attributen untereinander inhaltliche Auflagen an die Attributswerte gewährleisten kann; man spricht in diesem Zusammenhang häufig auch von "semantischen Datenbanken", die im Prinzip sogar Datenmanipulationsfunktionen in die Datenbank-Operationen verlagern könnten.

Fast parallel zur Entwicklung des relationalen Modells von E. F. Codd hat sich ein Team von Datenbank-Experten unter Führung des "American National Standards Institute" (Ansi) zusammengefunden und eine allgemeingültige Architektur für Datenbank-Management-Systeme konzipiert. Primärziel dieser Arbeitsgruppe, die sich "Standards Planning and Requirements Committee" (Sparc) nannte, war, eine allgemeingültige Datenbank-Architektur zu finden, die den Anwendungsprogrammen eine höchstmögliche Datenunabhängigkeit gewährleistet.

3-Schema-Architektur zur Datenunabhängigkeit

Ergebnis dieser Entwicklung, die 1977 verabschiedet wurde, war die sogenannte 3-Schema-Architektur. In einer solchen Software-Architektur werden Daten auf drei voneinander unabhängigen Ebenen beschrieben:

Externe Ebene

Auf dieser Ebene werden die Daten in der Form beschrieben, wie sie tatsächlich in den Anwendungen und bei den Benutzern erarbeitet und benutzt werden. Die Sicht zu den Daten ist dabei vollständig problem- und aufgabenorientiert und nicht bezogen auf die tatsächliche physische Speicherung oder bezogen auf irgendein ideales logisches Modell oder Konzept.

Konzeptionelle Ebene

Auf dieser Ebene werden die Daten in einem logischen Modell beschrieben, wie es für die gesamte Unternehmensorganisation allgemeingültig ist. Diese Ebene dient gleichzeitig als Grundlage zur Ableitung der darüberliegenden externen Ebene im Sinne von logischen Benutzersichten.

Interne Ebene

Hier werden die Daten in der Form beschrieben, wie sie tatsächlich physisch gespeichert sind. Entgegen dem logischen Datenmodell können hier wieder völlig abweichende Datenstrukturen organisiert werden, die aus den verschiedenartigsten Gründen wie Performance-Anforderungen, Integration von Standardsoftware oder historisch bedingter Datenbestände vollständig vom logischnormalen Modell abweichen können. Dennoch wird diese Problematik zum Anwendungsprogramm hin nicht transparent.

Die 3-Schema-Architektur hat in den modernsten Datenbanktechnologien bereits Einzug gehalten. Allerdings gilt es hier, kritisch zu prüfen, inwieweit bei konsequenter Anwendung des 3-Schichten-Modells der vollständige Funktions- und Leistungsumfang des Datenbank-Management-Systems erhalten bleibt, so zum Beispiel die Fähigkeit, auch auf den abgeleiteten und zusammengeführten Benutzersichten Änderungen, Löschungen und Hinzufügungen durchführen zu können. Selbstverständlich muß auch hier die Integrität der Datenbank weiterhin gewährleistet bleiben.

Bereits vor vier Jahren hat James Martin in einem seiner Seminare zum ersten Mal die drei Phasen der Entwicklung von Meta-Datenbanken aufgezeigt. In klassischer Weise unterschied er zwischen passiven Dictionaries, welche in der Phase der Analyse und des Designs von Anwendungen Unterstützung leisten, den aktiven Dictionary-Systemen, welche darüber hinaus in der Phase der Entwicklung und Kompilierung Unterstützung leisten, und den Directories, welche neben den bisher genannten Phasen darüber hinaus auch die Ausführung von Anwendungen aktiv steuern und kontrollieren.

Directory-Steuerung gewinnt an Bedeutung

Wer sich heute bereits mit der nächsten Softwaregeneration befaßt hat, zum Beispiel mit Expertensystemen oder künstlicher Intelligenz im weitesten Sinne, kann genau erkennen, daß diese Softwaretechnologie ausschließlich directorygesteuert ist. Das Geheimnis einer Directorysteuerung liegt darin, daß eine neue oder veränderte Information über ein Datum oder eine Datenbank-Operation sofort bei der nächsten Programmausführung zur Wirkung kommt, ohne daß deshalb irgendeine Generierungsfunktion notwendig wäre .

Schade, daß so viele Softwarehersteller und auch andere Experten dieses Zeichen der Zeit noch nicht erkannt haben. Schließlich verwenden nahezu alle Query-Sprachen, die es seit fast zehn Jahren auf dem Markt gibt, diese Technik, wenngleich auch nur mit einem eingebetteten anstelle eines globalen Directories.

Relationale Datenbank-Management-Systeme leiden sehr stark unter dem Ruf einer schlechten Performance. Nach den Erfahrungen vieler Anwender sind die Vorwürfe zum Teil auch berechtigt. Es stellt sich hier jedoch die zwingende Frage, ob man aus dem Tatbestand unzureichender Implementierung durch den Softwarehersteller (oder auch Hardwarehersteller) das relationale Modell nicht als solches in Zweifel ziehen sollte. Wer sich die Zeit nimmt, nicht nur die systemtechnische Implementierung eines DBMS zu untersuchen, sondern aus der Sicht der Anwendungsentwicklung, der Datenadministration und der Pflege von Anwendungen die Vorteile eines wirklich relationalen Datenbank-Management-Systems zu prüfen, wird sehr schnell herausfinden, daß in diesen Bereichen immense Kosteneinsparungen erzielt werden können.

Performance-Probleme fordern Hersteller heraus

Dennoch ist eine kritische Betrachtung der potentiellen Performance-Probleme angebracht, denn hier liegt eindeutig die Herausforderung an die Softwarehersteller. Drei Problemkreise fallen besonders auf:

Relationaler Kalkulus

Das Umsetzen der relationalen Operationen in Datenbank-interne Operationen, welches über den relationalen Kalkulus erfolgt, ist die wohl anspruchsvollste Aufgabenstellung innerhalb des Datenbank-Management-Systems. Letztendlich muß das DBMS den Weg zu den Daten finden, die Daten an den verschiedenen Stellen "einsammeln", sie zusammenführen und dann in der gewünschten Schnittmenge und Darstellung an das Anwendungsprogramm abliefern oder den ganzen Prozeß in umgekehrter Folge durchführen.

Bei diesen Vorgängen gibt es mehrere Alternativen, zum Beispiel verschiedene Indices beim Zugriff oder die Reihenfolge der logischen Verknüpfungen. Dabei gibt es zwangsläufig optimale bis ungünstige Alternativen. Wie gut dieses Problem vom DBMS gelöst wird, hängt ganz einfach von der Implementierung des Kalkulus ab. Da muß man einfach akzeptieren, daß diese junge Technologie bis heute noch nicht über den optimalen Kalkulus verfügt.

Dies wurde in einem Leistungstest an der Universität Paris 1981 untersucht, indem man drei verschiedene relationale Datenbank-Management-Systeme mit einer äußerst komplexen Abfrage konfrontierte. Das eine System benötigte 40 Stunden, das zweite System 70 Stunden, das dritte System hatte nach 120 Stunden noch immer nicht die geeignete Navigations- und Derivationslogik gefunden.

View-Designkonzept bietet Alternative

Eine Alternative zu dem in den meisten relationalen Datenbank-Management-Systemen implementierten Automatismus ist das "View-Design-Konzept". Im Gegensatz zu dem oben beschriebenen Verfahren wird hier die Benutzertabelle auf zwei Ebenen beschrieben. Die eine Ebene beschreibt die logische Datenstruktur der Ergebnisrelation, die andere Ebene beschreibt die Derivationslogik und die Navigationslogik, wenn es sich um eine 2-Schema-Architektur handelt.

Unter Anwendung der modernen 3-Schema-Architektur läßt sich dies noch einmal trennen in die externe Ebene mit Beschreibung der Benutzerrelation und der Derivationslogik und die konzeptionelle (logische) Ebene mit Beschreibung der Navigationslogik. Im Gegensatz zu dem oben beschriebenen Verfahren wird hier der Datenfluß aufgrund des Wissens eines Datenbank-Administrators festgelegt. Zweifelsohne ist dieses Verfahren vom Aspekt der Performance interessanter, allerdings rückt hierbei die zentrale Daten(bank)-Administration sehr stark in den Vordergrund.

"Tabellen sind die logische Abbildung der Daten, nicht die physische Speicherungsform; in der Tat bleibt es dem DBMS überlassen, in der Wahl der physischen Speicherungsformen und Zugriffstechniken alle Möglichkeiten auszuschöpfen, um den hohen Anspruch an Performance erfüllen zu können." So beschreibt Chris Date, langjähriger Mitarbeiter und Assistent von Ted Codd, das Kriterium der Abbildung von Daten in der Form von Tabellen. Entscheidend hierbei ist, daß die physische Speicherungsform selbst nicht zum Anwendungsprogramm oder zum Benutzer durchschlägt, was eben durch die tabellarische Abbildung gewährleistet wird.

Die Möglichkeiten physischer Speicherungsformen und Zugriffstechniken sind aus der Erfahrung der verschiedensten Datenbank-Management-Systeme in den vergangenen 20 Jahren hinreichend bekannt. Nach wie vor gibt es keine neuen Techniken zur Speicherung von Daten auf Magnetplatten-Speichern. Daraus leitet sich natürlich die Frage ab, welche der bekannten Techniken am besten geeignet sind, um die hohen Ansprüche an die Performance relationaler Datenbank-Management-Systeme erfüllen zu können.

Entscheidet sich der Hersteller für die indizierte Speicherung und die Verwendung invertierter Listentechniken, so konfrontiert er den Anwender mit der altbekannten Performance-Problematik beim Löschen und Hinzufügen. Setzt der Hersteller auf Direkt-Adressierung und Verkettungstechniken, so fehlt die notwendige Zugriffsflexibilität.

Andererseits haben sich aber die erwähnten Speicherungsformen und Zugriffstechniken in der Vergangenheit auch mehrfach bewährt, wenn das individuelle Leistungsprofil des Datenbank-Management-Systems den besonderen Bedürfnissen einer Anwendung entgegenkam. Aus diesen Erfahrungen heraus läßt sich ableiten, daß bei der Vielfalt der heutigen Aufgabenstellungen das Datenbank-Management-System dem Datenbankverwalter die Wahl der günstigsten Speicherungsform und Zugriffstechnik überläßt.

Tuning darf Enduser nicht belasten

Das entscheidende Kriterium dabei ist, daß eine nachträgliche Änderung der Speicherungsform und Zugriffstechnik im Rahmen einer Tuning-Maßnahme sich auf keinen Fall wieder auf ein Anwendungsprogramm, eine Endbenutzertabelle oder gar den Endbenutzer selbst auswirkt: Eine auch vom Standpunkt der Kostenbetrachtung aus attraktive Eigenschaft, die der modernen 3-Schema-Architektur auf dem relationalen Modell zu verdanken ist.

Mit dem Problemkreis Kanalaktivitäten und Plattenzugriffe kämpfen nicht nur moderne Datenbank-Management-Systeme relationaler Eigenschaft, sondern auch alle Datenbank-Management- und Dateiverwaltungssysteme aus der Vergangenheit. Dennoch muß darauf hingewiesen werden, daß durch intelligente Paging- und Puffertechniken die Anzahl der physischen Zugriffe im Verhältnis zu den logischen Datenzugriffen extrem niedrig gehalten werden können.

Wenn ein Datenbank-Management-System in der heutigen Zeit nicht wenigstens 80 Prozent der Datenzugriffe kompensieren kann, dann hat der Hersteller nicht die notwendige Entwicklungsarbeit geleistet. Den Schaden trägt der Anwender, der durch gravierende Antwortzeit-Probleme (ein Plattenzugriff ist nach wie vor nicht wesentlich schneller als 30 Millisekunden) die Datenbank-Entscheidung in Frage stellen muß. Da nützt auch kein Hochrüsten mit mehr Hauptspeicher und noch mehr Mips.

Neben den vielen Möglichkeiten und Vorteilen, die Datenbank-Management-Systeme im weitesten Sinne und echt relationale Datenbank-Management-Systeme im besondere bieten, gibt es natürlich auch Leistungsgrenzen, die nicht vor Einführung neuer Techniken und Technologien durchbrochen werden können, insbesondere nicht durch aggressive Marketingsprüche von Softwareherstellern.

Auch DB-Maschinen sind k in Allheilmittel

Es ist immer wieder die Rede von neuen Speichertechnologien, wie beispielsweise Assoziativ-Speichern, Bubble-Memories oder auch Biochips, wie sie in der jüngsten Zeit in Japan intensiv erforscht werden. Die einzige verläßliche Prognose, die daraus abgeleitet werden kann, ist die, daß mit Sicherheit eine neue Generation von Speichertechnologie erscheinen wird und auch ersch(...)nen muß, gleichgültig, welche es letztendlich wird. Daraus folgt, daß eine sprunghafte Verbesserung der Leistungsproblematik aus diesem Bereich in den nächsten Jahren noch nicht erwartet werden kann.

Um so beteutungsvoller ist die Anforderung an heutige Datenbank-Management-Software, daß sie unter Verwendung intelligenter Zugriffs- und Puffertechniken die Problematik auf eine minimale Belastung reduziert. Andererseits sollte nicht übersehen werden, daß die Einführung neuer Speichertechnologien gravierende Auswirkungen auf bestehende Datenbank-Technologien haben wird. Wer heute noch auf konventionelle Dateiverwaltungs-Systeme oder verwaltete Datenbank-Management-Konzepte als Grundlage für die künftige Investition in der Anwendungsentwicklung setzt, darf sich nicht wundern, wenn am Tage "X" eine Milliardenbürde an Systemumstellung auf ihn zukommt.

Auch der Einsatz von Datenbank-Maschinen kann die ursächliche Performance-Problematik nicht lösen. Im Prinzip wird hierbei das Problem vom Verwaltungsrechner lediglich auf einen dedizierten Datenbankrechner verlagert, der seinerseits wiederum die Probleme der Kanalaktivitäten und Plattenzugriffe behandeln muß.

Intelligente Platten-Controller hingegen haben den durchaus interessanten Ansatz, daß sie Such und Übertragungsoperationen vom Host-Rechner wegnehmen und in die Datenspeicherungshardware verlagern können. Die daraus resultierende Reduzierung von Kanalaktivitäten und den damit verbundenen Unterbrechungsvorgängen auf die Warteschlangenverwaltung kann die Performance in diesem Problembereich sehr günstig beeinflussen.

Ähnliche Ansätze zur Teiloptimierung bieten erweiterte Cache-Memories und die Verlagerung von physischen Zugriffsoperationen vom Betriebssystem in den Micro-Code oder die Firmware. Aus der Sicht der Datenbankvewaltung selbst würde bei diesem Ansatz jedoch keine Verlagerung von Funktionen aus dem Host-System in die Hardware erfolgen.

Technischer Wandel zeichnet sich ab

Zusammenfassend läßt sich festhalten, daß sich sowohl hardware- als auch softwaretechnologisch ein Wandel in mehreren kleinen oder auch größeren Schritten vollziehen wird, der aus der heutigen Sicht des Ansenders eine höchstmögliche Un(...)hangigket seiner Anwendungen zur Entwicklung der Datenhaltungssysteme notwendig macht. Eine primäre Eigenschaft des relationalen Modells nach Codd sowie der 3-Schema-Architektur.

Verteilte Datenbanktechnologie wird nach wie vor häufig mit verteilter Verarbeitung und Kommunikation verwechselt, was zuweilen auf unseriöses Marketing von Softwareherstellern zurückzuführen ist. Nach wie vor gibt es keine implementierte verteilte Datenbanktechnologie auf Großrechnern. Einfachstes Prüfkriterium hierfür ist die Feststellung, ob die Verteilung der Daten - sprich: Lokalität - dem Anwendungsprogramm oder ausschließlich dem Datenbank-Management-System bekannt ist.

Anwendungsprogramm muß unbelastet bleiben

Wie auch im relationalen Modell verankert, ist die Problematik der Verteilung von Daten für das Anwendungsprogramm vollkommen irelevant beziehungsweise transparent. Demzufolge ist es Aufgabe des Datenbank-Management-Systems, welches dem Anwendungsprogramm als Kommunikationspartner dient, die Zusammenführungs-(Ableitungs-) und Navigationslogik durch eine verteilte Datenbank-Organisation selbständig durchzuführen.

Weder die Kommunikation zu verschiedenen Datenbank-Managern noch die namentliche Diversifizierung von Datenbanken oder Dateien dürfen in das Anvendungsprogramm durchschlagen, will man die heute so wichtige Datenunabhängigkeit erhalten. Darüber hinaus gibt es eine ganze Reihe von bislang ungelösten Problemen, welche die Anwendung solcher Technologien zum derzeitigen Stand der Entwicklung überfordern. Um dies zu verdeutlichen, hier einige Beispiele dazu:

- Dynamisches Recovery bei verteilten Update-Vorgängen (inklusive Löschung und Neuzugang),

- Übertragungsgeschwindigkeiten im Netz,

- Wiederherstellung von Datenbeständen nach physischer Zerstörung,

- Inhaltliche Integrität in verteilter Datenorganisation,

- Referentielle Integrität in verteilter Datenorganisation.

Geradezu beispielhaft ist die Rücksichtnahme auf den derzeitigen Stand der Entwicklung für verteilte Datenbanktechnologie die im relationalen Modell geforderte Verteilungsunabhängigket der Anwendungsprogramme. Das einzig Sinnvolle, was man strategisch vorbereitend für den nächsten Schritt der verteilten Datenbank tun kann, ist, dem Anwendungsprogramm bereits heute die absolute Unabhängigkeit dafür einzurichten. Dies gestattet einer DV-Organisation, diesen technologischen Fortschritt zu vollziehen, wenn die Zeit dafür reif geworden ist, ohne die bestehenden Anwendungen deshalb ändern zu müssen.

Datenhaltung und Applikation trennen

Sowohl Wissenschaft und Forschung als auch Industrie und Softwarehersteller werden in der Entwicklung der Datenbanktechnologie das Datenmanagement auf noch höhere Ebenen hochziehen, um die Datenhaltung selbst vom Anwendungsprogramm so weit wie möglich zu entfernen. Parallel dazu werden neue Hardware Technologien und Software-Techniken die Leistungsfähigkeit von Datenbank-Management-Systemen steigern.

Die Empfehlung im Jahre 1986 muß deshalb heißen, so früh wie möglich auf modernste Technologie zu setzen, um die immensen Investitionen, die in der Informationsverarbeitung getätigt werden, vor potentiellen Auswirkungen zu schützen. Jeder Tag, an dem diese Entscheidung früher getroffen wird, zahlt sich bar aus.

*Martin Forster ist Marketing-Manager bei der Cincom Systems GmbH & Co oHG, Frankfurt.