"DB/DC-System ist inzwischen ein landläufiger Ausdruck, der einem leicht von der Zunge geht - so als wären "DB" und "DC" eine selbstverständliche Einheit. Doch dem ist nicht so! Ein Online-System (DC) und die Speicherung der Daten in einer Datenbank (DB) sind "zwei Paar Schuh". Entsprechend müssen auch die beiden dafür notwendigen Software-Produkte - der TP-Monitor und das DBMS - gesondert betrachtet werden. Für eine terminalgestützte Online-Verarbeitung ist ein TP-Monitor inzwischen eine selbstverständliche Voraussetzung. Für die Speicherung der Daten hingegen gibt es die Alternative zwischen konventionellen Datenbanksystemen. Wofür soll man sich entscheiden?

Ein DB/DC-System stellt eine Verbesserung der DV-Leistungen für ein Unternehmen dar. Die sofortige Online-Verarbeitung spart Zeit und Geld für Datenerlassung und -korrektur; sie beschleunigt die Abwicklung der Geschäftsvorfälle; sie verbessert die Informationsqualität und den Kundenservice - alles Dinge, die einem Unternehmen nützlich und gewinnbringend sein können.

Diesen Gewinn aber bringt in erster Linie der Einsatz von Terminals und damit die TP-Software. Welchen Anteil an diesem Nutzen hat eine Datenbank?

Einen direkten Nutzen von der Datenbank hat der Endbenutzer, für den die DV ja da ist, eigentlich nicht, wenn man von den wenigen Fällen absieht, wo seine Informationswünsche ohne DBMS einfach nicht zu verwirklichen wären.

Die Frage des Nutzens

Im Normalfall lassen sich die Anforderungen an die Datenhaltung auch mit konventionellen Methoden lösen. Eine Datenbank wäre dann nur das Werkzeug, mit dem dies einfacher, komfortabler oder änderungsfreundlicher zu bewerkstelligen ist. Der Nutzen eines DBMS liegt also primär in seinen Vorteilen für die EDV-Leute und nicht für die Endbenutzer. Lohnt sich dafür ein so teures Werkzeug?

"Has your DBMS saved money?" fragte Tom Gilb in der Computer Weekly vom 30. 11. 78 und legte damit den Finger in eine Wunde: die Frage der Wirtschaftlichkeit.

Was wir alle wissen, ist, daß die Einführung einer Datenbank eine Millioneninvestition ist, wovon die Software kosten nur einen Teil ausmachen. Was wir nicht wissen, ist, wo und in welcher Höhe wir diese Kosten wieder hereinholen. Weniger Eigenprogrammierung? Leichtere Änderungen? Bessere Überschaubarkeit der Anwendungen und Daten? Unabhängig davon, ob man die Wirtschaftlichkeit einer Datenbank wirklich ermitteln kann, gibt es eine Anzahl von Gründen, warum eine Datenbank zumindest sinnvoll sein kann:

- Mehr Komfort und Flexibilität bei der Datenhaltung speziell für den Informationsbedarf von Online-Anwendungen;

- Mangelnde Unterstützung von konventionellen Dateien durch den TP-Monitor;

- Konkurrierende Nutzung der gleichen Dateien im Online- und Batch-Betrieb.

Auf der anderen Seite gibt es aber auch Aspekte, die den Einsatz einer Datenbank in einer Online-Umgebung problematisch machen.

Die Frage der Performance

Antwortzeitverhalten ist das entscheidende Leistungskriterium für ein Online-System. Datenbanken haben vielfach die Eigenschaft, die Performance eines Online-Systems negativ zu beeinflussen. Das liegt an zwei Dingen:

- der "Batch-Vergangenheit" der meisten DBMS

- Verwendung bestimmter Datenbank-Techniken

Keineswegs haben alle DBMS die gleiche negative Auswirkung, sondern es hängt davon ab, inwieweit performanceverschlechternde Techniken im Konzept des DBMS stecken und wie ausgefeilt die Software ist.

Obwohl ein DBMS die Datenzugriffe vieler Anwendungsprogramme auf sich konzentriert, wirkt es oft noch als Flaschenhals, weil es die Anforderungen serialisiert. Erst langsam können die Software-Hersteller dieses Relikt aus Batch-Zeiten beseitigen und "multithreaded" Versionen ihres Produktes anbieten.

Aber auch dies ist kein Allheilmittel: je stärker eine Datenbank strukturiert ist, desto mehr Zugriffe sind mit einem Datenbankbefehl verbunden (zum Beispiel Einfügen) und desto wichtiger wäre eine Überlappung von Zugriffen (Multi-Threading). Doch durch die Konzentration der I/O's bei Transaktionsende wird wiederum dieser Effekt weitgehend zunichte gemacht.

Die Auswirkungen sind größer als gedacht

Von den Datenbanktechniken, die sich im Online-Betrieb ungünstig auswirken können, möchte ich drei herausgreifen:

- Sperrmaßnahmen gegen konkurrierendes Update

- Aufwand für Datensicherung

- Zeitbedarf zum Abarbeiten eines Zugriffspfades.

Es ist schon ein Unterschied, ob während der Zeitdauer einer Transaktion ein ganzer Datenbankbereich mit vielen tausend Sätzen oder nur einzelne Sätze nicht mehr zur Verfügung stehen. Auch die Verknüpfungen in der Datenbank können dafür sorgen, daß wegen eines Satzes gleich zehn, 20 oder 100 andere indirekt mitgesperrt werden.

Die Strukturierung einer Datenbank beeinflußt nicht nur die Anzahl der I/O's, die ein Datenbankbefehl verursacht, sondern wirkt gleichermaßen auf den Datensicherungsaufwand (Logging). Ist dazu noch das Konzept der Datensicherung mangelhafte dann . . .

Es ist in einem Online-System nicht gleichgültig, ob pro Transaktion ein, zehn oder 40 Logsätze geschrieben werden.

Lange Zugriffspfade, die durch die Verfolgung von Ketten oder durch tiefgestaffelte Hierarchien entstehen, wirken sich auf die Antwortzeiten des Online-Systems nicht gerade günstig aus. Datenbank-Techniken, die solche Zugriffspfade schaffen, sind für Batch-Datenbanken geeignet. Was macht man aber, wenn das eingesetzte DBMS keine anderen Methoden bieten kann?

DC stellt andere Anforderungen an DB

Auch aus diesen knappen Überlegungen daß ein DC-System einige Anforderungen an seinen Partner DB stellt. Diese müssen erfüllt werden, damit nicht der Nutzeffekt der Online-Verarbeitung gefährdet wird.

Die Anforderungen beziehen sich zum einen auf die softwaretechnische Realisierung des DBMS, zum anderen aber auf die angebotenen Datenbank-Techniken. Hierbei gewinnen solche Verfahren an Bedeutung, die die Zugriffsflexibilität erhöhen und die Datenbank "entstrukturieren" helfen, wie zum Beispiel Sekundärindizierung und investierte Dateien. Eine Datenbank für Online-Systeme bewegt sich zwangsläufig in relationale Richtung.