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 die physische Sicht der Datenbank. Sie beschreibt, wie auf dem Speichermedium im Computer die Daten abgelegt werden.

Ein logisch ideales ("normalisiertes") Datenmodell ist volkommen redundanzfrei - abgesehen von der technisch notwendigen Mehrfachspeicherung von Fremdschlüsseln bei Primärschlüssel-Fremdschlüssel-Beziehungen.

Die Zugriffszeit einer SQL-Abfrage hängt wesentlich davon ab, wie viele Tabellen miteinander verknüpft werden müssen. Um eine bessere Zugriffs-Performens zu erreichen, ist es in vielen Fällen sinnvoll, die Inhalte von mehreren Tabellen in einer Tabelle zu speichern. Damit kann die Ausführung eines Joins bei der Evaluierung einer Abfrage vermieden werden.

Mit Denormalisierungen lassen sich oftmals wesentlich größere Performance-Verbesserungen erreichen als mit einem Tuning der Datenbankinstallation.

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.

Die Begründung zur Rücknahme der zweiten oder dritten Normalform ist meistens die Vermeidung eines Joins und damit die Vereinfachung und Beschleunigung der Lesezugriffe. Es betrifft typischerweise zwei Tabellen, die in einer 1:N-Beziehung zueinander stehen. Beispiel: Mitarbeiter und Abteilung. Wenn viele performenskritische 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 oft perfektioniert bei der Modellierung von Dimensions-Tabellen für ein Data Warehouse (Datenlager). Bei normalisierten Dimensions-Tabellen spricht man von einem Schneeflockenschema. Bei denormalisierten Dimensions-Tabellen spricht man von einem Sternschema. Ein Sternschema kommt mit viel weniger Tabellen aus. Dadurch wird die Gestaltung von Abfragen einfacher und die Ausführung der Abfragen wird performanter. In der Praxis wird meistens dem Sternschema der Vorzug gegeben.

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.

Man unterscheidet horizontale und vertikale Fragmentierung.

Bei der Horizontalen Fragmentierung wird die Gesamtheit aller Datensätze auf mehrere Tabellen aufgeteilt. Wenn diese Tabellen auf dem selben 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.

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 zu einem Schlüssel ein großes Datenvolumen haben (z.B. >4KB) jedoch nur auf wenige Attribute sehr häufig zugegriffen wird. Dann kann man die wenigen häufig zugegriffenen Attribute in eine Gruppe zusammenfassen und den Rest in eine zweite Gruppe zusammenfassen.

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 Erstellung von Indices ist auch eine redundante Datenspeicherung und damit - genau genommen - eine Denormalisierung. Der Vorteil eines Index liegt darin, dass die Datenbank diese Datenstruktur selber aktualisiert bei jeder Änderung der Basistabelle. Indices sind vor allem dann gut geeignet zur Performens-Steigerung, wenn die Daten selten geändert werden 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 sehr aufwändig. Die Lese-Performens kann jedoch mit excelenten Zugriffszeiten glänzen.

Nachteilig ist oft der zusätzliche Aufwand der getrieben werden muss, um die redundanten Daten konsistent zu halten und die Gefahr von Datenanomalien auf Grund der redundanten Speicherung.

Dieser Nachteil kann jedoch in vielen Fällen praktisch aufgehoben werden, wenn es gelingt, die Aktualisierung der redundant gespeicherten Daten an das Datenbankmanagementsystem zu delegieren.

Die Datenbankhersteller bieten verschiedene Funktionen, um redundant gespeicherte Informationen automatisch zu aktualisieren.

• Dass die Aktualisierung eines Index automatisch erfolgt, ist schon so selbstverständlich, dass man es gar nicht anders erwartet.
• Die einzelnen Partitionen einer Tabelle können unter einem einheitlichen Tabellennamen angesprochen werden.
• 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 Performens 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.