Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

Achtung: Dies ist nicht der vollständige Artikel, sondern nur ein paar Seiten davon. Wenn Sie hier nicht erfahren, was Sie wissen möchten, finden Sie am Ende Informationen darüber, wie Sie den ganzen Artikel lesen können.

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Gedrucktes Heft

Diesen Beitrag finden Sie in Ausgabe 6/2006.

Unser Angebot für Sie!

Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'!

Diesen Beitrag twittern

Zusammenfassung

Lernen Sie unsere neue Beispieldatenbank kennen und erfahren Sie, wie man Änderungen an bestehenden Datenmodellen durchführt.

Techniken

Tabellen, Datenmodellierung

Voraussetzungen

Access 97

Beispieldatei

Südsturm.mdb

Shortlink

411

Südsturm - die bessere Beispieldatenbank

André Minhorst, Duisburg

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

Sie haben das Ende des frei verfügbaren Teils des Artikels erreicht. Lesen Sie weiter, um zu erfahren, wie Sie den vollständigen Artikel lesen und auf viele hundert weitere Artikel zugreifen können.

Sind Sie Abonnent?Jetzt einloggen ...
 

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

© 2003-2015 André Minhorst Alle Rechte vorbehalten.