Ist in Bezug auf Datenbanken das Mantra "Normalisieren für Korrektheit, Denormalisieren für Leistung" richtig?

Question

Die Normalisierung führt zu vielen wesentlichen und wünschenswerten Eigenschaften, einschließlich des ästhetischen Genusses. Außerdem ist sie auch theoretisch "richtig". In diesem Zusammenhang wird die Denormalisierung als Kompromiss angewandt, als Korrektur, um Leistung zu erzielen. Gibt es außer der Leistung noch einen anderen Grund, warum eine Datenbank denormalisiert werden könnte?

Answer 1

Die beiden häufigsten Gründe für eine Denormalisierung sind:

1. Leistung
2. Unwissenheit

Ersteres sollte mit einem Profiling überprüft werden, während letzteres mit einer zusammengerollten Zeitung korrigiert werden sollte ;-)

Ich würde sagen, ein besseres Mantra wäre "normalisieren für Korrektheit, denormalisieren für Geschwindigkeit - und nur wenn nötig".

Answer 2

Um die Bedeutung der ursprünglichen Frage vollständig zu verstehen, müssen Sie etwas über die Teamdynamik in der Systementwicklung und die Art des Verhaltens (oder Fehlverhaltens) verstehen, zu dem verschiedene Rollen/Typen von Menschen prädisponiert sind. Normalisierung ist wichtig, weil es nicht nur eine sachliche Debatte über Entwurfsmuster ist, sondern auch viel damit zu tun hat, wie Systeme im Laufe der Zeit entworfen und verwaltet werden.

Datenbankmitarbeiter sind darauf geschult, dass die Integrität der Daten von größter Wichtigkeit ist. Wir denken gerne in Begriffen der 100%igen Korrektheit von Daten, so dass man, wenn die Daten einmal in der DB sind, nicht mehr darüber nachdenken oder sich damit befassen muss, ob sie jemals logisch falsch sind. Diese Denkweise misst der Normalisierung einen hohen Stellenwert bei, weil sie ein Team dazu zwingt, sich mit der zugrunde liegenden Logik der Daten und des Systems auseinanderzusetzen. Ein triviales Beispiel: Hat ein Kunde nur einen Namen und eine Adresse, oder könnte er mehrere haben? Irgendjemand muss das entscheiden, und das System ist darauf angewiesen, dass diese Regel konsequent angewendet wird. Das klingt nach einem einfachen Problem, aber multiplizieren Sie dieses Problem mit dem 500-fachen, wenn Sie ein einigermaßen komplexes System entwerfen, und Sie werden das Problem erkennen - Regeln können nicht nur auf dem Papier bestehen, sie müssen durchgesetzt werden. Ein gut normiertes Datenbankdesign (mit zusätzlicher Hilfe von Eindeutigkeitsbeschränkungen, Fremdschlüsseln, Prüfwerten, logikerzwingenden Triggern usw.) kann Ihnen helfen, ein gut definiertes Kerndatenmodell und Regeln für die Datenkorrektheit zu haben, was wirklich wichtig ist, wenn Sie wollen, dass das System wie erwartet funktioniert, wenn viele Leute an verschiedenen Teilen des Systems arbeiten (verschiedene Anwendungen, Berichte, was auch immer) und verschiedene Leute im Laufe der Zeit an dem System arbeiten. Oder anders ausgedrückt: Wenn Sie keine Möglichkeit haben, ein solides Kerndatenmodell zu definieren und operativ durchzusetzen, wird Ihr System schlecht funktionieren.

