Eine Datenbank zu planen ist genauso eine Aufgabe, wie eine Software-Architektur aufzubauen. Diesen Planungsschritt nennt man Datenmodellierung. Hierbei legt man die benötigten Tabellen und die Spaltennamen fest. Im Gegensatz zur klassenbasierten Programmierung, muss man jedoch im Hinterkopf behalten, dass nicht zu erwarten ist, dass Tabellen üblicherweise im Speicher des Datenbankservers liegen, sondern Daten gerade bei großen Datenbeständen erst auf der Festplatte gesucht werden müssen. Entsprechend sollten die Tabellen hierfür optimiert werden.

Grundsätzlich gibt es zwei Verfahren, wie man die den Aufbau der Daten ermitteln kann.

Zum einen schaut man einfach, wie die Zettelwirtschaft bisher funktioniert: die bisherige Arbeitsweise wird auf ein abstraktes Modell übertragen. Dafür schauen wir den Mitarbeitern auf die Finger und analysieren deren Arbeitsabläufe und die dafür erzeugten und gesuchten Daten. Dies nennt sich Bottom-Up-Verfahren. Hierbei besteht jedoch die Gefahr, dass man bereits gemachte Fehler wiederholt. In einer Datenbank sollte Redundanz möglichst vermieden werden. Steht ein Kunde in den Karteikästen zweier Abteilungen, können sich Fehler einschleichen. Meyer oder Meier? Wenn der Kunde umzieht, wird die Rechnung an die neue Adresse geschickt, die Ware aber an die alte, weil niemand auf die Idee gekommen ist, die Information über den Umzug an die Versand-Abteilung weiter zu leiten. Wenn wir also die Datenhaltung eines Unternehmens im Bottom-Up-Verfahren übernehmen, übernehmen wir möglicherweise auch die Fehler, die das Unternehmen in der bisherigen Verwaltung gemacht hat.

Es ist also sinnvoller, erst zu schauen, welche zu sammeln, welche Informationen insgesamt benötigt werden und anschließend daraus die Datenbank zu modellieren. Dieses Verfahren nennt sich Top-Down-Verfahren, also von der abstrakten Ebene aus wird die Datenbank modelliert. Man sammelt von allen beteiligten Parteien, welche Daten sie einsehen müssen und welche Daten sie bearbeiten müssen. Anschließend untersucht man sie, wo sich Daten wiederholen und arbeitet dieses Feld auf. Der Versand benötigt also genauso die Adresse vom Kunden, wie die Rechnungsabteilung. Diese Adresse kann man nun zusammenführen, so dass beide Abteilungen immer die eine gleiche Adresse vorliegen haben. Oder man erfährt im Gespräch mit beiden Abteilungen, dass es eine Rechnungs- und eine Versandadresse geben kann, die aber auch identisch sein kann.

Bestellt man bei Online-Versandhäusern erkennt man oft sehr schnell am Bestellformular, wie die Datenbank aufgebaut ist. Kann nur eine Versandadresse übernommen werden und steht dort zunächst die Rechnungsadresse drin, handelt es sich vermutlich um eine Tabelle, wo alle Felder hintereinander in Spalten übertragen wurden. Kann man sich eine Auswahl von Versandadressen anlegen und anschließend eine Versandadresse wählen, so existiert vermutlich eine zweite Tabelle in der die Adressen abgelegt werden.

Redundanz bedeutet Wiederholung - und zwar im Sinne von überflüssig. Eine Information, die der Datenbank bereits bekannt ist, sollte nicht nochmals gespeichert werden. Das kann zum einen die bereits beschriebene Adresse sein, die in mehreren Abteilungen aufgeschrieben wurde, aber auch beispielsweise die Information, wieviel ein Artikel mit und ohne Steuer kostet. Wird der Artikel im Einkauf teurer, passt man den Nettoverkaufspreis an, vergisst man jedoch den Verkaufspreis anzupassen, so erhält der Privatkunde den Artikel mit Steuern günstiger, als der Geschäftskunde ohne Steuern. Die Differenz, den Verlust zahlt das Unternehmen und das Unternehmen wird sich vermutlich dann beim Datenbankentwickler melden. Der Verkaufspreis mit Steuern ist durch den Verkaufspreis ohne Steuern berechenbar. Solche berechenbaren Daten nennen sich Prozessdaten und Prozessdaten sollten nicht in der Datenbank gespeichert werden. Redundanz zeigt sich aber auch beim Kunden Meyer, der in der einen Abteilung Meyer geschrieben wird und in der anderen Meier. Es ist nun relativ schwer herauszufinden, ob es sich um einen einzelnen Kunden handelt oder um zwei unterschiedliche Kunden. Aus diesem Grund sollte Daten so beschrieben wiedern, dass sie eindeutig unterscheidbar sind. Dies erreicht man in der Regel, in dem man die Daten einfach durchnummeriert. Jeder Kunde, Lieferant, Mitarbeiter, Artikel und jede Bestellung erhält eine Nummer: eine Kundennummer, eine Lieferantennummer, eine Mitarbeiternummer, eine Artikelnummer und eine Bestellnummer. Selbst wenn zwei Kunden den gleichen Vornamen und Nachnamen haben und im gleichen Haus wohnen, so kann man sie in der Datenbank eindeutig voneinander unterscheiden.

Mit dieser Einleitung sollten wir einen grundsätzliche Idee haben, welche Informationen überhaupt in eine Datenbank übernommen werden sollten und wie wir an die Informationen herankommen. Im Idealfall sammeln wir zunächst die Daten, indem wir die Arbeitsabläufe analysieren (und das im Idealfall nicht nur vom Schreibtisch aus) und anschließend bauen wir im Top-Down-Verfahren alle relevanten Daten in ein Datenbankmodell ein. Dabei achten wir darauf, dass wir Redundanz vermeiden, keine berechneten Daten speichern und uns zum Beispiel durch Durchzählen der Datensätze eindeutige Kennungen der einzelnen Datensätze aufbauen.

Im nächsten Kapitel werden wir die Sache mit der Eindeutigkeit von Datensätzen weiter vertiefen. Wir lernen Schlüssel kennen.