Normalisierung
In diesem Kapitel werden einige Überlegungen angestellt, wie eine Datenbank konzipiert werden soll.
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
[Bearbeiten]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
[Bearbeiten]Überlegen wir uns zunächst, welche Informationen benötigt werden.
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
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.
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
[Bearbeiten]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. |
|---|
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
Es werden also zwei Schritte benötigt:
- Zusammengesetzte Werte werden in Einzelinformationen aufgeteilt: je eine Spalte für jeden unteilbaren Wert.
- Wiederholungen werden in getrennte Tabellen ausgelagert; welche Daten zusammengehören, wird durch eine laufende Nummer angegeben.
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
[Bearbeiten]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.
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.
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).
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
[Bearbeiten]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.
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.
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.
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
[Bearbeiten]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
[Bearbeiten]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
[Bearbeiten]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
[Bearbeiten]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
[Bearbeiten]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
[Bearbeiten]Fassen wir diese Erkenntnisse zusammen zu einigen Regeln, die bei der Entwicklung einer Datenbank-Struktur zu beachten sind.
Allgemeine Regeln
[Bearbeiten]- 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
[Bearbeiten]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
[Bearbeiten]Ü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)