Normalisierung

In diesem Kapitel werden einige Überlegungen angestellt, wie eine Datenbank konzipiert werden soll.

(Einführung in SQL: Normalisierung)

(Einführung in SQL: Normalisierung)

Dieses Kapitel geht über die Anforderungen einer Einführung hinaus; denn es richtet sich weniger an „einfache“ Anwender, die eine vorhandene Datenbank benutzen wollen, sondern an (künftige) Programmentwickler, die eine Datenbank entwerfen und erstellen. Aber wann soll man darüber sprechen, wenn nicht am Anfang?

Grundgedanken

Schon das einfache Muster einer unzureichenden Tabelle wie im vorigen Kapitel weist auf ein paar Forderungen hin, die offensichtlich an eine sinnvolle Struktur gestellt werden sollten:

Redundanz vermeiden

Eine Information, die an mehreren Stellen benötigt wird, soll nur einmal gespeichert werden. Dadurch müssen auch sämtliche Änderungen, die solche Informationen betreffen, nur an einer Stelle erledigt werden.

Im Beispiel waren das u. a. die Angaben zum Fahrzeughalter und zum Sachbearbeiter (mit seinen Telefonnummern), die bei jedem Vertrag angegeben werden.

Wiederholungen trennen

Die Zusammenfassung gleichartiger Informationen ist nicht sehr übersichtlich. Im vorigen Kapitel waren zunächst Festnetz- und Mobil-Rufnummer in einer Spalte untergebracht. Das ist praktisch, wenn man sich keine Gedanken darüber machen will, welche und wie viele Kontaktnummern es gibt. Es ist ziemlich unpraktisch, wenn man gezielt einzelne Nummern suchen will oder von einer Nummer auf den Sachbearbeiter schließen will. Sinnvoller ist es, Festnetz- und Mobilnummer in getrennten Spalten zu speichern.

Primärschlüssel verwenden

Jeder Datensatz muss eindeutig identifiziert werden, damit die Informationen verwendet werden können.

In der ungenügenden Tabelle wurde wegen der Zeilennummern darauf verzichtet. Aber selbst wenn man die Suche in zigtausend Zeilen für machbar hielte, spätestens bei der Aufteilung in mehrere Tabellen braucht man Werte, um die Zusammenhänge eindeutig darzustellen.

Bei diesen Überlegungen handelt es sich nur um ein paar Gedanken, die sich einem aufdrängen. Das wollen wir nun besser strukturieren.

Tabellenkalkulation als Ausgangspunkt

Überlegen wir uns zunächst, welche Informationen benötigt werden.

Grundlegende Daten

Für die Verträge müssen die folgenden Angaben gespeichert werden.

• die Vertragsdaten selbst, also Nummer, Abschlussdatum und Art des Vertrags (HP = Haftpflicht, TK = Teilkasko, VK = Vollkasko) und der Prämienberechnung
• der Vertragspartner mit Name, Anschrift, Telefonnummern, dazu bei natürlichen Personen Geschlecht und Geburtsdatum sowie bei juristischen Personen der Eintrag im Handelsregister o. ä.
• das versicherte Fahrzeug mit Kennzeichen, Hersteller und Typ (die Farbe ist eine Zusatzinformation, die bei manchen Suchvorgängen hilfreich sein kann)
• der zuständige Sachbearbeiter mit Name, Abteilung und Telefonnummern

Ein Teil der Angaben muss immer vorhanden sein, ein anderer Teil je nach Situation (Geschlecht bei Personen) und ein weiterer Teil nur bei Bedarf (Mobiltelefon).

Schnell stellen wir fest, dass ein Versicherungsnehmer auch mehrere Fahrzeuge versichern kann. Andererseits kann ein Fahrzeug zu mehreren Verträgen gehören, wenn Haftpflicht und Vollkasko getrennt abgeschlossen werden oder wenn zur Haftpflicht vorübergehend Vollkasko fürs Ausland hinzukommt. Jeder Vertrag ist ein eigener Datensatz; also stehen bei jedem Datensatz die Angaben des Vertragspartners und des Fahrzeugs. Um alle Verträge eines Kunden gemeinsam anzuzeigen, brauchen wir folglich ein paar Angaben zur Organisation:

• Kundennummer und laufende Nummer seiner Verträge als eindeutiger Suchbegriff (vielleicht als Primärschlüssel)
• Vertragsnummer als eindeutiger Wert
• Fahrzeug-Kennzeichen als Wert, der meistens (aber nicht immer) nur einmal vorkommt

