Làm thế nào để thể hiện ràng buộc này trong một lược đồ cơ sở dữ liệu?

Tôi có các phụ thuộc chức năng sau trong BCNF:

a,b -> c
a -> d
b -> d

Với các ràng buộc bổ sung, không avà bnên được kết hợp với a c, ở đâu avà bcó các ds khác nhau .

Thí dụ:

a | d   b | d   a | b | c
-----   -----   ---------
1 | 3   5 | 3   1 | 5 | 6
2 | 4           2 | 5 | 7

Hàng đầu tiên a,b,cđược phép ( 1->3, 5->3), nhưng hàng thứ hai bị cấm, vì ( 2->4, 5->3) 4 != 3.

Ràng buộc bổ sung này có thể có hai hiệu ứng trên dữ liệu của tôi. Đối với mỗi a,b,ccó hai cách xác định dự phòng d. Có thể có dữ liệu vi phạm các ràng buộc. Làm thế nào lược đồ của tôi có thể phản ánh ràng buộc bổ sung này?

Tóm lại, hãy tạo một ASSERTIONđể đảm bảo rằng bất kỳ lúc nào quy tắc kinh doanh có thể bị vi phạm, ví dụ cú pháp SQL-92 tiêu chuẩn đầy đủ:

CREATE TABLE T1
(
 a INTEGER NOT NULL, 
 d INTEGER NOT NULL, 
 UNIQUE (a, d)
);

CREATE TABLE T2
(
 b INTEGER NOT NULL, 
 d INTEGER NOT NULL, 
 UNIQUE (b, d)
);

CREATE TABLE T3
(
 a INTEGER NOT NULL,
 b INTEGER NOT NULL, 
 c INTEGER NOT NULL, 
 UNIQUE (a, b, c)
);

CREATE ASSERTION no_a_and_b_should_be_combined_with_a_c_where_a_and_b_have_different_ds
   CHECK (
          NOT EXISTS (
                      SELECT *
                        FROM T3
                       WHERE NOT EXISTS (
                                         SELECT T1.d
                                           FROM T1
                                          WHERE T1.a = T3.a 
                                         INTERSECT        
                                         SELECT T2.d
                                           FROM T2
                                          WHERE T3.b = T3.b 
                                        )
                     )
         );

Tin xấu là không có sản phẩm SQL thương mại (hoặc nói cách khác?) Hỗ trợ CREATE ASSERTION.

Hầu hết các sản phẩm SQL có độ mạnh công nghiệp đều hỗ trợ các trình kích hoạt: người ta có thể thực hiện các điều trên trong một trình kích hoạt trên mỗi bảng áp dụng . MS Access là sản phẩm thương mại duy nhất tôi biết có hỗ trợ các truy vấn con trong các CHECKràng buộc nhưng tôi không coi đó là thế mạnh công nghiệp. Có nhiều cách giải quyết khác, ví dụ, buộc người dùng chỉ cập nhật bảng thông qua các thủ tục được lưu trữ có thể được hiển thị để không bao giờ rời khỏi cơ sở dữ liệu ở trạng thái bất hợp pháp.

Tóm lại, giới thiệu dvào bảng thứ ba để kích hoạt các ràng buộc khóa ngoại vanilla, ví dụ cú pháp SQL-92 chuyển tiếp:

CREATE TABLE T1
(
 a INTEGER NOT NULL, 
 d INTEGER NOT NULL, 
 UNIQUE (a, d)
);

CREATE TABLE T2
(
 b INTEGER NOT NULL, 
 d INTEGER NOT NULL, 
 UNIQUE (b, d)
);

CREATE TABLE T3
(
 a INTEGER NOT NULL,
 b INTEGER NOT NULL, 
 c INTEGER NOT NULL, 
 d INTEGER NOT NULL, 
 UNIQUE (a, b, c),
 FOREIGN KEY (a, d) REFERENCES T1 (a, d), 
 FOREIGN KEY (b, d) REFERENCES T2 (b, d)
);

"Vì vậy, câu trả lời của bạn là" không thể "?"

Nhiều thứ có thể. Trong trường hợp rất đặc biệt của bạn, có vẻ như tôi thực thi ràng buộc 'bổ sung' của bạn bằng cách giữ bảng cơ sở dữ liệu đơn (4 cột). Điều này sẽ đảm bảo với bạn rằng mọi kết hợp a, b sẽ luôn luôn tương ứng với cùng một d (bởi vì chỉ có thể có một d). Cái giá bạn phải trả là không còn cách "tự nhiên" (tức là một hệ quả tức thời của cấu trúc rất logic của cơ sở dữ liệu) sẽ tự động thực thi a-> d và b-> d FD của bạn "tự động" .

Một thực tế nổi tiếng là quá trình phân rã thông thường hóa cổ điển, đôi khi yêu cầu một số FD nhất định được khôi phục như một ràng buộc cơ sở dữ liệu, bởi vì trong thiết kế phân tách, quy tắc không còn có thể được nêu là FD. Trường hợp cụ thể của bạn dường như là một trường hợp như vậy, trong đó bạn có sự lựa chọn giữa một thiết kế "tự động" thi hành a-> d và b-> d, nhưng bạn phải nỗ lực thêm để thực thi ràng buộc bổ sung hoặc thiết kế đó "tự động" thi hành ràng buộc bổ sung của bạn, nhưng ở đó bạn phải thực hiện thêm công việc để thực thi [các ràng buộc tương ứng với] các a-> d và b-> d FD của bạn.

Có TẤT CẢ các ràng buộc mà bạn đề cập được thi hành chỉ bằng cấu trúc cơ sở dữ liệu, trong trường hợp cụ thể của bạn, có thể sử dụng giải pháp của onedaywhen. Tuy nhiên, (a) chỉ là một giải pháp cho các trường hợp cụ thể như ví dụ của bạn, (b) giá bạn phải trả là tăng dự phòng và do đó, sự phức tạp bổ sung trong việc cập nhật cơ sở dữ liệu của bạn (và một số cập nhật nhất định có thể không đạt được !!!) và (c) vẫn còn một thực tế là không phải tất cả các ràng buộc cơ sở dữ liệu có thể hiểu được đều có thể biểu thị như một FD.

(Xin lỗi vì đã đăng câu trả lời thứ hai. Đăng nhập Stackoverflow của tôi không cho phép tôi nhận xét ở đây.)