Andere Leute (oft weniger erfahrene Entwickler) sehen das anders. Sie sehen die Datenbank bestenfalls als ein Werkzeug, das der Anwendung, die sie entwickeln, untergeordnet ist, oder schlimmstenfalls als eine zu vermeidende Bürokratie. (Beachten Sie, dass ich von "weniger erfahrenen" Entwicklern spreche. Ein guter Entwickler wird sich der Notwendigkeit eines soliden Datenmodells und der Korrektheit der Daten ebenso bewusst sein wie ein Datenbankexperte. Sie mögen unterschiedlicher Meinung darüber sein, was der beste Weg ist, um dies zu erreichen, aber meiner Erfahrung nach sind sie ziemlich offen dafür, diese Dinge in einer DB-Schicht zu tun, solange das DB-Team weiß, was es tut und auf die Entwickler eingehen kann.) Diese weniger erfahrenen Leute sind oft diejenigen, die auf die Denormalisierung drängen, mehr oder weniger als Ausrede für eine schnelle und schmutzige Arbeit beim Entwurf und der Verwaltung des Datenmodells. Auf diese Weise entstehen Datenbanktabellen, die 1:1 mit den Anwendungsbildschirmen und Berichten übereinstimmen, wobei jede Tabelle die Entwurfsannahmen eines anderen Entwicklers widerspiegelt, und die Tabellen sind völlig uneinheitlich und inkohärent. Ich habe das in meiner Laufbahn schon mehrmals erlebt. Es ist eine entmutigende und äußerst unproduktive Art, ein System zu entwickeln.

Ein Grund dafür, dass die Menschen ein starkes Gefühl für die Normalisierung haben, ist also, dass das Thema stellvertretend für andere Themen steht, die ihnen am Herzen liegen. Wenn Sie in eine Debatte über Normalisierung hineingezogen werden, denken Sie an die zugrunde liegende (nicht-technische) Motivation, die die Parteien in die Debatte einbringen könnten.

Dies vorausgeschickt, hier eine direktere Antwort auf die ursprüngliche Frage :)

Es ist sinnvoll, sich Ihre Datenbank so vorzustellen, dass sie aus einem Kerndesign, das einem logischen Design so nahe wie möglich kommt - hochgradig normalisiert und eingeschränkt - und einem erweiterten Design besteht, das andere Aspekte wie stabile Anwendungsschnittstellen und Leistung berücksichtigt.

Sie sollten Ihr Kerndatenmodell einschränken und normalisieren wollen, denn wenn Sie das nicht tun, gefährden Sie die grundlegende Integrität der Daten und alle Regeln/Annahmen, auf denen Ihr System aufbaut. Wenn Sie diese Aspekte außer Acht lassen, kann Ihr System sehr schnell unbrauchbar werden. Testen Sie Ihr Kerndatenmodell anhand von Anforderungen und realen Daten, und iterieren Sie wie verrückt, bis es funktioniert. Dieser Schritt wird sich eher wie die Klärung von Anforderungen anfühlen als die Entwicklung einer Lösung, und das sollte er auch. Verwenden Sie das Kerndatenmodell als Zwangsfunktion, um klare Antworten auf diese Designfragen für alle Beteiligten zu erhalten.

Vervollständigen Sie Ihr Kerndatenmodell, bevor Sie mit dem erweiterten Datenmodell fortfahren. Nutzen Sie es und sehen Sie, wie weit Sie damit kommen. Abhängig von der Datenmenge, der Anzahl der Benutzer und den Nutzungsmustern benötigen Sie vielleicht nie ein erweitertes Datenmodell. Schauen Sie, wie weit Sie mit der Indizierung und den 1.001 leistungsbezogenen Knöpfen, die Sie in Ihrem DBMS drehen können, kommen.

Wenn Sie die Leistungsmanagement-Funktionen Ihres DBMS wirklich ausschöpfen wollen, müssen Sie Ihr Datenmodell so erweitern, dass eine Denormalisierung hinzugefügt wird. Dabei geht es nicht um die Denormalisierung Ihres Kerndatenmodells, sondern um das Hinzufügen neuer Ressourcen, die die Denormdaten verarbeiten. Wenn es beispielsweise einige große Abfragen gibt, die Ihre Leistung erdrücken, sollten Sie einige Tabellen hinzufügen, die die Daten, die diese Abfragen erzeugen würden, vorberechnen, d. h. die Abfrage wird im Wesentlichen vorab ausgeführt. Es ist wichtig, dies so zu tun, dass die Kohärenz der denormalisierten Daten mit den (normalisierten) Kerndaten erhalten bleibt. In DBMS, die dies unterstützen, können Sie zum Beispiel eine MATERIALIZED VIEW verwenden, um die Pflege der denormalisierten Daten zu automatisieren. Wenn Ihr DBMS diese Möglichkeit nicht bietet, können Sie vielleicht Trigger für die Tabellen erstellen, in denen die zugrunde liegenden Daten vorhanden sind.

