ความสัมพันธ์กับคีย์ต่างประเทศแบบมีเงื่อนไข

ขณะนี้ฉันมีรหัสต่างประเทศระหว่างสองหน่วยงานและฉันต้องการสร้างความสัมพันธ์แบบมีเงื่อนไขให้กับประเภทรายการของตารางใดตารางหนึ่ง นี่คือลำดับชั้นของตารางซึ่งทำได้ผ่านการอ้างอิง FK ตั้งแต่เด็กจนถึงผู้ปกครอง

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

ขณะนี้ฉันมีความสัมพันธ์ FK จากพนักงานเพื่อจัดเก็บ

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

ฉันต้องการเพิ่มเงื่อนไข:

WHERE TransactionalStores.storeType != 'ONLINE_TYPE'

เป็นไปได้หรือไม่ฉันต้อง subclass 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 และ BrickMakers จะมีโครงสร้างพื้นฐานเหมือนกัน แต่ด้วย StoreType ที่ จำกัด เฉพาะ 'O' หรือ 'B' ตามความเหมาะสม

ตอนนี้คุณต้องการการอ้างอิงจากตารางอื่นไปยัง TransactionalStores (และผ่านไปยังตารางร้านค้าต่างๆ) แต่ จำกัด ไว้ที่ Kiosks และ 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 ในตารางนั้นอาจเป็นตัวเลือกการออกแบบที่ดีกว่า

คีย์ต่างประเทศไม่สามารถทำตามเงื่อนไขเพื่อให้เป็นไปตามคำถาม กฎทางธุรกิจที่จะปรากฏขึ้นที่พนักงานสามารถทำงานได้เพียงหนึ่งเดียวและทางกายภาพของร้านค้า ระบุว่าชนิดสุดของร้านมีสองประเภทย่อยตามที่คุณแนะนำ: ทางกายภาพและออนไลน์ แต่ละร้านค้าทางกายภาพอาจมีพนักงานหนึ่งคนขึ้นไปและพนักงานแต่ละคนต้องได้รับมอบหมายให้กับร้านค้าทางกายภาพหนึ่งแห่งเท่านั้น ร้านค้าทางกายภาพแล้วมีสองชนิดย่อยอิฐและปูนและคีออสก์ มีสามประเภทย่อยโดยตรง - Kiosk , OnlineและBrick and Mortar- ซ่อนคุณสมบัติที่ถูกครอบครองโดยทุกร้านค้าไม่ว่าจะพบได้ในที่ตั้งจริงหรือไม่ ตอนนี้การออกแบบอาศัยมนุษย์ที่จะเข้าใจความหมายที่แฝงอยู่ในชื่อประเภทย่อยเพื่อทำความเข้าใจว่าร้านค้าออนไลน์ไม่มีพนักงาน สิ่งนี้ไม่ปรากฏชัดเจนในสคีมาที่ประกาศไว้และโค้ดในรูปแบบของทริกเกอร์จะต้องเขียนเพื่อแสดงความเข้าใจในวิธีที่ DBMS สามารถบังคับใช้ การพัฒนา, การทดสอบและการบำรุงรักษาทริกเกอร์ที่ไม่ได้ส่งผลกระทบต่อประสิทธิภาพการทำงานเป็นโซลูชั่นที่ยากมากที่จะใช้เป็นที่ปรากฏอยู่ในหนังสือคณิตศาสตร์ประยุกต์สำหรับผู้เชี่ยวชาญด้านฐานข้อมูล

Sub-typ Storeเป็นอันดับแรกในประเภทของสถานที่และจากนั้นในประเภทของร้านค้าทางกายภาพคือการออกแบบที่ถูกต้องมากขึ้นเกี่ยวกับกฎเกณฑ์ทางธุรกิจและไม่จำเป็นต้องเขียนรหัสเพื่อบังคับใช้กฎ เมื่อคุณสมบัติถูกรวมไว้อย่างชัดเจนเป็นประเภทที่ตั้งร้านค้าซึ่งสามารถใช้เป็นตัวเลือกสำหรับประเภทย่อยความสัมพันธ์สามารถทำระหว่างพนักงานและร้านค้าทางกายภาพโดยตรงและทำให้การใช้กฎอย่างเต็มที่เพียงแค่มีข้อ จำกัด ที่สำคัญต่างประเทศ ere เป็นตัวแบบข้อมูลที่สร้างขึ้นด้วยOracle SQL Developer Data Modelerที่แสดงขั้นสูงและการพิมพ์ย่อยโดยใช้Barker-Ellisกล่องในสัญกรณ์กล่องสำหรับ super และ sub-types ซึ่งฉันชอบสำหรับการนำเสนอที่หรูหรา ไดอะแกรมสามารถแสดงกฎได้อย่างชัดเจนเช่นกัน