Südsturm – die bessere Beispieldatenbank

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 (s. Abb. 1). Es ist auch kein Fehler, sich den Inhalt des Beziehungsfensters auszudrucken und die geplanten änderungen mit einem Stift einzutragen.

pic001.tif

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

Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!
Hier geht es zur Bestellung des Jahresabonnements des Magazins Access im Unternehmen:
Zur Bestellung ...
Danach greifen Sie sofort auf alle rund 1.000 Artikel unseres Angebots zu - auch auf diesen hier!
Oder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:

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.

Tabellennamen anpassen

Am einfachsten scheint die Anpassung der Tabellennamen (s. Kasten Benennung von Tabellen und Primärschlüsseln). Besonders leicht wird dies durch die Objektnamenautokorrektur, die zumindest in anderen Tabellen, Abfragen, Formular- und Berichtsfeldern alle Bezüge auf Objekte mit geänderten Namen aktualisiert.

Testen Sie das direkt einmal und ändern Sie den Namen der Tabelle Lieferanten in tblLieferanten. Und wenn Sie schon einmal dabei sind, benennen Sie auch direkt das Primärschlüsselfeld Lieferant-Nr in LieferantID um.

Die Funktionstüchtigkeit der Objektnamenautokorrektur können Sie anschließend im Entwurf der Tabelle Artikel prüfen: Das Feld Lieferanten-Nr dieser Tabelle dient als Fremdschlüsselfeld für die Verknüpfung mit der Lieferanten-Tabelle und ist gleichzeitig als Nachschlagefeld ausgelegt. Leider übernimmt Access die änderungen nur teilweise: Der Tabellenname wurde zwar angepasst, der Feldname aber leider nicht (s. Abb. 2).

pic002.tif

Abb. 2: Die Objektnamen-Autokorrektur ändert in der Tat nur Objekt-, aber keine Feldnamen.

Also helfen Sie per Hand nach und ändern die passende SELECT-Abfrage wie folgt:

SELECT LieferantID, Firma FROM tblLieferanten ORDER BY Firma;

Damit sind Sie gleichzeitig die lästigen eckigen Klammern los. Da die änderungen an der Tabelle tblLieferanten sowie ihre Auswirkungen auf die übrigen Tabellen abgeschlossen sind, führen Sie die passenden änderungen an den übrigen „außen“ liegenden Tabellen durch.

Lassen Sie nur die Tabelle Kunden außen vor – hier steht ja bekanntlich die Umwandlung des Primärschlüsselfeldes in einen anderen Datentyp an.

Interessanterweise wirkt sich die Objektnamen-Autokorrektur bei den Tabellen Kunden, Versandfirmen und Personal auch auf die Definition der jeweiligen Nachschlagefelder in der Tabelle Bestellungen aus. Dennoch sollte man dies jeweils manuell prüfen.

Datentyp des Primärschlüssels ändern

Der schwierigste Teil ist das überführen des Primärschlüssels der Tabelle Kunden in einen Long-Wert. Dazu gehen Sie folgendermaßen vor:

  1. Fügen Sie der Tabelle ein neues Feld namens KundeID hinzu und stellen Sie seinen Datentyp auf Autowert ein. Access füllt dieses Feld automatisch mit den passenden Zahlenwerten.
  2. Verschieben Sie die Primärschlüssel-Eigenschaft vom Feld Kunden-Code auf das neue Feld.
  3. Fügen Sie der Tabelle Bestellungen ein neues Feld namens KundeID hinzu.
  4. Und nun kommt der interessante Teil: Das neue Verknüpfungsfeld der Tabelle tblBestellungen namens KundeID soll mit den in der Tabelle tblKunden enthaltenen Daten gefüllt werden. Dies erledigt die Abfrage aus Abb. 3, deren Quellcode so aussieht:
    UPDATE tblKunden INNER JOIN tblBestellungen ON tblKunden.[Kunden-Code] = tblBestellungen.[Kunden-Code] SET tblBestellungen.KundeID = [tblKunden].[KundeID];
  5. Nach einer kurzen Prüfung, ob die Werte des aktualisierten Feldes stimmen, können Sie die Beziehung zwischen den Tabellen tblBestellungen und tblKunden entfernen und eine neue Beziehung über das neue Feld KundeID herstellen. Das geht am schnellsten mit dem Nachschlage-Assistenten. Vergessen Sie nicht, anschließend im Beziehungsfenster referentielle Integrität festzulegen. Apropos Beziehungsfenster: Dieses dürfte nach dem ändern sämtlicher Tabellennamen leer sein. Fügen Sie einfach alle Tabellen erneut hinzu.

