Wie bestimmen Sie, wie weit eine Datenbank normalisiert werden soll?

StackOverflow https://stackoverflow.com/questions/47711

Frage

Welche guten Richtlinien sind beim Erstellen einer Datenbankstruktur zu befolgen oder welche guten Möglichkeiten gibt es, um zu bestimmen, wie weit eine Datenbank normalisiert werden sollte?Sollten Sie eine nicht normalisierte Datenbank erstellen und diese im Verlauf des Projekts aufteilen?Sollten Sie es vollständig normalisiert erstellen und Tabellen nach Bedarf für die Leistung kombinieren?

War es hilfreich?

Lösung

Sie möchten mit dem Entwurf einer normalisierten Datenbank bis zur 3. Normalform beginnen.Während Sie die Geschäftslogikschicht entwickeln, entscheiden Sie möglicherweise, dass Sie ein wenig denormalisieren müssen, aber Niemals Gehen Sie unter die 3. Form.Achten Sie immer darauf, dass die 1. und 2. Form konform sind.Sie möchten aus Gründen der Einfachheit des Codes denormalisieren, nicht aus Gründen der Leistung.Verwenden Sie dazu Indizes und gespeicherte Prozeduren :)

Der Grund für die Nicht-Normalisierung liegt darin, dass Sie den Code, den Sie bereits geschrieben haben, jedes Mal ändern müssten, wenn Sie das Datenbankdesign ändern.

Es gibt ein paar gute Artikel:

http://www.agiledata.org/essays/dataNormalization.html

Andere Tipps

@GrizzlyGuru Ein weiser Mann hat mir einmal gesagt: „Normalisiere, bis es weh tut, denormalisiere, bis es funktioniert.“

Es hat mich noch nicht im Stich gelassen :)

Ich bin nicht damit einverstanden, damit in nicht normalisierter Form zu beginnen. Meiner Erfahrung nach war es jedoch einfacher, Ihre Anwendung an eine weniger normalisierte Datenbank anzupassen als an eine stärker normalisierte.Es könnte auch zu Situationen führen, in denen es „gut genug“ funktioniert, sodass Sie nie dazu kommen, es zu normalisieren (bis es zu spät ist!)

Normalisierung bedeutet, redundante Daten zu eliminieren.Mit anderen Worten: Eine nicht normalisierte oder denormalisierte Datenbank ist eine Datenbank, in der dieselben Informationen an mehreren verschiedenen Stellen wiederholt werden.Das bedeutet, dass Sie eine komplexere Update-Anweisung schreiben müssen, um sicherzustellen, dass Sie überall die gleichen Daten aktualisieren. Andernfalls erhalten Sie inkonsistente Daten, was wiederum bedeutet, dass die Ausgabe von Abfragen unzuverlässig ist.

Das ist ein ziemlich großes Problem, daher würde ich sagen, dass Denormalisierung weh tut, nicht umgekehrt.

In manchen Fällen können Sie sich bewusst dafür entscheiden, bestimmte Teile einer Datenbank zu denormalisieren, wenn Sie der Meinung sind, dass der Nutzen den zusätzlichen Aufwand bei der Datenaktualisierung und das Risiko einer Datenbeschädigung überwiegt.Beispielsweise bei Datawarehouses, bei denen Daten aus Leistungsgründen aggregiert werden und Daten häufig nach der Ersteingabe nicht aktualisiert werden, wodurch das Risiko von Inkonsistenzen verringert wird.

Aber im Allgemeinen sollten Sie sich davor hüten, aus Leistungsgründen eine Denormalisierung vorzunehmen.Beispielsweise kann der Leistungsvorteil eines denormalisierten Joins typischerweise durch die Verwendung erreicht werden materialisierte Sicht (auch genannt indizierte Ansicht), was genauso schnell ist wie das Abfragen einer denormalisierten Tabelle, aber dennoch die Konsistenz der Daten schützt.

Jeff hat auf seinem Blog einen ziemlich guten Überblick über seine Philosophie: Vielleicht ist Normalisierung nicht normal.Die Hauptsache ist:Übertreiben Sie es nicht mit der Normalisierung.Aber ich denke, ein noch wichtigerer Punkt ist, dass es wahrscheinlich keine allzu große Rolle spielt.Sofern Sie nicht das nächste Google verwenden, werden Sie wahrscheinlich keinen großen Unterschied bemerken, bis Ihre Anwendung wächst.

Die Normierung von Datenbanken halte ich für eine Kunstform.

Sie möchten Ihre Datenbank nicht übermäßig normalisieren, da Sie sonst über zu viele Tabellen verfügen und die Abfrage selbst einfacher Objekte dadurch länger dauert, als sie sollte.

Eine gute Faustregel, die ich befolge, besteht darin, immer wieder dieselben Informationen zu normalisieren.

Wenn Sie beispielsweise eine Kontaktverwaltungsanwendung erstellen, ist es sinnvoll, die Adresse (Straße, Stadt, Bundesland, Postleitzahl usw.) anzugeben..) als eigene Tabelle.

Wenn Sie jedoch nur zwei Arten von Kontakten haben, geschäftliche oder private, benötigen Sie dann eine Kontakttypentabelle, wenn Sie wissen, dass Sie nur zwei haben werden?Für mich nicht.

Ich würde damit beginnen, zunächst herauszufinden, welche Datentypen Sie benötigen.Verwenden Sie als Hilfsmittel ein Modellierungsprogramm wie Visio.Sie möchten nicht mit einer nicht normalisierten Datenbank beginnen, da Sie irgendwann normalisieren werden.Beginnen Sie damit, Objekte in ihre logischen Gruppierungen einzuordnen. Wenn Sie sehen, dass sich Daten wiederholen, werden diese Daten in eine neue Tabelle übernommen.Ich würde mit diesem Prozess fortfahren, bis Sie das Gefühl haben, dass Sie die Datenbank entworfen haben.

