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ö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 VII, Teil 1:
Der Mythos der dritten Normalform
Da eine Datenbank - anders als die bisher üblichen Dateien - alle Anwendungen gleichermaßen mit Daten versorgen soll, muß sie entsprechend anwendungsneutral konzipiert werden. Dieser Sachverhalt ist sicher einleuchtend, doch bei seiner Umsetzung in die Praxis hapert es oft.
Einige Probleme, die immer wieder auftauchen, sind:
- Man verliert durch die Vielzahl von Datenelementen und Anwendungen leicht den Überblick; dadurch fällt eine systematische Analyse der Daten schwer.
-Durch die existierenden Dateien glaubt man die Datenstruktur schon zu kennen und verzichtet auf eine systematische Analyse.
-Im Hinblick auf das inzusetzende DBMS hat man schon bestimmte technische Lösungen im Auge und entwickelt - die Datenorganisation auf das DBMS hin.
-Man besitzt keine Methodik und keine Werkzeugen für das Daten-Design, so daß man mehr intuitiv vor sich hinarbeitet.
Dies sind einige der Ursachen, weswegen Datenbanken manchmal schneller einer Umstrukturierung unterzogen werden müssen, als man gehofft hatte. Und das kann viel Arbeit bedeuten, denn nicht jeder DBMS ist in dieser Hinsicht flexibel
Lassen Sie noch nicht ins Bockshorn jagen !
Will man nun seine Datenbank mit mehr Systematik - und damit längerfristig stabil - entwerfen, so muß man sich mit dem Thema "Datenbank-Design" etwas näher befassen; zum Beispiel durch Fachartikel oder Vorträge. Doch sofort wird man mit einer Vielzahl neuer Begriffe konfrontiert: Entity, Relation, Erste/Zweite/Dritte Normalform, Conceptual Design, Kanonische Datenstrukturen und so weiter. Manchen Autoren genügen auch drei Normalformen noch nicht und erfinden weitere.
Da wird mancher den Kopf schütteln und fragen: "Ist das denn wirklich so kompliziert? Oder wird hier vieles nur akademisch verbrämt?"
Bei näherem Hinsehen wird man feststellen, daß die ganze Angelegenheit gar nicht so kompliziert und der Sachverhalt, um den es geht, recht einleuchtend ist. Unser Problem in der DV ist allerdings, daß wir immer neue Begriffe prägen; zum Teil auch nur, um uns von anderen abzuheben.
Normalisierung - eine ganz normale Sache
Wer sich schon länger mit Datenbankanwendungen befaßt hat, stellt bei den Normalisierungsregeln von Codd fest, daß sie im Prinzip nichts Neues darstellen. Es war schon immer eine Design-Technik, Daten in die DNF (= Dritte Normalform) zu überführen. Nur wußten viele nicht, daß es die DNF war - sie handelten so aufgrund sachlicher Überlegungen. John Codd danken wir es, daß er Prinzipien dieser Überlegungen herausgearbeitet und als Regel formuliert hat.
Zwar klingen die Definitionen, wann sich Dateien in welcher Normalform befinden, recht kompliziert und akademisch. Doch erläutert und mit Beispielen untermauert, werden sie recht verständlich. Und mancher entdeckt, daß er eigentlich schon immer diese Überlegung bei der Datenorganisation angestellt hatte.
Dazu ein einfaches Beispiel:
Zur Überführung von Daten in die Dritte Normalform werden "Abhängigkeiten zwischen Nicht-Schlüsselattribute beseitigt, indem man daraus neue Relationen bildet." Was bedeutet das nun konkret?
Abbildung 1 zeigt einen (stark verkürzten) Seminar-Stammsatz mit dem Schlüssel bestehend aus Kursnummer (KNR) und Termin, sowie einige Felder. Der Satzaufbau ist schon weitgehend normalisiert: Jedes einzelne Feld eines Satzes steht in einfacher Abhängigkeit zum jeweiligen Schlüsselfeld; d.h. es gibt keine Wiederholfelder. Trotzdem gibt es zwischen den Feldern Ort und Teilnehmerzahl noch eine eigenständige Beziehung. Die Teilnehmerzahl ist nämlich an den Seminsrort gekoppelt, und sie ändern sich, falls der Ort geändert wird. Diese Felder stellen somit eine - wenn auch nur einfach vorkommende - Feldgruppe dar.
Um ihre gemeinsame Aktualisierung sicherzustellen, wird man sie zu einem eigenständigen Satztyp (= Relation machen und mittels eines Schlüssels die Verbindung herstellen: Dabei fällt zugleich mehrfaches Vorkommen eines gleichen Feldinhalts weg.
Diese Vorgehensweise ist sicherlich recht einleuchtend. Sie ist auch nicht DB-spezifisch, sondern findet bei der grundlegenden Datenorganisation statt, die noch unabhängig von der späteren physischen Speicherung ist. (Wird fortgesetzt)