pic003.tif

Abb. 3: Diese unscheinbare Abfrage aktualisiert das Feld KundeID für alle Datensätze der Tabelle tblBestellungen entsprechend dem Wert des passenden Feldes in der Tabelle tblKunden.

änderungen an Abfragen

Wie bereits bei den Tabellen erledigt die Objektnamen-Autokorrektur auch hier einen Großteil der Arbeit. In einem Fall kann sie jedoch nicht helfen: Das gelöschte und durch KundeID ersetzte Feld Kunden-Code müssen Sie in den Abfragen manuell oder durch eine entsprechende Routine ersetzen. Ein Beispiel dazu finden Sie im Modul mdlDatenmodellAnpassen in der Beispieldatenbank.

Zusammenfassung und Ausblick

Das Datenmodell der neuen Beispieldatenbank ist eine optimierte Fassung der alten Nordwind-Datenbank. Weitere Beiträge in den folgenden Ausgaben von Access im Unternehmen zeigen am Beispiel der neuen Südsturm-Datenbank die Grundlagen des Entwurfs von Tabellen, Abfragen, Formularen und Berichten. Die Formulare und Berichte lehnen sich dabei durchaus an der in der Nordwind-Datenbank enthaltenen Objekte an, sollen aber das Erstellen von Formularen und Berichten grundsätzlich erläutern.

pic004.tif

Abb. 4: Die überarbeitete Fassung des Datenmodells

Quellen

[1] RVBA Naming Conventions: http://www.xoc.net/standards/rvbanc.asp

Benennung von Tabellen und Primärschlüsseln

Welche Regeln man für die Bezeichnung von Tabellen und Primärschlüsselfeldern verwendet, bleibt natürlich jedem selbst überlassen. Allerdings haben sich folgende Regeln in der Praxis bewährt:

  • Tabellennamen bestehen aus dem Präfix tbl und der Mehrzahl der in der Tabelle gespeicherten Objekte, etwa tblArtikel, tblFahrzeuge oder tblBestellungen.
  • Primärschlüsselfelder tragen eine Bezeichnung, die aus der Einzahl der in der Tabelle enthaltenen Objekte und dem Suffix ID besteht. Beispiele: ArtikelID, FahrzeugID oder BestellungID.
  • Ein Sonderfall sind Verknüpfungstabellen in m:n-Beziehungen. Im einfachsten Fall bestehen diese aus dem Präfix tbl, der Mehrzahl der in der ersten Tabelle gespeicherten Objekte und der Mehrzahl der in der zweiten Tabelle gespeicherten Objekte (tblFahrzeugeAusstattungen). Der Name des Primärschlüsselfeldes setzt sich entsprechend aus dem Singular der passenden Objekte und dem Suffix ID zusammen (FahrzeugAusstattungID). Viele Verknüpfungstabellen enthalten gar keinen einzelnen, sondern einen aus den Fremdschlüsselfeldern zu den verknüpften Tabellen zusammengesetzten Primärschlüssel – dabei übernehmen die Fremdschlüsselfelder den Namen des Primärschlüsselfeldes der verknüpften Tabelle. In einigen Fällen gibt es auch eine bessere, weniger schematische Bezeichnung für Verknüpfungstabellen. In der Nordwind-Datenbank heißt so die Tabelle zur Verknüpfung von Bestellungen und Artikeln schlicht „Bestelldetails“.

Downloads zu diesem Beitrag

Enthaltene Beispieldateien:

S

Schreibe einen Kommentar