DB DC DD

30.07.1982

In thematisch zusammenhängenden Beiträgen beschäftigt sich Michael Bauer mit Fragen des Ob und Wie einer Datenbankimplementierung, 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örterung.

*Michael Bauer, Leiter des Bereichs DV - Beratung bei der GES - Gesellschaft für elektronische Systemforschung mbH in Allensbach, ist seit vielen Jahren mit der Anwendungspraxis von Datenbank - und Online - Systemen vertraut. Er ist Autor zahlreicher Fachbeiträge zur DB / DC - Thematik. Teil 2

Aufgrund der seriellen Verarbeitungscharakteristik der Stapelanwendungen brachte die Struktur der Daten - das heißt ihre logischen Beziehungen untereinander - wenig Probleme mit sich. Durch Sortierung und sequentielles Durcharbeiten lassen sich die Daten immer richtig zusammenmischen.

Bei der Dialogverarbeitung dagegen müssen die Daten für mehr Anwendungen gleichzeitig organisiert werden; das heißt anwendungsneutral und weitgehend redundanzfrei. Charakteristisch ist der wahlfreie, gezielte Zugriff. Jetzt spielt auch die Struktur der Daten eine größere Rolle.

Denn zwischen den verschiedenen Satzarten bestehen hierarchische oder vernetzte Beziehungen, die als Zugriffspfad in irgendeiner Weise auch technisch realisiert sein müssen. Wie kommt man beispielsweise von einem Kundensatz zu allen dazugehörigen Sätzen in der Auftragsdatei ohne serielles Durchsuchen?

Die logischen Beziehungen zwischen Daten lassen sich auf zwei Grundformen zurückführen:

- die hierarchische Struktur

- die vernetzte Struktur.

Betrachten wir deshalb kurz die Möglichkeiten konventioneller Dateien. Eine hierarchische Struktur wie sie das Beispiel in Abbildung 2 zeigt, kann man leicht mittels mehrerer Satzarten in einer ISAM - Datei abbilden. Bei geeigneter Schlüsselwahl lassen sich auch mehrstufige Hierarchien abbilden. Der Zugriff kann gezielt auf einen Satz oder in hierarchischer Ordnung erfolgen. Auch Ergänzungen neuer Satzarten tangieren nicht die bestehenden Programme wie bei einem Datenbanksystem!

Zur Speicherung hierarchisch - strukturierter Daten braucht man also kein DBMS. Wie sieht es aber bei vernetzten Datenstrukturen aus?

Bei Netzstrukturen wird es schwieriger, weil ein Satz über mehrere unterschiedliche Ordnungskriterien auffindbar sein muß. Abbildung drei zeigt dazu ein Beispiel:

Ein Teilnehmer muß sowohl dem Seminar, für das er angemeldet wurde, als auch seiner Firma zugeordnet werden können. Man kann das dadurch erreichen, daß zu der Teilnehmer - Datei je ein zusätzlicher Index mit dem Seminarcode und mit der Firmennummer angelegt wird (Sekundärindizierung).

Hier aber kommt das erste Problem: Nicht bei jedem Hersteller gibt es für die indexsequentielle Zugriffsmethode auch Sekundärindizierung. Deswegen hat Siemens kürzlich das Zusatzpzrodukt LEASY herausgebracht .

Das zweite Problem entsteht durch den permanenten Umweg über die Indexstruktur bei jedem Zugriff. Bei komplexen Netzstrukturen (zum Beispiel Stückliste) und vielen Zugriffen sind deshalb direkte Zeiger günstiger.

Das dritte Problem ist die Gefahr der Inkonsistenz der alternativen Indizes. Dies kann durch das Logging des TP - Monitors nicht in jedem Falle vermieden werden.

Man sieht: Auch vernetzte Datenstrukturen lassen sich mit komfortablen Zugriffsmethoden abbilden - aber es gibt Probleme.

Ist die verfügbare Zugriffsmethode aber weniger komfortabel und bietet keine Sekundärindizierung, könnte man sich natürlich eigene Verweisdateien anlegen und diese selbst verwalten. Doch: Finger weg von so etwas "Selbstgestricktem"! Dann sollten wir besser ein DBMS einsetzen.

Wird fortgesetzt

_AU:Michael Bauer*