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 Benutzerbene Außerdem stehen Themen wie Data Dictionary, Dritte Normalform, neue Hochsprachen und Datensicherheit im Mittelpunkt seiner Erörterungen.

*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.

Kapitel Vll, Teil 3:

Der Mythos der Dritten Normalform

Nachdem wir einen Überblick über die Vorgehensweise und die Phasen bei der Einführung einer Datenbank gewonnen haben, sollten wir den eigentlichen Designprozeß näher betrachten. Ausgangsbasis hierzu ist eine ordentliche Funktions- und Informationsanalyse. Was beinhaltet sie?

Da eine Datenbank die Daten entsprechend den unterschiedlichen Sichten der verschiedenen Anwendungen beziehungsweise Benutzer abbilden soll, müssen zunächst alle Benutzersichten ("user views") ermittelt werden. Um eine weitgehend stabile Datenstruktur zu gewinnen, müssen die Anwendungen möglichst vollständig betrachtet werden. So genügt es zum Beispiel nicht, die Verwendung von artikelbezogenen Daten nur aus der Sicht der Auftragsverwaltung zu analysieren, sondern es müssen ebenso die Anwendungsgebiete "Lagerverwaltung", "Bestellwesen" und "Fertigungsplanung" mit einbezogen werden.

Um die einzelnen Benutzersichten definieren zu können, müssen aber zunächst die Anwendungen detailliert analysiert werden. Dies geschieht üblicherweise im Rahmen einer schrittweisen Verfeinerung: Beginnend mit einer Grobübersicht werden die Anwendungen heruntergebrochen auf die Ebene von Elementarfunktionen (siehe Abbildung 3). Jede dieser Funktionen wird beschrieben mit

- Ergebnisdarstellung (Ausgabe),

- Datenherkunft (Eingabe)

- Prozeßbeschreibung (Verarbeitung)

und zum Beispiel als EVA-Diagramme (IPO-Diagramme) dargestellt. Informations- und Funktionsanalyse sind also zwei Vorgänge, die parallel ablaufen, und deren Ergebnisse sich wechselseitig beeinflussen.

Gleichermaßen im Top-Down-Verfahren erfolgt die Informationsanalyse. Hierbei korrespondieren die Ergebnisse der jeweiligen Entwurfsebene mit denen der Funktionsanalyse (siehe dazu Abbildung 3). In der Phase der Vorstudie wird eine Anwendung in Funktionen zergliedert und diese zum Beispiel in Form eines Funktionsdiagrammes dargestellt. Dabei werden auch die Informationsobjekte (zum Beispiel Kunden, Vertreter, Aufträge, Umsätze, Lieferorte etc ) festgestellt, mit denen man es zu tun hat. Beziehungen zwischen den Informationsobjekten "entities") werden analysiert und können in grafischer Form (zum Beispiel als "Entity-Relationship-Modell") dargestellt werden

Auf der Ebene der Elementarfunktionen ißt sich dann präzisieren, welche Datenelemente für die jeweilige Funktion benötigt werden. Die Beziehungen der Datenelemente untereinander werden festgestellt und können in grafischer Form (zum Beispiel als Blasendiagramme) visualisiert werden.

Eine solche Benutzersicht beinhaltet:

- alle benötigten Datenelemente,

- das Einstiegselement (Schlüssel oder Schlüsselkombination),

- Zugriffsart (direkt oder sequentiell),

- Beziehungen zwischen den Datenelementen (1:1 1:N und N:M).

Die Analyse der Datenstruktur auf Elementebene ist sicherlich eine Fleißarbeit, vor der sich manche scheuen. Aber es ist der sichere Weg, allen Informationsbedarf zu berücksichtigen. Selbst bei umfangreichen Anwendungen lassen sich auf dieser Basis in einem fast mechanischen Prozeß komplexe Datenstrukturen entwickeln und ihre Vollständigkeit prüfen.

Bottom-up-Vorgehen

Wenn alle Benutzersichten vorliegen, können sie zu einem Gesamtmodell konsolidiert werden (siehe Abbildung 3). Bei diesem Prozeß - von James Martin als. "kanonische Synthese" bezeichnet - werden die Beziehungen zwischen den Eintrittselementen der verschiedenen Benutzersichten definiert, redundante Datenelemente entfernt und die Beziehungen zwischen den Datenelementen überprüft.

Aus diesem Gesamtmodell auf Elementebene ist es dann einfach, die Datensätze und ihre Struktur abzuleiten:

- Jedes Eintrittselement ist Kandidat für den Schlüssel des zu bildenden Satzes.

- Alle Daten, die pro Schlüssel nur einmalig vorkommen (1:1-Verhältnis), werden Felder dieses Satzes; zum Beispiel Personalnummer und Nachname, Steuerklasse, Eintrittsdatum etc.

- Eintrittselemente, die miteinander im 1 :1-Verhältnis stehen, sind Kandidaten für Sekundärschlüssel; zum Beispiel Kundennummer und Kundenname.

- Daten, die pro Schlüssel mehrfach vorkommen ( 1 :N-Verhältnis), bilden einen eigenständigen untergeordneten Satz, wobei gegebenenfalls ein identifizierbares Kriterium geschaffen werden muß, zum Beispiel die monatlichen Gehaltsdaten eines Mitarbeiters.

In diesem hier knapp geschilderten Prozeß wird aus den einzelnen anwendungsbezogenen Datensichten eine Synthese erzeugt - nämlich eine konzeptionelle (oder logische) Datenstruktur.