Vorgehen bei der Erstellung von (Access-) Datenbanken

Geschrieben von Olaf am 2011-11-20

Wie geht man beim Erstellen einer (Access-) Datenbank vor? Diese Frage stellt sich in Anbetracht der Komplexität von Access bzw. dem Thema. Die Erfahrung hat gezeigt, dass ein einfaches Schema die Erstellung der (ersten) eigenen Datenbanken sehr erleichtern kann. Dieses Schema ist in der Grafik Abbildung 1: 10 Punkte Plan dargestellt. Das kleine Mindmap ist im Uhrzeigersinn zu lesen, beginnend bei Punkt 1: Was will ich?

Abbildung 1: 10 Punkte Plan

Noch wenige allgemeine - aber wichtige - Hinweise:

• Fehlermeldungen sollten unbedingt gelesen werden! Access gibt hier gute Hinweise auf Probleme, Gefahren und Fehler. Nutzen Sie die Access Hilfe, um sich näher über die Aussage der Fehlermeldungen zu informieren.

• Datenbanken haben nur eine sehr eingeschränkte Möglichkeit, Aktionen rückgängig zu machen. Ist ein Datensatz eingegeben oder verändert worden und wurde verlassen, so ist dieser Vorgang nicht mehr mit STRG-Z rückgängig zu machen! Gleiches gilt für das Löschen von Datensätzen: Ein gelöschter Datensatz kann nicht wieder hergestellt werden!

1. Was will ich?

Hier wird zunächst möglichst genau beschrieben welche Ziele die Datenbank erfüllen soll. Warum wird diese Datenbank erstellt, welchen Zweck soll sie verfolgen, welche Daten sollen gespeichert und welche Auswertungen damit erstellt werden.

Diese und die folgenden Überlegungen sollten zweckmäßigerweise auf einem Blatt Papier stattfinden - nicht am PC. Der (unschlagbare) Vorteil zu diesem Entwicklungszeitpunkt ist, dass ein Papier sehr einfach zu "bedienen" ist: Erweiterungen und Hinzufügungen sind schnell gemacht, ebenso wie Änderungen oder Löschungen (am besten Bleistift und Radiergummi verwenden). Kurz gesagt: Rechts der Mitte wird nur mit Papier und Bleistift, erst links wird am PC gearbeitet!

2. Welche Daten

Zum Beispiel durch ein Brainstorming, durch Befragung derjenigen, die später mit der Datenbank direkt arbeiten sollen bzw. derjenigen die die Datenbank in Auftrag gegeben haben werden die benötigten Daten unstrukturiert zusammengetragen. Personen die Erfahrung im Datenbankdesign haben sind hierbei hilfreich, aber auch Mitarbeiter, Vorgesetzte und Untergebene. Je mehr Personen am Brainstorming beteiligt sind, desto vollständiger wird die Sammlung der benötigten Daten und desto weniger (wichtige) werden übersehen.

3. Daten gruppieren

Die in 2. gesammelten Daten werden nun logisch gruppiert. Alle Daten die beispielsweise einen Kunden direkt betreffen gehören in die Gruppe "Kunden". Das könnte der Kundennachname, der Vorname, eine Kundennummer, Telefon und Kommunikationsdaten sein. Die Adresse der Kunden sollte schon in Schritt 2 atomisiert worden sein, d. h. nicht "Adresse" sondern "Straße", "Postleitzahl" und "Ort" werden jeweils einzeln erfasst.

Um den Gedanken der Normalisierung zu verfolgen, sollte immer berücksichtigt werden, wovon ein Kunde (hier im Beispiel) nur eine beschränkte Anzahl haben kann (z. B. Kundenummer, Vorname, Nachname) oder wovon jeder Kunde mehrere Einheiten besitzen kann. Als Beispiel sind die Kommunikationsdaten zu nennen. Jeder Kunde könnte mehrere Telefonnummern besitzen. Schon zu diesem Zeitpunkt ist es wichtig zu beachten ob in einem solchen Fall generell erlaubt sein soll, dass ein Kunde beliebig viele (n) oder nur eine bestimmte Anzahl (z. B. 2) besitzen darf. Wird zu diesem Zeitpunkt festgelegt, dass ein Kunde nur 2 Telefonnummern besitzen darf können hierfür neben dem Feld "Vorname" auch die Felder "Telefonnummer_1" und "Telefonnummer_2" angelegt werden.

Weitere logische Gruppen könnten "Bestellungen" oder "Lieferanten" sein.

4. Datentypen

