第2篇：数据库关系建模
第二篇：数据库关系建模
前言
ER建模环节完成后，需求就被描述成了ER图。之后，便可根据这个ER图设计相应的关系表了。
但从ER图到具体关系表的建立还需要经过两个步骤：1. 逻辑模型设计 2. 物理模型设计。其中前者将ER图映射为逻辑意义上的关系表，后者则映射为物理意义上的关系表。逻辑意义上的关系表可以理解为单纯意义上的关系表，它不涉及到表中字段数据类型，索引信息，触发器等等细节信息。
本文将详细介绍前者。确切来说，也就是ER模型到逻辑关系表的映射是如何完成的。
基本概念
在开始进行ER模型到逻辑关系表的具体映射之前，首先来学习一下逻辑模型中所涉及到的一些概念。
1. 关系(relation)
关系就是在数据库中存在的，包含行和列的一张表。也常被称为关系表，或者表。注意只有在确保不会引起混乱的时候使用最后一种称呼，因为关系表和一般意义上的表有很大区别(下文会分析)。
2. 列(column)
列就是字面意义上表的列。但是它也有时被称作属性，或者域。
3. 行(row)
行就是字面意义上表的行。但是它也有时被称作元祖，或者记录。
4. 关系表 VS 一般的表
关系表有以下几个基本约束：
a. 一个列只能有一个名称；
b. 不能出现完全一样的行；
c. 表中每个值都必须为单值；
d. 同一列中的所有值都必须属于同一个域；
e. 行/列顺序无关
5. 主码(primary key)
每个关系必须要有一个主码(可含多列)，用来唯一标识表中各行记录。
6. 实体完整性约束(entity integrity constraint)
指所有主码必须非空。
6. 外码(foreign key)
外码是某关系中的一列，而这一列恰恰又是另一个关系的主码。
7. 参照完整性约束(reference integrity constraints)
外码取值要么为空，要么为其参照关系中的主码取值。
ER模型到关系表的映射
1. 将常规实体映射为关系
对常规实体来说，每个常规属性对应到关系表中的一列，而某单值且唯一的列则映射为主码，标记下划线。
如下实体：
将映射为关系：
2. 将具有复合属性的实体映射为关系
这类映射中，复合属性的各子属性会映射到的新的关系中，但是复合属性名本身不会。
如下实体：
将映射为关系：
虽然关系中没有出现符合属性名了，但数据库上层的前端应用可能会利用到复合属性名。也就是ER图在各个阶段都有可能用到，不是说映射为关系后就没啥事了。
3. 将具有唯一复合属性的实体映射为关系
这类映射中，将会形成一个复合主码，其成员为复合属性的各子属性。
如下实体：
将映射为关系：
4. 将具有可选属性的实体映射为关系
这类映射中，需要将可选属性对应的列标记一个(O)。
如下实体：
将映射为关系：
5. 一对多(1：M)联系的映射
这类映射的规则为：在由1：M联系中属于M侧的实体所映射得到的关系中设置一个外码，这个外码对应于由1侧的实体映射得到的关系中的主码。
如下ER模型：
将映射为关系：
注意，外码命名不一定要和它对应的主码一致，应根据实际情况决定。
6. 多对多(M：N)联系映射
这类映射的规则为：除了具有多对多联系的两个实体之外，联系本身也需要映射为关系。联系对应的关系中将有两个外码，分别对应两个实体的主码，同时这两个外码构成新关系的主码。
比如下面这个ER模型：
将映射为关系：
7. 一对一(1：1)联系的映射
这类映射和1：M的很相似。原则上外键设在任何一个实体的关系中都OK，但如果一对一联系中的基数约束是强制单个和可选单个这种类型，则最好将外键设置在可选多的一侧。因为这样可以保证关系中不会出现太多空值。
比如下面这个ER模型：
将映射为关系：
8. 将具有若干候选码的实体映射为关系
这类映射中，主码依然标记划线，而非主码唯一属性则标记(U)。
如下实体：
将映射为关系：
9. 将具有多值属性的实体映射为关系
这类映射中，需要为多值属性创建一个新的关系。新的关系中包含一个外码，对应到主实体的主码。同时属性值和外码构成新的关系的复合主码。
如下实体：
将映射为关系：
10. 将具有派生属性的实体映射为关系
派生属性不需要做什么特别处理，那是前端的事情，哈哈。
11. 一对多(1：M)一元联系的映射
这类映射的规则为：实体映射得到的关系中包含一个外码，对应到关系自身的主码。
如下ER模型：
将映射为关系：
需要注意的是，该映射中外键名和主键名是不同的，以区分它和主码。事实上关系中也不允许出现名称相同的两列。
12. 多对多(M：N)一元联系的映射
这类映射的规则为：除了实体本身需要映射为关系之外，多对多联系需要映射为另一个关系。新的关系中将有两个外码，它们均对应到实体主码。且这两个外码又组合为新关系的复合主码。
如下ER模型：
将映射为关系：
这里同样要注意外键名要避免和主键名重复。
13. 一对一(1：1)一元联系的映射
和上面第11条讲的一对多的一元联系映射规则完全相同，此处不再举例说明。
14. 将弱实体映射为关系
弱实体映射和常规一对多联系映射一样需要在弱实体(M侧实体)中建立一个对应到属主实体(1侧实体)的外码。然而区别是弱实体中的主码是弱实体自身的部分码+外码构成的复合主码，而后者的主码仅是M侧实体自己的主码。
如下ER模型：
将映射为关系：
当然，如果联系是一对一，则弱实体的主码就是那个对应到其属主实体的外码而没有部分码了。
如下ER模型：
将映射为关系：
15. 将关联实体映射为关系
关联实体本身就是联系，因此它的映射规则和联系是一样的。联系的映射在前文已经完成讲解，此处不再累述了。
16. 三元联系的映射
这类映射和多对多联系的映射比较相似。如下ER模型：
可映射为：
这里提示下，三元联系的情况，联系肯定是多对多对多的。因为如果这三元中有一个为一，那么三元联系就应转成两个二元的一对多联系。
概念模型 VS 逻辑模型
想必有不少人还不大清楚概念模型，逻辑模型，物理模型的区别。这里先来探讨下概念模型和逻辑模型，有关物理模型的讨论则将放到第四篇。
我们首先可以认为概念模型建模和ER建模，需求可视化表达的是一个意思。在这个环节中，数据开发人员绘制ER图，并和项目各方人员协同需求，达成一致。由于这部分的工作涉及到的人员开发能力比较薄弱，甚至不懂开发，因此ER图必须清晰明了，不能涉及到过多的技术细节。在ER图绘制完毕之后，才开始将它映射为关系表。这个映射的过程，就叫做逻辑模型建模或者关系建模。
有人会说，ER图不是可以直接映射到关系吗，而且已经有了相应的映射工具了，为什么还要绘制ER图多此一举呢？针对这个问题前文已经回答了。ER图是拿出去和别人谈需求的，要求各方人员都能看得懂。而关系表涉及到了过多实现细节，比如：要给多对多联系/多值属性等多建一张表，要设置外码，各种复合主码等。这些东西不应该在谈需求的时候出现，它们应当对非开发人员透明。而且ER图中每个属性只会出现一次，减少了蕴含的信息量，是更好的交流和文档化工具。
还有，ER模型所蕴含的信息，也没有全部被逻辑模型包含。比如联系的自定义基数约束，比如实体的复合属性，派生属性，用户的自定义约束等等。因此ER模型在整个开发流程(如物理模型建模，甚至前端开发)中是都会用到的，不能认为ER模型转换到逻辑模型后就可以扔一边了。
小结
本文的逻辑关系表都是利用建模工具直接由ER图生成的。这确实很方便，但那些系统自动增加的字段和表的命名则需要根据实际情况进行调整。
逻辑模型设计好后，就可以开始着手数据库的物理实现了。数据库的物理实现也被称为物理模型建模，这个阶段不但需要参照逻辑模型，还应当参照ER图。