Một đơn đặt hàng sẽ luôn có một khách hàng, phải không? Vì vậy, nó không phải là kết hợp bên trái mà là kết hợp bên trong.
Những gì liên kết chúng là customer_id. Vì vậy, SQL của bạn chỉ đơn giản là:
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;
Mối quan hệ thực thể:
Đặt hàng CustomerCustomer_Id 0 ... N> --- + 1 Customer_Id ... ...
Mối quan hệ EF này là từ cơ sở dữ liệu mẫu Northwind của MS SQL Server. Trong cơ sở dữ liệu mẫu đó, giống như của bạn, có Khách hàng và Đơn đặt hàng. Các bảng Khách hàng và Đơn hàng có liên quan với nhau thông qua các trường CustomerId trong cả hai bảng (nó là khóa chính trong Khách hàng và khóa ngoại trong bảng Đơn hàng). Khi bạn mô hình hóa điều đó dưới dạng quan hệ Thực thể, bạn có sơ đồ trên. Thực thể khách hàng có thuộc tính điều hướng "Đơn đặt hàng" (qua customerId) trỏ đến Đơn đặt hàng của một Khách hàng cụ thể. Và thực thể Đơn hàng có thuộc tính điều hướng trỏ đến Khách hàng của nó (một lần nữa thông qua CustomerId). Mối quan hệ là 1 đến 0 hoặc nhiều (1 - *), có nghĩa là một Khách hàng có thể có 0 hoặc nhiều Đơn đặt hàng.
Khi bạn thực hiện tham gia từ phía Khách hàng, bạn sử dụng tham gia TRÁI "nếu bạn muốn xem tất cả Khách hàng bất kể họ có (các) Đơn hàng hay không" - 0 hoặc nhiều Đơn hàng. Nếu bạn chỉ muốn xem những người có (các) Thứ tự thì bạn sử dụng một phép nối bên trong.
Khi bạn thực hiện tham gia từ phía Đơn đặt hàng, thì Đơn hàng phải có Khách hàng nên nó không thể là tham gia TRÁI. Đó là tham gia INNER.
Bạn có thể kiểm tra mối quan hệ từ cả hai phía bằng cách sử dụng trường CustomerId kết nối.
Bạn sẽ không có một bảng riêng biệt cho "OrderId, CustomerId" vì nó không phải là quan hệ nhiều-nhiều (nó sẽ là sự dư thừa thuần túy và sẽ tạo ra sự bất thường trong quá trình chuẩn hóa).
Hy vọng bây giờ nó rõ ràng hơn.