Lassen Sie sich durch Tests sagen, ob Sie Tabellen kombinieren müssen.Eine gut geschriebene Abfrage kann jede übermäßige Normalisierung abdecken.

Ich glaube, dass es normalerweise am einfachsten ist, mit einer nicht normalisierten Datenbank zu beginnen und sich im Laufe der Zeit der Normalisierung zuzuwenden.Auf die Frage, wie weit man normalisieren kann, ist meine Philosophie, so lange zu normalisieren, bis es anfängt zu schmerzen.Das hört sich vielleicht ein wenig oberflächlich an, ist aber im Allgemeinen eine gute Möglichkeit abzuschätzen, wie weit man gehen muss.

Mit einer normalisierten Datenbank erhalten Sie die größte Flexibilität und die einfachste Wartung.Ich beginne immer mit einer normalisierten Datenbank und entnormalisiere sie dann nur dann, wenn es ein reales Problem gibt, das angegangen werden muss.

Ich betrachte dies ähnlich wie die Codeleistung, d. h.Schreiben Sie wartbaren, flexiblen Code und gehen Sie bei der Leistung Kompromisse ein wissen dass es ein Leistungsproblem gibt.

Auf dem Originalplakat wurde nie beschrieben, in welcher Situation die Datenbank verwendet wird.Wenn es sich um ein Data-Warehousing-Projekt irgendeiner Art handelt, bei dem Sie irgendwann Würfel (OLAP) benötigen, die Daten für ein Front-End verarbeiten, wäre es klüger, mit einem Sternschema (Faktentabellen + Dimension) zu beginnen, als sich damit auseinanderzusetzen Normalisierung.Die Kimball-Bücher werden in diesem Fall eine große Hilfe sein.

Ich stimme zu, dass es normalerweise besser ist, mit einer normalisierten Datenbank zu beginnen und diese dann zu denormalisieren, um ganz bestimmte Probleme zu lösen, aber ich würde wahrscheinlich damit beginnen Boyce-Codd-Normalform anstelle der 3. Normalform.

Die Wahrheit ist, dass "es abhängt." Es hängt von vielen Faktoren ab, einschließlich:

  • Code (handcodiert oder Tool-gesteuert (wie ETL-Pakete))
  • Primäre Anwendung (Transaktionsverarbeitung, Data Warehousing, Reporting)
  • Art der Datenbank (MySQL, DB/2, Oracle, Netezza usw.)
  • Datenbankarchitektur (tabellenförmig, spaltenförmig)
  • DBA-Qualität (proaktiv, reaktiv, inaktiv)
  • Erwartete Datenqualität (Möchten Sie die Datenqualität auf Anwendungsebene oder Datenbankebene durchsetzen?)

Ich stimme zu, dass Sie so weit wie möglich normalisieren und nur dann denormalisieren sollten, wenn dies für die Leistung unbedingt erforderlich ist.Und bei materialisierten Ansichten oder Caching-Systemen ist dies oft nicht notwendig.

Beachten Sie, dass Sie durch die Normalisierung Ihres Modells der Datenbank mehr Informationen darüber geben, wie Sie Ihre Daten einschränken können, sodass Sie das Risiko von Aktualisierungsanomalien beseitigen können, die in unvollständig normalisierten Modellen auftreten können.

Wenn Sie denormalisieren, müssen Sie entweder mit der Tatsache leben, dass es zu Aktualisierungsanomalien kommen kann, oder Sie müssen die Einschränkungsvalidierung selbst in Ihrem Anwendungscode implementieren.Dadurch werden viele Vorteile der Verwendung eines DBMS verloren, mit dem Sie diese Einschränkungen deklarativ definieren können.

Unter der Annahme der gleichen Codequalität führt die Denormalisierung möglicherweise nicht zu einer besseren Leistung.

Erwähnenswert ist auch, dass Hardware heutzutage günstig ist, sodass es oft kosteneffizienter ist, das Problem mit zusätzlicher Rechenleistung zu lösen, als die potenziellen Kosten für die Bereinigung beschädigter Daten in Kauf zu nehmen.

Wenn Sie so weit normalisieren, wie es Ihre andere Software zulässt, sind Sie oft fertig.

Wenn Sie beispielsweise die objektrelationale Mapping-Technologie verwenden, verfügen Sie über einen umfangreichen Semantiksatz für verschiedene Viele-zu-Eins- und Viele-zu-Viele-Beziehungen.Unter der Haube werden Join-Tabellen mit effektiv zwei Primärschlüsseln bereitgestellt.Obwohl dies relativ selten vorkommt, führt eine echte Normalisierung häufig zu Beziehungen mit drei oder mehr Primärschlüsseln.In solchen Fällen bleibe ich lieber beim O/R und rolle meinen eigenen Code, um die verschiedenen DB-Anomalien zu vermeiden.

Versuchen Sie einfach, Ihren gesunden Menschenverstand zu nutzen.

Einige sagen auch – und ich muss ihnen zustimmen – dass Sie, wenn Sie feststellen, dass Sie in den meisten Ihrer Abfragen 6 (die magische Zahl) Tabellen miteinander verbinden – ohne die berichtsbezogenen Tabellen –, über eine leichte Denormalisierung nachdenken sollten.

Vergiss es nicht Die Mutter aller Datenbanknormalisierungsdebatten zum Thema Coding Horror (zusammengefasst im High Scalability-Blog).

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top