Ist es möglich, sogenannte "Spurious Tuples" vollständig loszuwerden?

Ist es möglich, sogenannte "Spurious Tuples" vollständig loszuwerden?

Zum Beispiel: In diesem Beispiel aus einem Lehrbuch gibt es eine Originaltabelle:

Ich sehe nichts falsches an den beiden Projektionen:

Aber ihre Verbindung erzeugt immer noch falsche Tupel:

(Diese Zahlen stammen aus ToddEveretts Antwort .)

Das ist eine gute Frage. Eine Normalisierung über BCNF hinaus ist äußerst schwer zu verstehen. Hoffentlich kann ich eine sinnvolle Antwort geben. Ich hatte über 20 Jahre lang mit diesen Konzepten zu kämpfen, bevor ich sie dank Fabian Pascals Practical Database Foundation Series endlich verstand .

Das bereitgestellte Beispiel ist eine EmpRoleProjR-Tabelle, die so aussieht:

Anschließend werden Projektionen der ursprünglichen EmpRoleProjR-Tabelle wie folgt angezeigt:

Der Grund, warum Sie mit den Basistabellen nichts falsches sehen Table 1und Table 2ist, dass Sie die im Geschäftsmodell, das die Geschäftsregeln beschreibt, definierten Abhängigkeitsregeln (in diesem Fall MVD- Regeln ( Multivalued Dependency Rules)) nicht berücksichtigen . Wenn wir beispielsweise annehmen, dass in den Geschäftsregeln keine MVDs definiert sind, befindet sich EmpRoleProj trotz des "Auftretens" von Redundanzen in 5NF . Es scheint zum Beispiel, dass die Information, dass Smith ein Designer ist, redundant gespeichert wird. Es scheint auch, dass die Informationen, die ein Designer für das Amazon-Projekt benötigt, redundant gespeichert werden. Während dies der Fall zu sein scheint , ist es Smith, wenn man erfährt, dass es sich tatsächlich nicht um MVDs handeltgeschieht ein Designer auf ein paar Projekte zu sein, aber es ist nicht eine Tatsache , dass Smith ist ein Designer und damit diese Tatsache soll nicht geschlossen werden. Wenn Tabelle 1 und Tabelle 2 verbunden werden, ergibt sich Folgendes:

zeigt Jones als Designer für das Nil-Projekt, aber wir wissen, dass dies nicht der Fall ist.

Nehmen wir an , anstatt das Geschäftsmodell hat es sagen war MVDs von empName-->>roleund role-->>projName. In diesem Fall bedeuten diese MVDs , dass, wenn ein Mitarbeiter eine Rolle spielt und wenn diese Rolle in einem Projekt spielt , dieser Mitarbeiter per Definition diese Rolle in diesem Projekt spielt. In diesem Beispiel ist , dass gleiche EmpRoleProj Tabelle jetzt nicht in 5NF und jetzt nicht von Redundanz leiden. Jetzt werden die Fakten, dass Smith ein Designer ist und ein Designer für das Amazon-Projekt benötigt wird , redundant gespeichert, da diese Fakten aus der Verknüpfung von Tabelle 1 und Tabelle 2 abgeleitet werden könnten ! Ebenso ist die Verknüpfung von Tabelle 1 und Tabelle 2 jetzt nicht mehr möglichDies führt zu einem falschen Tupel, da die Schlussfolgerung, dass Jones ein Designer des Nil-Projekts ist , nun auf den von den MVDs definierten Geschäftsregeln basiert.

Aus diesem Grund können Sie die normale Form einer R-Tabelle nicht beurteilen, ohne die Abhängigkeiten und den definierten Schlüssel zu kennen. Jede Annahme, auch eine, die Ihnen sinnvoll erscheint, kann gefährlich sein. Wenn Sie jemals gefragt werden, in welcher normalen Form sich eine R-Tabelle befindet, müssen Sie nach den zu bewertenden Abhängigkeiten fragen. Neben Fabians Aufsatzreihe liefern Chris Dates Arbeiten die besten verfügbaren Informationen zur Normalisierungstheorie.

Ein falsches Tupel kann auftreten, wenn Zeilen in einer Datenbank falsch verknüpft werden. Dies kann dazu führen, dass aufgrund des Fehlers eine neue, aber falsche Zeile erstellt wird.

In Ihrem Beispiel aus dem Buch Databases Illuminated Third Edition von Ricardo und Urban zeigen sie dieses Beispiel :

Wie Sie sehen können, führt die Aufteilung der Datensätze in 6.8 (B) in zwei Tabellen, jedoch ohne Beibehaltung der Bedeutung der Daten, dazu, dass der Join in 6.8 (C) Jones Designer sowohl mit Amazon (was korrekt ist) als auch mit Nile verbindet (was falsch ist).

