Wie kann sich der Anwender vor leeren Verkaufsargumenten schützen:

Mangelnde MIPS lassen Traum von der Komfort-DB platzen

18.07.1980

Beim Einsatz von Datenbanksystemen für Kleincomputer sind vom Anwender einige organisatorische und technische Aspekte zu beachten, die bei Großcomputern nicht so sehr ins Gewicht fallen oder gar nur eine untergeordnete Rolle spielen. Zu den organisatorischen Aspekten zählen die Integrationstiefe der Anwendungen und die Absicht oder den Zwang, selbst zu programmieren oder Standardlösungen für bestimmte Aufgaben zu kaufen. Zu den technischen Aspekten, zählen die funktionale Vollständigkeit und der konstruktive Aufbau heutiger Datenbanksysteme.

Noch vor wenigen Jahren wurden Kleincomputer im kommerziellen Bereich ausschließlich zur Bearbeitung von Einzelaufgaben wie Auftragsannahme, Rechnungsschreibung oder Gehaltsabrechnung eingesetzt. Der technologische Wandel mit den- Konsequenzen billiger Hardwareelemente und der Verfügbarkeit von Bildschirmarbeitsplätzen führte zur direkten Verarbeitung anfallender Daten am Arbeitsplatz. Damit entstand der Wunsch der Benutzer von Kleincomputern - vor allem von Mehrplatzsystemen - zu den bisherigen Einzelaufgaben weitere Aufgaben hinzuzunehmen.

Da die Aufgaben miteinander über Informationsbeziehungen und Datenstrukturen zusammenhängen, wächst dieser Zusammenhang - die Integration - mit jeder Hinzunahme einer neuen Aufgabe. Die Komplexität einer integrierten EDV-Anwendung erhöht sich jedoch nicht linear, sondern exponentiell, wie das Schaubild zeigt.

Komplexere Anwendungen

Wie aus der Trenddatstellung ersichtlich ist, ist bei niedriger Integrationstiefe der Einsatz eines Datenbanksystems nicht notwendig und auch nicht immer von Vorteil (siehe auch Beitrag des Autors in CW Nr. 13 vom 28. 3. 80), bei hoher Integrationstiefe von Aufgaben jedoch unerläßlich.

Kauft ein Benutzer mit dem Kleincomputer gleichzeitig eine Standardlösung für sein Anwendungsproblem, so interessiert ihn letztlich nur das Preis-Leistungsverhältnis der Software und nicht die Lösungs- und Programmiermethode an sich. Ist er jedoch gezwungen, seine Anwendung selbst zu programmieren oder programmieren zu lassen, so ist bei Verwendung eines Datenbanksystems die Datenbanksprache und die Trägersprache von essentieller Bedeutung. Einher mit dieser Betrachtungsweise geht die Frage nach der Programmproduktivität .

Der Hohepriester der Datenverarbeitung, James Martin, hat unter Zugrundelegung der (geschätzten) Geschwindigkeit, die DV-Maschinen 1985 haben werden, sowie der voraussichtlichen Installationen eine kleine Rechnung aufgestellt, um die Anzahl der Millionen von Anweisungen, die 1985 per Sekunde zu programmieren sind zu ermitteln.

Wenn man annimmt, daß die Programmproduktivität sich nicht verändert, kann man fragen, wie viele Programmierer benötigt werden, um diese Anzahl an Programmen zu schaffen. Das Resultat ist rund 40 Millionen Programmierer in den USA. Strukturierte Programmierung wird die Programmproduktivität verdoppeln. Aber das hilft nicht viel - man braucht immer noch 20 Millionen Programmierer. Aus dieser kleinen Rechnung lassen sich zwei Alternativen ableiten: Es wird in wenigen Jahren keine Programmierer am Markt geben, die komplexe Anwendungen in Programme umsetzen können, oder aber eine entscheidende Produktivitätsverbesserung ist notwendig.

Diese entscheidende Produktivitätsverbesserung kann durch eine Datenbanksprache erreicht werden. Der Benutzer eines Kleincomputers, der seine integrierte komplexe Anwendung selbst realisieren will oder muß, muß daher sein besonderes Augenmerk auf die Datenbanksprache richten. Eine Abfragesprache allein genügt nicht.

Relational contra navigierend

