Südsturm – die bessere Beispieldatenbank

Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.

Die Nordwind-Datenbank gehört zu Access wie die Milch zum Kaffee. Sie dient als Beispiel für diverse Techniken und ihre Tabellen sind Grundlage so mancher Beispieldatenbank in diesem Magazin. Doch immer blieb ein wenig Bauchweh: Tabellennamen ohne Präfix, Sonderzeichen in Feldnamen oder Leerzeichen in Objektnamen – ja, da gibt es einiges zu optimieren. Also baut Access im Unternehmen daraus eine neue Beispieldatenbank: Südsturm. Den Anfang machen wir in diesem Beitrag mit der Anpassung des Datenmodells.

Die Nordwind-Datenbank

Die Beispieldatenbank Nordwind wird seit vielen Versionen mit Access ausgeliefert. Wann immer auf die Schnelle keine Beispieldatenbank zur Verfügung steht, um etwas zu demonstrieren, muss die Nordwind-Datenbank herhalten. Und das, obwohl viele der enthaltenen Elemente gängigen Praktiken widersprechen. Beispiel gefällig

Da wären zunächst einmal die Objektnamen. Glaubt man den Beispieldatenbanken, die man im Internet findet, verwenden die meisten Entwickler eine, wenn auch nicht immer konsistente und einheitliche Notation.

Diese entspricht meist den Vorschlägen der so genannten Reddick VBA Naming Convention [1] und vergibt meist aus drei Buchstaben bestehende Präfixe an Datenbankobjekte und Variablen.

Die Objekte der Nordwind-Datenbank wie etwa Tabellen, Abfragen oder Formulare enthalten einen einfachen Namen ohne irgendwelche Zusätze.

Ein weiteres Beispiel sind die Feldnamen in den Tabellen: Es ist allgemein bekannt, dass man in VBA direkt auf Feld- und Objektnamen zugreifen kann, sofern diese keine Sonderzeichen enthalten, wobei hierzu auch Leer- oder Minuszeichen gehören:

strBezeichnung = rst!Bezeichnung

Viele Feldnamen enthalten allerdings Sonderzeichen, was dazu führt, dass man diese im Code in eckige Klammern setzen muss:

strBezeichnung = rst![Eigenwillige Bezeichnung]

Ebenfalls unschön ist die Verwendung eines aus fünf Buchstaben bestehenden Kunden-Codes als Primärschlüssel der Kunden-Tabelle. Das ist zwar nicht verboten, aber üblicherweise verwendet man einen Long-Wert als Primärschlüssel oder – soweit es die Umstände erfordern – GUIDs.

Damit ist die Aufgabe für diesen Beitrag umrissen:

• Tabellennamen anpassen,
• Feldnamen anpassen,
• String-Primärschlüssel durch Long-Werte ersetzen.

Warum der Aufwand

Eigentlich sollte man meinen, die Entwickler der Nordwind-Datenbank hätten sich etwas dabei gedacht, die Tabellen und Feldnamen sowie die weiteren Objekte so zu benennen. Haben sie vielleicht auch: Zum Beispiel sollen vielleicht vorrangig Einsteiger mit dieser Datenbank experimentieren, und die will man möglicherweise nicht direkt mit all dem kryptischen Zeug wie Präfixen oder Feldnamen ohne Sonderzeichen belasten.

Früher oder später wird der Entwickler aber durch Foren, Newsgroups und Beispiele aus dem Web sowieso gestählt, was diese Dinge angeht, also kann er sich auch direkt damit auseinandersetzen.

Aber warum sollen Objekte, Präfixe und Feldnamen keine Sonderzeichen enthalten, wenn man doch technisch damit zurechtkommen kann Ganz einfach: Wenn man jeder Objektart ein eigenes Präfix verpasst, weiß man etwa im VBA-Code auch, ob man sich bei der OpenRecordset-Methode auf eine Tabelle oder eine Abfrage bezieht.

Außerdem muss man, wenn man die abgekürzte Ausrufezeichen-Schreibweise verwenden will, keine eckigen Klammern einsetzen. Und wenn Sie dann noch auf Umlaute verzichten, gibt es – zumindest von Seiten der Feldnamen – keine Probleme, wenn mal eine Portierung auf ein anderes Datenbanksystem ansteht.

Eins nach dem anderen

Bevor Sie sich an die Arbeit machen, sollten Sie sich zunächst das Datenmodell im Beziehungsfenster ansehen und sich die geplanten änderungen vor Augen führen (siehe Bild 1). Es ist auch kein Fehler, sich den Inhalt des Beziehungsfensters auszudrucken und die geplanten änderungen mit einem Stift einzutragen.

Bild 1: Das ursprüngliche Datenmodell der Nordwind-Datenbank

Wie bereits erwähnt, sollte sich die Objektnamenautokorrektur (zu aktivieren im Optionen-Dialog (Extras/Optionen) auf der Seite Allgemein im Bereich Objektnamen-Autokorrektur) um die automatische änderung der Bezüge auf geänderte Objekt- und Feldnamen kümmern.

Den VBA-Code müssen Sie dann allerdings manuell anfassen: Daher unbedingt den Ausdruck des Beziehungsfensters aufbewahren, um die änderungen durch halbautomatisches Suchen und Ersetzen in den VBA-Code zu übertragen.

Bei Härtefällen, wie dem ändern des Primärschlüssels der Tabelle Kunden, sind einige Schritte mehr erforderlich: Immerhin verweist die Tabelle Bestellungen per Fremdschlüsselfeld auf den zu ändernden Primärschlüssel, und um die Anpassung der Werte in der Tabelle Bestellungen müssen Sie sich selbst kümmern – dafür schreiben Sie aber weiter unten eine kleine VBA-Prozedur.

Auch die Reihenfolge der Tabellenänderungen spielt eine wichtige Rolle: So beginnt man am besten mit den änderungen an Tabellen, auf die keine anderen Tabellen per Fremdschlüsselfeld verweisen.

Im Datenmodell der Nordwind-Datenbank bieten sich dazu die Tabellen, Lieferanten, Kategorien, Kunden, Personal und Versandfirmen an.

Um die Auswirkungen der änderungen auf die verknüpften Tabellen im Blick zu behalten, passen Sie jeweils nach dem Abschluss der änderungen an den oben genannten Tabellen die Fremdschlüsselfelder der verknüpften Tabellen an.

Berücksichtigen Sie dabei auch eventuell vorhandene Nachschlagefelder. Wenn Sie alle „außen“ liegenden Tabellen, also solche ohne eigene Fremdschlüsselfelder, angepasst haben, arbeiten Sie sich auf die gleiche Weise zu den „innen“ liegenden Tabellen vor. In den folgenden Abschnitten erfahren Sie, wie das im Detail geschieht.

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

Testzugang

eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel

diesen und alle anderen Artikel mit dem Jahresabo