In thematisch zusammenhängenden Beiträgen beschäftigt sich Michael Bauer mit Fragen des Ob und Wie einer Datenbank-Implementierung, der Auswahl eines geeigneten TP-Monitors und der Ausbildungserfordernisse je nach Benutzerebene. Außerdem stehen Themen wie Data Dictionary, Dritte Normalform, neue Hochsprachen und Datensicherheit im Mittelpunkt seiner Erörterungen.

Kapitel 1, Teil 3:

Muß es denn gleich eine Datenbank sein

In den ersten Abschnitten dieses Beitrages wurde erläutert, inwieweit man hierarchische und vernetzte Datenstrukturen auch mit konventionellen Dateien abbilden kann. Dies ist besonders für Dialogverarbeitung wichtig.

Ersetzt ein TP-Monitor ein Datenbanksystem?

Wir hatten anfangs festgestellt, daß das Problem mit der Abbildung von Datenstrukturen erst durch die Dialogverarbeitung besonders hervorgetreten ist, weil hier wahlfreie, gezielte Zugriffe statt seriellen Durcharbeitens erforderlich sind.

Diese Dialogverarbeitung Schlagwort: "DC-Betrieb" findet aber unter der Steuerung eines TP-Monitors statt. Dadurch kann ein TP-Monitor für konventionelle Dateien Funktionen anbieten, die man sonst nur vom Datenbanksystem erhält:

- Mehrfachzugriff für viele Benutzer,

- Schutz gegen konkurrierendes Update

- Automatische Maßnahmen für Datensicherung/Restart

- Parallele E/A-Operationen

- Schutz gegen unberechtigte Benutzung.

Zwar deckt nicht jeder TP-Monitor dieses Funktionsspektrum vollständig ab,

doch ein komfortabler TP-Monitor wertet konventionelle Dateien auf. Zur Verdeutlichung, inwieweit konventionelle Dateien durch einen TP-Monitor verbessert werden, dient die Gegenüberstellung von VSAM und DL/1-DOS/VS im Online-Einsatz unter CICS/VS (Abbildung 4).

Wann braucht man überhaupt eine Datenbank?

Die bisherigen Überlegungen zeigen, daß man mit konventionellen Dateien auch heute noch gut leben kann. Voraussetzung sind eine komfortable Zugriffsmethode und ein ausgereifter TP-Monitor. Und da liegt auch der Hase im Pfeffer! Aus dem Leistungsmangel dieser Werkzeuge ergeben sich bereits die ersten Gründe, ein DBMS einzusetzen. Darüber hinaus gibt es aber noch weitere Anlässe, die eine Datenbank sinnvoll erscheinen lassen. Ich will hier acht wesentliche Argumente für eine Datenbank aufführen, die an dieser Stelle allerdings nicht so ausführlich wie in unseren Seminaren erläutert werden können:

1. Komplexe Datenstrukturen

Hierarchische Strukturen können mit konventionellen Zugriffsmethoden abgebildet werden. Netzstrukturen aber nur, wenn auch Sekundärindizierung unterstützt wird. Deswegen ist bei Netzstrukturen - insbesondere komplexen wie Stücklisten - ein DBMS empfehlenswert. Es bietet meist wirkungsvollere Verwaltungstechniken.

2. Vielfache Zugriffswege

Besonders bei der Dialogverarbeitung ist es erforderlich, auf die gleichen Daten mit unterschiedlichen Schlüsseln oder Suchargumenten zugreifen zu können (zum Beispiel mit Kundennummer, Name, Match-Code etc.). Ohne Sekundärindizierung bedeutet das bei konventionellen Dateien: Selbststricken.

3. Selektive Informationsbereitstellung

Die für Dialoganwendung benötigte gezielte Bereitstellung qualifizierter Informationen erfordert oft Suchoperationen mit verknüpften Suchargumenten (Boolesche Suchlogik).Mit seriellem Durchsuchen findet man zwar jedes Ergebnis - aber bei einem großen Datenbestand kann das Stunden dauern.

Relationale Datenbanksysteme wie zum Beispiel Adabas, Sesam, SQL\DS und

andere bieten mir ihrer Technik der invertierten Dateien hierfür geeignete, schnelle Verfahren. Wird fortgesetzt