考虑上面的问题,“CommonChild”实体可以是子类型 A 或 B,但不是 C。我将如何在关系 [SQL] 数据库中设计物理模型?
理想情况下,该解决方案将允许...
- 用于识别 CommonChild 与其相关子类型之间的关系。
- 1:N 的关系。
可能的解决方案
向超类型添加额外的子类型,并将子类型 A 和 B 移动到新的子类型下。然后,CommonChild 可以对新创建的子类型进行 FK 约束。适用于上述情况,但如果添加了一个可以与子类型 A 和 C 有关系但不与 B 有关系的附加实体,则不能。
在 CommonChild 和 SuperType 之间添加 FK 约束。在允许新元组进入 CommonChild 之前,对超类型的鉴别器使用触发器或检查约束(w/UDF)。看起来很简单,但现在 CommonChild 几乎看起来像是新的子类型本身(它不是)。
我的模型存在根本缺陷。改造和问题应该消失。
我正在寻找其他可能的解决方案或确认我已经提出的上述解决方案之一。
谢谢!
编辑
我将实施 Branko Dimitrijevic 提供的专有外键解决方案(请参阅接受的答案)。
在这种情况下,我将稍作修改:
- 超类型、子类型和“CommonChild”都具有相同的 PK 并且;
- PK 是 3 列复合材料。
修改是创建一个中间表,其唯一作用是强制子类型和“CommonChild”之间的排他 FK 约束(Dimitrijevic 提供的精确模型减去“CommonChild”属性。)。CommonChild 的 PK 将对中间表具有正常的 FK 约束。
这将防止“CommonChild”拥有 2 组 3 列复合 FK。另外,由于标识关系是从超类型到“CommonChild”维护的,因此 [read] 查询可以有效地完全忽略中间表。