Eine Bestellung würde immer einen Kunden haben, oder? Es handelt sich also nicht um einen linken, sondern um einen inneren Join.
Was sie verbindet, ist die Kunden-ID. Ihr SQL ist also einfach:
select o.order_number, o.customer_ID, o.address,
c.first_name, c.last_name
from orders o
inner join customer c on o.customer_ID = c.customer_ID;
Entitätsbeziehung:
Auftrag KundeKunden_Id 0...N>---+ 1 Kunden_Id... ...
Diese EF-Beziehung stammt aus der Beispieldatenbank Northwind von MS SQL Server. In dieser Beispieldatenbank gibt es, genau wie in Ihrer, Kunden und Bestellungen. Die Tabellen „Kunden“ und „Bestellungen“ sind über die Felder „CustomerId“ in beiden Tabellen verknüpft (dies ist der Primärschlüssel in der Tabelle „Kunden“ und der Fremdschlüssel in der Tabelle „Bestellungen“). Wenn Sie dies als Entitätsbeziehung modellieren, haben Sie das obige Diagramm. Kundenentitäten verfügen über eine Navigationseigenschaft „Bestellungen“ (über die Kunden-ID), die auf die Bestellungen eines bestimmten Kunden verweist. Und die Bestellentität hat eine Navigationseigenschaft, die auf ihren Kunden verweist (wieder über CustomerId). Das Verhältnis ist 1 zu 0 oder viele (1 - *), was bedeutet, dass ein Kunde 0 oder mehr Bestellungen haben kann.
Wenn Sie die Verknüpfung von der Seite des Kunden vornehmen, verwenden Sie eine LINKE Verknüpfung „wenn Sie alle Kunden sehen möchten, unabhängig davon, ob sie Bestellungen haben oder nicht“ – 0 oder mehr Bestellungen. Wenn Sie nur die mit Order(s) sehen möchten, verwenden Sie einen Inner Join.
Wenn Sie den Beitritt von der Seite der Bestellungen aus durchführen, muss eine Bestellung einen Kunden haben, sodass es sich nicht um einen LINKS-Beitritt handeln kann. Es ist ein INNER Join.
Sie können die Beziehung von beiden Seiten überprüfen, indem Sie das Feld CustomerId verbinden.
Sie hätten keine separate Tabelle für "OrderId, CustomerId", da es sich nicht um eine Viele-zu-Viele-Beziehung handelt (es wäre reine Redundanz und würde Normalisierungsanomalien erzeugen).
Hoffe es ist jetzt klarer.
