Unterschied zwischen einer Eins-zu-Viele- und einer Viele-zu-Eins-Beziehung

117

Was ist der wirkliche Unterschied zwischen einer Eins-zu-Viele- und einer Viele-zu-Eins-Beziehung? Es ist nur umgekehrt, irgendwie?

Ich kann kein anderes 'gut und leicht verständliches' Tutorial zu diesem Thema finden als dieses: SQL für Anfänger: Teil 3 - Datenbankbeziehungen

Zhaf
quelle
1
Dies ist die perfekte Erklärung: en.wikipedia.org/wiki/Many-to-many_(data_model)
RobertPitt
@RobertPitt Wie ist der Viele-zu-Viele-Artikel für die Frage relevant? Sie meinten wahrscheinlich eher en.wikipedia.org/wiki/One-to-many_(data_model)
TMG

Antworten:

111

Ja, umgekehrt. Dies hängt davon ab, auf welcher Seite der Beziehung die Entität präsent ist.

Wenn eine Abteilung beispielsweise für mehrere Mitarbeiter arbeiten kann, ist Abteilung zu Mitarbeiter eine Eins-zu-Viele-Beziehung (1 Abteilung beschäftigt viele Mitarbeiter), während die Beziehung von Mitarbeiter zu Abteilung viele zu Eins ist (viele Mitarbeiter arbeiten in einer Abteilung).

Weitere Informationen zu den Beziehungstypen:

Datenbankbeziehungen - IBM DB2-Dokumentation

Devendra D. Chavan
quelle
2
Ich fürchte, das macht keine Szenen! ( NICHT SICHER ABER ) Ich denke, die Reihenfolge repräsentiert die Abhängigkeit! Nicht wahr? ZB kann ein Benutzer zu Rolle 1 zu viele sein, aber nicht viele zu eins, da man keine Referenzen des Benutzers erhalten kann, der die Rolle verwendet! Ist das sinnvoll?
Amanuel Nega
Vielleicht jetzt Datenbankbeziehungen ?
Fragorl
29

Von dieser Seite über Datenbankterminologie

Die meisten Beziehungen zwischen Tabellen sind eins zu viele.

Beispiel:

  • Ein Bereich kann der Lebensraum vieler Leser sein.
  • Ein Leser kann viele Abonnements haben.
  • Eine Zeitung kann viele Abonnements haben.

Eine Viele-zu-Eins-Beziehung ist dieselbe wie eine Eins-zu-Viele-Beziehung, jedoch aus einem anderen Blickwinkel.

  • Viele Leser leben in einem Bereich.
  • Viele Abonnements können von ein und demselben Leser sein.
  • Viele Abonnements gelten für ein und dieselbe Zeitung.
Nathan Gonzalez
quelle
20

Was ist der wirkliche Unterschied zwischen einer Eins-zu-Viele- und einer Viele-zu-Eins-Beziehung?

Es gibt konzeptionelle Unterschiede zwischen diesen Begriffen, die Ihnen bei der Visualisierung der Daten helfen sollen, sowie mögliche Unterschiede im generierten Schema, die vollständig verstanden werden sollten. Meistens liegt der Unterschied jedoch in der Perspektive.

In einer Eins-zu-Viele- Beziehung hat die lokale Tabelle eine Zeile, die vielen Zeilen in einer anderen Tabelle zugeordnet sein kann. Im Beispiel von SQL für Anfänger , ein Customermöglicherweise zu vielen in Verbindung gebracht werden Orders.

In der entgegengesetzten Viele-zu-Eins- Beziehung kann die lokale Tabelle viele Zeilen enthalten, die einer Zeile in einer anderen Tabelle zugeordnet sind. In unserem Beispiel können viele Orders einem zugeordnet sein Customer. Dieser konzeptionelle Unterschied ist wichtig für die mentale Repräsentation.

Darüber hinaus kann das Schema, das die Beziehung unterstützt, in den Tabellen Customerund unterschiedlich Orderdargestellt werden. Zum Beispiel, wenn der Kunde Spalten hat idund name:

id,name
1,Bill Smith
2,Jim Kenshaw