Schadensfälle

Nun sollen zu einem Vertrag auch die Schadensfälle gespeichert werden. Wir benötigen also eine oder mehrere Spalten mit den erforderlichen Angaben (Datum und Art des Schadens, Sachbearbeiter der Schadensabwicklung, andere beteiligte Fahrzeuge); aber wie wird das am besten gespeichert?

• eine gemeinsame Spalte für alle diese Angaben für alle Schadensfälle (denn die Mehrzahl der Fahrzeuge fährt schadensfrei)
• je eine Spalte für alle Angaben eines Schadensfalls (werden dann zwei oder drei Spalten benötigt, oder muss man für „Mehrfach-Sünder“ gleich zehn Spalten vorsehen?)
• oder einzelne Datensätze für jeden Schaden eines Fahrzeugs (sodass sich alle Fahrzeug- und Vertragsdaten in diesen Datensätzen wiederholen und nur die Schadensangaben unterscheiden)

Ungeklärt bleibt dabei noch dieses Problem: Wie viele versicherte Schadensgegner gibt es denn – keine (wenn ein Reh angefahren wird), einen (z. B. beim Parken) oder viele (bei einem Auffahrunfall auf der Autobahn)?

Entscheiden wir uns deshalb provisorisch für ein eigenes Arbeitsblatt Schadensfälle mit folgender Struktur:

• je eine Spalte für die Angaben, die direkt zum Schadensfall gehören
• vorläufig 5 Gruppen für maximal 5 beteiligte Fahrzeuge
• jede dieser Gruppen enthält in einzelnen Spalten Fahrzeug-Kennzeichen und die Halter-Angaben (Name, Anschrift)

Damit stehen die Fahrzeugdaten in beiden Arbeitsblättern. Als praktisches Problem kommt hinzu: Für die Schadenshäufigkeit eines bestimmten Fahrzeugs muss man es in fünf Spalten heraussuchen. Die Beschränkung auf fünf beteiligte Fahrzeuge wird im nächsten Schritt aufgelöst, machen wir uns dazu keine weiteren Gedanken.

Auf diesem Weg kann jedenfalls keine sinnvolle Struktur erreicht werden.

„Update-Anomalien“

Mit diesem Begriff werden die folgenden Unklarheiten bezeichnet. Dabei handelt es sich um weitere Probleme bei einer ungenügenden Struktur.

Einfügen-Anomalie

In der ersten Tabelle sind u. a. die Sachbearbeiter enthalten. Es wäre sinnvoll, auch alle anderen Mitarbeiter der Gesellschaft hier einzutragen. Aber bei einem Vertrag werden zwingend Vertragsnummer und Abschlussdatum benötigt; dieser Zwang verhindert das Speichern der Teilinformation Sachbearbeiter ohne Bezug auf einen Vertrag.

Löschen-Anomalie

Wenn ein Vertrag gekündigt und abgelaufen ist und deshalb gelöscht wird, dann sind in der ersten Tabelle auch alle Angaben zum Vertragspartner verloren. Wenn er drei Tage später einen neuen Vertrag abschließt, müssen alle seine Angaben neu aufgenommen werden. Und was soll mit den Schadensfällen geschehen, die zu diesem Vertrag gespeichert sind?

Ändern-Anomalie

Wenn der Sachbearbeiter wechselt, muss sein Name bei allen von ihm betreuten Verträgen geändert werden, obwohl eine einzige Änderung ausreichend sein sollte. (Dies ist auf die Datenredundanz zurückzuführen, dass nämlich dieser Hinweis vielfach gespeichert ist statt einmalig.)

All diesen Problemen wollen wir nun durch eine deutlich verbesserte Datenstruktur begegnen. Nehmen wir dazu zunächst an, dass alle benötigten Informationen in den beiden Arbeitsblättern Verträge und Schadensfälle der Tabellenkalkulation stehen, und beginnen wir, dies sinnvoll zu strukturieren.

Die 1. Normalform

Am „grausamsten“ für den Aufbau der Tabelle und die praktische Arbeit ist die vielfache Wiederholung gleicher Informationen.

