Koşullu Yabancı Anahtar İlişkisi

Şu anda iki varlık arasında bir yabancı anahtar var ve bu ilişki tablolardan birinin entityType koşullu yapmak istiyorum. İşte tabloların hiyerarşisi, bu çocuktan aileye FK referansları ile yapılır

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

Şu anda Çalışandan mağazaya FK ilişkim var

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

Koşullu eklemek istiyorum:

WHERE TransactionalStores.storeType != 'ONLINE_TYPE'

Bu mümkün mü yoksa TransactionalStores'ı iki yeni alt tipe (örneğin, Fiziksel Depolar ve Sanal Depolar) alt sınıfta tutmalıyım

Yabancı anahtarlar olabilir koşullu ... çeşit yapılabilir. Her tablonun düzenini göstermezsiniz, bu yüzden ilişkilerinizi gösteren tipik bir tasarım:

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 ve BrickMorters aynı temel yapıya sahip olacaktı, ancak StoreType uygun şekilde sadece 'O' veya 'B' ile sınırlıydı.

Şimdi başka bir tablodan TransactionalStores'a (ve çeşitli mağaza tablolarına) bir referans istiyorsunuz ancak Kiosks ve BrickMorter ile sınırlısınız. Tek fark kısıtlama olacaktır:

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

Bu tabloda, FK başvurusu StoreType'ı 'K', 'O' veya 'B' olmaya zorlar, ancak alan kısıtlaması bunu yalnızca 'K' veya 'B' ile sınırlar.

Örnek olarak, TransactionStores tablosundaki mağaza türlerini sınırlamak için bir kontrol kısıtlaması kullandım. Gerçek hayatta, StoreType'ın bu tablo için bir FK olduğu bir StoreTypes arama tablosu muhtemelen daha iyi bir tasarım seçimi olacaktır.

Yabancı bir anahtar şartlı hale getirilemez, bu yüzden söz konusu değildir. İş kuralı, bir çalışanın yalnızca bir fiziksel mağaza için çalışabileceği şeklindedir . Buna göre, süper mağaza türünün önerdiğiniz gibi iki alt türü vardır: Fiziksel ve Çevrimiçi . Her fiziksel mağazada bir veya daha fazla çalışan bulunabilir ve her çalışan bir ve yalnızca bir fiziksel mağazaya atanmalıdır. Fiziksel mağazaların Tuğla ve Harç ve Kiosk olmak üzere iki alt türü vardır . Üç doğrudan alt türe sahip olmak - Kiosk , Online ve Brick ve Harç- fiziksel bir yerde bulunsun veya bulunmasın, her mağazaya ait olan bir mülkü gizler. Artık tasarım , çevrimiçi mağazaların çalışanlarının olmadığını anlamak için alt tür adlarının doğasında olan anlambilimi anlaması için bir insana güveniyor . Bu, beyan edilen şemada açıkça görülmez ve DBMS'nin uygulayabileceği bir şekilde bu anlayışı ifade etmek için bir tetikleyici şeklinde kod yazılmalıdır. Performansı etkilemeyen bir tetikleyicinin geliştirilmesi, test edilmesi ve sürdürülmesi Veritabanı Profesyonelleri için Uygulamalı Matematik kitabında gösterildiği gibi uygulanması çok daha zor bir çözümdür .

Alt-yazma Mağaza önce kendi yerine, daha sonra fiziksel mağazanın yapısına göre iş kurallarına göre daha doğru bir tasarımdır ve kuralı uygulamak için kod yazma ihtiyacını ortadan kaldırır. Mülk, alt türler için ayrımcı olarak kullanılabilen bir mağaza konumu türü olarak açıkça dahil edildiğinde, çalışanlar ve fiziksel mağazalar arasında doğrudan ilişki kurulabilir ve böylece kural sadece yabancı anahtar kısıtlamasıyla tam olarak uygulanabilir. ere, Barker-Ellis kullanarak süper ve alt yazmayı gösteren Oracle SQL Developer Data Modeler ile oluşturulan bir veri modelidirzarif sunumu için tercih ettiğim süper ve alt tipler için kutu gösteriminde kutu. Diyagram artık kuralı da açıkça gösterebilir.