|
| |
sponsered by
 |
|
| Letztes Update: 16.08.2005 17:53:45 |
|
| |
| * Link führt ins Internet |
|
| |
Optimierung des Datenmodells
|
|
Die Definition des Datenmodells ist insbesondere bei komplexen Problemlösungen nicht einfach. Anfängern unterlaufen dabei häufiger Fehler, weil die Daten nicht so behandelt werden können wie bei einer herkömmlichen Datenverwaltung auf Papier. Um die Erstellung des Datenmodells zu vereinfachen und Fehler in Form von Redundanzen zu vermeiden, wurden Regeln entwickelt, nach denen das Datenmodell effektiv erstellt werden kann. Das Prinzip dabei ist, komplexe Beziehungen von Tabellen in einfache Beziehungen zu bringen, um Datenstrukturen zu erreichen, die stabil und flexibel gegenüber Erweiterungen des Datenmodells sind.
Normalisierung
Diese Behandlung wird als Normalisierung bezeichnet. Die Normalisierung erfolgt dabei in mehreren Schritten, die weiter unten beschrieben werden.
Unterschätzt wird oft auch die für die Erstellung eines guten Datenbankdesigns notwendige Zeit. Zeit, die in ein möglichst optimales Datenbankdesign investiert wird, zahlt sich später in besserer Performance, leichterer Wartung und geringerem Aufwand bei der Programmierung aus.
Anhand des Beispiels einer Kundendatei, die Bestellungen speichert, wird im Folgenden die Normalisierung von Datenbanken erläutert.
Als Grundlage dient dabei eine Tabelle, in der alle Bestellungen des Kunden aufgelistet sind.
| Kunde | Ort/PLZ | Gekaufte Produkte | Besteller |
| TC Consulting | Berlin/13887 | Epson TX, DVDX | L. Bernhard |
| Pop-Connect | München/80179 | LC-HUB, DVDX | B. Maier |
| Wurz AG | Hamburg/40838 | Siemens PC | F. Windhorst |
| Co-TV | Köln/75879 | T-HUB, Epson TX | G. Schmidt |
| TC | Berlin/13887 | Epson TX | L. Bernhard |
Roh-Daten
Die Tabelle ist so angelegt, wie man wahrscheinlich die Verkäufe auf dem Papier mitprotokollieren würde. Bei der Durchsicht der Tabelle fallen folgende Punkt auf:
. Mehrere Informationen werden in einer Spalte notiert.
. Doppelte Spalteneinträge bei offenbar identischen Adressen.
. Abweichungen zwischen Produktcode und Produkbezeichnung, obwohl offensichtlich dieselbe Ware bezeichnet ist.
Folgene Probleme können dadurch bei einer Bearbeitung in einer Datenbank entstehen:
. Die Zusammenfassung gleichartiger Datensätze, wie die Umsätze bezogen auf einen Kunden, ist erschwert oder nicht möglich.
. Es müssen Daten wiederholt eingegeben werden.
. Durch dieselben Einträge entsteht eine Redundanz, die die Dateigröße der Datenbank unnötig vergrößert.
Normalformen
Durch ein besseres Datenbankdesign können negative Effekte dieser Art vermieden werden. Dies ist auch die Zielsetzung der Normalisierung über eine standardisierte Behandlung von Tabellen. Insgesamt gibt es neun Regeln, die auch als 1. bis 9. Normalform bezeichnet werden, von denen aber nur die Formen 1. bis 5. praxisrelevant und hier besprochen und anhand des Beispiels oben vorgestellt werden sollen.
1. Normalform
Eine Relation befindet sich in der 1. Normalform, wenn keine Spalte mit demselben Inhalt vorliegt und somit keine Wiederholungen beinhaltet. Ausserdem dürfen in dieser Form Daten in einer Tabelle keine untergeordnete Relation bilden. Weiterhin muss eine Tabelle in der 1. Normalform einen Attributswert besitzen, der eine Zeile einer Tabelle eindeutig identifiziert. Dieser Attributswert wird als Schlüsselattribut bezeichnet.
Für unser Beispiel sind deshalb alle Zeilen, in denen jeweils mehrere Informationen in den Spalten Ort/PLZ und Gekaufte Produkte vorhanden sind, aufzulösen. Durch die Auflösung in mehrere Zeilen sind die einzelnen Zeilen jedoch nicht mehr eindeutig zu unterscheiden. Dehalb müssen zusätzlich eindeutige Schlüssel, beispielsweise in Form einer Kunden-ID (KID) und Produkt-ID (PID), hinzugefügt werden.
Die 1. Normalform sieht in diesem Fall wie folgt aus:
| KID | Kunde | Besteller | PLZ | Ort | PID | Gekaufte Produkte/TD> |
| 1 | TC Consutling | L. Bernhard | 13887 | Berlin | 1000 | Epson TX/TD> |
| 1 | TC Consutling | L. Bernhard | 13887 | Berlin | 1001 | DVDX/TD> |
| 2 | Pop-Connect | B. Maier | 80179 | München | 1002 | LC-HUB/TD> |
| 2 | Pop-Connect | B. Maier | 80179 | München | 1001 | DVDX/TD> |
| 3 | Wurz AG | F. Windhorst | 40838 | Hamburg | 1003 | Siemens PC/TD> |
| 4 | Co-TV | G. Schmidt | 75879 | Köln | 1004 | T-HUB/TD> |
| 4 | Co-TV | G. Schmidt | 75879 | Köln | 1000 | Epson TX/TD> |
| 1 | TC | L. Bernhard | 13887 | Berlin | 1000 | Epson TX |
Schon besser
In der 1. Normalform sind jetzt alle Daten so gespeichert, dass sie einzeln behandelt werden können. Allerdings können auch hier weiterhin Anomalien vorkommen. Eine Anomalie wäre die unterschiedliche Schreibweise und Adresse des Kunden TC. Zur Vermeidung solcher Anomalien ist es sinnvoll, die Tabelle in die 2. Normalform zu überführen.
2. Normalform
Damit eine Tabelle in der 2. Normalform vorliegen kann, müssen mindestens die Kriterien der 1. Normalform erfüllt sein. Die 2. Normalform ist dadurch charakterisiert, dass jedes Nicht-Schlüsselattribut vom Primärschlüssel funktional abhängig ist. Praktisch wird das dadurch erreicht, dass die Informationen in mehreren Tabellen gespeichert werden. Die Tabellen werden so organisiert, dass Informationen, die vom Primärschlüssel abhängig sind, in eigenen Tabellen zusammengefasst werden. In unserem Beispiel gehören Name und Adresse sowie die Produkte in eine eigene Tabelle. Die Tabellen sehen dann wie folgt aus:
Tabelle Kunden
| KID | Kunde | Besteller | Ort | PLZ |
| 1 | TC Consutling | L. Bernhard | Berlin | 13887 |
| 2 | Pop-Connect | B. Maier | München | 80179 |
| 3 | Wurz AG | F. Windhorst | Hamburg | 40838 |
| 4 | Co-TV | G. Schmidt | Köln | 75879 |
Übersichtlich ...
Tabelle Produkte
| PID | Gekaufte Produkte |
| 1000 | Epson TX |
| 1001 | DVDX |
| 1002 | LC-HUB |
| 1003 | Siemens PC |
| 1004 | T-HUB |
... und eindeutig
Damit ist ein erstes Ziel, Anomalien einzuschränken, erreicht, weil zusammengehörige Informationen konsistent sind. So werden beispielsweise unterschiedliche Schreibweisen für die einzelnen Kunden vermieden. Allerdings hat diese Form noch den Schwachpunkt, dass Änderungen bei Produkbezeichnungen in allen betroffenen Spalten vorgenommen müssen. Zur Lösung dieses Problems wurde die 3. Normalform definiert.
3. Normalform
Zusätzlich zur 2. Normalform gilt die Regel, dass alle nicht zum Primärschlüssel gehörenden Attribute nicht von diesem transitiv (funktional) abhängen. Alle Spalten dürfen also nur vom Schlüsselattribut und nicht von anderen Werten abhängen. Sind weitere solcher Abhängigkeiten vorhanden, müssen diese aufgelöst werden.
In unserem Beispiel ist der Besteller ein solcher Fall. Der Besteller ist eine Eigenschaft der Firma, da verschiedene Personen eine Bestellung aufgeben können. Damit ist die Tabelle Kunden noch nicht in der 3. Normalform. Die Auflösung erfolgt analog der 2. Normalform, indem eigene Tabellen erzeugt werden. Die 3. Normalform sieht wie folgt aus:
Tabelle Kunden
| KID | Kunde | Ort | PLZ |
| 1 | TC Consutling | Berlin | 13887 |
| 2 | Pop-Connect | München | 80179 |
| 3 | Wurz AG | Hamburg | 40838 |
| 4 | Co-TV | Köln | 75879 |
Jetzt funktioniert's auch ...
Tabelle Besteller
| BID | KID | Besteller |
| 1 | 1 | L. Bernhard |
| 2 | 2 | B. Maier |
| 3 | 3 | F. Windhorst |
| 4 | 4 | G. Schmidt |
... mit den Bestellern ...
Tabelle Produkte
| PID | Gekaufte Produkte |
| 1000 | Epson TX |
| 1001 | DVDX |
| 1002 | LC-HUB |
| 1003 | Siemens PC |
| 1004 | T-HUB |
... und deren Produkten
4. Normalform
Die 4. Normalform bezieht sich auf Mehrfachabhängigkeiten von Attributen auf einen übergeordneten Schlüssel. Diese Mehrfachabhängigkeiten müssen in Einzelabhängigkeiten aufgelöst werden.
5. Normalform
Wenn durch die 4. Normalform keine verlustfreie Zerlegung in Einzelabhängigkeiten möglich ist, müssen eventuell mehrere übergeordnete Schlüssel hinzugezogen werden, bis nur noch Einzelabhängigkeiten vorliegen.
Allerdings ist die Auflösung der Datenbanken in Normalformen nur ein Hilfsmittel zur Erstellung eines guten Datenbankdesigns. Die vollständige Auflösung in Normalformen bringt im Allgemeinen auch einige Nachteile mit sich. So wird die Anzahl einzelner Tabellen unter Umständen relativ hoch, sodass insbesondere bei der Programmierung der Datenbanken ein erhöhter Aufwand entstehen kann. Je mehr Tabellen vorhanden sind, umso schwieriger wird auch die Definition von SQL-Befehlen, weil alle Tabellen über entsprechende Befehle verknüpft werden müssen.
Häufig wird auch als Argument gegen eine vollständige Normalisierung von Datenbanken eine schlechtere Performance genannt. Ob die Performance von SQL-Statements im Einzelfall wirklich schlechter ist, kann allerdings oft nur durch entsprechende Analyseprogramme, die beide Varianten vergleichen, festgestellt werden. Der Aufwand für einen solchen Vergleich ist unter Umständen beträchtlich.
|
|
|
|
|
|
|
|
SELFPHP
SELFPHP - Damir Enseleit, info@selfphp.de, Impressum, Kontakt