Умовні зовнішні ключові відносини

Наразі у мене є зовнішній ключ між двома сутностями, і я хотів би, щоб це відношення було обумовлене типом entity однієї з таблиць. Ось ієрархія таблиць, це робиться за допомогою рефлексив FK від дитини до батька

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

В даний час у мене є стосунки ФК від Співробітник до магазину

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

Я хотів би додати умовне:

WHERE TransactionalStores.storeType != 'ONLINE_TYPE'

Чи можливо це чи треба підкласити TransactionalStores у два нові підтипи (наприклад, PhysicalStores та VirtualStores)

Іноземні ключі можна зробити умовними ... подібними. Ви не показуєте макет кожної таблиці, тому ось типовий дизайн, який показує ваші стосунки:

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 і BrickMorters мали б однакову базову структуру, але StoreType обмежений лише "O" або "B".

Тепер ви хочете посилання з іншої таблиці на TransactionalStores (і через неї на різні таблиці магазинів), але обмежившись кіосками та BrickMorter. Єдина різниця полягала б у обмеженні:

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 )
);

У цій таблиці посилання FK примушує StoreType бути або "K", "O" або "B", але обмеження поля додатково обмежує його лише "K" або "B".

Для ілюстрації я використав обмеження для перевірки обмеження типів магазину в таблиці TransactionStores. У реальному житті кращим вибором дизайну може стати таблиця пошуку StoreTypes, в якій StoreType є FK для цієї таблиці.

Іноземний ключ не можна робити умовним, тому про це не йдеться. Правилом бізнесу є те, що працівник може працювати в одному і лише одному фізичному магазині. Враховуючи це, супер тип магазину має два підтипи, як ви запропонували: Фізичний та Інтернет . У кожному фізичному магазині може бути один чи більше працівників, і кожен працівник повинен бути призначений до одного і лише одного фізичного магазину. Тоді у фізичних магазинах є два підтипи - цегла та міномет та кіоск . Маючи три прямі підтипи - Кіоск , Інтернет та Цегла та Ступка- приховує майно, яким володіє кожен магазин - незалежно від того, чи його можна знайти у фізичному місці. Тепер дизайн покладається на людину, щоб зрозуміти семантику, притаманну іменам підтипу, і зрозуміти, що в інтернет-магазинах немає співробітників. Це не очевидно в заявленій схемі, і код у формі тригера повинен бути записаний, щоб виразити це розуміння способом, яким можуть застосовувати СУБД. Розробка, тестування та підтримка тригера, який не впливає на продуктивність, є набагато складнішим рішенням, як показано в книзі « Прикладна математика для фахівців з бази даних» .

Підтипання магазину спочатку за типом розташування, а потім за типом структури фізичного магазину є більш правильним дизайном щодо правил бізнесу та виключає необхідність введення коду для виконання правила. Після того, як властивість буде чітко включено як тип розташування магазину, який може бути використаний як дискримінатор для підтипів, взаємозв'язок може бути встановлений безпосередньо між співробітниками та фізичними магазинами, і, таким чином, повністю реалізувати правило лише з обмеженням зовнішнього ключа. ere - модель даних, створена за допомогою Oracle SQL Developer Data Modeler, яка демонструє супер та субтипу за допомогою Barker-Ellisполе в позначеннях коробки для супер і підтипів, що я віддаю перевагу для його елегантної презентації. Діаграма також може чітко показувати правило.