Sowohl beim Namen des Fahrzeughalters als auch bei den Mitarbeitern steht der Name bisher in einer Spalte in der Form „Nachname, Vorname“, was als Suchbegriff geeignet ist. Nun benötigen wir aber auch eine persönliche Anrede (Name mit Titel) und eine Briefanschrift (Vorname, Name). Soll dies in weiteren Spalten gespeichert werden? Nein, denn all dies kann aus den Einzelangaben „Name“ und „Vorname“ zusammengesetzt werden.

Ein Schadensfall ist bisher auf fünf beteiligte Fahrzeuge beschränkt, auch wenn selten mehr als zwei Beteiligungen benötigt werden. Wenn nun ein sechstes, zehntes oder zwanzigstes Fahrzeug beteiligt ist, muss dann jedesmal die Tabellenstruktur (und jedes Makro, das auf diese Spalten zugreift) geändert werden?!

Damit haben wir bereits zwei Regeln, die als Definition der ersten Normalform gelten. Hinzu kommt eine dritte Regel, die zwar formal nicht erforderlich ist; aber aus praktischen Gründen gibt es keine sinnvolle Lösung ohne diese Regel.

	Die 1. Normalform 1. Jede Spalte enthält nur unteilbare (atomare, atomische) Werte. 2. Spalten, die gleiche oder gleichartige Informationen enthalten, sind in eigene Tabellen (Relationen) auszulagern. 3. Jede Tabelle enthält einen Primärschlüssel.

Verletzung der 1. Normalform

Unsere Ausgangstabelle verstößt an vielen Stellen gegen diese Regeln:

• Zusammengesetzte Werte befinden sich z. B. an folgenden Stellen:
  • Fahrzeughalter: Name und Vorname, PLZ und Ort, ggf. Straße und Hausnummer
  • Sachbearbeiter: Name und Vorname, Festnetz- und Mobilnummer
• Wiederholungen finden sich vor allem hier:
  • mehrere Fahrzeuge bei einem Schadensfall

Vorgehen zur Herstellung der 1. Normalform

Es werden also zwei Schritte benötigt:

1. Zusammengesetzte Werte werden in Einzelinformationen aufgeteilt: je eine Spalte für jeden unteilbaren Wert.
2. Wiederholungen werden in getrennte Tabellen ausgelagert; welche Daten zusammengehören, wird durch eine laufende Nummer angegeben.

Eine erste Verbesserung

An jeder Stelle, die Namen oder Anschrift enthält, werden getrennte Spalten verwendet, beispielsweise im Arbeitsblatt Verträge:

Kundennummer  Vertrag  Abschluss   Halter_Name             Halter_PLZ  Halter_Ort   Sachbearbeiter_N  Sachbearbeiter_V  Telefon
    1          DG-01   03.05.1974  Heckel Obsthandel GmbH  46282       Dorsten      Pohl              Helmut            0201/4014186
    1          DG-02   04.07.1974  Heckel Obsthandel GmbH  46282       Dorsten      Pohl              Helmut            0201/4014186    

Die Tabelle Schadensfälle wird auf die eigentlichen Daten beschränkt; die beteiligten Fahrzeuge stehen in einer eigenen Tabelle Zuordnungen.

Nummer  Datum       Schadensort                           Beschreibung              Sachbearbeiter_N  Sachbearbeiter_V  Telefon
   1    02.03.2007  Recklinghausen, Bergknappenstr. 144   Gartenzaun gestreift      Schindler         Christina         0201/4012151
   2    11.07.2007  Haltern, Hauptstr. 46                 beim Ausparken hat ...    Aliman            Zafer             0201/4012161

Die Anzahl der beteiligten Fahrzeuge an einem Schadensfall wird durch eine eigene Tabelle Zuordnungen berücksichtigt:

Nummer  Fahrzeug    Hersteller  Typ     Halter_Name  Halter_Vorname  Halter_PLZ  Halter_Ort      Halter_Straße
   1    RE-LM 902   Opel        Corsa   Heckel Obsthandel GmbH       46282       Dorsten         Gahlener Str. 40  
   2    BO-GH 102   Volvo       C30     Geissler     Helga           44809       Bochum          Steinbankstr. 15
   2    RE-CD 456   Renault     Twingo  Cornelsen    Dorothea        44577       Castrop-Rauxel  Kiefernweg 9

Die Zusatzbedingung eines Primärschlüssels wurde gleichzeitig erfüllt; die betreffenden Spalten wurden unterstrichen.

Die 2. Normalform

