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 Ausbildungs erfordernisse je nach Benutzerebene. 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 4:

Der Mythos der Dritten Normalform

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

Da ein solches konzeptionelles Modell aus der Analyse der Anwendungen entstanden ist, enthält es noch keine DB- spezifischen Besonderheiten. Deswegen läßt es sich im Prinzip auch mit jeder Dateiorganisation - sei es Datenbank oder sei es konventionelle Datei - abbilden. Allerdings müssen bei der Umsetzung in das jeweilige physische Modell mehr oder weniger viele Anpassungen an Möglichkeiten und Grenzen des DBMS beziehungsweise der Dateiorganisation erfolgen. Speziell die Auswirkungen auf das Zeitverhalten spielen bei der Abwägung von Lösungsalternativen beim physischen Modell eine Rolle.

Automatisches Datenbank- Design?

Bei der Betrachtung der Vorgehensweise des Datenbank- Designs - speziell der Konsolidierungsphase - entsteht die Frage, ob man einen solchen recht mechanischen Prozeß nicht automatisieren kann. Wozu haben wir schließlich unsere Computer?

Aber die Sache ist nicht ganz unproblematisch. Bis zur Analyse der Benutzersichten handelt es sich noch weitgehend um einen intellektuellen Prozeß. Die Ergebnisse dieses Prozesses müßten dann in eine formale Sprache umgesetzt werden, die verständlich, präzise und leicht handhabbar ist. Hierzu gibt es schon viele Versuche - ob sie aber den Anforderungen der täglichen Praxis standhalten, ist fraglich.

Bei der Konsolidierung der Benutzersichten muß sehr darauf geachtet werden, Datenelemente mit gleicher Bedeutung und verschiedenen Namen (Synonyme) und Datenelemente mit gleichen Namen aber verschiedener Bedeutung (Homonyme) zu erkennen. Ebenso müssen unterschiedliche Beziehungen zwischen Datenelementen unterschieden werden können (zum Beispiel gibt es zwischen Person und Auto die Beziehung "besitzt" und "fährt"). Diese Klippen können meist nur von Sachkundigen erkannt und umschifft werden.

Wieder leichter computerisierbar ist der Prozeß, aus der konsolidierten Gesamtsicht ein konzeptionelles Modell zu erstellen.

Es gibt schon seit Jahren Softwareprodukte zur Unterstützung des DB- Design. wie zum Beispiel der Data Base Design Aid (DBDA) von IBM. Allerdings scheinen die Erfahrungen mit diesem Produkt nicht ausreichend für eine intensive Verbreitung gewesen zu sein. In der Zwischenzeit wurden weitere Werkzeuge entwickelt. So zum Beispiel der Data- Designer von DMW und der Design- Manager von MSP. Ihr Einsatz in der Praxis wird zeigen, ob und in welchem Maße eine Automatisierung des Datenbank:- Entwurfes möglich wird.

Fazit

In diesem kurzen Beitrag ist keine umfassende Erläuterung des WIE eines Datenbank- Designs möglich, aber die Systematik des Vorgehens und dieangewandten prinzipiellen Arbeitsweisen konnten aufgezeigt werden. Damit soll ein Beitrag zur. "Entmythologisierung" dieser Thematik die voller unterschiedlicher Konzepte, Methoden und verwirrender Terminologie steckt, erbracht werden.

Zum, anderen ist sicher erkennbar geworden, daß die Einführung einer Datenbank viel Zeitaufwand in der Analyse- und Planungsphase mit sich bringt. Im Gegensatz zu bisherigen Dateien, die nur für das jeweilige Anwendungsgebiet konzipiert wurden, erfordert eine Datenbank die Schaffung einer gemeinsam nutzbaren Datenbasis. Dabei liegt die Hauptlast auf der organisatorischen Arbeit: Bereinigung der Daten- Landschaft, klare Definition der Bedeutung, Festlegen der Beziehungen zwischen den Daten und Dokumentieren der Verwendung. Auf dieser Basis ist die Entwicklung der geplanten - und zusätzlich späterer - Anwendungen leichter, weil sich die Programme nicht mehr um das Besorgen der Daten kümmern müssen, was bisher einen beachtlichen Teil der Programmlogik ausgemacht hat.

Die Arbeit verlagert sich also von der Realisierungsphase stärker auf die Planungsphase. Und Sie sollten diese notwendige Zeit bei ihrem ersten DB- Projekt unbedingt einkalkulieren, sonst holen Sie sich später den Ärger mehrfach!