概览
良好的数据库设计不仅仅能够满足数据库用户的需求，而且对应用程序有着非常重大的影响。然而数据库设计是一个复杂的过程，良好的数据库设计并不是一件简单的事。对于小型的应用，理解需求的数据库设计者可能直接就能给出要构建的关系、关系的属性以及其上的约束。但是现实的应用往往是复杂的，通常没有一个人能够理解应用所有的数据需求并直接给出最终的数据库设计。因此遵循一个数据库设计的方法是很有必要的。数据库设计通常包括以下阶段：
逻辑设计：将高层概念模式映射到将使用的数据库系统的实现数据库模型 物理设计：指明数据库的物理特征，包括文件组织格式和索引结构的选择
本文将主要介绍如何构建一个数据模型，并将数据模型转化为关系模式，以及如何评价关系模式的合理性。对于刻画用户的数据需求和物理设计并不会过多的介绍。因为数据需求来自于需求分析，这在软件工程中是一个很大的过程；而物理设计和所选择的 DBMS 有着很大的关系。
概念模型
实体-关系(E-R)数据模型是在数据库最经常使用的概念模型。因为它能够将现实世界的含义和交互映射到概念模式上，使得技术人员和非技术人员都能够用统一的语言去描述用户的数据需求。这一节首先将会介绍 E-R 模型，然后将说明如何将 E-R 模型转化为关系模式。
实体集
联系集
属性
前面介绍实体集的时候介绍过属性，这里将介绍属性的分类：
简单和复合属性：不能划分为更小的部分的属性称为简单属性，可以再分为更小的部分称为复合属性。比如一个 DBMS 的类型就是简单属性，而地址是一个复合属性，它可以分为街道名、门牌号等。 单值和多值属性：对于一个特定的实体，如果一个属性只有一个值，就称为单值属性，否则为多值属性。比如一个人的身份证号是单值的，但是他的手机号是多值的。 派生属性：这类属性的值可以从别的相关的属性或者实体派生出来。比如一个人的信息有出生日期和年龄，那么年龄就是一个派生属性。
约束
仅仅有实体和联系并不能完全刻画现实事物之间的关系，比如一个实体通过联系集关联到另一实体的个数、一个实体参与到联系的个数。映射基数用来表示一个实体通过联系集关联到另一个实体的个数，它必然是以下四种情况之一：
一对一：实体集 A 中的一个实体至多和实体集 B 中的一个实体相关联，反之亦然。
一对多：实体集 A 中的一个实体可以与实体集 B 中的任意数目相关联，而 B 中的一个实体至多与 A 中的一个实体相关联。
多对一：实体集 A 中的一个实体至多和实体集 B 中的一个实体相关联，而 B 中的一个实体可以与 A 中的任意数目相关联。
多对多：实体集 A 中的一个实体可以与实体集 B 中的任意数目相关联，B 中的一个实体也可以与 A 中的任意数目相关联。
转化为关系模式
具有简单属性的强实体集的表示
具有简单属性的强实体集与其对应的关系模式的属性是一一对应的，并且强实体集的主码就是关系模式的主码。比如一个公民的实体集有两个属性：身份证 ID、名字，那么对应的模式为：
chinese_public(ID, name)
具有复杂属性的强实体集的表示
对于具有复杂属性的强实体集的转化稍微复杂一点：
对于复合属性自身并不直接创建一个属性，而是将它所有的简单属性添加到关系模式中。
对于多值属性，我们将创建一个新的关系模式。新的关系模式中的一个元组对应一个值，并且使用多值属性所在的实体集的主码进行关联。
对应派生属性，我们并不在关系模式中显示的表达出来。
弱实体集的表示
联系集的表示
联系集转化而来的关系模式的属性是它自身的属性和参与到联系的所有实体集的主码的并集。关系模式的主码选择可以分为以下情况：
对于多对多的二元联系，参与的实体集的主码的并集成为主码。
对于一对一的二元联系集，任何一个实体集的主码都可以选为主码。
对于一对多或者多对多的二元联系集，联系集中“多”的那方实体集的主码成为主码。
对于 n 元联系集，联系集中非“一”的所有实体集的主码的并集成为主码。
模式的冗余
规范化
前面介绍了 E-R 模型以及如何将 E-R 模型转化为关系模式，但是得到的关系模式就是一个好的设计吗？答案显然是不一定的，如果 E-R 模型本身质量就不高，那么得到关系模式大概率质量也是不高的。要回答这个问题，首先需要明确什么样的设计是好的或者是不好的，然后才能做出评价。对于不好的设计，我们需要给出一种方法将它变成一个好的设计。
一个不好的设计
这张表存在什么样的问题呢？首先是数据冗余的问题。如果一个人多次借了多本书，那么这个人的信息会多次重复；如果一本书被多个人借过，那么这本书的信息也会多次重复。而数据冗余会带来数据一致性的问题。修改一个人的信息需要更新他的所有借书记录；修改一本书的信息同样需要更新所有包括这本书的记录。其次是数据完整性的问题。一个图书馆的会员如果没有借过书，那么将无法保存他的信息；一本新书如果没有被借过，那么这本书的信息也将无法保存；如果一个人注销自己的账号，而有一本书只有他借过，那么这本书的信息也将随之消失。
应用范式进行规范化
第一范式
显然，第一范式只能让表看起来更好看一些，对于前面的问题并没有实质性的解决。所以，接下来需要增加约束。
第二范式
满足第一范式 非主属性对于所有主属性完全函数依赖
这里需要解释几个名词：
非主属性：不包含在主键中的属性。
主属性：包含在主键中的属性。
完全函数依赖：若属性集 X 和属性集 Y 之间存在函数关系 X -> Y，且对于X的任何一个真子集 X‘，X‘ -> Y 不成立，那么我们称 Y 对于 X 完全函数依赖。
也许有人会觉得完全函数依赖的解释看起来和没解释是一样的，所以这里使用上面的例子进行说明。上面提到过，我们使用 ID 和出借的图书作为主键，那么 ID 和出借的图书一旦确定，名字、居住地也随之确定，即函数(ID, 出借的图书) -> (名字, 居住地)成立。但是，如果 ID 确定了，名字、居住地也能被确定下来，所以对于(ID, 出借的图书)的真子集(ID)，函数(ID) -> (名字, 居住地)依然成立。所以上面的表不满足第二范式。
第三范式
这个关系模式的主键是图书名，显然它满足第一范式。因为主键只有一个字段，非主属性对于所有主属性一定是完全函数依赖，所以它也满足第二范式。但是如果在给这张表增加一本人民邮电出版社出版的《深入理解 MySQL》，我们就会发现出版商的地址会存在冗余！为了消除这种冗余，第三范式就被提出来了。
第三范式需要满足以下两点：
满足第二范式
非主属性对于主码不存在传递函数依赖
为了消除非主属性对于主码的传递函数依赖，我们将上面的表拆分为两个表：
BCNF
前面提到的第二范式和第三范式分别消除了非主属性对于主属性的部分函数依赖和传递依赖，那么如果主属性对于主键存在部分函数依赖和传递函数依赖会怎么样呢？举个例子，假设：
一个数据库公司给多个甲方提供技术支持
一个甲方公司现场只需要一名技术支持人员，一名技术支持人员也只能在一个甲方公司做支持
一个甲方公司使用了数据库公司的多个产品，每个产品的维护时间都不一样
满足第三范式 主属性对于主键不存在部分函数依赖和传递依赖
小结
回顾 E-R 关系模型和范式，其实我们可以发现：
不满足第一范式的关系模式可能是根本没有建立 E-R 模型，直接将所有信息放到一张表；或者是 E-R 模型没有主键；或者是 E-R 模型转化为关系模式时多值属性、复合属性没有处理好
不满足其他范式最大的原因应该是没有正确的识别实体集和关系集。比如第二范式中的例子，会员实体集和图书实体集的信息完全混到了一起；第三范式中图书实体集和出版商实体集混到了一起；BCNF 例子则更可能来自实体集甲方公司、技术支持人员、项目的一个三元关系集。
总结
本文只介绍了数据库设计一小部分，这一小部分对于一个高质量的数据库设计是很重要的，但是也是远远不够的。为了得到一个高质量的数据库设计，还需要从两方面去努力。一方面，在 E-R 模型的上游需要做好领域模型的构建，以便于对需要构建的系统有更深入的理解，从而得到更高质量的 E-R 模型。另一个方面，需要非常了解使用的 DBMS 的特性。比如使用 MySQL，需要知道使用哪种类型的存储引擎存储是合适的，使用什么类型的字段是合适的等；有的人还建议不使用关系模式的主键，而是使用自增主键。这两方面也不是完全孤立的，比如要为哪些字段创建索引要基于查询来考虑，而最经常会有的查询其实在业务建模的时候就能明确的。总的来说，数据库设计是一个系统的工程，需要对整个系统都有详细的了解才能做好。
社区近期动态
Mycat 问题免费诊断
诊断范围支持：
Mycat 的故障诊断、源码分析、性能优化
服务支持渠道：
技术交流群，进群后可提问
QQ群（669663113）
社区通道，邮件&电话
osc@actionsky.com
现场拜访，线下实地，1天免费拜访
关注“爱可生开源社区”公众号，回复关键字“Mycat”，获取活动详情。
社区技术内容征稿
征稿内容：
格式：.md/.doc/.txt
主题：MySQL、分布式中间件DBLE、数据传输组件DTLE相关技术内容
要求：原创且未发布过
奖励：作者署名；200元京东E卡+社区周边
投稿方式：
邮箱：osc@actionsky.com
格式：[投稿]姓名+文章标题
以附件形式发送，正文需注明姓名、手机号、微信号，以便小编及时联系