Bốn thiết kế mối quan hệ bảng

Question

Tôi đã gặp phải tình huống này nhiều lần trong các dự án khác nhau gần đây. Dưới đây là một sơ đồ của bốn bảng, dán nhãn với các chữ cái:

 A 
    1/\ 1 
/ \ 
*/ \ * 
B  C 
1 \ /1 
    \ /
    * \/* 
    D 

Trong kịch bản này, nó có thể cho các dữ liệu trở nên không phù hợp nếu các phím B-A và C-A không phù hợp cho một được cung cấp D.

Đối với một cụ thể (tạo thành) Ví dụ, hãy tưởng tượng A là Company, B là Employee, C là Project, và D là WorkItem. Trong trường hợp này, không có gì ngăn cản một mục công việc được tạo ra mà tuyên bố được gán cho một người thậm chí không làm việc cho công ty sở hữu dự án.

Tôi chủ yếu chỉ tò mò, có một giải pháp thiết kế cho sự cố này không? Tôi biết trong các ứng dụng thực tế, điều này quan trọng bạn có thể sử dụng các bộ kích hoạt hoặc một số biện pháp bảo vệ khác. Tôi đã không tìm thấy một cách để thay đổi các bảng để làm cho một sự không thống nhất như vậy không thể. Là có một cách?

Lưu ý rằng chỉ cắt đứt một trong những kết nối, như C-A không làm việc, bởi vì nếu không có D 's tồn tại cho C mà bạn sẽ không có cách nào truy tìm các kết nối trở lại A.

Answer 1

Sử dụng các phím tổng hợp (ví dụ: khóa bao gồm nhiều trường) cho bảng hạ lưu. Sau đó, trong D, bạn có thể sử dụng chỉ là một lĩnh vực tổ chức của một chính:

[EDIT: Cố định ngu ngốc sao & dán lỗi trong D's 2 FK]

CREATE TABLE A (
    A_ID INTEGER PRIMARY KEY 
    -- Any other fields you want... 
); 

CREATE TABLE B (
    A_ID INTEGER REFERENCES A.A_ID, 
    B_ID INTEGER, 
    -- Any other fields you want... 
    PRIMARY KEY (A_ID, B_ID) 
); 

CREATE TABLE C (
    A_ID INTEGER REFERENCES A.A_ID, 
    C_ID INTEGER, 
    -- Any other fields you want... 
    PRIMARY KEY (A_ID, C_ID) 
); 

CREATE TABLE D (
    A_ID INTEGER, -- This field forms part of the FK for BOTH B and C 
    B_ID INTEGER, 
    C_ID INTEGER, 
    D_ID INTEGER, 
    -- Any other fields you want... 
    PRIMARY KEY (A_ID, B_ID, C_ID, D_ID), 
    FOREIGN KEY (A_ID, B_ID) REFERENCES B (A_ID, B_ID), 
    FOREIGN KEY (A_ID, C_ID) REFERENCES C (A_ID, C_ID) 
); 

tôi đã không kiểm tra trên SQL, nhưng bạn có được ý tưởng hy vọng. Lưu ý rằng D không cần một ràng buộc FK thứ ba trở lại A, bởi vì điều này đã được ngụ ý bởi các FK khác của nó (trên thực tế nó được ngụ ý riêng biệt bởi mỗi một trong số chúng).

Kiểm tra tính toàn vẹn tham chiếu luôn tốt hơn trình kích hoạt - ít nhất với PostgreSQL, và tôi nghi ngờ điều đó đúng với tất cả RDBMS.