Dies ist der letzte Schritt der komplett ohne PC durchgeführt wird! Lassen Sie sich nicht verführen und überspringen Sie einen Schritt oder setzen schon zu früh einen PC ein. Letztendlich ist dieses Vorgehen viel Zeitaufwendiger als zunächst auf Papier zu arbeiten¹.

Die bisherigen Ergebnisse werden weiter konkretisiert:

• Welche Inhalte hält das Feld "Vorname" später? Zahlen? Buchstaben? Wie viele Buchstaben?

• Wie verhält es sich um das Feld "Bemerkung"? Wie viele Buchstaben werden dort erfasst? 50, 200 oder mehr als 250?

• Werden im Feld "Postleitzahl" nur Zahlen gespeichert? Welche Folgen hat es, wenn ein Feld nur Zahlen speichert? Sollte der Datentyp trotz (deutscher) Postleitzahlen nicht doch Text sein?

Dies sollen nur einige Bespiele sein. Wie bei keinem anderen Punkt aus dem 10 Punkte Plan (S. 1) ist eine allgemein gültige Aussage möglich. Die Aufgabe des Datenbankentwicklers ist es, jedes der zuvor als notwendig erfassten Felder nun mit einem zutreffenden Datentypen zu belegen.

Nun ist ebenfalls ein guter Zeitpunkt Felder festzulegen, die die einen Datensatz einer Gruppe eindeutig identifizieren können. Dies sind Primärschlüssel. In jeder Gruppe sollte es einen Primärschlüssel geben. Als sinnvoll hat sich herausgestellt, ein extra Feld hierfür zu Hilfe zu nehmen und dem Datenbankprogramm dessen Verwaltung zu überlassen. Dieses Feld könnte z. B. "ID", "Kunden_ID" oder "ID_Kunden" heißen. Die beiden letzten Vorschläge machen ein späteres identifizieren der zugehörigen Gruppe einfacher.

Neben Überlegungen zum Primärschlüssel können Gedanken zu Indizes angestellt werden: Welche Daten(kombination) darf z. B. nur 1x in einer Gruppe vorkommen? Beispiel: In einer Bestellung kann jedes Produkt nur 1x aufgeführt sein. Wenn ein Kunde das Produkt 2x bestellt, ist die Bestellte Menge mit 2 angegeben, das Produkt selbst ist jedoch nur 1x aufgeführt.

5. Tabellen erstellen

Jetzt erst wird der PC zu Hilfe genommen! Alle bisherigen Arbeiten zielten darauf ab, die Erstellung der Tabellen am PC, im Datenbankprogramm zu erleichtern. Die bisherigen Arbeitsergebnisse werden nun in den PC übertragen - ganz einfach umgesetzt. Aus jeder bisherigen Gruppe von Daten wird nun eine Tabelle. So beispielsweise die Tabelle "Kunden". Primärschlüssel und Indizes sollten nun auch im PC erfasst bzw. übertragen werden.

6. Beziehungen

Um die einwandfreie Funktion der Datenbank später sicherzustellen, um Nachschlage- bzw. Kombinationsfelder möglichst sinnvoll einzusetzen, um Formulare, Unterformulare (UFOs) und Berichte erstellen zu können, müssen die Daten aus unterschiedlichen Gruppen - nun Tabellen - zusammengestellt werden.

Beziehungen stellen eine Verbindung zwischen unterschiedlichen Tabellen einer relationalen Datenbank dar. Ein Kunde der Tabelle Kunden kann einen oder mehrere Einträge in der Tabelle Bestellungen haben. Damit eine Bestellung jedoch einem Kunden zugeordnet werden kann, muss eine Beziehung zwischen beiden bestehen. Dies lässt sich z. B. durch ein extra Feld in der Tabelle Bestellungen bewerkstelligen in dem die ID_Kunden (d. h. der Primärschlüssel) des bestellenden Kunden gespeichert ist. Eine Beziehung besteht also zwischen dem Feld ID_Kunden der Tabelle Kunden und dem Feld ID_Kunden der Tabelle Bestellungen².

7. Formulare

Benutzereingaben sollten immer über Formulare und niemals direkt in Tabellen stattfinden! Formulare bieten verschiedene Eingabevereinfachungen und können gleichzeitig den Inhalt mehrerer Tabellen darstellen. Außerdem lassen sich Sicherheitsfunktionen und Programmcode integrieren.

Formulare dienen prinzipiell der Eingabe von Daten. Vorhandene Daten können über Formulare geändert oder auch gelöscht werden. Sortieren und Filtern ist ebenfalls möglich und natürlich lassen sich Formulare auch drucken. Die Ausgabe auf Papier sollte jedoch durch Berichte stattfinden.

