子类型数据库表

一个简单的例子是有一个带有主键的Person表和该表中的一些列。现在,您可以创建另一个名为student的表,该表具有人员表(其父类型)的外键。现在student表有一些列,而supertype没有这些列,如gpa、major等,但是name、last name等将在父表中。您始终可以通过学生表中的外键访问个人表中的学生姓名。

总之,记住以下几点:

• 层次结构描述了超类型和子类型之间的关系。
• 父类型具有公共属性
• 子类型具有唯一属性

表的子类型是EER图中的概念性内容。我没有看到直接支持它的RDBMS(不包括对象关系DBMS)。它们通常在

1. 单个表中子类型的每个属性的一组可为空的列
2. 具有用于基类型属性的表和一些其他表,每个基表最多有一行将包含子类型属性

当使用ORM映射器生成类子类型的继承关系并对域进行精确建模时,表子类型的概念非常有用。

子类型表将具有返回其父级的外键,该父级也是子类型表的主键。

请记住,在设计绑定应用程序时,与访问应用程序一样,子类型在连接方面会带来很高的成本。

例如,如果您有一个具有三个子类型表的父类型表,并且需要一次以一个表单显示全部三个子类型表(并且您不仅需要显示父类型日期),那么您最终可以选择使用三个外部联接和nz(),或者需要三个相互排斥的select语句(每个子类型一个)的union all。这两者都不可编辑。

我本来打算从第一个主要应用程序粘贴一些SQL,我在那里处理super/subtype表,但是看一看,SQL太复杂了,会让人困惑。这并不是因为我的应用程序很复杂,而是因为问题的本质是复杂的——向用户呈现完整的数据集,包括超级数据集和子类型数据集,本质上是复杂的。我的结论是,如果只使用一个子类型表,我会过得更好。

这并不是说在某些情况下它是不有用的,只是访问绑定的表单不一定能使向用户呈现这些数据变得容易。

我有一个我一直在研究的类似问题。

在寻找可重复的模式时,我希望确保不会放弃引用完整性,这意味着我不会使用(table_name,pk_id)解决方案。

我最终决定:

基类型表:客户

子类型表:个人、企业、政府实体

我将可以为空的prerson_id、business_id和govt_entity_id字段放在customer中,每个字段上都有外键,并且检查约束只有一个不为空。添加新的子类型很容易,只需要添加可为空的外键并修改check约束。