Frage

Angenommen, ich habe zwei Tabellen in einer Datenbank, T 10 und T 11 , mit 10 und 11 Spalten, die jeweils, wobei 10 der Säulen sind genau das gleiche auf beide.

Was (falls vorhanden) Normalisierung Regel bin ich zu verletzen?

War es hilfreich?

Lösung

Edit: Ich habe darüber informiert, dass keine Normalformen werden hier in der Theorie verletzt. Da dies die akzeptierte Antwort war, ich verlasse hier als Referenz, und weil Denken über 3NF kann in der Praxis helfen, zu vermeiden Situationen, wie in der Frage.

Sie verletzen die dritte Normalform (3NF) , denn wenn meist die gleichen Daten jedes Attribut jeder Tabelle wird in beiden Tabellen gehalten, dann ist nicht direkt abhängig von der Tonart der jeweiligen Tabelle.

Andere Tipps

Ob Sie es glauben oder nicht, Spalten über Tabellen duplizieren verletzt keine theoretische Normalform an und für sich. Mit Ausnahme der Domain / Schlüssel Normalform (DKNF) werden normale Formen in Bezug auf den einzelnen, nicht mehr Tabellen definiert. DKNF wird in Bezug auf die Randbedingungen festgelegt, von denen es keine in dem allgemeinen Fall sind. So, wenn es eine Verletzung einer Normalform:

  • es spezifisch für eine der Tabellen sein muss, und besteht unabhängig beiden Tabellen von (das heißt, die Tabelle immer noch die normale Form verletzen würde, auch wenn Sie die andere Tabelle entfernt) oder
  • hat die Beziehung eine Einschränkung, die DKNF verletzt, was bedeutet es kein Beispiel für den allgemeinen Fall ist in der Frage skizzierte aber ein spezifischeres Fall. Es ist nicht die doppelten Spalten, die die Verletzung, sondern die zusätzliche Einschränkung für die zusätzliche Spalte.
  • erstellen

Betrachten Sie die Normalformen , mit den kurzen Definitionen aus dem Wikipedia-Artikel:

  
1NF
  
    
Die Tabelle stellt eine Beziehung treu und hat keine sich wiederholenden Gruppen.
   

Das hier ist ziemlich geradlinig. Der Begriff „sich wiederholende Gruppen“ mehrere Bedeutungen in der Theorie, aber keiner von ihnen haben nichts mit doppelten Spalten oder Daten zu tun.

  
  
2NF
  
    
Kein Non-Prime-Attribut in der Tabelle auf einer echte Teilmenge von jedem Kandidatenschlüssel funktional abhängig ist.
    

Hier ist der wichtige Begriff zu prüfen ist „funktionale Abhängigkeit“. Im Wesentlichen eine funktionale Abhängigkeit ist, wo Sie eine Beziehung zu zwei Spalten, X und Y projizieren, und mit einer Funktion X → Y. Sie können keine funktionale Abhängigkeit zwischen zwei (oder mehr) Tabellen * . Darüber hinaus können nicht mehrere Tabellen Schlüssel Kandidaten umfassen.

  
  
3NF
  
    
Jedes Non-Prime-Attribut ist nicht transitiv abhängig von jedem Kandidatenschlüssel in der Tabelle.
    

Transitiv Abhängigkeit wird in Bezug auf die funktionale Abhängigkeit definiert: eine transitive Abhängigkeit ist eine Abhängigkeit in der X → Z nur, weil X → Y und Y → Z. X, Y und Z in der gleichen Tabelle sein muss, weil diese funktionalen Abhängigkeiten sind.

  
  
4NF
  
    
Jede nicht-triviale Mehrwertige Abhängigkeit in der Tabelle eine Abhängigkeit von einem superkey ist.
    

Mehrwertig Abhängigkeit ist ein wenig komplizierter, aber es kann mit einem Beispiel erläutert werden: „wann immer die Tupel (a, b, c) und (a, d, e) in R vorhanden ist, die Tupel (a, b, e) und (a, d, c) auch in r existieren sollte“(wobei "r" ist, ein Tisch). Am wichtigsten für die Sache in der Hand, eine mehrwertige Abhängigkeit gilt nur für eine einzelne Tabelle.

  
  
5NF
  
    
Jeder nicht-triviale beitreten Abhängigkeit in der Tabelle durch die superkeys der Tabelle angedeutet wird.
    

hat eine Tabelle ein beitreten Abhängigkeit , wenn sie als die natürliche anderer Tabellen verbinden ausgedrückt werden kann . Diese anderen Tabellen, jedoch brauchen nicht in der Datenbank vorhanden ist. Wenn die Tabelle T 11 in dem Beispiel hatte eine Abhängigkeit kommen, wäre es immer noch ein, auch wenn Sie entfernte Tabelle T 10

  
  
6NF (C. Datum)
  
    
Tabelle verfügt über keine nicht-triviale Abhängigkeiten überhaupt verbinden (mit Bezug auf die generali Join-Operator).
    

Die gleiche Argumentation für 5NF.

  
  
