Oracle中的外键约束

Question

我有实体关系模型（ERD），其中实体IndividualCategory和TeamCategory与实体Category有关。现在我想在Oracle DB中创建表。我一开始是这样的：

CREATE TABLE Category(
    category_id INT PRIMARY KEY, 
    ... 
); 

CREATE TABLE Individual_category(
    category_id INT CONSTRAINT fk_cat_indivcat REFERENCES Category(category_id), 
    ..., 
    CONSTRAINT pk_indivgamecat PRIMARY KEY (category_id) 
); 

CREATE TABLE Team_category(
    category_id INT CONSTRAINT fk_cat_teamcat REFERENCES Category(category_id), 
    ..., 
    CONSTRAINT pk_teamcat PRIMARY KEY (category_id) 
); 

的外键和主键约束，该组合保证了每一个Individual_category会有Category“超级”表中的相应记录（或“父”表？）。并且将只有一个IndividualCategory记录为特定的Category记录。 Team_category也一样。

要强制继承我需要多一个约束：即确保在Category每个记录都会有IndividualCategory（X）无论是记录或在TeamCategory记录但不能同时约束。

如何创建这样的约束？

---

编辑：这就是我说的 '于E-R模型的继承'。这是我的数据库老师的幻灯片（他们称之为“实体分型”的存在，但他们有时称之为它只是继承）：

Answer 1

一个完全不同的方式来做到这一点使用延迟约束：

CREATE TABLE Category(
    category_id INT PRIMARY KEY, 
    team_category_id INT, 
    individual_category_id INT, 
    ... 
); 

CREATE TABLE Individual_category(
    individual_category_id INT PRIMARY KEY, 
    category_id INT NOT NULL, 
    ..., 
); 

CREATE TABLE Team_category(
    team_category_id INT PRIMARY KEY, 
    category_id INT NOT NULL, 
    ..., 
); 

确保一个Category是TeamCategory XOR的IndividualCategory：

alter table Category add constraint category_type_check check 
    ( (team_category_id is null and individual_category_id is not null) 
    or (team_category_id is not null and individual_category_id is null) 
); 

创建可延迟的完整性约束，使人们可以插入同一交易中的类别和团队/ Individual_Category;否则，您无法在TeamCategory/IndividualCategory之前插入类别，反之亦然。一个catch-22。

alter table category add constraint category_team_fk 
    foreign key (team_category_id) 
    references team_category (team_category_id) 
    deferrable initially deferred; 

alter table category add constraint category_individual_fk 
    foreign key (individual_category_id) 
    references individual_category (individual_category_id) 
    deferrable initially deferred; 

alter table individual_category add constraint individual_category_fk 
    foreign_key (category_id) 
    references category (category_id) 
    deferrable initially deferred; 

alter table team_category add constraint team_category_fk 
    foreign_key (category_id) 
    references category (category_id) 
    deferrable initially deferred; 

Answer 2

一个可以如何做到这一点，利用一个简单的例子：

CREATE TABLE Category(
    category_id INT PRIMARY KEY, 
    category_type varchar2(300) not null, 
    ... 
    [list of required attributes for only individual category, but nullable], 
    [list of required attributes for only team category, but nullable] 
); 

alter table category add constraint check_category_individual check 
    ( category_type <> 'INDIVIDUAL' 
    or ( category_type = 'INDIVIDUAL' 
     and [list of individual category attributes IS NOT NULL] 
    ) 
); 

alter table category add constraint check_category_team check 
    ( category_type <> 'TEAM' 
    or ( category_type = 'TEAM' 
     and [list of team category attributes IS NOT NULL] 
    ) 
); 

然后，您可以创建视图，如：

create view individual_category as 
select category_id, [base category attributes], [individual category attributes] 
    from category 
where category_type = 'INDIVIDUAL; 

你甚至可以把一个INSTEAD OF触发的视图，它会出现在应用程序能够像任何其他的表。

Answer 3

另一种在数据库中实现复杂约束的方法是使用物化视图（MV）。

在这个例子中的MV可以被定义如下：

create materialized view bad_category_mv 
refresh complete on commit 
as 
select c.category_id 
from category c 
left outer join individual_category i on i.category_id = c.category_id 
left outer join team_category i on t.category_id = c.category_id 
where ( (i.category_id is null and t.category_id is null) 
     or (i.category_id is not null and t.category_id is not null) 
    ); 

alter table bad_category_mv 
add constraint bad_category_mv_chk 
check (1=0) deferrable; 

所以MV是只为打破规则类别稀少，但随后的检查约束确保，结果在一个行中的任何交易MV将失败（因为1 = 0永远不会）。

我在过去的here上发表了关于这种方法的博客。

注意：尽管我对这种方法很感兴趣，但我从未在生产数据库中“愤怒”地使用它。需要进行仔细的基准测试，以确保每当数据发生变化时整个MV刷新的开销不会太高。

Answer 4

ERD继承是gen-spec设计模式的典型例子。关于如何在像Oracle这样的关系DBMS中设计gen-spec有很多文章。你可以通过谷歌搜索“泛化专业化关系建模”找到其中的一些。

您将在这些文章中看到的大部分内容已通过对此问题的其他回复概述。这个话题在SO中已经出现过很多次了。以前的讨论样本，click here。

传统解决方案的主要特点是专用表具有一个id列，该id列是引用广义表的id列的主键和外键。以这种方式，这些子实体不会获得他们自己的身份。您真正需要注意的功能是实现析取的约束。并非所有文章都在他们提出的解决方案中强制执行这一规则。