Die Bezeichnung "Datenbanksprache" kennzeichnet einen Satz von Datenbankoperatoren, die in eine höhere Programmiersprache eingebettet sind. Diese höhere Programmiersprache wird auch als Trägersprache bezeichnet. Da in der kommerziellen DV Cobol, Basic und RPG am weitesten verbreitet sind, dienen diese Sprachen als Trägersprachen. Die Bezeichnung "Abfragesprache" bezieht sich gewöhnlich auf eine eigenständige, nichtprozedurale Sprache, mit der ein Benutzer direkt mit dem Datenbanksystem kommuniziert.

Die Formulierung einer Datenbanksprache ist abhängig von dem verwendeten Datenmodell. Im Bereich der externen Datenmodelle haben sich heute drei Datenmodelle zur Modellierung der Benutzersicht eingebürgert. Es sind dies das relationale und das hierarchische Datenmodell sowie das Netzwerkmodell, repräsentiert durch den Codasyl-Ansatz.

Beim Codasyl-Ansatz und beim hierarchischen Modell ist das klassifizierende Merkmal der zugehörigen Datenbanksprachen die Beschränkung auf die Manipulation eines Datensatzes pro Operation (one-record-at-a-time-interface). Relationale Operatoren manipulieren jedoch mehrere Datensätze gleichzeitig (multiple-record-at-a-time-interface or set relation operation level).

Unter dem Blickwinkel der Programmproduktivität ist eine relationale Datenbanksprache mit Mengen-(Relationen)-Niveau produktiver als eine navigierende Datenbanksprache mit Satz-bei-Satz-Zugriffsniveau.

Es genügt also nicht nur die Orientierung am relationalen Ansatz, so wie es etwa beim IBM System /38 geschehen ist, sondern es müssen auch die mächtigen relationalen Operatoren in der zugehörigen Datenbanksprache vorhanden sein, um die entscheidende Produktivitätsverbesserung zu erreichen.

Verklemmungen führen zu Dumps

Neben den organisatorischen Problemen wie Integrationstiefe, Komplexität einer EDV-Anwendung und Datenbanksprache sind bei Kleincomputern auch einige technische und konstruktive Aspekte von Datenbanksystemen zu beachten. Besonderes Augenmerk hat ein Käufer oder Benutzer von Datenbanksystemen auf die funktionale Vollständigkeit des Systems zu legen. Da gerade dieser Kreis von Benutzern nicht gleichzeitig mit der Beschaffung eines Datenbanksystems eine Expertenabteilung mit einkaufen oder aufbauen will, ist er im besonderen Maße vom korrekten Funktionieren des Systems abhängig.

Dies zeigt sich besonders deutlich im Fehlerfall oder bei Verklemmungen, wo es um den Erhalt und die Konsistenz des gesamten Datenbestandes geht. Zur Vollständigkeit eines Datenbanksystems gehören daher die Funktionen zur Sicherung des Datenbestandes, Wiederherstellung eines konsistenten Datenbestandes und Wiederanlauf. Fehlen solche Funktionen, so ist der Anwender mit den herkömmlichen und zeitaufwendigen Sicherungsmethoden wie File-Dumps und Hauptspeicherdumps auf sich alleine gestellt. Dies kann zu einem bösen Erwachen führen und dazu, daß die gesamte EDV-Planung samt Budget über den Haufen geworfen wird.

Sieht man sich auf dem Markt um so stellt man fest, daß kaum ein Hersteller oder Anbieter von Datenbanksystemen die Forderung nach funktionaler Vollständigkeit und automatischen Recoveryfunktionen erfüllt, auch wenn das jeder von sich behauptet. Wie kann sich ein Anwender vor solchen leeren Verkaufsargumenten schützen?

Transaction und Recovery

Unablässig für die Wahrung der Konsistenz einer Datenbank und für automatische Wiederherstellungsverfahren bei Mehrplatzsystemen ist der Transaktionsbegriff. Dieses Konzept ist jedoch nur dann als echt und nicht nur als Verkaufsargument zu werten, wenn es sich in der Datenbanksprache niederschlägt in Form von Operatoren wie Begin-of-Transaction und End-of-Transaction. Bei den Wiederherstellungsstrategien heißt das Stichwort dagegen Roll forward mit entsprechenden Operatoren.

Beim konstruktiven Aufbau von Datenbanksystemen schweigen sich selbst die Experten aus. Was ist nun darunter zu verstehen, und welche Konsequenzen hat der konstruktive Aufbau heutiger Datenbanksysteme für den Einsatz und das Leistungsverhalten von Systemen? Um die komplexen Sachverhalte verständlich zu machen, wird zunächst die Stellung von Datenbanksystem (DBS) gegenüber Benutzer, Programm und Betriebssystem betrachtet.