Eine weitere Wiederholung in den „Monster-Tabellen“ sind die Angaben zum Halter bei den Verträgen und den Zuordnungen oder die Fahrzeugdaten sowohl bei den Verträgen als auch bei den Zuordnungen. Auch diese werden in eigene Tabellen ausgelagert; das ergibt sich als Definition aus der folgenden Regel:

	Die 2. Normalform 1. Die Tabelle erfüllt die 1. Normalform. 2. Alle Informationen in den Spalten, die nicht Teil des Primärschlüssels sind, müssen sich auf den gesamten Primärschlüssel beziehen.

Man sagt dazu auch, dass die Informationen funktional abhängig sind von der Gesamtheit der Schlüsselwerte. Umgekehrt formuliert bedeutet es: Wenn eine Spalte nur zu einem einzelnen Schlüsselfeld gehört, ist die 2. Normalform nicht erfüllt.

Während sich die 1. Normalform auf die einzelnen Spalten und Wiederholungen innerhalb eines Datensatzes bezieht, befasst sich die 2. Normalform mit Wiederholungen bei verschiedenen Datensätzen.

Verletzung der 2. Normalform

Unsere derzeitigen Tabellen verstoßen mehrfach gegen diese Regel:

• Bei den Verträgen beziehen sich Name und Anschrift des Vertragspartners nur auf die Kundennummer, aber nicht auf die Vertragsnummer.
• Bei den Verträgen stehen auch die Fahrzeugdaten. (Dies wurde bei der Beschreibung der grundlegenden Daten erwähnt, fehlt aber in den bisherigen Beispielen.) Diese beziehen sich auf die Vertragsnummer, haben aber nur indirekt etwas mit Name und Anschrift des Vertragspartners zu tun.
• Bei den Zuordnungen der Schadensfälle gehören sowohl die Fahrzeug- als auch die Halterdaten nur zu einem Fahrzeug (also dem Kennzeichen), aber nicht zu einem Schadensfall.

Vorgehen zur Herstellung der 2. Normalform

Es müssen alle „unpassenden“ Informationen in eigene Tabellen ausgelagert werden. Der Primärschlüssel wird vereinfacht, sodass er sich nur auf die „eigentlichen“ Informationen einer Tabelle bezieht.

• Aus den Verträgen werden alle Angaben des Vertragspartners entfernt und in eine Tabelle Versicherungsnehmer übertragen. Der Primärschlüssel besteht nur noch aus der Spalte Vertrag. Die Spalte Kundennummer ist nur noch ein Fremdschlüssel als Verweis auf die neue Tabelle Versicherungsnehmer.

• Aus den Verträgen werden alle Angaben des Fahrzeugs entfernt und in eine neue Tabelle Fahrzeuge übertragen. Das Fahrzeug-Kennzeichen ist hier nur noch ein Fremdschlüssel als Verweis auf die Tabelle Fahrzeuge.

• Aus den Zuordnungen werden alle Angaben der Fahrzeuge entfernt und in eine Tabelle Fahrzeuge übertragen. Die Tabelle Zuordnungen besteht nur noch aus den Spalten des Primärschlüssels.

Damit stehen die Fahrzeugdaten nur noch in einer Tabelle – sowohl für die Verträge als auch für die Schadensfälle (genauer: die Zuordnungen).

Eine zweite Verbesserung

Die ursprüngliche Tabelle Verträge beschränkt sich jetzt auf diese Angaben:

Vertrag  Abschluss   Typ   Kundennummer  Fahrzeug   Sachbearbeiter_N  Sachbearbeiter_V  Telefon
 DG-01   03.05.1974  HP          1       RE-LM 901  Pohl              Helmut            0201/4014186
 DG-02   04.07.1974  HP          1       RE-LM 902  Pohl              Helmut            0201/4014186

Die neue Tabelle Versicherungsnehmer umfasst die Daten, die sich auf den Vertragspartner beziehen:

Kundennummer  Name         Vorname    Geburtsdatum  PLZ    Ort        Straße       Hausnummer
    1         Heckel Obsthandel GmbH                46282  Dorsten    Gahlener Str.    40   
    5         Geissler     Helga      13.01.1953    44809  Bochum     Steinbankstr.    15

Die neue Tabelle Fahrzeuge umfasst nur noch die Daten, die sich auf das Fahrzeug selbst beziehen. Name und Anschrift des Fahrzeughalters werden durch die Kundennummer, also den Verweis auf die Tabelle Versicherungsnehmer ersetzt.

