是否有DBMS允许外键引用视图（而不仅仅是基表）？

受到Django建模问题的启发：Django中具有多个多对多关系的数据库建模。数据库设计类似于：

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)为无效的组合添加评分。

AFAIK，复杂的CHECK约束（或ASSERTIONS）涉及子查询和一个以上的表（可能解决此问题），在任何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)
) ;

三个问题：

• 是否有DBMS允许（可能实现）VIEW带有PRIMARY KEY？

• 是否有DBMS允许一个FOREIGN KEY是REFERENCES一个VIEW（而不仅仅是基础TABLE）？

• 是否可以使用可用的DBMS功能来解决此完整性问题？

澄清：

由于可能没有100％令人满意的解决方案-Django问题甚至不是我的！-我对可能对问题进行攻击的一般策略而不是详细的解决方案更感兴趣。因此，完全可以接受诸如“在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）的外键，更不用说主键了。