Kann nicht entscheiden, ob Normalisierung oder De-Normalisierung funktionieren würde

Question

Diese Frage kann ein bisschen breit sein!

Kürzlich lerne ich MySQL. Ich mache eine Informationsdatenbank für Schulprüfungen. Ich habe eine Tabelle mit dem Namen subjects erstellt, in der Informationen zu verschiedenen Themen gespeichert sind, einschließlich vollständiger Name oder vollständige Markierungen für jedes Thema. Ich habe auch eine andere Tabelle mit dem Namen exams erstellt, in der die von jedem Schüler zu jedem Thema erhaltenen Noten gespeichert sind. Offensichtlich ist subjects die Haupttabelle und exams ist die untergeordnete Tabelle hier. Basierend auf den Daten, die in diesen beiden Tabellen gespeichert sind, werden Informationen wie Prozentsatz und Note für jeden Schüler zusammengefügt.

Aber was ist, wenn sich die bestimmte Information in der subjects Tabelle in Zukunft ändert. Sagen Sie, dass die vollständigen Noten für ein bestimmtes Thema geändert werden. In diesem Fall sind die älteren Datensätze in der Tabelle ungültig oder falsch , weil der Join nun neue Werte erzeugt, die für aktuelle Datensätze korrekt sind, aber für ältere Datensätze falsch sind.

Was soll ich in dieser Situation tun? Zerlege ich beide Tabellen zu einer vollständigen Tabelle? Aber mein schüchternes Wissen im Datenbankdesign sagt, dass das eine falsche Praxis ist!

Jede Hilfe oder Einsicht wird sehr geschätzt.

Answer 1

Sie können der Tabelle subjects eine neue Zeile hinzufügen, anstatt eine vorhandene zu ändern, wenn sich ein Betreff ändert. Also, die Betreff - Tabelle enthält Versionen von Themen. Dies kann mit Gültigkeitsdaten kombiniert werden. Nach dem Anwenden des Ansatzes benötigen Sie einen Normalisierungsschritt. Dies könnte sein, was mit einem der Kommentare gemeint ist.

Answer 2

Sie müssen modellieren Sie Ihre historische Situation (en), so wie Sie Ihre aktuelle Situation modelliert haben.

Sie können oder nicht wählen, vergangene Daten zu denormalisieren. Der größte Nutzen pro Aufwand besteht jedoch darin, historische Situationstabellen wie die aktuellen Situationstabellen aussehen zu lassen oder tatsächlich zu sein. Dies beinhaltet Investitionen in weiter normalisieren aktuellen Zeilen in Untergruppen, die Sie dann um ein Datum erweitern, so dass Sie Unterserien von demselben Datum zusammenfügen können.

Wenn duplizierte Daten eine demonstrierte Last ist/werden, können Sie eine Tabelle in mehrere Tabellen aufteilen, für Unterverzweigungen, denen Sie die letzte Änderung zuordnen möchten, während andere Unterverzweigungen seit einer früheren Änderung veraltet sind. Dann können Sie Reihen zusammenführen, die zu einem bestimmten Datum die neuesten sind. In einigen "temporalen" Datenbanken minimieren wir redundante Daten, indem wir Zeilen in Unterzeilen aufteilen und nicht nur datieren, sondern sie mit einem Datumsbereich versehen, in dem sie aktuell sind.

Von a recent answer of mine:

Vorschläge zu hart löschen davon ausgehen, dass Sie historische Daten gewünscht halten. Beschränken Sie nicht Ihr Denken darüber, dies zu erreichen, indem Sie nur FKs deklassieren, kaskadieren, eine Flagge/Datumsspalte zu einer vorhandenen Tabelle hinzufügen oder irgendetwas anderes. Richtig modellieren Sie beide vorhandenen & Vergangenheit einschließlich Datenbankänderungen, die als eine DBMS-Transaktion bei jeder ausgewählten Anwendungssituation Änderung auftreten müssen. Vorschläge für das Soft-Delete beinhalten nur das Einfügen bestimmter aktueller und historischer Daten in dieselbe Tabelle gegenüber anderen. Dies funktioniert nur für sehr einfache Modelle von aktuellen & historischen Situationen.

Es ist normalerweise einfach, eine Datenbank nur für eine aktuelle Anwendungssituation zu entwerfen. Aber wenn wir uns um die Vergangenheit kümmern, kümmern wir uns normalerweise nur um etwas davon. Wenn dies der Fall ist, können wir bei bestimmten Anwendungssituationen, die sich von aktuell zu aktuell ändern, einen Schnappschuss des relevanten aktuellen Zustands in den historischen Zustand kopieren. Das Kennzeichnen von Daten mit Soft-Delete-Flags vs. Datumsangaben ist die kombinierte Tabellenversion von undatierten vs datierten historischen Daten, bei denen wir uns nur um aktuelle und vergangene Situationen kümmern, und nur dann, wenn eine Änderung auftrat.

"Temporal" -Datenbanken erfassen mehr oder weniger die aktuelle Situation und eine Reihe von einmal datierten aktuellen Situationen. Diese Aufzeichnung vergangener Daten unter Verwendung der Struktur für aktuelle Daten vereinfacht das Verstehen & Abfragen von aktuellen & vergangenen Daten. (Die Abfrage nach Zeitintervallen, die eine temporäre Datenbank erleichtern kann, kann ziemlich kompliziert werden.) Es stellt sich jedoch heraus, dass das Erstellen einer temporalen Version eines gegebenen aktuellen Datenentwurfs nicht nur das Hinzufügen von Datumsspalten zu vorhandenen aktuellen Datentabellen beinhaltet. Dazu müssen die aktuellen Daten umgestaltet und in kleinere Tabellen mit mehr Einschränkungen unterteilt werden. Dies liegt daran, dass verschiedene Arten von Anwendungssituationsänderungen erfordern, dass verschiedene Spaltenkombinationen des vorhandenen aktuellen Datenentwurfs verwendet werden. (Hard-und Soft-historische Snapshot-Designs müssen dies adressieren, aber für eine begrenzte Vergangenheit/Geschichte.)