概览作者：邓欢
良好的数据库设计不仅仅能够满足数据库用户的需求，而且对应用程序有着非常重大的影响。然而数据库设计是一个复杂的过程，良好的数据库设计并不是一件简单的事。对于小型的应用，理解需求的数据库设计者可能直接就能给出要构建的关系、关系的属性以及其上的约束。但是现实的应用往往是复杂的，通常没有一个人能够理解应用所有的数据需求并直接给出最终的数据库设计。因此遵循一个数据库设计的方法是很有必要的。数据库设计通常包括以下阶段：
1. 完整的刻画未来数据库用户的数据需求
2. 选择数据模型，并采用所选数据模型的概念将需求转化为数据库的概念模式
3. 将抽象数据模型转化为数据库实现：
- 逻辑设计：将高层概念模式映射到将使用的数据库系统的实现数据库模型
- 物理设计：指明数据库的物理特征，包括文件组织格式和索引结构的选择
本文将主要介绍如何构建一个数据模型，并将数据模型转化为关系模式，以及如何评价关系模式的合理性。对于刻画用户的数据需求和物理设计并不会过多的介绍。因为数据需求来自于需求分析，这在软件工程中是一个很大的过程；而物理设计和所选择的 DBMS 有着很大的关系。
实体-关系(E-R)数据模型是在数据库最经常使用的概念模型。因为它能够将现实世界的含义和交互映射到概念模式上，使得技术人员和非技术人员都能够用统一的语言去描述用户的数据需求。这一节首先将会介绍 E-R 模型，然后将说明如何将 E-R 模型转化为关系模式。
E-R 模型介绍
E-R模型有三个基本概念：实体集、联系集和属性。这一小节首先会介绍这三个基本概念，然后将说明 E-R 模型上定义的一些约束。
实体集
实体是现实世界中可区别于所有其他对象的一个“事物”或者“对象”。比如公司里每个人都是一个实体。每个实体都有一些描述性性质（被称为属性），其中一些性质的可以唯一标识一个实体（被称为码）。比如工号将唯一标识一位员工。除了现实世界中实实在在的事物可以看作实体，一些抽象的事物也可以作为实体。比如购物订单。实体集在 E-R 图中使用分为两部分的矩形表示，第一部分包含实体集的名字，第二部分包含实体集中的所有属性，并且可以在唯一标识实体的属性下面加上下划线。
实体集是相同性质的实体的集合。比如一个公司的所有员工的集合可以定义为实体集 employee。
有一些实体集本身找不出唯一标识实体集中单个实体的属性，它必须依附于另一个实体才能存在，这种实体集叫做弱实体集。比如将 stackoverflow 上的答案作为一个实体，那么所有的答案就是一个弱实体集，因为每个答案都必须依附问题这个实体才能存在，它的唯一标识属性是问题 ID 和答案 ID。与弱实体集相对应的就是那些本身的属性就能唯一标识单个实体的强实体集。弱实体集在 E-R 图中与强实体的表示类似，不同的是它的唯一标识属性下面是虚下划线。
联系集
联系是指多个实体间的相互关联。比如一个项目和开发人员的联系 develop，这一联系指明这个项目是由哪些开发人员开发的。联系也可以有描述性属性。比如 develop 联系可以增加 startsAt 属性表明开发人员是哪天开始加入到这个项目的。
联系集是相同类型联系的集合。联系集在 E-R 图中使用菱形表示，而与弱实体集关联的联系集则使用双菱形表示。联系集的每个属性都放在一个矩形中，通过虚线与联系集相连接。
属性
前面介绍实体集的时候介绍过属性，这里将介绍属性的分类：
- 简单和复合属性：不能划分为更小的部分的属性称为简单属性，可以再分为更小的部分称为复合属性。比如一个 DBMS 的类型就是简单属性，而地址是一个复合属性，它可以分为街道名、门牌号等。
- 单值和多值属性：对于一个特定的实体，如果一个属性只有一个值，就称为单值属性，否则为多值属性。比如一个人的身份证号是单值的，但是他的手机号是多值的。
- 派生属性：这类属性的值可以从别的相关的属性或者实体派生出来。比如一个人的信息有出生日期和年龄，那么年龄就是一个派生属性。
约束
仅仅有实体和联系并不能完全刻画现实事物之间的关系，比如一个实体通过联系集关联到另一实体的个数、一个实体参与到联系的个数。映射基数用来表示一个实体通过联系集关联到另一个实体的个数，它必然是以下四种情况之一：
- 一对一：实体集 A 中的一个实体至多和实体集 B 中的一个实体相关联，反之亦然。
- 一对多：实体集 A 中的一个实体可以与实体集 B 中的任意数目相关联，而 B 中的一个实体至多与 A 中的一个实体相关联。
- 多对一：实体集 A 中的一个实体至多和实体集 B 中的一个实体相关联，而 B 中的一个实体可以与 A 中的任意数目相关联。
- 多对多：实体集 A 中的一个实体可以与实体集 B 中的任意数目相关联，B 中的一个实体也可以与 A 中的任意数目相关联。
一个实体集参与到联系的个数通过参与约束来描述。如果一个实体集 E 中的每个实体都参与到一个联系集 R 的至少一个联系中，则称实体集 E 在联系集 R 中是全部参与；如果 E 中只有部分实体参与到 R 的联系中，则称实体集 E 在联系集 R 中是部分参与。
转化为关系模式
E-R 模型是现实世界的含义和交互在概念模型上的体现，而关系模式是数据库中全体数据的逻辑结构和特征的描述。因此将 E-R 模型转化为关系模式是一个里程碑式的阶段，在这之后到最后的库表结构就非常接近了。下面将介绍具体的转化方式。
具有简单属性的强实体集的表示
具有简单属性的强实体集与其对应的关系模式的属性是一一对应的，并且强实体集的主码就是关系模式的主码。比如一个公民的实体集有两个属性：身份证 ID、名字，那么对应的模式为：
chinese_public(ID, name)
具有复杂属性的强实体集的表示
对于具有复杂属性的强实体集的转化稍微复杂一点：
- 对于复合属性自身并不直接创建一个属性，而是将它所有的简单属性添加到关系模式中。
- 对于多值属性，我们将创建一个新的关系模式。新的关系模式中的一个元组对应一个值，并且使用多值属性所在的实体集的主码进行关联。
- 对应派生属性，我们并不在关系模式中显示的表达出来。
弱实体集的表示
弱实体集转化为关系模式和强实体集类似，不同的是它的主码包括它依赖的实体集的主码和它自身的分辨符。
联系集的表示
联系集转化而来的关系模式的属性是它自身的属性和参与到联系的所有实体集的主码的并集。关系模式的主码选择可以分为以下情况：
- 对于多对多的二元联系，参与的实体集的主码的并集成为主码。
- 对于一对一的二元联系集，任何一个实体集的主码都可以选为主码。
- 对于一对多或者多对多的二元联系集，联系集中“多”的那方实体集的主码成为主码。
- 对于 n 元联系集，联系集中非“一”的所有实体集的主码的并集成为主码。
在将联系集转化为关系模式时会出现关系模式的数量少于联系集的数量的情况。这是因为模式的冗余和模式的合并的存在。
模式的冗余
考虑一个弱实体集，它本身就包括它所依赖的强实体集的主码。如果这个弱实体集和它所依赖的强实体集的联系集没有其他属性，那么所有出现在联系集中属性都将出现在弱实体集中。因此弱实体集转化而来的关系模式是包括了联系集转化而来的关系模式的所有属性。这种情况下，不需要为联系集给出对应的关系模式。
模式的合并
考虑实体集 A 到实体集 B 的一个多对一的联系集 AB。按照前面的方法，我们将得到三个关系模式：A、B 和 AB。那么我们可以将 A 和 AB 模式合并成包含两个模式的所有属性的并集的模式，并且合并后模式的主码就是 A 的主码。如果 A 是全部参与的，那么合并后模式中来自 B 的属性都是有值的；否则 A 中未参与联系集的元组在合并后模式对应的元组中，来自 B 的属性是 NULL。对于一对一的联系集，它的关系模式可以合并到任意一个实体集中。
前面介绍了 E-R 模型以及如何将 E-R 模型转化为关系模式，但是得到的关系模式就是一个好的设计吗？答案显然是不一定的，如果 E-R 模型本身质量就不高，那么得到关系模式大概率质量也是不高的。要回答这个问题，首先需要明确什么样的设计是好的或者是不好的，然后才能做出评价。对于不好的设计，我们需要给出一种方法将它变成一个好的设计。
一个不好的设计
这是一个图书馆图书当前出借的表，所有的信息都保存在这张表中。
这张表存在什么样的问题呢？首先是数据冗余的问题。如果一个人多次借了多本书，那么这个人的信息会多次重复；如果一本书被多个人借过，那么这本书的信息也会多次重复。而数据冗余会带来数据一致性的问题。修改一个人的信息需要更新他的所有借*录；修改一本书的信息同样需要更新所有包括这本书的记录。其次是数据完整性的问题。一个图书馆的会员如果没有借过书，那么将无法保存他的信息；一本新书如果没有被借过，那么这本书的信息也将无法保存；如果一个人注销自己的账号，而有一本书只有他借过，那么这本书的信息也将随之消失。
应用范式进行规范化
前面通过一个例子说明了不好的设计会有数据冗余和完整性的问题。下面将通过范式将其规范化，以消除这些问题。
第一范式
第一范式要求每个列的值域都是由原子值组成，每个字段的值都只能是单一值，并且每一行需要有主键。
以前面的例子为例，为了满足第一范式，我们需要将出借的图书和图书类别的多个值放到不同的行中，并且将 ID 和出借的图书作为主键（假设图书名不会重复）。下面是修改后的结果：
显然，第一范式只能让表看起来更好看一些，对于前面的问题并没有实质性的解决。所以，接下来需要增加约束。
第二范式
第二范式的要求有两点：
- 满足第一范式
- 非主属性对于所有主属性完全函数依赖
这里需要解释几个名词：
- 非主属性：不包含在主键中的属性。
- 主属性：包含在主键中的属性。
- 完全函数依赖：若属性集 X 和属性集 Y 之间存在函数关系 X -> Y，且对于X的任何一个真子集 X‘，X‘ -> Y 不成立，那么我们称 Y 对于 X 完全函数依赖。
也许有人会觉得完全函数依赖的解释看起来和没解释是一样的，所以这里使用上面的例子进行说明。上面提到过，我们使用 ID 和出借的图书作为主键，那么 ID 和出借的图书一旦确定，名字、居住地也随之确定，即函数(ID, 出借的图书) -> (名字, 居住地)成立。但是，如果 ID 确定了，名字、居住地也能被确定下来，所以对于(ID, 出借的图书)的真子集(ID)，函数(ID) -> (名字, 居住地)依然成立。所以上面的表不满足第二范式。
我们需要对这张表进行拆分为会员表和图书表以及图书当前出借表：