Damit a Ordermit a verknüpft werden kann Customer, fügen viele SQL-Implementierungen der OrderTabelle eine Spalte hinzu, in der iddie zugehörigen Customer(in diesem Schema customer_id:

id,date,amount,customer_id
10,20160620,12.34,1
11,20160620,7.58,1
12,20160621,158.01,2

Wenn wir uns in den obigen Datenzeilen die customer_idID-Spalte ansehen , sehen wir, dass Bill Smith(Kunden-ID Nr. 1) zwei Bestellungen zugeordnet sind: eine für 12,34 USD und eine für 7,58 USD. Jim Kenshaw(Kunden-ID Nr. 2) hat nur 1 Bestellung für 158,01 USD.

Es ist wichtig zu erkennen, dass die Eins-zu-Viele-Beziehung normalerweise keine Spalten zur Tabelle hinzufügt, die die "Eins" ist. Das Customerhat keine zusätzlichen Spalten, die die Beziehung zu beschreiben Order. Tatsächlich haben die Customermöglicherweise auch eine Eins-zu-Viele-Beziehung zu ShippingAddressund SalesCallTabellen und haben dennoch keine zusätzlichen Spalten hinzugefügtCustomer Tabelle .

Für die Beschreibung einer Viele-zu-Eins-Beziehung wird jedoch häufig eine idSpalte zur Tabelle "Viele" hinzugefügt, die ein Fremdschlüssel zur Tabelle "Eins" ist. In diesem Fall wird der customer_idSpalte "Viele" eine Spalte hinzugefügt Order. Der zugehörigen Bestellung Nr. 10 für 12,34 USD Bill Smithweisen wir die customer_idSpalte der Bill SmithID 1 zu.

Es ist jedoch auch möglich, dass eine andere Tabelle vorhanden ist, die die Beziehung Customerund beschreibt Order, sodass der OrderTabelle keine zusätzlichen Felder hinzugefügt werden müssen. Anstatt customer_idder OrderTabelle ein Feld hinzuzufügen , könnte es eine Customer_OrderTabelle geben, die Schlüssel für Customerund enthält Order.

customer_id,order_id
1,10
1,11
2,12

In diesem Fall ist das Eins-zu-Viele und das Viele-zu-Eins alles konzeptionell, da zwischen ihnen keine Schemaänderungen bestehen. Welcher Mechanismus von Ihrem Schema und Ihrer SQL-Implementierung abhängt.

Hoffe das hilft.

Grau
quelle
3
Der allgemeine Fall wird als Einschlussabhängigkeit bezeichnet. Eine Fremdschlüsseleinschränkung ist die häufigste Art der Einschlussabhängigkeit, aber nicht alle Einschlussabhängigkeiten beinhalten einen Fremdschlüssel. Das gemeinsame Attribut oder die gemeinsamen Attribute (die "Referenz") sind in beiden Tabellen immer vorhanden . Auf der "einen" Seite werden diese Attribute als Kandidatenschlüssel bezeichnet. Auf der "vielen" Seite können sie ein Fremdschlüssel sein. Die Begriffe "Eins-zu-Viele" oder "Viele-zu-Eins" könnten auf jede Einschlussabhängigkeit angewendet werden, die mindestens einen Kandidatenschlüssel umfasst, ohne notwendigerweise zu implizieren, welche Seite optional sein kann.
Nvogel
Interessantes @sqlvogel. In Java ist das javax.persistence.OneToManyanders als das ManyToOne. Wollen Sie damit sagen, dass sie synonym sind oder nur, dass es von der Implementierung abhängt? Ist meine Antwort falsch?
Grau
2
Die Frage bezieht sich auf relationale Datenbanken und SQL, nicht auf Java. Vielleicht haben Sie Recht mit Java.
Nvogel
Ich habe es als Beispiel @sqlvogel verwendet. Wollen Sie damit sagen, dass "Eins-zu-Viele" und "Viele-zu-Eins" synonym sind?
Grau
2
Ich sage, dass dies zwei Möglichkeiten sind, genau dieselbe Beziehung zu beschreiben, aber aus unterschiedlichen Perspektiven. In der gleichen Weise bedeutet "A ist eine Teilmenge von B" dasselbe wie "B ist eine Obermenge von A".
Nvogel
4

Es gibt keinen Unterschied. Es ist nur eine Frage der Sprache und der Präferenz, in welcher Richtung Sie die Beziehung angeben.

nvogel
quelle
1
Es gibt sicherlich einen Unterschied, sowohl konzeptionell als auch im generierten Schema. Siehe meine Antwort: stackoverflow.com/a/37954280/179850
Gray
4
@Grau. Nein, da ist kein. Ihre Antwort ist nicht nur falsch, sie verwirrt auch Anfänger (diejenigen, die diese Frage stellen).
PerformanceDBA
4

Die Antwort auf Ihre erste Frage lautet: Beide sind ähnlich,

Die Antwort auf Ihre zweite Frage lautet: Eins-zu-viele -> ein MANN (MAN-Tisch) kann mehr als eine Frau (FRAUEN-Tisch) viele-zu-eins haben -> mehr als eine Frau hat einen MANN geheiratet.

Wenn Sie diese Beziehung nun mit zwei Tabellen MAN und WOMEN verknüpfen möchten, kann eine MAN-Tabellenzeile viele Beziehungen zu Zeilen in der WOMEN-Tabelle haben. hoffe es ist klar.

Kumpel
quelle
3

Beispiel

Zwei Tabellen mit einer Beziehung

SQL

In SQL gibt es nur eine Art von Beziehung, die als Referenz bezeichnet wird. (Ihr Frontend kann hilfreiche oder verwirrende Dinge tun [wie in einigen der Antworten], aber das ist eine andere Geschichte.)

  • Ein Fremdschlüssel in einer Tabelle (die referenc ing Tabelle)
    Referenzen
    einen Primärschlüssels in einer anderen Tabelle (der referenc ed Tabelle)
  • In SQL-Begriffen verweist Bar auf Foo.
    Nicht umgekehrt

    CREATE TABLE Foo (
        Foo   CHAR(10)  NOT NULL, -- primary key
        Name  CHAR(30)  NOT NULL
        CONSTRAINT PK             -- constraint name
            PRIMARY KEY (Foo)     -- pk
        )  
    CREATE TABLE Bar (
        Bar   CHAR(10)  NOT NULL, -- primary key
        Foo   CHAR(10)  NOT NULL, -- foreign key to Foo
        Name  CHAR(30)  NOT NULL
        CONSTRAINT PK                -- constraint name
            PRIMARY KEY (Bar),       -- pk
        CONSTRAINT Foo_HasMany_Bars  -- constraint name
            FOREIGN KEY   (Foo)      -- fk in (this) referencing table
            REFERENCES Foo(Foo)      -- pk in referenced table
        )
  • Da Foo.Fooes sich um einen Primärschlüssel handelt, der eindeutig ist, gibt es für einen bestimmten Wert von nur eine ZeileFoo

  • Da Bar.Fooes sich um eine Referenz, einen Fremdschlüssel und keinen eindeutigen Index handelt, können für jeden Wert von viele Zeilen vorhanden seinFoo
  • Daher die Beziehung Foo::Bar eins zu viele
  • Jetzt können Sie die Beziehung umgekehrt wahrnehmen (betrachten),Bar::Foo ist viele zu eins
    • Aber lassen Sie sich davon nicht verwirren: Für eine BarZeile gibt es nur eine FooZeile, auf die verwiesen wird
  • In SQL ist das alles, was wir haben. Das ist alles was nötig ist.

Was ist der wirkliche Unterschied zwischen einer zu vielen und vielen zu einer Beziehung?

Es gibt nur eine Beziehung, daher gibt es keinen Unterschied. Die Wahrnehmung (von einem "Ende" oder dem anderen "Ende") oder das Rückwärtslesen ändert nichts an der Beziehung.

Kardinalität

Die Kardinalität wird zuerst im Datenmodell deklariert, dh logisch und physisch (die Absicht), und dann in der Implementierung (die realisierte Absicht).

Kardinalität

Eins zu Null zu Viele
In SQL ist dies (oben) alles, was erforderlich ist.

Eins zu eins zu viele
Sie benötigen eine Transaktion , um die in der Referenzierungstabelle angegebene zu erzwingen.

Eins zu Null zu Eins
Sie brauchen in Bar:

CONSTRAINT AK    -- constraint name
    UNIQUE (Foo) -- unique column, which makes it an Alternate Key

Eins zu eins
Sie benötigen eine Transaktion , um die in der Referenzierungstabelle angegebene zu erzwingen.

Viele zu viele
Auf der physischen Ebene gibt es so etwas nicht (erinnern Sie sich, es gibt nur eine Art von Beziehung in SQL).

Auf den frühen logischen Ebenen während der Modellierungsübung ist es zweckmäßig , eine solche Beziehung zu zeichnen. Bevor sich das Modell der Implementierung nähert, sollte es besser dazu gebracht werden, nur Dinge zu verwenden, die existieren können. Eine solche Beziehung wird durch Implementieren einer assoziativen Tabelle gelöst.

Viele zu viele gelöst

PerformanceDBA
quelle
1
@ Martinij Peters. Ich kann es bearbeiten, um dem Verhaltenskodex zu entsprechen. Sie haben aber auch (a) Erklärungen entfernt und (b) Tatsachen in der Realität nachgewiesen. Was mache ich dagegen?
PerformanceDBA
3
Finden Sie einen anderen Weg, um diese Dinge auszudrücken, ohne zu schimpfen, Namen zu nennen und den Intellekt oder das berufliche Verhalten eines Menschen in Frage zu stellen. Konzentrieren Sie sich auf die Technologie, nicht auf die Menschen, die möglicherweise falsch liegen oder nicht.
Martijn Pieters
2

Eins-zu-Viele und Viele-zu-Eins sind in der Vielheit ähnlich, aber nicht im Aspekt (dh in der Richtung).

Die Abbildung von Assoziationen zwischen Entitätsklassen und den Beziehungen zwischen den Tabellen. Es gibt zwei Kategorien von Beziehungen:

  1. Multiplizität (ER-Begriff: Kardinalität)
    • Eins-zu-eins-Beziehungen : Beispiel Ehemann und Ehefrau
    • Eins-zu-viele-Beziehungen : Beispiel Mutter und Kinder
    • Viele-zu-Viele-Beziehungen : Beispiel für Schüler und Fach
  2. Direktionalität : Hat keinen Einfluss auf die Zuordnung, macht jedoch einen Unterschied darin, wie wir auf Daten zugreifen können.
    • Unidirektionale Beziehungen : Ein Beziehungsfeld oder eine Eigenschaft, die sich auf die andere Entität bezieht.
    • Bidirektionale Beziehungen : Jede Entität verfügt über ein Beziehungsfeld oder eine Beziehungseigenschaft, die sich auf die andere Entität bezieht.
Premraj
quelle
In einer relationalen Datenbank gibt es keine "Direktionalität". Jede Beziehung hat zwei "Enden": die Referenz (Tabelle, auf die verwiesen wird) und die Referenzierung (Tabelle, auf die verwiesen wird). Mit SQL / DML kann auf jede Tabelle verwiesen werden, wie Sie möchten ... eine Seite ... die andere Seite ... beide Seiten ... keine Seiten.
PerformanceDBA
0

Es gibt keinen praktischen Unterschied. Verwenden Sie einfach die Beziehung, die am sinnvollsten ist, wenn Sie Ihr Problem so sehen, wie Devendra es illustriert.

Tom Bell
quelle
Es gibt sicherlich einen Unterschied, sowohl konzeptionell als auch im generierten Schema. Siehe meine Antwort: stackoverflow.com/a/37954280/179850
Grau
3
@Grau. Nein, da ist kein. Ihre Antwort ist nicht nur falsch, sie verwirrt auch Anfänger (diejenigen, die diese Frage stellen).
PerformanceDBA
0
  • --- Eins zu viele --- Ein Elternteil kann zwei oder mehr Kinder haben.
  • --- Viele zu einem --- Diese 3 Kinder können alleinerziehende Eltern haben.

    Beide sind ähnlich. Dies kann verwendet werden, gehört zum Bedarf. Wenn Sie Kinder für einen bestimmten Elternteil finden möchten, können Sie mit One-To-Many gehen. Oder wenn Sie Eltern für Zwillinge finden möchten, können Sie mit Many-To-One gehen. Gleichfalls....,

Samuel H.
quelle
-6

eins zu viele hat übergeordnete Klasse enthält n Anzahl von Kindern, so dass es sich um eine Sammlungszuordnung handelt.

Viele-zu-Eins hat n Anzahl von Kindern enthält ein Elternteil, so dass es sich um eine Objektzuordnung handelt

Chandra
quelle
Diese Antwort ist gut und hat zusätzliche Informationen, die nicht verstehen, warum sie abgelehnt wurden. Im unidirektionalen Kontext bieten eins zu viele und viele zu eins je nach UX nicht die gleiche Codequalität: Wenn Sie eine Reihe von Daten benötigen, die sich darauf beziehen Daher ist eins zu viele klüger, wenn Sie keine select-Anweisung benötigen, bei der eine Bedingung in Ordnung ist, da sich die Menge in der Karte befindet. Wenn der Benutzer die Daten jedoch nicht abrufen muss und sich für jede Zeile als eindeutig interessiert gewünschte Instanz so viele zu einem ist klüger Wahl
Mohammed Housseyn Taleb
Es mag eine gute Antwort sein, aber sie sind nicht die gleichen: Viele-zu-Eins hat eine Elternklasse mit n Anzahl von Kindern, Eins-zu-Viele hat viele Eltern zu einem Kind. In SQL macht es möglicherweise keinen Unterschied, da die Viele-zu-Eins-Beziehung omnidirektional sein kann. In einem Framework wie Django ist dies jedoch ein großes Problem, da es keine Eins-zu-Viele-Beziehung und keinen Fremdschlüssel gibt befasst sich mit der Viele-zu-Eins-Beziehung funktioniert nur natürlich in eine Richtung, dies kann nicht auf die gleiche Weise umgekehrt verwendet werden.
iFunction