조건부 외래 키 관계

현재 두 엔티티 사이에 외래 키가 있으며 해당 관계를 테이블 중 하나의 entityType에 조건부로 만들고 싶습니다. 여기에 테이블의 계층 구조가 있습니다. 이것은 자식에서 부모로의 FK 굴절을 통해 이루어집니다

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

저는 현재 Employee에서 store까지 FK 관계가 있습니다.

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'로만 제한합니다.

예를 들어, CheckStore 제약 조건을 사용하여 TransactionStores 테이블의 상점 유형을 제한했습니다. 실제로는 StoreType이 해당 테이블에 대한 FK 인 StoreTypes 룩업 테이블이 더 나은 디자인 선택입니다.

외래 키는 조건부로 만들 수 없으므로 문제가 아닙니다. 비즈니스 규칙은 직원이 하나의 물리적 상점 에서만 작업 할 수있는 것으로 보입니다 . 이를 감안할 때, 수퍼 유형의 상점에는 제안한대로 Physical 및 Online의 두 가지 하위 유형이 있습니다 . 각 실제 상점에는 한 명 이상의 직원이 근무할 수 있으며 각 직원은 하나의 실제 상점에만 지정되어야합니다. 그런 다음 실제 상점에는 두 가지 하위 유형 ( Brick과 Mortar 및 Kiosk)이 있습니다. 키오스크 , 온라인 및 벽돌 및 박격포의 세 가지 직접 하위 유형이 있습니다.-물리적 위치에서 찾을 수 있는지 여부에 관계없이 모든 상점에서 소유 한 자산을 숨 깁니다. 이제 디자인은 사람에 의존 하여 하위 유형 이름에 내재 된 의미 를 이해하여 온라인 상점에 직원이 없음을 이해합니다. 선언 된 스키마에서는 쉽게 알 수 없으며 트리거 형식의 코드 를 작성하여 DBMS가 적용 할 수있는 방식으로 이해를 표현해야합니다. 성능에 영향을 미치지 않는 트리거를 개발, 테스트 및 유지 관리하는 것은 데이터베이스 전문가를위한 응용 수학 책에 나와있는 것처럼 구현하기가 훨씬 더 어려운 솔루션 입니다.

서브 타이핑 스토어 첫번째 위치의 종류에와 다음 구조의 물리적 상점의 종류에는 비즈니스 규칙에 대한보다 정확한 디자인하고 규칙을 시행하는 코드를 작성 할 필요가 없습니다. 하위 유형의 판별 자로 사용할 수있는 상점 위치 유형으로 특성이 명확하게 포함되면 직원과 실제 상점 사이의 관계를 직접 작성할 수 있으므로 외래 키 제약 조건으로 규칙을 완전히 구현할 수 있습니다. ere는 Oracle SQL Developer Data Modeler로 작성된 데이터 모델로 Barker-Ellis를 사용하여 수퍼 및 서브 타이핑을 보여줍니다.슈퍼 및 하위 유형에 대한 상자 표기법을 사용하여 우아한 프레젠테이션을 선호합니다. 다이어그램은 이제 규칙을 명확하게 보여줄 수 있습니다.