Grund Key Normalform (EKNF)
  
    
Jede nicht-triviale funktionale Abhängigkeit in der Tabelle entweder die Abhängigkeit eines elementaren Schlüsselattribut oder eine Abhängigkeit von einem superkey ist.
    

Die gleiche Argumentation für 2NF.

  
  
Boyce-Codd Normalform (BCNF)
  
    
Jede nicht-triviale funktionale Abhängigkeit in der Tabelle ist eine Abhängigkeit von einem superkey.
    

Die gleiche Argumentation für 2NF.

  
  
Domain / Key Normalform (DKNF)
  
    
Jede Einschränkung für die Tabelle ist eine logische Konsequenz aus der Domäne Einschränkungen der Tabelle und Key-Einschränkungen.
    

Wenn T 11 eine Einschränkung hat, die auf T hängt 10 , dann ist es entweder eine Schlüsselbedingung oder eine komplexere Einschränkung, dass bezieht sich noch auf T 10 . Der letztere Fall ist nicht der allgemeine Fall in der Frage erwähnt. Mit anderen Worten, während es bestimmte Schemata mit doppelten Spalten sein könnte, die DKNF verletzt, es ist nicht wahr, im Allgemeinen. Darüber hinaus ist es die Einschränkung (nicht die normale Form), die in Bezug auf mehrere Tabellen und die Einschränkung (nicht die Spalte Vervielfältigung), die DKNF verursacht Verletzung definiert wird.

  

Der Zweck zur Normalisierung enthält Anomalien zu verhindern. Allerdings ist die Normalisierung in nicht vollständig, dass es nicht gewährleistet eine relationale Datenbank wird von Anomalien vollständig frei sein. Dies ist ein Beispiel, wo die Praxis divergiert von der Theorie.

Falls dies noch nicht, dass Sie nicht überzeugen, betrachtet das Schema KM. Kommentar Hinweise auf, wobei T 11 eine Geschichte darstellt (oder versioniert) Version von T 10 . Der Primärschlüssel von T 11 besteht aus den Primärschlüsselspalten gemeinsam mit T 10 gehalten , plus dem zusätzlichen Spalte (Datum / Version Spalte). Das T 11 hat verschiedene Schlüsselkandidaten macht den Unterschied zwischen einer Anomalie anfällig und Anomalie frei, normalisierte Design.

* Jemand könnte denken, dass Sie verwenden könnten eine Abhängigkeit zwischen zwei Tabellen erstellen verbindet. Während ein beitreten könnte eine Tabelle erstellen, die eine Abhängigkeit hat, besteht die Abhängigkeit von dieser Tabelle nicht zwischen den Bestandteilen des Joins. Im vorliegenden Fall wird dies wiederum bedeutet, dass eine der Tabellen würde eine verknüpfte Tabelle und aus der Abhängigkeit selbst, unabhängig von der anderen Tabelle in der Datenbank leiden würde.

Vielleicht ist die Regel redundante Daten zu vermeiden? (Das heißt, die gleichen Daten in zwei Tabellen)

, wenn 10 der 11 Spalten gleich sind, warum kann das nicht nur eine Tabelle, wo die 11. Spalte links leer ist (zusammen mit einer möglichen 12. Spalte zu bezeichnen, welche Art von Daten es ist, das heißt die es Tisch wäre ursprünglich gewesen)?

Es hängt davon ab, was in den Tabellen ist.

Wenn keine Datensätze miteinander verwendet (zum Beispiel, wenn eine Tabelle einfach archivierten Aufzeichnungen mit Ursprung in, sondern aus der ersten Tabelle entfernt) Sie keine Regeln verletzt werden.

Aber wenn diejenigen, die gleichen Datensätze in jeder Tabelle sind, haben Sie ein Abhängigkeitsproblem - die elfte Spalt nur auf dem Schlüsselwert aus dem Datensatz abhängig ist, nicht die zusätzlichen Spalten. Unter der Annahme, dass alle zehn Spalten in dem Primärschlüssel nicht beteiligt ist, haben Sie 3. NF verletzt.

Mit zwei identischen oder nahezu identischen Beziehungen ist nicht selbst eine Verletzung irgendeiner die üblichen Normalformen. Outis hat sehr ausführlich erklärt, warum. Es könnte gut sein, ein Verstoß gegen die Prinzip der Orthogonales Design aber das ist ein weiterer Aspekt der relationalen Datenbank-Design-Theorie ist.

Wenn alle 10 Spalten sind Teil Ihrer Schlüssel, dann Zweite Normalform: Eliminieren redundanter Daten. Insbesondere fällt dies unter „Nonsurrogate Versus Surrogate Primärschlüssel“ Dilemma - um ehrlich zu sein, erinnere ich mich nicht eine dieser beiden Möglichkeiten „zu verletzen“ 2NF zu sein, aber der Ersatzschlüssel ist auf jeden Fall näher an den Geist der 2NF

Nur Primärschlüssel kann redundante zwischen Tabellen sein. jede Menge an nicht Primärschlüsselspalten in mehreren Tabellen verletzt dritte Normalform.

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