Menschen, die C.J.Dates Einführung in das Datenbanksystem oder Bücher mit ähnlichem Niveau lesen, sollten keine Probleme mit der Definition von Normalisierung und Denormalisierung haben.
Allerdings ist die Erinnerung nicht mehr das, was sie einmal war, und ich sehe mir oft ein Design an und sage, dass es nicht normalisiert ist, obwohl ich nicht finden kann, welche der normalen Formen es bricht.
Das tatsächliche Beispiel, das es veranschaulicht, ist:
Wenn wir Beziehungen haben
r1 (A, B, C) und r2 (A, D)
mit FDs: AB- & gt; C und A- & gt; D
und r1 stellen Detaildaten dar, während r2 eine Zusammenfassung dieser Daten darstellt (mit anderen Worten, jede Instanz von D ist eine Funktion von Werten in r1. In diesem Beispiel sei es eine Zwischensumme von Werten C nach A von r1).
Beispiel-Beispiel
%Vor%Obwohl ich nicht sagen kann, dass es zum Beispiel 2NF oder 3NF bricht, stehe ich fest auf der Idee, dass das Design im folgenden Sinne noch denormalisiert ist (von Codd, EF "Weitere Normalisierung der Datenbank") Relationales Modell ", S. 34, kommentiert die Gründe für die Normalisierung jenseits von 1NF):
- Um die Sammlung von Beziehungen von unerwünschten Einfügungen zu befreien, Abhängigkeiten aktualisieren und löschen;
- Um die Notwendigkeit der Umstrukturierung der Sammlung von Beziehungen als neue Arten von Daten sind eingeführt, und so das Leben zu erhöhen Umfang der Anwendungsprogramme;
- Um das relationale Modell für Benutzer informativer zu gestalten;
- Um die Sammlung von Relationen für die Abfrage neutral zu machen Statistiken, wo diese Statistiken sind kann sich mit der Zeit ändern.
Wie ich sagen kann, wenn wir D als eine Summe aller Cs von r1 definieren, wobei A von r1 gleich A von r2 ist, dann, wenn wir C in r1 aktualisieren und wir D in r2 nicht aktualisieren, wir kann zu einer unerwünschten Aktualisierungsabhängigkeit führen und die Daten enden in einem inkonsistenten Zustand. Ich finde diesen Grund, r1 und r2 denormalisiert zu nennen und sie als denormalisiert zu betrachten. (Tatsächlich ist das ganze r2 eine Funktion von r1 und bringt null neue Fakten in das Modell; r2 = f (r1))
Die Fragen sind also
HINWEIS:
Für diejenigen, die die Frage (n) interessant genug finden, um eine Antwort zu geben, bitte ich Sie, entweder etwas zitierbares zur Verfügung zu stellen oder es in eine Form von spezifischen Annahmen und Schlussfolgerungen zu bringen (oder mit anderen Worten, wenn Sie es einfügen wollen) Ihre Meinung, folgen Sie bitte mit einigen Überlegungen).
BEARBEITEN Ich habe Dportas Antwort angenommen. Ich werde versuchen, hier ein wenig hinzuzufügen: C.J.Date kann eine klare und strenge Unterscheidung machen:
Ein Großteil der Design-Theorie hat damit zu tun Reduzierung der Redundanz; Normalisierung reduziert Redundanz innerhalb von relvars, Orthogonalität reduziert es quer durch relvars.
zitiert aus Datenbank in Tiefe: relationale Theorie für die Praktiker
und auf der nächsten Seite
nur als ein Fehler, alle zu normalisieren Weg impliziert Redundanz und kann zu führen gewisse Anomalien, so kann a Fehler bei der Einhaltung der Orthogonalität.
Wenn angenommen wird, dass AB ein Schlüssel in r1 ist und A ein Schlüssel in r2 ist, dann scheint es, dass das Schema in 6NF ist. Das Relational Database Dictionary (Date) definiert Denormalisierung als:
Ersetzen einer Reihe von Relvars R1, R2,. . ., Rn durch ihre Verbindung R, so dass für alles ich die Projektion von R auf der Attribute von Ri ist garantiert zu sein gleich Ri (i = 1, 2, ..., n).
Im Grunde handelt es sich bei Normalisierung / Denormalisierung um Kompositions- und Nichtverlustzerlegung mit den Operatoren projection und join . In diesem Beispiel haben Sie Redundanz durch einen anderen Operator verursacht: Summierung. Ich erwarte, dass es prinzipiell möglich wäre, eine Theorie der "Normalisierung" für andere Operatoren als Projektion und Join zu bilden, vielleicht sogar für nicht-relationale Funktionen wie Summation. So normalisiert sich die Normalisierung jedoch nicht, und in Ermangelung einer soliden Grundlage für etwas anderes sollten wir meiner Meinung nach die technische Bedeutung der Denormalisierung anwenden, wie sie in dem obigen Zitat von Date definiert ist.
Ihre Definition für Spalte D in r2, "eine Summe aller Cs von r1, wobei A von r1 gleich A von r2 ist", ist eine Einschränkung für D. Formal ist, wo Σ eine Summation ist, π Projektion und σ ist Auswahl,
(a,d) ∈ r2 ⇔ (a, d) = (a, Σ c), a ∈ πA(r1), c ∈ πC(σA=a(r1))
Da diese Einschränkung weder eine Domäneneinschränkung noch eine Schlüsseleinschränkung ist, befindet sich r2 nicht in Domain / Key Normal Form < (DKNF).
DKNF ist die einzige normale Form, von der ich weiß, dass sie nicht in Bezug auf eine einzelne Beziehung definiert ist, hauptsächlich weil sie in Bezug auf Einschränkungen und nicht auf Abhängigkeiten definiert ist.
Also ist r2 eine Funktion von r1, was bedeutet, dass r2 eine materialisierte Ansicht dieser Funktion von r1
ist und in diesem Beispiel wäre das eine Ansicht von select A, sum(C) from r1 group by A
Ansichten werden in Codds Arbeit zur Normalisierung nicht behandelt, aber ich denke, er hat über sie geschrieben
Das Verwirklichen einer Ansicht erfolgt normalerweise aus Gründen des Cachens, die manche für eine Form der Denormalisierung halten könnten. Daher gab es Papiere, die automatisch entschieden, welche Ansicht materialisiert werden sollte, so dass die Datenbank sie manchmal schneller machen könnte / p>
aber als Updates zu Ansichten sind normalerweise nicht erlaubt, obwohl ich denke, dass ich gelesen habe, dass Codd so etwas wie alle Ansichten, die update-fähig sein kann, sollte sein und es gab Papiere darüber, dass das in einigen komplexen Fällen funktioniert
Ich denke, dass das Paar der Beziehungen die fünfte Normalform verletzt.
R2 ist eine Projektion von R1. Einige argumentieren, dass SUM nicht in den Anwendungsbereich des relationalen Modells fällt. In diesem Fall ist SUM eine triviale Erweiterung von COUNT, die im Rahmen des relationalen Modells liegt.
Tags und Links database-design theory relational