Es besteht ein himmelweiter Unterschied zwischen Selektiv Denormalisierung einer Datenbank in einem kohärent die Art und Weise, wie man mit einer realistischen Leistungsherausforderung umgeht, im Gegensatz zu einem schwachen Datendesign, bei dem man die Leistung als Rechtfertigung dafür benutzt.

Wenn ich mit wenig bis mittelmäßig erfahrenen Datenbankmitarbeitern und -entwicklern zusammenarbeite, bestehe ich darauf, dass sie ein absolut normalisiertes Design erstellen ... und kann dann später eine kleine Anzahl erfahrenerer Mitarbeiter in eine Diskussion über selektive Denormalisierung einbeziehen. Denormalisierung ist in Ihrem Kerndatenmodell mehr oder weniger immer schlecht. Außerhalb des Kerns ist an der Denormalisierung überhaupt nichts auszusetzen, wenn Sie sie überlegt und kohärent durchführen.

Mit anderen Worten, eine Denormalisierung von einem normalen Entwurf zu einem Entwurf, der das Normale beibehält und gleichzeitig etwas Denormales hinzufügt - das sich mit der physischen Realität Ihrer Daten befasst, während die wesentliche Logik erhalten bleibt - ist in Ordnung. Entwürfe, die keinen Kern aus normalem Design haben - die man nicht einmal als de-normalisiert bezeichnen sollte, weil sie von vornherein nie normalisiert waren, weil sie nie bewusst auf disziplinierte Weise entworfen wurden - sind nicht in Ordnung.

Akzeptieren Sie nicht die Terminologie, dass ein schwaches, undiszipliniertes Design ein "denormalisiertes" Design ist. Ich glaube, dass die Verwirrung zwischen absichtlich/vorsichtig denormalisierten Daten und einfachem, altem, beschissenem Datenbankdesign, das zu denormalen Daten führt, weil der Designer ein unvorsichtiger Idiot war, die Hauptursache für viele der Debatten über Denormalisierung ist.

Answer 3

Die Denormalisierung führt normalerweise zu einer Verbesserung der Abfrageeffizienz (warum sollte man sie sonst überhaupt durchführen?), aber zu einem enormen Aufwand bei der Validierung der Daten während der Änderungsoperationen (Einfügen, Aktualisieren, manchmal sogar Löschen). Meistens wird die zusätzliche Komplexität ignoriert (weil sie zu schwer zu beschreiben ist), was zu falschen Daten in der Datenbank führt, die oft erst später entdeckt werden - z. B. wenn jemand versucht herauszufinden, warum das Unternehmen in Konkurs gegangen ist, und sich herausstellt, dass die Daten selbst inkonsistent waren, weil sie denormalisiert wurden.

Ich denke, das Mantra sollte lauten: "Normalisieren Sie aus Gründen der Korrektheit, denormalisieren Sie nur, wenn die Unternehmensleitung Ihnen anbietet, Ihre Stelle an jemand anderen zu vergeben", und dann sollten Sie die Gelegenheit wahrnehmen, neue Wege zu beschreiten, da die derzeitige Stelle möglicherweise nicht so lange erhalten bleibt, wie Sie es sich wünschen.

Oder: "Denormalisieren Sie nur, wenn die Geschäftsleitung Ihnen eine E-Mail schickt, die Sie von dem entstehenden Chaos entlastet".

Dies setzt natürlich voraus, dass Sie von Ihren Fähigkeiten und Ihrem Wert für das Unternehmen überzeugt sind.

Answer 4

Mantras vereinfachen fast immer ihr Thema. Dies ist ein typisches Beispiel dafür.

Die Vorteile der Normalisierung sind mehr als nur theoretischer oder ästhetischer Natur. Für jede Abweichung von einer Normalform für 2NF und darüber hinaus gibt es eine Aktualisierungsanomalie, die auftritt, wenn man die Normalform nicht befolgt, und die verschwindet, wenn man die Normalform befolgt. Die Abweichung von der 1NF ist ein ganz anderes Thema, auf das ich hier nicht eingehen werde.

