Immer mehr Anwender betreiben heute die Ablösung ihrer herkömmlichen Datei-Organisationen durch ein zentrales Datenbank-System. Dabei hat sich die Euphorie Anfang der siebziger Jahre zu einer eher nüchternen Betrachtungsweise gewandelt, die auf der einen Seite zwar eine hohe Wertschätzung des Instrumentes "Datenbank" widerspiegelt, auf der anderen Seite aber auch Ausdruck eines in der Praxis gewachsenen Problem-Bewußtseins ist.

Sind Datenbank-Systeme werkzeugfeindlich? Man muß sich diese Frage wirklich stellen. Angesichts der breiten Palette an Software-Tools im Bereich herkömmlicher Einzel-Dateien ist zunächst die Feststellung zu treffen, daß beispielsweise für DL/1 kein auch nur annähernd so breites Angebot besteht. Angefangen von "Ditto" bis hin zu komplexen File-Management- und Retrieval-Systemen: Wenn es um seine Datenbank geht, entbehrt der Anwender meistens die gewohnte Unterstützung. Ausnahmen in Form von speziellen Datenbank-Schnittstellen einiger Auswertungssysteme mögen die Regel bestätigen, spezielle Datenbank-Tools sind. sie nicht - wollen es auch nicht sein.

Dieser Zustand mag sich teilweise aus der höheren Komplexität von hierarchischen und vernetzten Datenbanken erklären. Andererseits bedingt diese Komplexität einen erhöhten Bedarf an Software-gestützten Werkzeugen zur einfachen und schnellen Daten-Gewinnung, -Aufbereitung und -Erzeugung, aber auch zur -Veränderung, ganz besonders bei Datenbanken im Test-Stadium.

Es geht natürlich auch ohne Tool. Da fast alle Datenbank-Systeme über eine Call-Schnittstelle verfügen, kann man für jede Segment-Auflistung, für jede Feld-Änderung etc. ein Programm schreiben. Dies ist weniger ein technisches als ein Zeit- und Kosten-Problem.

Ausgehend von dem Meinungsbild vieler Anwender soll im folgenden versucht werden, einen Katalog von Leistungskriterien für ein Datenbank-Dienstprogramm (DB-Utility) zu erarbeiten:

- Ausführung aller Datenbank-Zugriffe: Lesen und Schreiben, direkt und sequentiell, dabei freie Auswahl von gesamten oder Teil-Datenbanken sowie Möglichkeit der Parallelverarbeitung mehrerer Datenbanken (bei DL/ 1: mehrerer PCBs) .

- Einfacher Formalismus: Ein Spezial-Utility sollte Bezug auf bereits vorhandenes Wissen sowie auf DV-übliche Sprach-Gewohnheiten nehmen, wie Befehle im Schlüsselwort-Format, Spaltenfreiheit der Parameter sowie Formulierung der DB-Zugriffe in einer dem DBMS analogen Form (bei DL/1: Verwendung von Function-Code und SSAs; bei CODASYL möglichst orginalgetreue Nachbildung der DML) .

- Segment-Aufbereitung: Der Ausdruck von Segmenten im Ditto-Format ist für ein Datenbank-Utility Voraussetzung, aber nicht ausreichend. Der Anwender sollte eine feldweise Daten-Aufbereitung, wahlweise mit Feld-Auswahl-Funktionen, erwarten.

- Daten-Eingabe: Die Eingabe von Datenfeldern beliebigen Formates und beliebiger Länge ist selbstverständlich; ein Zufallsgenerator zur Unterstützung bei der Erstellung von Test-Datenbanken sollte ebenfalls erwartet werden.

- Daten-Selektion: Das Absuchen von Segmenten (Scannen), aber auch das gezielte Aufsuchen von Daten an ganz bestimmter Segment-Position gilt als Standard-Funktion. Wertvoll ist dabei die Möglichkeit zur Angabe von kombinierten Selektions-Bedingungen.

- Datenschutz: Ein updatefähiges Datenbank-Utility kann zur "Bombe" werden, wenn es nicht über einen wirkungsvollen Kontroll-Mechanismus verfugt. Dazu gehört nicht nur ein personenbezogener Schutz (Password etc.), sondern auch die Möglichkeit, gezielt ganz bestimmte Datenbanken vom Zugriff auszuschließen oder nur für 'Read-Only'-Zugriffe zuzulassen.

- Online-Unterstützung: Datenbank-Systeme arbeiten immer häufiger in einer integrierten DB/DC-Umgebung. Deshalb verlangt der Anwender zu recht, daß sein Datenbank-Utility ebenfalls per Bildschirm einsetzbar ist.

Funktionen zur Unterstützung von Tuning-Maßnahmen, zur Simulation von Call-Folgen oder zum Ausdruck von Kontrollblöcken runden das Bild ab. Das Kriterium einer leichten Produkt-Modifikation an speziell dafür vorgesehenen Benutzer-Schnittstellen ist zwar für System-Software nicht typisch; jedoch sollte bei einem Produkt mit der Anwendungsbreite eines DB-Utilitys zumindest die Möglichkeit von User-Exits vorgesehen sein.

Die Praxis hat gezeigt, daß die aufgezählten Funktionen einen großen Teil dessen ausmachen, was im Rahmen von Datenbank-Projekten an täglicher Arbeit zu leisten ist. Es soll hier aber dennoch nicht der Eindruck entstehen, als ob durch den Einsatz eines Werkzeuges der oben beschriebenen Art alle Probleme einer Datenbank-Einführung beseitigt würden vor allem im Bereich der Projekt-Planung und des Datenbank-Designs werden weiterhin konzeptionelle und sehr benutzerspezifische Probleme zu lösen sein. Daß aber ein beträchtlicher Teil der Realisierung eines DB-Projektes Software-gestützt vereinfacht werden kann, dafür sprechen die Erfahrungen deutlich.

*Lutz Wagner ist bei der S.P.O. consult Beratungsgesellschaft mbH, Hamburg, zuständig für die Planung und Realisierung von DB/DC-Systemen. S.P.O vertreibt das Datenbank-Dienstprogramm "Dlimaster".