Viele Anwender machen die Erfahrung, daß ihre Excel-Lösungen von der Datenorganisation her an die Grenzen einer Tabellenkalkulation stoßen. Für solche "Upsizer" liegt es nahe, sich mit Hilfe von Datenmodellierungs-Assistenten, wie sie Access mitliefert, den notwendigen Umstieg auf eine relationale Datenhaltung zu erleichtern. Tatsächlich gaukeln sie ungeübten Benutzern vor, das erforderliche konzeptionelle Know-how für relationale Systeme sei dank der Assistenten verzichtbar.
Testen einer Demo-Datenbank
Nichts gegen Assistenten. Aber sie sind nur dann sinnvoll, wenn der Anwender seine Aufgabe mit ihnen schneller erledigen kann als ohne sie. Muß eine vom Assistenten produzierte Lösung noch individuell angepaßt werden, darf der für dieses Customizing erforderliche Zeitaufwand nicht höher liegen als die ursprüngliche Zeitersparnis. An relativ anspruchslosen Beispielen - die Beispieldateien finden Sie unter http://www.nsl.de - soll gezeigt werden, daß die Datenmodellierungs-Assistenten von Access 7.0 diesen Anforderungen nicht gerecht werden.
Während Datenbank-, Tabellen- und Datentyp-Assistent für den Entwurf einer kompletten Datenbank, einzelner Tabellen oder einzelner Felder gedacht sind, dient der Tabellenanalyse-Assistent der Normalisierung eines vorhandenen Tabellenbestandes. Einem CASE-Tool-gestützten Datenbankdesign können sie jedoch nicht das Wasser reichen.
Die drei erstgenannten Assistenten werden im folgenden daraufhin überprüft, ob sie die Access-Demodatenbank "Nordwind" "nachzubauen" helfen (siehe Abbildung 1). Beginnen wir mit dem mitgelieferten Datenbankassistenten, der 22 Datenbankvorlagen anbietet, elf davon laut Microsoft für geschäftliche Anwendungen. Da sich die Nordwind-Datenbank im Kern mit dem Bestell- und Beschaffungswesen befaßt, liegt es nahe, die Datenbankvor- lage "Bestellabwicklung" heranzuziehen. Der Datenbankassistent erzeugt eine Basislösung "CW-01.MDB".
Sechs der neun Nutzdatentabellen scheinen für das angestrebte Nordwind-Datenmodell geeignet: Kunden, Bestellungen, Bestelldetails, Artikel, Versandarten und Personal. Es fehlen Tabellen für die Lieferanten und Artikelkategorien.
Das Entfernen der überflüssigen Tabellen für Zahlungen, Zahlungsweisen und Firmeninformationen führt beim Öffnen von "CW-02.MDB" zu einem wenn auch nicht kritischen Laufzeitfehler, weil die Tabelle Firmeninformationen nicht mehr zur Verfügung steht, aus der die Daten für das automatisch geöffnete Formular Hauptübersicht gelesen werden.
Generell ist anzumerken, daß Abfragen, Formulare und Berichte als externe Sichten, die auf eliminierte Tabellen zugreifen, nunmehr funktionslos werden und schlimmstenfalls die Dialogführung lahmlegen.
Andere Informationen zum Personal, zu Artikeln und zu Versandarten sowie die Berichte sind wegen der gelöschten Tabellen überhaupt nicht mehr erreichbar. Fazit: Um die Funktionsfähigkeit der vom Datenbankassistenten automatisch miterzeugten Dialogführung zu erhalten, muß nach dem Entfernen überflüssiger Tabellen ein erheblicher Customizing-Aufwand betrieben werden.
Im nächsten Schritt soll die fehlende Tabelle "Lieferanten" mit dem Tabellenassistenten erstellt werden. Wir haben insofern Glück, als sich unter den 25 geschäftlichen Beispieltabellen auch eine Lieferantentabelle befindet (CW-03.MDB). Normalerweise dürfte der Tabellenassistent nur in Ausnahmefällen genau die zu der gewünschten Entität passende Tabellenvorlage bereithalten. Da fehlende Felder ohnehin ebenso wie die Regeln der referentiellen Integrität (RI) für hinzukommende Beziehungen manuell nachzutragen sind, erweist sich der Tabellenassistent als nur sehr begrenzt nützlich.
Referentielle Integrität
Stellt der Tabellenassistent keine geeignete Vorlage bereit, was eher die Regel als die Ausnahme sein dürfte, bleibt noch der Datenblattassistent, der ein leeres Datenblatt öffnet, in das der Entwickler direkt Daten eingeben kann (CW-04.MDB). Seine Leistungsfähigkeit reduziert sich auf die automatische Auswahl eines Datentyps mit begrenzter Intelligenz. Wenn wir für die Kategorienummer fortlaufende Zahlen von 1 bis 8 eingeben, kommt der Assistent nicht auf die Idee, daß es sich hier um den Datentyp "Autowert" handeln könnte. Fazit: Der Datenblattassistent leistet nicht mehr, als aus den vom Anwender eingegebenen Beispieldaten die Felddatentypen Text, ganze Zahlen, gebrochene Zahlen, Währung, Datum/Zeit und Ja/Nein herauszulesen. Da die Unterscheidung dieser Datentypen selbst den unbedarftesten Anwender nicht überfordern dürfte, kann der Datenblattassistent als schlicht und einfach überflüssig bezeichnet werden.
Geradezu abenteuerlich ist, was der Datenbankassistent an Beziehungen und referentiellen Integritätsregeln produziert (CW-05.MDB). Dort, wo er die Beziehungen mit referentieller Integrität belegt, greift er gleich wagemutig zur Aktualisierungs- und Löschweitergabe (siehe Abbildung 1). Wegen der mehrstufigen Löschweitergabe von der Kundentabelle auf die Bestellungstabelle und von dieser wiederum auf die Bestelldetailtabelle zieht das automatische Löschen von Kundendatensätzen gravierende Datenverluste in den beiden anderen Tabellen nach sich. Es geht hier nicht um die Frage, ob in der Nordwind-Datenbank eine Löschweitergabe von der Tabelle "Bestellungen" auf die Tabelle "Bestelldetails" sinnvoller wäre, sondern ausschließlich darum, mit welcher Regel der refentiellen Integrität ein Entwickler zunächst auf der "sicheren Seite" ist. Unter diesem Gesichtspunkt spricht viel dafür, daß der Datenbankassistent Beziehungen mit referentieller Integrität und Aktualisierungsweitergabe, aber ohne Löschweitergabe erstellen sollte.
Auf merkwürdige Weise definiert der Datenbankassistent von Access auch die Beziehungen zwischen den Tabellen Personal und Versandfirmen einerseits und der Tabelle Bestellungen andererseits: Er vertauscht nicht nur die Master- und Detailseite, sondern entscheidet sich statt für Gleichheits- für Inklusionsverknüpfungen - diese zudem noch in der falschen Richtung und ohne referentielle Integrität. Das hat Folgen: Es kann zu Bestellungen kommen, die von nicht vorhandenen Mitarbeitern bearbeitet und von nicht vorhandenen Spediteuren ausgeliefert werden. Um diesen offensichtlichen Unfug zu verhindern, richtet der Datenbankassistent die Fremdschlüsselfelder in der Bestellungstabelle als Nachschlagefelder mit Listenfeldbeschränkungen ein. Diese Lösung läßt sich wohl zurecht als "von hinten durch die Brust ins Auge geschossen" bezeichnen.
Fazit: Der Datenbankassistent produziert befremdliche Regeln für referentielle Integrität und Verknüpfungseigenschaften, die dringend der Nacharbeit bedürfen, was aber ohne relationales Know-how von Anwenderseite nicht zu bewerkstelligen ist.
"Der sogenannte Tabellenanalyse-Assistent ist ein Kind der Erkenntnis, daß viele Anwender mit dem Entwurf relationaler Datenbanken überfordert sind", erklärt die Fachzeitschrift "c't", "Er hilft flache Dateistrukturen zu normalisieren." Diese rosige Aussicht provoziert die Gegenprobe, ob der Tabellenanalyse-Assistent nicht vielleicht selbst mit dem Normalisieren überfordert ist. Wir wählen das einfache Beispiel einer fiktiven Autovermietung (siehe Abbildung 2).
Zwischen den Mietern (links) und den Mietwagen (rechts) besteht eine n-zu-m-Beziehung, deren Abbildung in einer einzigen Tabelle Redundanzen verursacht, die eine Quelle potientieller Datenanomalien bilden, was man durch Normalisieren vermeiden möchte. Bei dem Unterfangen, diesen Verstoß gegen die 1. Normalform (1NF) zu erkennen und durch Auslagerung einer der beiden Wiederholungsgruppen zu beseitigen, versagt der Tabellenanalyse-Assistent seinen Dienst. Wenn man ihm die Entscheidung überläßt - wofür er konzipiert ist -, überrascht er mit der Empfehlung, die Tabelle nicht aufzuteilen. Der Verweis des Assistenten auf die manuelle Aufteilbarkeit ist gut gemeint, dürfte aber jeden von der Normalformenlehre unbeleckten Anwender hoffnungslos überfordern.
Nach Auslagerung der Mieterattribute (Mieter-ID, Name, Branche) bleibt eine immer noch redundanzhaltige "Resttabelle" (Wagen-ID, Mieter-ID, Fahrzeugtyp, Baujahr, Versicherung, Mietsatz, Mietdauer) übrig. Da die Attribute Fahrzeugtyp, Baujahr, Versicherung und Mietsatz nur von der Wagen-ID und nicht vom gesamten, sondern nur von einem Teil des Primärschlüssels funktional abhängig sind, liegt hier ein Verstoß gegen die zweite Normalform (2NF) vor, der durch Auslagerung dieser Nichtschlüsselattribute in eine eigenständige Tabelle zu beheben ist. Auch bei diesem Normalisierungsschritt läßt der Tabellenanalyse-Assistent den Anwender mit der bekannten Meldung im Stich und zwingt ihn wiederum zur "Handarbeit".
Verstöße gegen die Normalform
Damit ist die Redundanzbeseitigung aber immer noch nicht beendet. In der neu entstandenen Tabelle (Wagen-ID, Fahrzeugtyp, Baujahr, Versicherung, Mietsatz) ist das Nichtschlüsselattribut Mietsatz durch das Nichtschlüsselattribut Fahrzeugtyp determiniert, so daß nun gegen die dritte Normalform (3NF) verstoßen wird. Wenn es sich hierbei nicht um eine Zufälligkeit der wenigen, vorhandenen Ist-Daten handelt, sondern die Preispolitik die Geschäftregel des betroffenen Unternehnemens korrekt widerspiegelt, dann muß eine neue Tabelle (Fahrzeugtyp, Mietsatz) gebildet werden. Aber auch zu einer Empfehlung für die 3NF-Tabellenaufteilung mag sich der Assistent nicht aufraffen.
Fazit: Der Tabellenanalyse-Assistent ist mit der automatischen Erkennung von Verstößen gegen eine der drei üblicherweise einzuhaltenden Normalformen in den genannten Fällen hoffnungslos überfordert. Für eine manuelle Normalisierung mag er als technisches Hilfsmittel fungieren, zumal die hierfür notwendigen Auswahl- und Aktionsabfragen dank des vorbildlich einfachen grafischen Abfrage-Editors von Ac- cess leicht zu erstellen sind. Die Kenntnis der Normalformenlehre kann der Assistent aber in keinem Fall ersetzen.
Eine Alternative
Während uns der Tabellenanalyse-Assistent bei der Normalisierung bisher komplett im Stich gelassen hat, wären wir bei der Formulierung eines Entity-Relationship-Modells (ERM) fast automatisch - sozusagen aus der Logik der Sache selbst - zumindest bei der zweiten Normalform angelangt. Die Daten in Abbildung 2 legen nämlich folgende Erkenntnisse nahe: Es gibt einen Entitätstyp Mieter, der über die assoziative Entität Vermietung in einer n-zu-m-Beziehung zum Entitätstyp Mietwagen steht. Zieht man noch die hier unterstellte Abhängigkeit des Mietpreises vom Fahrzeugtyp in Betracht, dann kommt man sehr schnell zum Entity-Relationship-Modell der Abbildung 4, das exakt die vier Tabellen widerspiegelt, die in einem relationalen Datenbanksystem wie Access zu implementieren wären.
Daraus läßt sich also schließen, daß man den Aufwand für die Verwendung der Datenmodellierungs-Assistenten angesichts der unbefriedigenden Ergebnisse besser in die Erstellung eines Entity-Relationship-Modells stecken sollten. Entsprechende Tools gibt es auch für Access. Diese Vorgehensweise bietet gegenüber den Datenmodellierungs-Assistenten erhebliche Vorteile:
-Das semantisch am Fachkonzept und der Endbenutzerterminologie orientierte ERM ist für die Kommunikation mit den prospektiven Anwendern besser geeignet als das Access-Beziehungsfenster.
-Alle Spezifikationen des logischen und physikalischen Datenmodells werden zentral und leicht zugänglich verwaltet.
-Die Dokumentation ist mit CASE-basierten Reports flexibler gestaltbar und weiterverwendbar als mit dem Access-Datenbankdokumentierer.
-Ein Wechsel der Datenhaltung von der Jet-Engine zu einem der gängigen SQL-Server ist mit Hilfe von sogenanntem foreward engineering in kontrollierter Weise möglich.
-Last, but not least: Der Einsatz eines Datenmodellierungswerkzeugs nötigt dazu, vor dem (Quick-and-dirty)-Entwurf von Tabellen in Access zunächst einmal gründlich über das Datenmodell als eine der wichtigsten Säulen einer datenbankgestützten Applikation nachzudenken.
*Manfred Sommer ist Professor für Wirtschaftsinformatik an der Hochschule für Wirtschaft und Politik in Hamburg und Mitgesellschafter des Microsoft Solution Providers NSL GmbH, Bielefeld.