关系数据设计

概念

世界上充斥着【一对一】、【一对多】、【多对多】的关系，实际上所谓【多对多】关系是不存在的。

关系，总是有两个对象，一为【主体】，一为【客体】，其间就是他们的关系的具体内容。

比如“我是你的同学”，“我”是主体，“你”是客体，“同学”是关系的具体内容。

在关系型数据库中，关系的内容就简单得多，都可表达为【拥有】。

而【拥有】这种关系，只有两种表现形式：

• 主体拥有【一】个客体
• 主体拥有【多】个客体

本质上【一】是【多】的形式中的一种情况，只不过在关系表的设计中有差异，才区分出来。

关系型数据库的实体关系的设计，本质上就是主实体拥有【一】或【多】个客实体的设计。不存在多主体拥有多客体的关系，认同多对多关系的观点，实质是主次不分、概念混乱。

关系型数据库的表设计

在做表设计时，我们只需要设计两种表：

• 实体表：只存储实体信息
• 关系表：只存储关系

注：主体与客体都是实体。谁是主体谁是客体，取决于观察者的立场。

主体拥有【一】个客体的表设计

这种关系有两种设计方法：

• 不用关系表：将客体的主键作为主体的一个字段，表示客体天然地从属于主体，存在必然的强烈的从属关系。
• 使用关系表：将主体与客体的关系存储在关系列，作为主体有多客体的一种情况，表示可选的、组合的、无从属关系或者概念弱相关的关系。

例如，司机、驾驶证与身份证的关系。

• 司机必然拥有一个驾驶证，表设计就是：一张司机实体表，一张驾驶证实体表，驾驶证实体表的主键作为司机实体表的一个字段。
• 司机拥有一个身份证，身份主与司机在概念上无必然联系，它们的关系是由更加抽象的层次产生的（公民与身份证），所以身份证不应该作为司机的字段，而应当使用一个关系表来存储。

注：使用关系表的情况，应当作为主体拥有【多】个客体的一种特殊情况来对待。

主体拥有【多】个客体的表设计

这种关系可以表述为主体与客体是可选的、组合的、无从属关系或者概念弱相关的关系。

这种关系只有一种设计方法：一张主体实体表、一张客体实体表、一张关系表。

当主体与客体的关系可以由另一个主体实体来体现时，关系表可以省去。

比如 学生、课程、成绩的关系。学生作为主体时，叙述是学生有多门课程、每门课程有一个成绩。按这个视角，会存在多个关系表。当把成绩作为主体时，学生与课程就成了成绩的必然的客体属性，同时学生成课程的关系也完美地体现在成绩实体表内。

错误的设计：

为了省去关系表，而将主体的主键作为客体的字段，来存储主体拥有多个客体的关系，是一种错误的设计。

表关系设计规范

• 实体表：
  • 以合适的主体/客体的名称命名
  • 只存储实体字段、下属体主键字段、必要的元数据字段
• 关系表：
  • 按【主体表名_客体表名_rel】的格式命名，【_rel】后缀表示关系表这种表类型；当客体表名有前缀时应当省略前缀，其省去的前缀的层级长短由具体概念确定
  • 只存储主体表主键、客体表主键、必要的元数据字段
  • 如果是主体拥有【一】个客体的关系，则为关系表中的主体表主键字段添加唯一性约束

 可以将所有关系都存储在一张表中，统一存储与管理，避免产生众多的关系表。比如 subject_object_rel，其字段为：

关系表主键（id）、主体表名称（subject_name）、主体表主键（subject_id）、客体表名称（object_name）、客体表主键（object_id）