Bei diesen Aktualisierungsanomalien handelt es sich im Allgemeinen um das Einfügen neuer Daten, das Aktualisieren vorhandener Daten und das Löschen von Zeilen. In der Regel lassen sich diese Anomalien durch geschickte, trickreiche Programmierung umgehen. Die Frage ist dann, ob der Nutzen einer geschickten, trickreichen Programmierung die Kosten wert ist. Manchmal sind die Kosten Bugs. Manchmal ist der Preis der Verlust der Anpassungsfähigkeit. Manchmal sind die Kosten sogar, ob Sie es glauben oder nicht, eine schlechte Leistung.

Wenn Sie die verschiedenen Normalformen lernen, sollten Sie Ihr Lernen als unvollständig betrachten, bis Sie die dazugehörige Aktualisierungsanomalie verstehen.

Das Problem mit "denormalisieren" als Leitfaden ist, dass er Ihnen nicht sagt, was Sie tun sollen. Es gibt zahllose Möglichkeiten, eine Datenbank zu denormalisieren. Die meisten davon sind unglücklich, und das ist noch milde ausgedrückt. Eine der dümmsten Methoden ist es, einfach einen Schritt nach dem anderen zu denormalisieren, jedes Mal, wenn man eine bestimmte Abfrage beschleunigen will. Das Ergebnis ist ein verrücktes Durcheinander, das ohne Kenntnis der Anwendungshistorie nicht zu verstehen ist.

Viele Denormalisierungsschritte, die "zum damaligen Zeitpunkt eine gute Idee" zu sein schienen, stellen sich später als sehr schlechte Maßnahmen heraus.

Wenn Sie sich gegen eine vollständige Normalisierung entscheiden, gibt es eine bessere Alternative: Sie sollten eine Entwurfsdisziplin anwenden, die bestimmte Vorteile bietet, auch wenn diese Entwurfsdisziplin von der vollständigen Normalisierung abweicht. Ein Beispiel dafür ist der Entwurf von Sternschemata, der in Data Warehousing und Data Marts weit verbreitet ist. Dies ist ein weitaus kohärenterer und disziplinierterer Ansatz als die bloße Denormalisierung nach Gutdünken. Ein Sternschema bietet bestimmte Vorteile, die Sie den Aktualisierungsanomalien gegenüberstellen können, die Sie erleiden werden, weil das Sternschema dem normalisierten Design widerspricht.

Im Allgemeinen bauen viele Leute, die Sternschemata entwerfen, eine sekundäre Datenbank auf, eine, die nicht mit den OLTP-Anwendungsprogrammen interagiert. Eines der schwierigsten Probleme bei der Pflege einer solchen Datenbank ist die so genannte ETL-Verarbeitung (Extract, Transform, Load). Die gute Nachricht ist, dass all diese Verarbeitungen in einer Handvoll von Programmen zusammengefasst werden können, und die Anwendungsprogrammierer, die mit der normalisierten OLTP-Datenbank arbeiten, müssen sich nicht mit diesen Dingen befassen. Es gibt Tools, die bei ETL helfen, und das Kopieren von Daten aus einer normalisierten OLTP-Datenbank in einen Star Schema Data Mart oder ein Warehouse ist ein wohlbekannter Fall.

Wenn Sie einmal ein Sternschema erstellt haben und Ihre Dimensionen gut ausgewählt, Ihre Spalten klug benannt und vor allem Ihre Granularität gut gewählt haben, wird die Verwendung dieses Sternschemas mit OLAP-Tools wie Cognos oder Business Objects fast so einfach wie ein Videospiel. So können sich Ihre Datenanalysten auf die Analyse der Daten konzentrieren, anstatt zu lernen, wie der Datencontainer funktioniert.

Neben dem Sternschema gibt es noch andere Entwürfe, die von der Normalisierung abweichen, aber das Sternschema ist eine besondere Erwähnung wert.

Answer 5

Vergessen Sie nicht, dass jedes Mal, wenn Sie einen Teil Ihrer Datenbank denormalisieren, Ihre Fähigkeit, sie weiter anzupassen, abnimmt, da das Risiko von Fehlern im Code steigt und das gesamte System immer weniger tragfähig wird.

Viel Glück!