Zu den Eingabeerleichterungen von Formularen gehören Nachschlagefelder (auch Kombinationsfelder genannt), Buttons (Knöpfe) die beim Klicken eine bestimmte Aktion auslösen, Listenfelder, Farben

Automatisch vergebene Primärschlüssel sollten dem Benutzer nie gezeigt werden!

8. Berichte

Berichte dienen der Ausgabe von Daten. Berichte können sowohl am Bildschirm angezeigt (Druckvorschau) oder ausgedruckt werden. Oft bietet es sich an, eine Druckvorschau zu zeigen bevor ein Dokument gedruckt wird. Der Benutzer möchte evtl. ein anderes Ausgabemedium, einen anderen Drucker (vielleicht einen PDF-Drucker) wählen. Wird ein Bericht direkt gedruckt, so geschieht dies über den Standarddrucker.

Berichte können die Daten von Tabellen oder Abfragen zeigen. Berichte können Unterberichte enthalten - z. B. Kundendaten (ein Kunde im Hauptformular) und alle seine bisherigen Bestellungen (im Unterformular). Durch die Möglichkeit der Gruppierung eines Berichts nach verschiedenen Kriterien ist eine Nutzung von Unterberichten oft nicht notwendig.

Werden die einem Bericht zu Grunde liegenden Daten durch eine Abfrage geliefert, ist eine Sortierung in der Abfrage nicht notwendig. Die Sortierung sollte durch Gruppen im Bericht erzeugt werden - diese Lösung ist schneller.

Berichte können in Access nur (mit dem Assistenten) erstellt werden wenn ein Drucker im System installiert ist!

Abfragen

Dieser Teil hat absichtlich keine Nummer. Das Erstellen von Abfragen kann zu ganz unterschiedlichen Zeiten während der Erstellung einer Datenbank notwendig und oder sinnvoll sein.

Abfragen können für als Datenquelle für Nachschlagefelder dienen. Wird ein Nachschlagefeld direkt in eine Tabelle eingefügt (sollte nicht sein), müssen sie dann erstellt werden wenn ein das Feld erstellt wird. Wird ein Nachschlagefeld in einem Formular verwendet, kann die zu grunde liegende Abfrage dann erstellt werden.

Manche Abfragen lassen sich erstellen bevor Beziehungen festgelegt wurden, bei anderen Abfragen ist dies nicht möglich: Immer dann, wenn Daten aus mehr als einer Tabelle verwendet werden müssen Beziehungen zwischen diesen bestehen um sinnvolle Ergebnisse zu erhalten.

Abfragen können auch als Datenquelle für Formulare und Bericht Verwendung finden. Wenn sie als Quellen für Berichte dienen, ist zu beachten, dass die Daten von der Abfrage gesammelt werden, die später auch angezeigt werden sollen. Soll der Name eines Kunden, der eine Bestellung aufgegeben hat gezeigt werden, darf nicht nur dessen ID von der Abfrage erfasst werden. Die Felder Vorname und Nachname sind ebenfalls notwendig.

Selbst wenn alle Tabellen, Formulare und Berichte fertig erstellt sind, ist manchmal die Erstellung von Abfragen noch immer sinnvoll. Eine einfache Auswertung, die kein Ausdrucken erfordert (und ein Bericht somit zu viel Aufwand darstellen würde).

Tests

Dieser Teil trägt ebenfalls keine Nummer. Tests sind zu jeder Zeit des Datenbankdesigns, der Datenbankentwicklung notwendig. Nach dem erstellen der Tabellen, Abfragen, Formulare und Berichte. Hierbei sind zwei unterschiedliche Tests zu unterscheiden:

Tests mit Testdaten: Hierbei werden nur wenige Datensätze in die einzelnen Tabellen eingefügt. Nur so ist es oft möglich die Richtigkeit von Abfragen und Berichten zu kontrollieren.

Tests im Realbetrieb: Eine Datenbank wird in den wenigsten Füllen (eher nie) direkt nach dem Entwurf 100%tig funktionieren. Je komplexer die Datenbank, desto mehr Fehler werden darin auftreten. Auch ein Testen mit Testdaten hilft wird kaum alle solche Fehler beseitigen. Der Einsatz der Datenbank im Realbetrieb ist notwendig. So können die tatsächlichen Nutzer Probleme entdecken und die Datenbank kann nach und nach verbessert werden (z. B. der Einbau von benutzerdefinierten Fehlermeldungen).

Comments: