关系型数据库设计范式及原则

好的数据库设计一定是精致、优雅、赏心悦目、让人心醉。

为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。，以提升数据库的存储效率、数据完整性和可扩展性。

 

第一范式：确保每列保持原子性

要求：

• 要求每一列都是不可分割的原子属性。
• 要求不存在重复的属性。

举例：

学号	姓名	性别	年龄	联系电话	居住地址
10010	张思平	男	24	15667084589	河北省唐山市路北区24号
10011	李卫国	男	23	15648972564	辽宁省大连市甘井子区32号

在上面的表中，“居住地址” 列不满足原子性的要求，故不满足第一范式。

调整如下：

学号	姓名	性别	年龄	联系电话	省份	城市	详细地址
10010	张思平	男	24	15667084589	河北省	唐山市	路北区24号
10011	李卫国	男	23	15648972564	辽宁省	大连市	甘井子区32号

注意：

原子性还要根据具体项目需求来定，上面这个例子比较适用于系统经常会访问“地址”属性中的“城市”部分，或者根据省份进行分类、查询等操作时。

当然，如果你的项目压根就不大，而且你有能力预见你的项目未来业务无论如何扩展，都不会涉及像上述根据省份、城市进行查询排序等操作，那么你完全可以将他们存储到一个字段。

 

第二范式：确保表中的每列都和主键相关

要求：

• 要求必须先满足第一范式。
• 要求每一个属性都完全依赖于主键，而不能只完全依赖于主键的某一部分（针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种类型的数据，不可以把多种数据保存在同一张数据库表中。

举例：

订单号	商品号	商品数量	商品单价	总价	订单时间	收货人	联系方式	收货地址
10010	101	3	30	90	20200824	张明	15667054684	河北唐山
10011	102	5	10	50	20200824	赵刚	15667054684	辽宁大连

这个表中是以订单编号和商品号作为联合主键。这样在该表中商品数量、商品价格信息不与该表的主键（订单号）相关，而仅仅是与商品号相关。并且订单时间、联系方式、收货地址仅仅依赖于订单号而与商品号无关。所以在这里违反了第二范式的设计原则。

调整如下：

订单号	商品号	收货人	联系电话	收货地址	订单时间
10010	1	张明	15667054684	河北唐山	20200824
10011	2	赵刚	15667054684	辽宁大连	20200824

 

商品号	商品数量	商品单价	总价
101	3	30	90
102	5	10	50

这样设计，在很大程度上减小了数据库的冗余。

 

第三范式：确保每列都和主键列直接相关,而不是间接相关

要求：

• 要求必须先满足第二范式。
• 要求每个属性都和主键直接相关，而不能间接相关。

举例：

学号	姓名	性别	班主任姓名	班主任性别	班主任年龄
10010	莉莉	女	王爽	女	45
10011	张超	男	王爽	女	35

上表中，所有属性都完全依赖于学号，所以满足第二范式，但是 “班主任性别” 和 “班主任年龄” 直接依赖的是属于非主属性的 “班主任姓名”，而不是主键 “学号”，所以需做如下调整：

学号	姓名	性别	班主任姓名
10010	莉莉	女	王爽
10011	张超	男	王爽

班主任姓名	班主任性别	班主任年龄
王爽	女	45
黄伟	女	35

注：2NF 和 3NF 的概念很容易混淆，区分它们的关键点在于：

• 2NF：非主键列是否完全依赖于主键，还是依赖于主键的一部分（主要针对联合主键的表）；
• 3NF：非主键列是直接依赖于主键，还是直接依赖于非主键列。

以上三范式都是相对并非绝对，要根据具体项目具体分析

 

关于数据库冗余字段设计

在设计数据库时，某一字段属于一个表，但它又同时出现在另一个或多个表，且完全等同于它在其本来所属表的意义表示，那么这个字段就是一个冗余字段。

冗余字段的存在到底是好还是坏呢？

这是一个不好说的问题。可能在有人看来，这是一个很蹩脚的数据库设计。因为在数据库设计领域，有一个被大家奉为圭臬的数据库设计范式，这个范式理论上要求数据库设计逻辑清晰、关系明确，比如，”用户昵称”字段”nickname”本来属于表”user”，那么，表示”用户昵称”的字段就唯一的只应该属于”user”表的”nickname”字段，这样，当用户要修改昵称的时候，程序就只需要修改 user.nickname这个字段就行了，瞧，很方便。不过问题也随之而来，我在其他数据表(如订单orders表)里只存储了用户的ID，我要通过这个ID值得到用户昵称该怎么办呢？一个普遍的解决方法是通过联接(join)，在查询时，通过id这个唯一条件联接两个表，从而取到用户的昵称。

这样确实是没问题，我也一直觉得这样是最好的方案，扩展方便，当要更新用户信息时，程序中要修改的地方很少，但是随着数据库里数据不断增加，百万，千万，同时，用户表的数据肯定也在不断的增加的，它可能是十万，百万。这个时候，你会发现两个表通过联接来取数据就显得相当费力了，可能你只需要取一个nickname这个用户昵称属性，你就不得不去联一下那个已经几十万的用户表进行检索，其速度可想而知了。

这个时候，你可以尝试把nickname这个字段加到orders这个订单表中，这样做的好事是，当你要通过订单表呈现一个订单列表时，涉及用户的部分可能就不需要再进行联接查询了(变成了单表查询)。当然，有利就有弊，这样做的弊端就是，当你尝试更新用户信息时，你必须记得用户信息表里当前被更新的字段中，有哪些是冗余字段，分别属于哪些表，找到他们，然后加入到你的更新程序段中来。这个是程序中的开销，开销在开发人员的时间上了。至于这样做是否值得，就得看具体情况而定了。

所以，目前要创建一个关系型数据库设计，我们有两种选择：

1. 尽量遵循范式理论的规约，尽可能少的冗余字段，让数据库设计看起来精致、优雅、赏心悦目、让人心醉。
2. 合理的加入冗余字段这个润滑剂，减少join，让数据库执行性能更高更快。

选择哪一种呢？如果你是一个美学狂人，并且财大气粗，非要使用第一种方案，也没关系，这种方案的短板并非不可救药的。比如，你可以增加服务器，从数据库集群入手，进行读写分离，读的时候可以将压力分散到不同的数据库服务器上，这样也可以获得很好的性能，只是多付出了硬件成本和维护成本。或者，你可以在数据库前端架设Memcached之类的缓存服务，减少读写数据库的次数，也可以达到同样的效果。问题在于你确定你需要缓存之类的东西。