Das zerlegen eines ternären Beziehung in binäre Beziehungen

Entwerfe ich eine Datenbank, mit Benutzer-accounts und Projekten mit den folgenden Beziehungen und constraints:

  • Ein Konto hat viele Nutzer
  • Gehört ein Benutzer zu viele Konten
  • Ein Konto hat viele Projekte
  • Einem Projekt gehört nur ein Konto
  • Ein Benutzer arbeitet in vielen Projekten (redundante Hinweis: jedes von Ihnen gehören zu seinen eigenen account).

In anderen Worten, ein Benutzer kann die Zusammenarbeit in vielen Projekten mit dem gleichen Konto. Aber seit ein Benutzer kann Mitglied mehrere Konten, so kann ein Benutzer arbeiten Sie in vielen Projekten von mehreren Konten. Dies führt mich zu einer ternären arbeitet Beziehung:

Das zerlegen eines ternären Beziehung in binäre Beziehungen

Nach der Lektüre ein paar Papiere zum konvertieren von ternären Beziehungen in binäre Beziehungen, die ich kam mit der folgenden äquivalenten Beziehungen:

Das zerlegen eines ternären Beziehung in binäre Beziehungen

Zwei Frage stellt sich hier:

  1. Ist diese Umrechnung richtig? Ich habe festgestellt, dass ich haben, um zusätzliche Kontrollen auf Applikationsebene zu verarbeiten Einfügungen. Zum Beispiel, bevor ein neuer (User,Project) ich habe zu prüfen, dass der Benutzer gehört, die das gleiche Konto, das dem Projekt gehört.

  2. Ist es wirklich notwendig, um die Beziehung zwischen Account und User? Nachdem die Beziehung zwischen User und Project Hinzugefügt wurde, konnte nicht wir wissen, dass der account gehört ein Benutzer zu, durch Zugriff auf das Projekt?

Dank!!

InformationsquelleAutor elitalon | 2012-05-15
  1. 12

    Ist diese Umrechnung richtig?

    Wenn du mit "richtige" meinst du "gleichwertig", dann nicht.

    Es gibt nichts zu stoppen Sie verbindet Projekt-und account - ohne verbinden eines Benutzers (etc...), was nicht möglich wäre, in eine echte ternäre Beziehung.

    Ist es wirklich notwendig, um die Beziehung zwischen Account und Benutzer? ... konnten wir nicht wissen, der account gehört ein Benutzer zu, durch Zugriff auf das Projekt?

    Tatsächlich, wir würden nur wissen, welche Konten sind "Kandidaten" mit dem Benutzer, aber wir hätten keinen guten Weg, sich für eine zu entscheiden.

    Das eigentliche problem mit diesem System ist, dass es ermöglicht die Verbindung der Benutzer zu einem Konto ohne Bezug zu irgendeiner der Benutzer, die mit Projekten.

    Meiner Meinung nach, wenn Sie eine ternäre Beziehung, gehen Sie einfach weiter und direkt stellen es in das physische Modell. Wenn ich Ihre Anforderungen verstehen richtig, würde dies wie folgt Aussehen:

    Das zerlegen eines ternären Beziehung in binäre Beziehungen

    Hinweis, wie AccountId außerhalb Collaboration PK. Dies bedeutet, dass jedes Projekt/Benutzer-Kombination angeschlossen werden muss, um genau einen account (ein verschiedenen Kombination können immer noch eine Verbindung mit einem anderen Konto).

    • Ich mag Ihren Ansatz, aber eine Menge Leute empfehlen, die zersetzende standardmäßig, daher meine Frage.
    • Die Who empfiehlt das zerlegen standardmäßig?
    • Nicht immer etwas tun, nur weil jemand (mich eingeschlossen!) erzählt Sie. Immer verstehen, was Sie tun, und warum, andernfalls werden Sie Programmierung durch Zufall.
    • Sie werden überrascht sein, nach einer gründlichen Google-Suche :p
    • Ich habe gerade eine Google-Suche und bekam viele Ergebnisse, aber alle Schienen zu beinhalten kaufen eine PDF-Datei um die Antwort zu sehen! Hast du einen link zu etwas frei lesbar? Ich bin neugierig, aber nicht genug, um meine hand in meiner Tasche!
    • Ich zitiere das Fazit des "Binären Äquivalente Ternäre Beziehungen im Entity-Relationship-Modellierung: Logische ZERLEGUNG Ansatz" von Jones und Song: "Wir haben gezeigt, in diesem Papier, dass der logische (völlig äquivalent) Zerlegungen existieren für bestimmte Kombinationen von ternär / Binär-kardinalitäten, aber die Mehrheit nicht voll (logisch und praktisch) - äquivalenten."
    • Was für ein Zufall! Das Papier war eine der Quellen, die ich gelesen, um zu versuchen, um zu zerlegen die ternären Beziehungen. Dieser Satz war genau die, die mich Fragen, diese Frage
    • "Das wirkliche problem mit diesem System ist, dass es ermöglicht die Verbindung der Benutzer zu einem Konto ohne Bezug zu irgendeiner der Benutzer, die mit Projekten." Dies ist der Grund, warum elitalon schrieb, dass Sie haben, um die Anwendung level-Prüfungen. Gibt es irgendwelche Vorteile zu zersetzen? Beseitigung von Redundanz, aber vielleicht ist es ein guter trade-off?
    • Ich bin mir nicht sicher, wie OP ' s zweite Modell "beseitigt Redundanz". Als Allgemeine Regel gilt, Datenbank-Ebene deklarative Integrität sollte bevorzugt werden, um application-level-Integrität. Gründe sind zahlreich, aber kurz gesagt: die DB-Einschränkungen Minimierung der Wahrscheinlichkeit für Fehler (durch Ihre deklarative Natur), Förderung von Wiederverwendung (da Sie zentralisiert und nicht umgangen werden kann durch einen fehlerhaften Anwendung) und in der Regel sind performant und skalierbar. Es gibt Fälle, wo die application-level-Integrität gerechtfertigt ist, aber die DB-Integrität sollte endgültig Ihre "default" - Wahl.

    InformationsquelleAutor Branko Dimitrijevic
Schreibe einen Kommentar