Ternäre Beziehung: Was ist der Unterschied zwischen einer einzelnen Tabelle und mehreren Tabellen?

Betrachten Sie die folgende ternäre Beziehung:

Angenommen, alle Entitäten haben nur zwei Attribute (PK und Name).

Hier sind die Tabellen, die ich abgeleitet habe (5 Tabellen):

Sector
-------------------------
ID_Sector    SectorName
-------------------------

Product
-------------------------
ID_Product    ProductName
-------------------------

Company
--------------------------------------
ID_Company    ID_Sector    CompanyName
--------------------------------------

Relationship 1 (R1)
-------------------------
ID_Sector    ID_Product
-------------------------

Relationship 2 (R2)
-------------------------
ID_Company    ID_Product
-------------------------

Frage:

Ist es eine gute Lösung für diese ternäre Beziehung? Was ist der Unterschied zwischen 2 Tabellen (R1 und R2) anstelle der folgenden einzelnen Tabelle:

Ternary table
-------------------------------------
ID_Sector    ID_Company    ID_Product    
-------------------------------------

Für mich sieht es so aus, als ob zwei separate Tabellen für jede Beziehung (R1 und R2) eine bessere Lösung sind als eine einzelne Tabelle, aber ich weiß nicht, ob das tatsächlich stimmt oder ob es eine gute Praxis ist.

— fühle das
quelle

Die beiden Lösungen modellieren unterschiedliche Regeln. Mit der ternären Tabelle sagen Sie, dass ein Unternehmen möglicherweise nur bestimmte Produkte in einem bestimmten Sektor hat. In einem anderen Sektor wird es unterschiedliche Produktgruppen geben, obwohl sich die beiden Gruppen natürlich überschneiden können.

Mit den binären Tabellen geben Sie an, dass der Sektor keinen Einfluss darauf hat, auf welche Produkte sich ein Unternehmen bezieht. Ebenso hat das Unternehmen keinen Einfluss darauf, welche Produkte in welcher Branche angeboten werden.

Die Wahl zwischen diesen Alternativen wird durch Ihre Geschäftsregeln bestimmt. Es kann nicht durch eine abstrakte, akademische Diskussion beantwortet werden. Ich habe es am besten gefunden, die Beziehung zwischen den Entitäten zu benennen. Es ist interessant zu sagen, dass das Unternehmen mit dem Produkt verwandt ist. Noch besser ist es zu sagen, warum das Unternehmen mit dem Produkt verbunden ist. "Unternehmen kauft Produkt" ist eine andere Information als "Unternehmen stellt Produkt her" oder "Unternehmen hat keine Sicherheitsfreigabe zur Verwendung des Produkts". Auf diese Weise entdecke ich oft neue Beziehungen, Attribute und Entitätstypen. Möglicherweise benötigen Sie sowohl die binäre als auch die ternäre Tabelle!

Bearbeiten : Für die Regeln

Ein Unternehmen produziert viele Produkte / jedes Produkt wird von genau einem Unternehmen hergestellt
Ein Unternehmen berichtet in genau einem Sektor / jeder Sektor berichtet über viele Unternehmen
Ein Produkt wird in genau einem Sektor verkauft / jeder Sektor verfügt über viele Produkte.

Ich hätte diese Entitätstypen

Sektor - Sektor-ID

Firma - Firmen-ID, Sektor-ID

Produkt - ProductID, CompanyID

Wenn eine Ihrer Regeln viele zu viele ist, benötigen Sie die binären Zuordnungstabellen.

Nebenbei bemerkt, die Beziehungsnamen "hat", "gehört zu" und "ist ein" verstecken sich oft mehr als sie beleuchten. Wenn Sie feststellen, dass Ihre BAs diese verwenden, bitten Sie sie, einen anderen Gedanken zu haben.

— Michael Green
quelle

Lassen Sie uns die Geschäftsregeln annehmen , sind: 1) Die Unternehmen produzieren Produkte; 2) Unternehmen gehören einem Sektor an (Beispiele für Sektoren: Maschinen, Lebensmittel, Software); 3) Produkte gehören Sektoren an. Ich versuchte kurz zu sein und bezahlte den Preis für das Verstecken wichtiger Informationen. Vielen Dank!

— Feelthhis

Mein Kommentar wirft eine andere Frage auf: Welche Geschäftsregeln modelliert die ERD oben? Gibt es eine Möglichkeit, die ERD in Bezug auf die Geschäftsregeln sehr genau zu machen? Stellt die ternäre Tabelle die obige ERD genau dar? Wenn ja, dann ist die ERD oben das falsche Modell in Bezug auf die angegebenen 3 Geschäftsregeln, richtig?

— Feelthhis

Welche Geschäftsregeln hat das ERD-Modell oben: Die ternäre Tabelle würde bedeuten, dass es eine Sache gibt, die ProductID, SectorID und CustomerID als notwendigen und ausreichenden Schlüssel hat. So etwas wie "GE (Unternehmen) finanziert (Produkt) 90% (Attribut) aller Triebwerke (Sektor)", während "Goldman 5% der Triebwerke finanziert" und "GE 3% der Windmühlen finanziert".

— Michael Green

@feelthhis - "Gibt es eine Möglichkeit, die ERD in Bezug auf die Geschäftsregeln sehr genau zu machen": Ja! Das machen ERDs. Ich werde meine Antwort bearbeiten. "Stellt die ternäre Tabelle die ERD oben genau dar?": Ich denke, Sie meinen "Regeln oben". Nein. Ein Produkt wird von genau einer Firma hergestellt. Ein Unternehmen gehört genau einer Branche an. Wenn man ProductID kennt, kann man Kunden und Sektoren eindeutig identifizieren, und diese IDs wären in der ternären Tabelle redundant. Daher wird es nicht gemäß Ihren 3 Regeln normalisiert. "Wenn ja ...": Ich stimme zu.

— Michael Green

Ternary Table: a company may...Wenn Sie die Notation (IDSector, IDCompany, IDProduct) verwenden, sind die Tupel (1, 1, 1) und (1, 1, 2) zulässig ("c1" erzeugt "p1" und "p2" in "s1"). ); und dass die Tupel (1, 1, 1) und (2, 1, 2) nicht erlaubt sind ("c1" erzeugt "p1" in "s1" und erzeugt "p2" in "s2")? Warum? Sollte die ternäre Tabelle kein mögliches Tupel zulassen (IDSector, IDCompany, IDProduct)? Binary Tables: sector has...; company has...Ich dachte, dass die ternäre Tabelle den Binärdateien entspricht, wenn die ternäre Tabelle ein Tupel zulässt (IDSector, IDCompany, IDProduct).

— Feelthhis