Also, mach mit. Der Join, der den Fehler in 6.8 (C) verursachte, war darauf zurückzuführen, dass die Beziehungen zwischen den Daten aus den Augen verloren wurden. Einfach, wenn Sie die ursprünglichen Beitrittskriterien nicht angeben.

Wenn Sie eine Diashow-Diskussion wünschen, finden Sie hier ein Beispiel aus:

http://classes.engr.oregonstate.edu/eecs/winter2012/cs440/slides/slide9.pdf

   Design relation schemas to be joined with equality conditions 
        on attributes that are appropriately related.

       - Guarantees that no spurious tuples are generated

    Avoid relations that contain matching attributes 
        that are not (foreign key, primary key) combinations

Bei der Zerlegung eines relationalen Schemas ist ein "falsches Tupel" nur ein hypothetisches Symptom für verlorene Informationen. Dies bedeutet, dass eine Abhängigkeit, die in einer bestimmten Beziehung dargestellt wird, durch die Aufteilung dieser Beziehung in zwei oder mehr Komponenten verloren geht. Ob dies ein Problem ist, das Sie lösen müssen oder nicht, hängt davon ab, wie wichtig die verlorene Abhängigkeit für Sie ist.

In dem Beispiel, auf das Sie sich beziehen, gibt die EmpRoleProj-Tabelle an, an welchen Projekten jeder Mitarbeiter arbeitet. Im Design von Tabelle1, Tabelle2 gehen Informationen verloren - wir können nicht mehr feststellen, dass Jones nur im Amazon-Projekt und nicht im Nil-Projekt funktioniert.

Als Datenbankdesigner müssen Sie berücksichtigen, welche Informationen oder Integrität verloren gegangen sind, und dann entscheiden, welche Maßnahmen ergriffen werden sollen: Ändern Sie das Design, fügen Sie zusätzliche Integritätsbeschränkungen hinzu oder entscheiden Sie, dass die neue Zerlegung tatsächlich eine Verbesserung gegenüber dem vorherigen darstellt.

Wenn die Beziehung R gleich R1 JOIN R2 JOIN ist ... dann können wir R1 JOIN R2 JOIN ... anstelle von R verwenden. Offensichtlich. Aber R1, R2, ... werden Projektionen von R sein. Wenn wir dagegen Projektionen R1 ', R2', ... von R nehmen, wobei R nicht gleich R1 'JOIN R2' JOIN ist ... dann können wir nicht verwenden R1 'JOIN R2' JOIN ... anstatt R. Offensichtlich zu verwenden. Aber R1 'JOIN R2' JOIN ... wird wie R plus einige andere Tupel sein . Sie sind "falsche Tupel" im Vergleich zum Wert von R und R1 JOIN R2 JOIN .... Aber sie gehören in R1 'JOIN R2' JOIN .... Das ist einfach nicht R . Um „der falschen Tupel loszuwerden“ einfach nicht R1' verwenden JOIN R2' JOIN ... für R . Aber warum dann ?Sie? Nur wenn Sie dachten, dass alte Projektionen von R zu R. zurückkehren. Aber das tun sie nicht. Aber warum sollten sie dann?

Ihre Frage ist also seltsam formuliert. Wir möchten eine Tabelle, die die Verknüpfung einiger anderer ist, durch diese anderen ersetzen. Wir nicht wollen , eine Tabelle zu ersetzen, ist nicht die Verbindung von einigen anderen von den anderen. So können wir immer "die falschen Tupel loswerden", indem wir das nicht tun .

Bei der Normalisierung geht es darum, eine Tabelle, die die Verknüpfung einiger anderer ist, durch diese anderen zu ersetzen. Wenn R = R1 JOIN R2 JOIN ... sagen wir, dass eine JD (Join-Abhängigkeit) in R gilt. Im Gegensatz zu der erhaltenen Weisheit ist es sehr einfach , JDs zu sehen, wenn wir suchen und wissen, was unsere Tabellen bedeuten. Wenn R Tupel enthält, in denen " ... A1a ... A1b ... UND ... A2a ... A2b ... UND ...", ist dies die Verknüpfung von R1, R2, ... mit dem jeweiligen Attribut setzt {A1a, A1b, ...}, {A2a, A2b, ...}, ... mit den jeweiligen Bedeutungen " ... A1a ... A1b ... ", " ... A2a ... A2b ... ", .... Wir verwenden natürlich die meiste Zeit von Beginn an R1, R2, .... Erhaltene Weisheit ist auch, dass JDs, die FDs nicht begleiten (funktionale Abhängigkeiten), selten sind. Sie sind es, aber nur, weil die meisten JDs so offensichtlich sind, dass unsere anfänglichen Entwürfe sie vermeiden . Sie sind nur "schwer zu finden", weil sie so leicht zu finden sind. (Es ist etwas komplizierter, sich nicht nach JDs zu zersetzen, die keine Probleme verursachen.)