Dafür gibt es drei Möglichkeiten:

1. Das DBS ist ein integraler Bestandteil des Benutzerprogramms (durch Einbinden).

2. Das DBS ist ein unabhängiges System unter der Kontrolle des Betriebssystems.

3. Das DBS ist ein integraler Bestandteil des Betriebssystems.

Die erste Möglichkeit ist für ein System mit nur einem Benutzer anwendbar und bietet den Vorteil direkten Kontrollflusses zwischen Betriebssystem und Anwendungsprogramm beziehungsweise Datenbankverwaltungssystem. Für ein Mehrplatzsystem ist diese Möglichkeit jedoch nicht anwendbar.

Datenbank im Benutzerstatus

Die zweite Einordnungsmöglichkeit charakterisiert die heute üblicherweise bezogene Position. Von der Sicht des DBS aus besteht die Funktion des Betriebssystems lediglich aus einer Umschaltfunktion zwischen verschiedenen Subsystemen, wobei ein Subsystem in dieser Betrachtungsweise ein Textverarbeitungssystem, ein Teleprocessing-Monitor oder ein Spoolsystem sein kann.

Dieser monolithische Subsystemansatz ist im Bild 1 skizziert.

Die Konsequenzen sind aus diesem Bild fast direkt ablesbar. Das Betriebssystem behandelt die komplexe Instanz "Datenbanksystem" gleichwertig zu anderen Instanzen. Meist laufen die Routinen des Datenbanksystems dann noch im sogenannten Benutzerstatus ab, so daß alle Unterbrechungen zu einem Prozeßkontextwechsel führen. Bei diesem monolithischen Subsystemansatz muß ein Benutzerauftrag vollständig abgearbeitet werden, bis der nächste Benutzerauftrag bearbeitet werden kann. Damit führt diese Softwarearchitektur zu langen Wartezeiten und zu einem insgesamt schlechten Leistungsverhalten.

Konkurrente Programmierung

Der konstruktive Aufbau von heutigen DBS und die entstehende Softwarearchitektur ist zu vergleichen mit dem monolithischen Ansatz bei Betriebssystemen. Seit etwa zehn Jahren kennt man nämlich die konkurrente Betriebssystem-Programmierung mit der Aufteilung von Betriebssystemen in konkurrente Prozesse. Damit bietet sich als Gegenstück zum monolithischen Subsystemansatz die lntegration des DBS in das Betriebssystem an und damit auch die konkurrente Programmierung von Datenbanksystemen. Diese alternative Softwarearchitektur ist in Bild 2 veranschaulicht.

Sie führt zu einem insgesamt erheblich verbesserten Leistungsverhalten des Gesamtsystems.

Für den Anwender eines Datenbanksystems ist es - zusammenfassend - wichtig, die Integration seiner Aufgaben und die bestehende Organisationsform des Unternehmens zu prüfen. Erfordert die hohe Integrationstiefe oder die ständige Auskunftsbereitschaft eines Unternehmens den Einsatz eines Datenbanksystems, so stellt sich die Frage nach der Realisierung der EDV-Anwendung. Meist wird der Anwender heute feststellen, daß eine Standardlösung seiner EDV-Anwendung nicht existiert und so stürzt er sich in das Abenteuer der Programmentwicklung. Nur mit einer mächtigen Datenbanksprache ist hier eine echte Realisierungsmöglichkeit vorhanden.

Zur Vermeidung von bösen Überraschungen beim täglichen Routinebetrieb sind Funktionen zur Sicherung, Konsistenz und automatische Wiederanlaufverfahren unerläßlich. Diese Forderung nach funktionaler Vollständigkeit, eventuell in Verbindung mit einer mächtigen Datenbanksprache, führt zu äußerst komplexen Systemen. Die daraus resultierenden komplexen und umfangreichen Softwarepakete können keinesfalls zu den bestehenden Betriebssystemen der kleinen Systeme dazugepackt werden, so wie es bei Großsystemen aufgrund der hohen Leistungsfähigkeit - ausgedrückt in MIPS - gerade des Datenbestandes, Wahrung der noch vertretbar erscheint.

Aber außer diesen dazugepackten monolithischen Subsystemen ist auf dem Markt nichts zu finden. Was bleibt, ist die Anschaffung eines leistungsfähigen, genügend schnellen Rechensystems ab 500 000 Mark oder das Warten auf die nächste Generation integrierter Datenbanksysteme für Kleincomputer.

*Dr. Helmuth Seidel ist Mitarbeiter der Siemens AG.