Fahrzeug    Hersteller  Typ     Farbe   Halter
RE-LM 902   Opel        Corsa   ocker      1
BO-GH 102   Volvo       C30     rot        5
RE-CD 456   Renault     Twingo  ocker      3

Die Tabelle Schadensfälle muss nicht angepasst werden. Die Tabelle Zuordnungen vereinfacht sich radikal:

Nummer  Fahrzeug
   1    RE-LM 902 
   2    BO-GH 102   
   2    RE-CD 456   

Die 2. Normalform kann ganz einfach dadurch gewährleistet werden, dass sich der Primärschlüssel nur auf eine Spalte bezieht.

Die 3. Normalform

Beseitigen wir noch die übrigen Wiederholungen, nämlich die Sachbearbeiter bei den Verträgen und den Schadensfällen sowie die Hersteller bei den Fahrzeugen. Diese werden ebenfalls in eigene Tabellen ausgelagert gemäß der Definition nach der folgenden Regel:

	Die 3. Normalform 1. Die Tabelle erfüllt die 2. Normalform. 2. Informationen in den Spalten, die nicht Teil des Primärschlüssels sind, dürfen funktional nicht voneinander abhängen.

Die 3. Normalform befasst sich also mit Wiederholungen bei verschiedenen Datensätzen, die nur zusätzliche Informationen bereitstellen.

Verletzung der 3. Normalform

Unsere derzeitigen Tabellen verstoßen in folgender Hinsicht gegen diese Regel:

• Name, Vorname und Telefonnummer eines Sachbearbeiters hängen voneinander ab. Sie haben aber nur insgesamt etwas mit dem Vertrag bzw. dem Schadensfall zu tun, nicht als einzelne Information.
• Hersteller und Typ eines Fahrzeugs hängen voneinander ab. Sie haben aber nur insgesamt etwas mit dem Fahrzeug zu tun, nicht als einzelne Information.

Eine andere Erklärung dafür ist, dass die Zusatzinformation auch ohne Bezug zum eigentlichen Datensatz gültig bleibt. Der Sachbearbeiter gehört zum Unternehmen unabhängig von einem bestimmten Vertrag. Der Fahrzeughersteller existiert unabhängig davon, ob ein bestimmtes Fahrzeug noch fährt oder inzwischen verschrottet worden ist.

Vorgehen zur Herstellung der 3. Normalform

Alle „unpassenden“ Informationen kommen wieder in eigene Tabellen. Ihre Spalten werden ersetzt durch einen Fremdschlüssel als Verweis auf die neue Tabelle.

• Aus den Verträgen und den Schadensfällen werden alle Angaben zum Sachbearbeiter entfernt und in eine Tabelle Mitarbeiter übertragen. Die Spalte Sachbearbeiter verweist nur noch als Fremdschlüssel auf die neue Tabelle Mitarbeiter.

  Dies löst automatisch auch das oben erwähnte Problem: Wir können nun alle Mitarbeiter in einer gemeinsamen Tabelle speichern.

• Aus den Fahrzeugen werden alle Angaben zu Hersteller und Typ entfernt und in eine neue Tabelle Fahrzeugtypen übertragen. Die Spalten Hersteller und Typ werden ersetzt durch einen Fremdschlüssel als Verweis auf die Tabelle Fahrzeugtypen.

  Um es korrekt zu machen, gehört der Hersteller in eine weitere Tabelle Fahrzeughersteller; in der Tabelle Fahrzeugtypen verweist er als Fremdschlüssel auf diese weitere Tabelle.

Eine weitere Verbesserung

Die Tabellen Verträge und Schadensfälle werden also nochmals vereinfacht:

Vertrag  Abschluss   Typ   Kundennummer  Fahrzeug   Sachbearbeiter
 DG-01   03.05.1974  HP          1       RE-LM 901      9
 DG-02   04.07.1974  HP          1       RE-LM 902      9

Nummer   Datum       Schadensort                    Beschreibung      Sachbearb
   1     02.03.2007  Recklinghausen, Bergknappe...  Gartenzaun gestreift        14 
   2     11.07.2007  Haltern, Hauptstr. 46          beim Ausparken hat ...      15 

Hinzu kommt die neue Tabelle Mitarbeiter:

Nummer   Nachname    Vorname       Telefon
   9     Pohl        Helmut        0201/4014186
  14     Schindler   Christina     0201/4012151
  15     Aliman      Zafer         0201/4012161

