Thực hiện mối quan hệ một đến không hoặc một trong SQL

Hãy để chúng tôi nói rằng tôi đang thiết kế một cơ sở dữ liệu cho một kịch bản trong đó tồn tại mối quan hệ một đối một hoặc không (1-0..1). Ví dụ:

• Có một nhóm Người dùng và một số Người dùng cũng có thể là Khách hàng .

Vì vậy, tôi đã tạo ra hai bảng tương ứng, usersvà customers, nhưng

Cách tốt nhất để thể hiện và thực hiện tình huống này trong một nền tảng SQL nhất định là gì? Tôi đã xem xét hai giải pháp có thể:

1. Trong usersbảng, thêm customercột có thể là tham chiếu FOREIGN KEY đến customershoặc NULLđánh dấu.

2. Trong customersbảng, bao gồm một usercột (được đặt với một UNIQUEràng buộc) trỏ đến usersbảng.

Tôi đã hỏi một câu hỏi tương tự ở một số diễn đàn, nhưng câu trả lời về cơ bản là bất cứ điều gì bạn cần, bất cứ điều gì bạn nghĩ thuận tiện. Tôi không thích kiểu trả lời này. Tôi muốn một phần nghiêm trọng của lý thuyết DB thay vào đó, một câu trả lời có cơ sở. Tôi có thể đọc các mối quan hệ 1-0..1 ở đâu?

Tôi muốn một phần nghiêm trọng của lý thuyết DB

Lý thuyết quan hệ hiện đại bác bỏ null , dường như ngay lập tức làm mất hiệu lực tùy chọn của bạn 1. Tuy nhiên, người rơm này có thể bị loại bỏ bằng cách thay thế null mặc định bằng một giá trị mặc định, ví dụ như một khách hàng 'giả' được tạo ra để mô hình rõ ràng "không phải là khách hàng" thư tín.

Tôi nghĩ rằng tùy chọn 2 của bạn là hợp lý nhất về mặt lý thuyết bởi vì, không giống như tùy chọn 1 được sửa đổi, các mối quan hệ có thể ở dạng bình thường thứ sáu (6NF), là dạng bình thường tham gia chiếu và là dạng bình thường cao nhất có thể đạt được.

Tôi cũng đã nghe nói về một quy tắc thiết kế nói rằng một mối quan hệ nên mô hình hóa EITHER một thực thể HOẶC mối quan hệ giữa các thực thể nhưng không bao giờ cả hai, có vẻ hợp lý với tôi. Một lần nữa, điều này sẽ ủng hộ lựa chọn 2. Tuy nhiên, tôi đã nghe nói về quy tắc này từ nhiều năm trước, không nhớ lại nơi nào và không thể đưa ra cơ sở lý thuyết nghiêm túc nào (ngoài 6NF như đã đề cập ở trên).

Bạn đã được đưa ra câu trả lời đúng một phần. Câu trả lời thực sự đến từ mô hình dữ liệu của bạn và cách nó được chuẩn hóa. Điều quan trọng là làm thế nào bạn có được mối quan hệ:

• Các customersbảng bao gồm một số lĩnh vực xem xét cho các usersbảng thuộc với khái niệm khách hàng, và là null trừ khi người dùng cũng là một khách hàng (sub-type của người dùng). Trong trường hợp này, customersbảng kế thừa khóa chính từ usersbảng. (Có thể nhiều loại phụ có thể hoặc không thể trùng nhau.)

• Các customersbảng bao gồm một số lĩnh vực liên quan đến khái niệm khách hàng, nhưng không nhất thiết phải là khái niệm dùng. Khách hàng là một bảng mạnh và không phụ thuộc vào khái niệm người dùng. (Việc xóa usersbảng sẽ không ảnh hưởng đáng kể đến thiết kế của bảng khách hàng.) Trong trường hợp này, bảng khách hàng nhận được khóa chính của chính nó.

Những gì bạn có là một trường hợp đặc biệt của một mối quan hệ tùy chọn với nhiều mối quan hệ trong đó giới hạn trên là 1. Hãy xem xét nó từ cả hai phía: Liệu một người dùng có thể có nhiều khách hàng, hoặc một khách hàng có nhiều người dùng? Nếu vậy, bạn sẽ cần phải sửa sang lại dữ liệu của bạn.

Thêm user-idkhóa ngoại vào customersbảng có thể được coi là lựa chọn tốt hơn vì ánh xạ chính xác mối quan hệ một đến nhiều (giới hạn trên 1) và tránh trường không có giá trị. Để thực thi giới hạn trên, chỉ số khóa ngoài cần phải là duy nhất. Điều này sẽ tự động xảy ra nếu khóa chính là user-id.

Việc thêm customer-iddưới dạng khóa ngoại tùy chọn vào usersbảng sẽ thực thi giới hạn trên 1 trong mối quan hệ nhưng đảo ngược sự phụ thuộc.

Bạn đã xem xét một cách tiếp cận phức tạp hơn một chút nhưng linh hoạt. Bảng cha là "người" (hoặc "thực thể" tùy thuộc vào mức độ phức tạp mà bạn muốn trở thành). Sau đó, mỗi bảng khách hàng và bảng người dùng có một FK cho bảng người. Bảng người chứa thông tin cá nhân trong khi bảng khách hàng và người dùng chỉ chứa các thuộc tính được liên kết với người dùng hoặc khách hàng. Thông thường địa chỉ (email và thư điện tử), số điện thoại, v.v. cũng được thể hiện trong các bảng riêng biệt với các bảng ánh xạ để cho phép nhiều tình huống. Đây là một mô hình tương đối phổ biến mà bạn có thể tìm thấy trên một số trang web tham khảo.