Mối quan hệ nước ngoài có điều kiện

Tôi hiện có một khóa ngoại giữa hai thực thể và tôi muốn làm cho mối quan hệ đó có điều kiện với thực thể Loại của một trong các bảng. Đây là bảng chữ cái, điều này được thực hiện thông qua các điều chỉnh FK từ con đến cha mẹ

                  Store
            /                \
  Employees                    \
                             TransactionalStores
                            /       |         \
                     Kiosks         |          BrickMortars
                                 Onlines

Tôi hiện có mối quan hệ FK từ Nhân viên để lưu trữ

ALTER TABLE Employees ADD CONSTRAINT Employee_Store
            FOREIGN KEY (TransStoreId)
            REFERENCES TransactionalStores(StoreId)

Tôi muốn thêm điều kiện:

WHERE TransactionalStores.storeType != 'ONLINE_TYPE'

Điều này có thể hay tôi phải phân lớp Giao dịch viên thành hai loại con mới (ví dụ: PhysStores và VirtualStores)

Phím nước ngoài có thể được thực hiện có điều kiện ... loại. Bạn không hiển thị bố cục của mỗi bảng, vì vậy đây là một thiết kế điển hình thể hiện các mối quan hệ của bạn:

create table TransactionalStores(
    ID        int   not null auto_increment,
    StoreType char  not null,
    ..., -- other data
    constraint CK_TransStoreType check( StoreType in( 'B', 'K', 'O' )),
    constraint PK_TransactionalStores primary key( ID ),
    constraint UQ_TransStoreTypes unique( ID, StoreType ) -- for FK references
);
create table Kiosks(
    ID         int   not null,
    StoreType  char  not null,
    ..., -- other Kiosk data
    constraint CK_KioskStoreType check( StoreType = 'K' ), -- kiosks only
    constraint PK_Kiosks primary key( ID, StoreType ),
    constraint FK_Kiosks_TransStores foreign key( ID, StoreType )
        references TransactionalStores( ID, StoreType )
);

Onlines và BrickMorters sẽ có cùng cấu trúc cơ bản nhưng với StoreType bị ràng buộc chỉ 'O' hoặc 'B' là phù hợp.

Bây giờ bạn muốn có một tài liệu tham khảo từ một bảng khác đến TransactionalStores (và thông qua nó tới các bảng cửa hàng khác nhau) nhưng giới hạn ở Kiốt và BrickMorter. Sự khác biệt duy nhất sẽ là trong các ràng buộc:

create table Employees(
    ID         int       not null,
    StoreID    int,
    StoreType  char,
    ..., -- other Employee data
    constraint PK_Employees primary key( ID ),
    constraint CK_Employees_StoreType check( coalesce( StoreType, 'X' ) <> 'O' )), -- Online not allowed
    constraint FK_Employees_TransStores foreign key( StoreID, StoreType )
        references TransactionalStores( ID, StoreType )
);

Trong bảng này, tham chiếu FK buộc StoreType phải là 'K', 'O' hoặc 'B' nhưng giới hạn trường tiếp tục giới hạn nó chỉ ở 'K' hoặc 'B'.

Để minh họa, tôi đã sử dụng một ràng buộc kiểm tra để giới hạn các loại cửa hàng trong bảng TransactionStores. Trong cuộc sống thực, một bảng tra cứu StoreTypes với StoreType là FK cho bảng đó có lẽ là một lựa chọn thiết kế tốt hơn.

Một khóa ngoại không thể được thực hiện có điều kiện để ra khỏi câu hỏi. Quy tắc kinh doanh dường như là một nhân viên có thể làm việc cho một và chỉ một cửa hàng thực tế . Cho rằng, siêu loại cửa hàng có hai loại phụ như bạn đề xuất: Vật lý và Trực tuyến . Mỗi cửa hàng thực tế có thể được nhân viên của một hoặc nhiều nhân viên và mỗi nhân viên phải được chỉ định cho một và chỉ một cửa hàng thực tế. Các cửa hàng vật lý sau đó có hai loại phụ là Brick và Mortar và Kiosk . Có ba loại phụ trực tiếp - Kiosk , Trực tuyến và Gạch và Vữa- ẩn một tài sản được sở hữu bởi mọi cửa hàng - có thể tìm thấy nó tại một địa điểm thực tế hay không. Bây giờ thiết kế dựa vào một con người để hiểu ngữ nghĩa vốn có trong tên loại phụ để hiểu rằng các cửa hàng trực tuyến không có nhân viên. Điều này không dễ thấy trong lược đồ và mã được khai báo dưới dạng trình kích hoạt phải được viết để thể hiện sự hiểu biết đó theo cách mà DBMS có thể thực thi. Phát triển, thử nghiệm và duy trì một trình kích hoạt không ảnh hưởng đến hiệu suất là một giải pháp khó thực hiện hơn nhiều như trong sách Toán học ứng dụng cho các chuyên gia cơ sở dữ liệu .

Gõ phụ Lưu trữ đầu tiên trên loại vị trí của nó và sau đó trên loại cấu trúc của cửa hàng vật lý là một thiết kế chính xác hơn đối với các quy tắc kinh doanh và loại bỏ sự cần thiết phải viết mã để thực thi quy tắc. Khi tài sản được bao gồm rõ ràng là một loại vị trí cửa hàng có thể được sử dụng làm phân biệt đối xử cho các loại phụ, mối quan hệ có thể được thực hiện trực tiếp giữa nhân viên và cửa hàng thực tế và do đó thực hiện đầy đủ quy tắc chỉ với ràng buộc khóa ngoại. ere là một mô hình dữ liệu được tạo với ký hiệu hộp trong hộp cho các kiểu siêu và kiểu con, mà tôi thích cho cách trình bày thanh lịch của nó. Biểu đồ bây giờ có thể hiển thị rõ ràng các quy tắc là tốt. Oracle SQL Developer , cho thấy siêu và gõ phụ bằng Barker-Ellis