Ist es immer noch db Schema normalisiert? Datenbank

Question

Ich habe folgendes db-Schema.

Datei , GROUP und BLOCK die Objektstruktur der XML-Datei darstellen. Datei ist die Wurzel. GROUP hat FK auf Datei . BLOCK hat die eine FK auf GROUP und die andere eine FK auf UNIT .

UNIT Gruppen "ähnlich" Blöcke aus diffrent Statistik im Zusammenhang mit Datei .

Die Datenbank befindet sich derzeit in 3NF. Aber ich würde gerne wissen, welche UNITs , gehören in Datei .id = 1. Um dies tun noch, ich muss eine Abfrage machen, die alle vier Tabellen verknüpft. Um dieses Schema zu optimieren, kann ich die neue Beziehung erstellen UNIT n - FK -> 1 Datei . Doch meine Abfrage verknüpft nur zwei Tabellen auf dem optimierten db-Schema. Und hier ist die Frage: Ist das DB (mit diesem neuen FK) noch in 3 NF? Was sagt die Theorie?

BLOCK  n--FK-->1  GROUP  n--FK-->1  FILE
 n 
 |
 FK    
 |    
 1  
Unit

oder

            +--------+
      +-----|  File  |.....+
      |     +--------+     .
      |                    .
     /|\                  /.\
 +--------+           +--------+
 | Group  |--+     +--|  Unit  |
 +--------+  |     |  +--------+
             |     |
            /|\   /|\
           +---------+
           |  Block  |
           +---------+

Answer 1

Aus den vorliegenden Informationen geht hervor, dass dies eine echte parallele Hierarchie ist. Auf dieser Basis, so glaube ich, dass die vorgeschlagene geänderte Schema würde immer noch auf 3NF normalisiert werden.

Answer 2

Es ist nicht klar, wie die Einheit Tisch paßt in das Schema, bevor Sie Änderungen vornehmen.

Natürlich, nachdem Sie Änderungen vornehmen, alles, was Sie tun müssen, um zu wissen, welche Einheiten in einer Datei gehören, ist die Datei und UNIT Tabellen verbinden.

Da Tabellen in 3NF sind, wenn alle funktionalen Abhängigkeiten von den Schlüssel bestimmt werden, die ganze Schlüssel, und nichts als die Schlüssel (so helfen mir Codd), haben Sie in diesem Licht an Ihrem Schema suchen.

In Anbetracht der verfügbaren Informationen am wahrscheinlichsten die Tische sind alle in 3NF (und BCNF und AFAICT in 4NF und 5NF auch).

Answer 3

Ich glaube nicht, Ihr Diagramm unterstützt „Fuß kräht“, um die andere Abhängigkeiten in Ihrer Frage skizziert. Wie kamen Sie auf mit dem 1: Viele Beziehung zwischen FILE und UNIT

?

Dies sind die funktionalen Abhängigkeiten, dass Sie beschreiben ...

• GROUP -> Datei
• BLOCK -> GROUP
• BLOCK -> UNIT

Auch gehe ich davon aus, dass jede der oben genannten Attribute funktional einige bestimmen zusätzliche Attribute nicht angezeigt auf der linken Seite eines anderen funktionalen Abhängigkeit. Diese wären:

• Datei -> andere-Datei-Attribute
• GROUP -> andere gruppen Attribute
• BLOCK -> anderer block Attribute
• UNIT -> andere einheits Attribute

eine Reihe von 3NF Beziehungen von der Konstruktion über funktionale Abhängigkeiten gibt:

• FileRelation: ( Datei , andere-Datei-Attribute)
• GroupRelation: ( GROUP , Datei , andere gruppen Attribute)
• UnitRelation: ( UNIT , andere einheits Attribute)
• BlockRelation: ( BLOCK , GROUP UNIT , andere Block-Attribute)

Diese ziemlich entspricht dem, was Sie beschrieben haben.

Die Bestimmung der UNIT Instanzen beziehen sich auf eine bestimmte Datei erfordert eine Verknüpfung von FileRelation zu GroupRelation auf Datei und dann GroupRelation zu BlockRelation auf GROUP dann BlockRelation zu UnitRelation auf UNIT .

Sie mögen diese Multi-Table-Join vermeiden, indem sie eine neue Beziehung irgendwo im Modell eingefügt, dass gibt eine direkte Zuordnung von UNIT Datei . Eine solche Beziehung impliziert die funktionelle Abhängigkeit:

• UNIT -> Datei

Das sieht aus wie das Bit Sie die hinzugefügte „Krähen Fuß“ Diagramm. Hinzufügen Dies führt eine logische Widerspruch. Die ursprünglichen Träger Schema einer gegebenen Einheit in Zusammenhang mit mehrere Datei Instanzen. wie in:

• FileRelation (F1, ...)
• FileRelation (F2, ...)
• GroupRelation (G1, F1, ...)
• GroupRelation (G2, F2, ...)
• BlockRelation (B1, G1, U1, ...)
• BlockRelation (B2, G2, U1, ...)
• UnitRelation (U1, ...)

UNIT Instanz U1 bezieht sich auf FILE Instanzen F1 und F2. Angesichts dieser Situation entweder die UNIT -> Datei funktionale Abhängigkeit kann nicht unterstützt werden oder der ursprüngliche Satz von funktionalen Abhängigkeiten waren unvollständig und das Schema nicht in 3NF.

An diesem Punkt, den Sie lösen müssen, ob die reale Welt unterstützt die Datei -> UNIT Abhängigkeit oder nicht. Ist dies der Fall, dann ist das ursprüngliche Modell nicht in 3NF und ein bisschen mehr ist um das Schemas Nacharbeiten. Wenn die Abhängigkeit nicht unterstützt wird dann das Beste, was Sie sagen können, ist:

• Datei , UNIT -> nichts

und die entsprechende Beziehung:

• FileUnit: ( Datei , UNIT )

ist eine de-Normalisierung, weil sein Inhalt durch die bestehenden Tabellen funktionelle Abhängigkeiten abgeleitet werden kann.

============================================ =====================================

Bearbeiten

Auf der Grundlage einer Reihe von Kommentaren zu diesem und anderen Antworten gemacht, scheint es, dass:

• UNIT -> Datei

ist eine echte funktionale Abhängigkeit, die funktionale Abhängigkeit:

• BLOCK -> UNIT

zwar nicht falsch, müssen redundant sein. Ich glaube, den richtigen 3NF Satz Beziehungen fürDieses Modell ist jetzt:

• FileRelation: ( Datei , andere-Datei-Attribute)
• GroupRelation: ( GROUP , Datei , andere gruppen Attribute)
• UnitRelation: ( UNIT , Datei , andere einheits Attribute)
• BlockRelation: ( BLOCK , GROUP , andere Block-Attribute)

Beachten Sie, dass die UNIT Fremdschlüssel von dem BlockRelation gesunken. Dies liegt daran, die UNIT -> Datei FD gemacht es überflüssig. Das ( BLOCK , UNIT ) Beziehung jetzt durch den Beitritt UnitRelation zu FileRelation auf Datei gebildet wird, dann FileRelation zu GroupRelation auf Datei dann GroupRelation zu BlockRelation auf GROUP .

Das ursprüngliche Schema war nicht in 3NF aufgrund der unausgesprochenen funktionale Abhängigkeit: UNIT -> Datei . Der vorgeschlagene Satz von Beziehungen oben ist in 3NF.

Hinweis: Wenn Sie ein Schema zu normalisieren, muss jede funktionale Abhängigkeit angegeben werden vorne. Vermisst man kann das ganze Bild ändern!