In gleicher Weise wird die Tabelle Fahrzeuge gekürzt; die Angaben werden in die neuen Tabellen Fahrzeugtypen und Fahrzeughersteller ausgelagert.

Zusätzliche Maßnahmen

In der Theorie gibt es noch eine 4. und eine 5. Normalform (und eine Alternative zur 3. Normalform). Dazu sei auf den Wikipedia-Artikel und die dortigen Hinweise (Quellen, Literatur, Weblinks) verwiesen. In der Praxis ist aber eine Datenbank, die den Bedingungen der 3. Normalform entspricht, sehr gut konzipiert. Weitere Normalisierungen bringen kaum noch Vorteile; stattdessen können sie die Übersichtlichkeit und die Geschwindigkeit beim Datenzugriff beeinträchtigen.

Verzicht auf Zusatztabellen

Beispielsweise wiederholen sich in der Tabelle Versicherungsnehmer die Ortsangaben. Dabei gehören die Kombinationen PLZ/Ort immer zusammen; auch wenn der Kunde umzieht, ist eine solche Kombination unverändert gültig. Also könnte man in der Tabelle die Adresse wie folgt speichern:

Kd-Nr  Name         Vorname    Geburtsdatum  PLZ    Alort     Straße       Hausnummer
   1   Heckel Obsthandel GmbH                46282  10884500  Gahlener Str.    40  
   5   Geissler     Helga      13.01.1953    44809  05902500  Steinbankstr.    15

Der Ortsname ist dann zu finden über die PL-Datei der Deutschen Post AG (mit PLZ/Alort als Primärschlüssel):

Dateiversion  Geltung   PLZ    Alort     PLZ-Arten  Ortsname
PL 0509 244   20010101  44809  05902500  06 2 2     Bochum
PL 0509 244   20050329  46282  10884500  06 2 2     Dorsten

Das gleiche Verfahren ist möglich für die Straßennamen. Es sorgt dafür, dass nur gültige Anschriften gespeichert sind und auch bei Eingemeindungen die neuen Angaben eindeutig übernommen werden. Aber selbst wenn man wegen der Datensicherheit mit Alort arbeiten will, wird man für die praktische Arbeit den Ortsnamen in der Adressendatei behalten wollen.

Primärschlüssel nur zur Identifizierung

Im vorigen Kapitel hatten wir kurz darauf hingewiesen, dass der Primärschlüssel nur die Bedeutung als ID haben sollte.

Eine Begründung liefert die obige Tabelle Fahrzeuge, bei der das Kennzeichen zur Identifizierung benutzt wurde. Wenn der Fahrzeughalter in einen anderen Kreis umzieht, bekommt er ein neues Kennzeichen. Dann müsste es an allen Stellen geändert werden, an denen es gespeichert ist. Nun darf die Vertragsabteilung nur die Verträge ändern, die Schadensabwicklung die Schadensfälle (und wer weiß, wo noch darauf Bezug genommen wird). Jede Ummeldung verursacht also erheblichen Mehraufwand.

Sorgen wir also für mehr Datensicherheit und Arbeitsvereinfachung:

• Der Primärschlüssel ist eine automatisch zugewiesene ID. Diese ID wird niemals geändert.
• Die Identifizierung, die der Benutzer kennt, ist eine einzelne Spalte in einer einzigen Tabelle.

Beispiele: Vertragsnummer, Fahrzeug-Kennzeichen, Personalnummer

• Die Verknüpfungen mit anderen Tabellen regelt die Datenbank mit Hilfe der ID selbständig.

Änderungsdaten

In vielen Fällen ist es sinnvoll, wenn in einer Tabelle nicht nur der aktuelle Zustand gespeichert ist, sondern der Verlauf.

• Beispiel mit Änderung des Kennzeichens: Wenn die Polizei nach einem Unfallverursacher sucht, der inzwischen umgezogen ist, wird für das alte (nicht mehr gültige) Kennzeichen kein Fahrzeug gefunden.
• Adressenänderungen auf Termin legen: Es wäre viel zu aufwändig, wenn alle Änderungen gleichzeitig an dem Stichtag, an dem sie gelten sollen, eingegeben werden müssten. Besser ist es, sie sofort zu speichern mit Angabe des Geltungsdatums; die Datenbank holt abhängig vom aktuellen und dem Geltungsdatum immer die richtige Version.
• Aktueller Steuersatz: Die Abrechnung einer Versandfirma muss immer mit dem richtigen Steuersatz rechnen, auch wenn er mitten im Jahr geändert wird. Als Steuersatz 1 für die Mehrwertsteuer wird dann bei einer „älteren“ Rechnung mit 16 % und bei einer Rechnung neueren Datums mit 19 % gerechnet.

