기본 테이블뿐만 아니라 뷰를 참조하는 외래 키를 허용하는 DBMS가 있습니까?

Django 모델링 질문에서 영감을 얻었습니다. Django의 여러 다 대다 관계를 가진 데이터베이스 모델링 . db-design은 다음과 같습니다.

CREATE TABLE Book
( BookID INT NOT NULL
, BookTitle VARCHAR(200) NOT NULL
, PRIMARY KEY (BookID)
) ;

CREATE TABLE Tag
( TagID INT NOT NULL
, TagName VARCHAR(50) NOT NULL
, PRIMARY KEY (TagID)
) ;

CREATE TABLE BookTag
( BookID INT NOT NULL
, TagID INT NOT NULL
, PRIMARY KEY (BookID, TagID)
, FOREIGN KEY (BookID)  REFERENCES Book (BookID)
, FOREIGN KEY (TagID)   REFERENCES Tag (TagID)
) ;

CREATE TABLE Aspect
( AspectID INT NOT NULL
, AspectName VARCHAR(50) NOT NULL
, PRIMARY KEY (AspectID)
) ;

CREATE TABLE TagAspect
( TagID INT NOT NULL
, AspectID INT NOT NULL
, PRIMARY KEY (TagID, AspectID) 
, FOREIGN KEY (TagID)   REFERENCES Tag (TagID)
, FOREIGN KEY (AspectID)  REFERENCES Aspect (AspectID)
) ;

문제는 BookAspectRating테이블 을 정의하고 참조 무결성을 강화 (Book, Aspect)하는 방법이므로 유효하지 않은 조합에 등급을 추가 할 수 없습니다 .

서브 쿼리와이를 해결할 수있는 둘 이상의 테이블을 포함하는 복잡한 CHECK제한 조건 (또는 ASSERTIONS) 인 AFAIK 는 DBMS에서 사용할 수 없습니다.

또 다른 아이디어는 뷰를 사용 (의사 코드)하는 것입니다.

CREATE VIEW BookAspect_view
  AS
SELECT DISTINCT
    bt.BookId
  , ta.AspectId
FROM 
    BookTag AS bt
  JOIN 
    Tag AS t  ON t.TagID = bt.TagID
  JOIN 
    TagAspect AS ta  ON ta.TagID = bt.TagID 
WITH PRIMARY KEY (BookId, AspectId) ;

위의보기에 대한 외래 키가있는 테이블 :

CREATE TABLE BookAspectRating
( BookID INT NOT NULL
, AspectID INT NOT NULL
, PersonID INT NOT NULL
, Rating INT NOT NULL
, PRIMARY KEY (BookID, AspectID, PersonID)
, FOREIGN KEY (PersonID)   REFERENCES Person (PersonID)
, FOREIGN KEY (BookID, AspectID) 
    REFERENCES BookAspect_view (BookID, AspectID)
) ;

세 가지 질문 :

• A는 (아마도 구체화) 할 수있다 DBMS 있습니까 VIEWA의는 PRIMARY KEY?

• 을 할 수있다 DBMS 있습니까 FOREIGN KEY그 (및뿐만 아니라 기본 )은?REFERENCESVIEWTABLE

• 사용 가능한 DBMS 기능으로이 무결성 문제를 다른 방식으로 해결할 수 있습니까?

설명:

아마도 100 % 만족스러운 해결책이 없기 때문에 장고 질문은 내 것이 아닙니다! -자세한 해결책이 아니라 문제에 대한 일반적인 공격 전략에 더 관심이 있습니다. 따라서 "DBMS-X에서이 작업은 테이블 A의 트리거로 수행 할 수 있습니다" 와 같은 대답 은 완벽하게 허용됩니다.

이 비즈니스 규칙은 구속 조건 만 사용하여 모델에서 시행 할 수 있습니다. 다음 표는 문제를 해결해야합니다. 보기 대신 사용하십시오.

    CREATE TABLE BookAspectCommonTagLink
    (  BookID INT NOT NULL
    , AspectID INT NOT NULL
    , TagID INT NOT NULL
--TagID is deliberately left out of PK
    , PRIMARY KEY (BookID, AspectID)
    , FOREIGN KEY (BookID, TagID) 
        REFERENCES BookTag (BookID, TagID)
    , FOREIGN KEY (AspectID, TagID) 
        REFERENCES AspectTag (AspectID, TagID)
    ) ;

많은 경우에 모델만으로는 복잡한 비즈니스 규칙을 시행 할 수 없다는 것을 알게 될 것입니다. 이것은 적어도 SQL Server에서 트리거 (바람직하게는 트리거 대신)가 귀하의 목적에 더 잘 부합한다고 생각하는 경우 중 하나입니다.

Oracle에서 이러한 종류의 제약 조건을 선언적인 방식으로 적용하는 한 가지 방법은 쿼리에서 모든 유효하지 않은 행 (예 :에 BookAspectRating일치하지 않는 행)을 식별하는 커밋시 빠르게 새로 고쳐 지도록 구체화 된 뷰를 만드는 것 BookAspect_view입니다. 그런 다음 구체화 된 뷰에 행이있는 경우 위반 될 구체화 된 뷰에 대한 간단한 구속 조건을 작성할 수 있습니다. 이는 구체화 된보기에서 복제해야하는 데이터의 양을 최소화하는 이점이 있습니다. 그러나 트랜잭션을 커밋하는 시점에만 제약 조건이 적용되므로 커밋 작업이 실패 할 것으로 예상되는 많은 응용 프로그램이 작성되지 않고 제약 조건 위반이 다소 어려울 수 있기 때문에 문제가 발생할 수 있습니다. 특정 행 또는 특정 테이블과 연결합니다.

SIRA_PRISE가 허용합니다.

FK를 더 이상 "FK"라고 부르지 않고 "데이터베이스 제약 조건"만하고 "뷰"를 실제로 뷰로 정의 할 필요는 없지만 식을 정의하는 뷰를 데이터베이스 제약.

당신의 제약은 다음과 같습니다

SEMIMINUS(BOOKASPECT , JOIN(BOOKTAG , TAGASPECT))

그리고 당신은 끝났습니다.

그러나 대부분의 SQL DBMS에서는 제약 조건에 대한 분석 작업을 수행하고 위반 방법을 결정하고 필요한 모든 트리거를 구현해야합니다.

PostgreSQL에서 트리거를 사용하지 않고 솔루션을 상상할 수는 없지만 확실하게 해결 할 수 있습니다 (어떤 종류의 구체화 된 뷰를 유지하거나 이전 트리거를 켜기 BookAspectRating). ERROR: referenced relation "v_munkalap" is not a table기본 키는 물론 보기 ( )를 참조하는 외래 키가 없습니다 .