Denormalisierung
aus Wikipedia, der freien Enzyklopädie
Unter Denormalisierung versteht man die bewusste Rücknahme einer Normalisierung zum Zweck der Verbesserung des Laufzeitverhaltens einer Datenbankanwendung. Aus Sicht der ANSI-SPARC-Architektur wird Denormalisierung nur zum Design der internen Ebene angewendet. Die interne Ebene (auch physische Ebene genannt) ist die physische Sicht der Datenbank. Sie beschreibt, wie auf dem Speichermedium im Computer die Daten abgelegt werden.
Ein logisch ideales ("normalisiertes") Datenmodell ist vollkommen redundanzfrei - abgesehen von der technisch notwendigen Mehrfachspeicherung von Fremdschlüsseln bei Primärschlüssel-Fremdschlüssel-Beziehungen.
Mit Denormalisierungen lassen sich oftmals wesentlich größere Performance-Verbesserungen erreichen als mit einem Tuning der Datenbankinstallation.
Neben der Verbesserung des Laufzeitverhaltens wird Denormalisierung auch angewandt, um die Komplexität eines Systems zu verringern oder um die Administrierbarkeit der gespeicherten Daten zu erleichtern.
Inhaltsverzeichnis |
[Bearbeiten] Bereiche der Denormalisierung
[Bearbeiten] Rücknahme der ersten Normalform
Verstöße gegen die erste Normalform werden meistens zur Vermeidung einer unnötigen Komplizierung des Datenhaushalts und der damit verbundenen Systemkomponenten vorgenommen.
Die erste Normalform fordert eine atomare Speicherung von Daten, das bedeutet, dass in einem Attribut (=einem Datenbankfeld) nur atomare (=unzerteilbare) Informationen abgelegt werden dürfen. Beispiel: Die Definition eines 100 Zeichen langen Datenfeldes zur Aufnahme von einer oder mehrerer Telefonnummern verstößt gegen die Forderung der ersten Normalform. Um die erste Normalform zu erfüllen, müsste für die Speicherung der Telefonnummern eine eigene Tabelle geschaffen werden. So könnten zu einer Person beliebig viele Telefonnummern gespeichert werden. Die Unterbringung einer oder mehrerer Telefonnummern in einem einzigen Datenfeld ist jedoch oft völlig ausreichend und die Komplexität des Systems wird dadurch reduziert.
Ein weiteres Beispiel für eine aus praktischen Gründen sinnvolle Verletzung der ersten Normalform ist die Speicherung von Titel, Vorname und Nachname in einem einzigen Datenfeld. Solange in dem System nicht auf die Einzelkomponenten des Namens zugegriffen werden muss, wäre eine Speicherung der einzelnen Namenskomponenten in einem einzigen Textfeld ebenfalls eine gute Möglichkeit zur Vereinfachung des Systems.
Bei den meisten Datenbanken wird die Straße und die Hausnummer (mit evtl. noch ergänzenden Buchstaben) in einem einzigen Datenfeld gespeichert, obwohl das strenggenommen auch gegen die erste Normalform verstößt.
[Bearbeiten] Rücknahme der zweiten oder dritten Normalform
Die zweite und die dritte Normalform fordern, dass alle abhängigen Attribute allein vom Primärschlüssel abhängig sein dürfen. Alle Relationen, die diese Forderungen nicht erfüllen, müssen aufgespalten werden. Dadurch entstehen viele neue kleinere Tabellen. Um auf diese Daten zuzugreifen, müssen die Daten dieser Einzeltabellen wieder zusammengeführt werden durch Verwenden von SQL-Statements mit Joins. Die Ausführung eines Joins ist für das DBMS meistens zeitaufwändiger, als der Zugriff auf eine einzige Tabelle.
Die zweite oder dritte Normalform wird meistens zurückgenommen mit dem Ziel, einen Join zu vermeiden. Es betrifft typischerweise zwei Tabellen, die in einer 1:N-Beziehung zueinander stehen. Beispiel: Mitarbeiter und Abteilung. Wenn viele performance-kritische Lesezugriffe die Daten der Mitarbeiter und zusätzlich den Abteilungsnamen benötigen, dann kann die zusätzliche Speicherung des Abteilungsnamens in jedem Satz der Mitarbeitertabelle sinnvoll sein. Diese Zugriffe können dann alleine aus den Daten in der Mitarbeitertabelle bedient werden. Der zusätzliche Zugriff auf die Abteilungs-Tabelle ist nicht mehr erforderlich.
Diese Art der Denormalisierung wird perfektioniert bei der Modellierung von Dimensions-Tabellen für ein Data Warehouse (Datenlager). Bei denormalisierten Dimensions-Tabellen spricht man von einem Sternschema. Im Gegensatz dazu steht das Schneeflockenschema, bei dem die Dimensionstabellen normalisiert gestaltet werden. Durch die Normalisierung hat das Schneeflockenschema viel mehr Tabellen, als das Sternschema. Das Sternschema ist dadurch einfacher und übersichtlicher. Dadurch wird auch die Gestaltung von Abfragen einfacher und die Ausführung der Abfragen wird performanter. In der Praxis wird meistens dem Sternschema der Vorzug gegeben.
[Bearbeiten] Vorweggenommene Aggregation
Zur Ausführung von Abfragen müssen oft umfangreiche Aggregationen ausgeführt werden. Das ist besonders bei OLAP-Systemen der Fall. Wenn die Antwortzeit der Abfragen in nicht mehr akzeptable Bereiche kommt, dann können die Aggregationen auch vorweg berechnet und gespeichert werden. Ideal ist das bei Systemen, die nur in der Nacht aktualisiert werden. Dann werden nach der eigentlichen Aktualisierung der Daten auch alle möglichen Aggregationen berechnet und gespeichert. Wenn dann ein Anwender während des Tages eine Kennzahl (KPI) anfordert, dann sind alle dafür erforderlichen Aggregationen bereits vorhanden und die Kennzahl kann sekundenschnell ausgegeben werden.
[Bearbeiten] Fragmentierung
Man unterscheidet horizontale und vertikale Fragmentierung.
Bei der Horizontalen Fragmentierung wird die Gesamtheit aller Datensätze einer Relation auf mehrere Tabellen aufgeteilt. Wenn diese Tabellen auf demselben Server liegen, dann handelt es sich meistens um Partitionierung. Die einzelnen Tabellen können aber auch auf unterschiedlichen Servern liegen. So können z.B. die Daten für die Geschäfte in den USA auch auf einem Server in den USA liegen und die Daten für die Geschäfte mit Europa liegen auf einem Server in Deutschland. Diese Aufteilung wird auch als Regionalisierung bezeichnet.
Horizontale Fragmentierung schafft keine Redundanz der gespeicherten Daten, sondern der Strukturen. Wenn eine Relation geändert werden muss, dann muss nicht nur eine Tabelle geändert werden, sondern alle Tabellen, über die die Daten aus der betreffenden Relation verteilt werden, müssen geändert werden.
Bei der Vertikalen Fragmentierung werden die abhängigen Attribute (nicht-Schlüssel-Attribute) einer Tabelle in zwei oder mehrere Gruppen aufgeteilt. Aus jeder Gruppe wird eine eigene Tabelle. Jede Tabelle erhält zusätzlich alle Schlüssel-Attribute. Das kann dann sinnvoll sein, wenn alle Attribute einer Relation Datensätze mit einer Satzlänge von mehreren Kilobyte ergeben. Wenn zusätzlich noch die Zugriffe meistens nur einige wenige Attribute betreffen, dann kann man die wenigen häufig zugegriffenen Attribute in eine Gruppe zusammenfassen und den Rest in eine zweite Gruppe zusammenfassen. Die häufig auszuführenden Zugriffe werden dadurch schneller, weil eine geringere Menge an Daten von der Festplatte gelesen werden muss. Die selten auszuführenden Zugriffe auf die restlichen Attribute werden dadurch nicht schneller, aber auch nicht langsamer.
[Bearbeiten] Partitionierung
Partitionierung ist ein Spezialfall der horizontalen Fragmentierung.
Große Datenbestände lassen sich leichter administrieren, wenn die Daten einer Relation in mehrere kleine Teile (=Partitionen) aufgeteilt und diese separat gespeichert werden. Wenn eine Partition einer Tabelle gerade aktualisiert wird, dann können andere Partitionen der Tabelle zur selben Zeit reorganisiert werden. Wenn in einer Partition ein Fehler entdeckt wird, dann kann diese einzelne Partition aus einer Datensicherung wiederhergestellt werden, während Programme auf die anderen Partitionen weiter zugreifen können. Die meisten etablierten Datenbankhersteller bieten Partitionierung an, siehe z.B. Partitionierung bei DB2 und Partitionierung bei MySQL.
Die meisten Datenbanksysteme bieten die Möglichkeit, entweder einzelne Partitionen anzusprechen oder alle Partitionen unter einem einheitlichen Tabellennamen anzusprechen.
Durch Partitionierung können die Datenzugriffe beschleunigt werden. Der wesentliche Vorteil ist jedoch die leichtere Administrierbarkeit der gesamten Tabelle.
[Bearbeiten] Index
Die Erstellung eines Index ist auch eine redundante Datenspeicherung und damit - genau genommen - eine Denormalisierung. Die meisten Datenbankmanagementsysteme sind in der Lage, einen Index automatisch zu aktualisieren, wenn die Daten in der Basistabelle verändert werden. Indices sind vor allem dann gut geeignet zur Leistungssteigerung, wenn die Daten selten geändert, aber sehr oft gelesen werden. Es gibt Datenbanken, für die so viele Indices definiert wurden, dass alle Abfragen alleine aus den in den Indices gespeicherten Daten ausgeführt werden können (index only requests). Dadurch vervielfacht sich das zu speichernde Datenvolumen und Datenänderungen werden deutlich aufwändiger. Die Leseleistung kann jedoch mit exzellenten Zugriffszeiten glänzen.
[Bearbeiten] Nachteile
Nachteilig ist oft der zusätzliche Aufwand, der getrieben werden muss, um die redundanten Daten konsistent zu halten. Es besteht die Gefahr von Datenanomalien auf Grund der redundanten Speicherung.
Diese Gefahr kann aufgehoben werden, wenn es gelingt, die Aktualisierung der redundant gespeicherten Daten an das Datenbankmanagementsystem zu delegieren.
Die Datenbankhersteller bieten verschiedene Funktionen, um redundant gespeicherte Daten automatisch abzugleichen.
- Dass die Aktualisierung eines Index automatisch erfolgt, ist schon so selbstverständlich, dass man es gar nicht anders erwartet.
- Die Vorwegnahme von Aggregationen wird durch Materialized Views unterstützt, die diese Aggregationen automatisch im erforderlichen Umfang aktualisieren.
- Ferner gibt es Trigger, mit denen redundant gespeicherte Daten automatisch aktualisiert werden können.
Wenn das Datenbankmanagementsystem solche Aufgaben übernimmt, dann mag die Aktualisierung eines einzelnen Datensatzes dadurch nur unmerklich verlangsamt werden. Massendatenverarbeitungen können durch die Nutzung solcher Funktionen allerdings deutlich langsamer werden.
Meistens hat eine Denormalisierung einen zusätzlichen Speicherbedarf zur Folge. Oft ist man jedoch bereit, für eine Verbesserung der Leistung die Kosten für zusätzlichen Speicherplatz zu tragen. Im Einzelfall muss abgewogen werden, ob die Vorteile es wert sind, die damit verbundenen Nachteile in kauf zu nehmen.
[Bearbeiten] Weblinks
Computerwoche 34/1992: Die Denormalisierung trägt zur Perfonnance-Steigerung bei