Für alle solche Fälle erhalten Tabellen gerne zusätzliche Spalten gültig von und gültig bis. Anstelle einer Änderung werden Datensätze verdoppelt; die neuen Informationen ersetzen dabei die bisher gültigen.

Selbstverständlich erfordert eine solche Datenbankstruktur höheren Aufwand sowohl beim Entwickler der Datenbank als auch beim Programmierer der Anwendung. Der zusätzliche Nutzen rechtfertigt diesen Aufwand.

Reihenfolge ohne Bedeutung

Beim Aufbau einer Datenbank darf es nicht relevant sein, in welcher Reihenfolge die Zeilen und Spalten vorkommen: Die Funktionalität der Datenbank darf nicht davon abhängen, dass zwei Spalten in einer bestimmten Folge nacheinander kommen oder dass nach einem Datensatz ein bestimmter zweiter folgt.

• Ein Datensatz (also eine Zeile) steht nur über den Primärschlüssel bereit.
• Eine Spalte steht nur über den Spaltennamen zur Verfügung.

Nur ausnahmsweise wird mit der Nummer einer Zeile oder Spalte gearbeitet, z. B. wenn ein „Programmierer-Werkzeug“ nur indizierte Spalten kennt.

Zusammenfassung

Fassen wir diese Erkenntnisse zusammen zu einigen Regeln, die bei der Entwicklung einer Datenbank-Struktur zu beachten sind.

Allgemeine Regeln

Von der Realität ausgehen

Erstellen Sie Tabellen danach, mit welchen Dingen (Objekten) Sie arbeiten. Benutzen Sie aussagekräftige Namen für Tabellen und Spalten.

Einzelne Informationen klar trennen

Alle Informationen werden in einzelne Spalten mit unteilbaren Werten aufgeteilt.

Vollständigkeit

Alle möglichen Informationen sollten von vornherein berücksichtigt werden. Nachträgliche Änderungen sind zu vermeiden.

Keine berechneten Werte speichern

Eine Information, die aus vorhandenen Angaben zusammengestellt werden kann, wird nicht als eigene Spalte gespeichert.

Kleine Tabellen bevorzugen

Wenn eine Tabelle sehr viele Informationen umfasst, ist es besser, sie zu unterteilen und über einen einheitlichen Primärschlüssel zu verbinden.

Keine doppelten Speicherungen

Es darf weder ganze doppelte Datensätze geben noch wiederholte Speicherungen gleicher Werte (Redundanz von Daten). Doppelte Datensätze werden durch Primärschlüssel und Regeln zur Eindeutigkeit in Felder vermieden; Datenredundanz wird durch getrennte Tabellen ersetzt, sodass es nur die Fremdschlüssel mehrfach gibt.

Wichtig ist auch, dass der Aufbau der Datenbank beschrieben und ggf. begründet wird. Hilfreich sind dabei graphische Darstellungen, wie sie von vielen Datenbank-Programmen angeboten werden.

Abweichungen

Die vorstehenden Überlegungen werden nicht immer beachtet. Für fast jede Regel gibt es begründete Ausnahmen

Beispielsweise enthält eine Datenbank mit Adressen in der Regel die Adressen im Klartext und nicht nur als Verweise auf die Nummern von Orten, Ortsteilen, Straßen und Straßenabschnitten der Deutschen Post.

Entscheiden Sie erst nach bewusster Abwägung von Vor- und Nachteilen, wenn Sie von einer der Regeln abweichen wollen.

Siehe auch

Über Wikipedia sind weitere Informationen zu finden:

• Normalisierung
• Relationale Datenbank
• Edgar F. Codd und seine 12 Regeln für relationale Datenbanken
• Update-Anomalien
• Redundanz von Daten

Für eine sorgfältige Planung einer Adressen-Datenbank hilft die Datenstruktur der Deutschen Post:

• Datafactory als Überblick (PLZ, Orte / Ortsteile und Straßen)
• Datafactory Streetcode Handbuch mit Aufbau und Inhalt (PDF, 600 kB)