数据库的设计规范

前言

我是胡亦，一名热衷分享技术的博主。所谓无规矩不成方圆，数据库的设计也是同样；好的设计可以为我们带来性能上的提升。本篇文章主要通过一些举例来简单明了的讲解MySQL的三大范式及反范式化的出现和为什么需要反范式化等。
好了，话不多说，内容如下：

1.为什么需要数据库的设计

糟糕的数据库设计可能带来的问题：

• 数据冗余、信息重复，存储空间浪费
• 数据更新、插入、删除的异常
• 无法正确表示信息
• 丢失有效信息
• 程序性能差

良好的数据库设计有以下优点：

• 节省数据的存储空间
• 能够保证数据的完整性
• 方便进行数据库应用系统的开发

2 键和相关属性的概念

范式的定义会使用到主键和候选键，数据库中的键（key）由一个或者多个属性组成。数据表中常用的几种键和属性的定义如下：

• 超键：能唯一标识元组的属性集叫做超键；元组：就是一行数据

• 候选键：如果超键不包括多余的属性，那么这个超键就是候选键；

• 主键：用户可以从候选键中选一个作为主键

• 外键：如果数据表R1中的某属性集不是R1的主键，而是另一个数据表R2的主键，那么这个属性集就是数据表R1的外键。

• 主属性：包含在任一候选键中的属性称为主属性。

• 非主属性：与主属性相对，指的是不包含在任何一个候选键中的属性。

通常，我们也将候选键称之为"码"，把主键也称为 “主码”。因为键可能是由多个属性组成的，针对单个属性，我们还可以用主属性和非主属性来进行区分。

3. MySQL三大范式

3.1 范式简介

在关系型数据库中，关于数据表设计的基本原则，规则就称为范式。可以理解为，一张数据表的设计结构需要满足的某种设计标准的级别。想要设计一个结构合理的关系型数据库，必须满足一定的范式（规则）。

范式的英文名称是Normal Form，简称NF。它是英国人E.F.codd（埃德加·弗兰克·科德）在上个世纪70年代提出关系数据库模型后总结出来的。范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。

1981年，科德因在关系型数据库方面的贡献获得了图灵奖。他也被誉为：“关系数据库之父”

3.2 第一范式（1st NF）

第一范式主要是确保数据表中每个字段的值必须具有原子性，也就是说数据表中每个字段的值为不可再次拆分的最小数据单元**。

举例1：

假设一家公司要存储员工的姓名和联系方式。它创建一个如下表：

该表不符合1NF，因为规则说"表的每个属性必须具有原子(单个)值"，lisi和zhaoliu员工的emp_mobile值违反了该规则(有两个电话)。为了使表符合1NF，我们应该有如下表数据：

举例2：

属性的原子性是 主观的 ，你可以根据你的业务场景自行选择，答案取决于应用程序。如果应用程序需要分别处理地址中的省、市、地址则有必要把它们分开。否则，不需要。

表一：地址字段没有被分开

姓名	年龄	地址
张三	20	广东省广州市三元里78号
李四	24	广东省深圳市龙华新区

表二：地址字段分开

姓名	年龄	省	市	地址
张三	20	广东	广州	三元里78号
李四	24	广东	深圳	龙华新区

所以，范式的设计有时候还需要一点主观性。不是一定要严格遵守的。数据库的设计应该是与具体的业务有关的。越适合你业务的表结构越好。

3.3 第二范式（2nd NF）

第二范式要求，在满足第一范式的基础上，还要满足数据表里的每一条数据记录，都是可唯一标识的。而且所有非主键字段，都必须完全依赖主键，不能只依赖主键的一部分。如果知道主键的所有属性的值，就可以检索到任何元组(行)的任何属性的任何值。(要求中的主键，其实可以拓展替换为候选键)。

简言之，所有的属性都可以通过主键获取（也只能通过主键获取）

举例1：

成绩表 （学号，课程号，成绩）关系中，（学号，课程号）可以决定成绩，但是学号不能决定成绩，课程号也不能决定成绩，所以"（学号，课程号）→ 成绩" 就是 完全依赖关系 ，符合第二范式，因为学号+成绩构成主键，且所有列都依赖主键。

举例2：

存在比赛表player_game，里面包含球员编号、姓名、年龄、比赛编号、比赛时间和比赛场地等属性，这里候选键和主键都为（球员编号，比赛编号），我们可以通过候选键（或主键）来决定如下的关系：

(球员编号, 比赛编号) → (姓名, 年龄, 比赛时间, 比赛场地，得分)

但是这个数据表不满足第二范式，因为数据表中的字段之间还存在着如下的对应关系：

# 姓名和年龄"部分依赖"球员编号。
(球员编号) → (姓名，年龄)
# 比赛时间, 比赛场地"部分依赖"比赛编号。(通过比赛的编号，我们就可以得到比赛的时间和比赛场地。这些信息不通过球员编号一样可以得到)
(比赛编号) → (比赛时间, 比赛场地)

对于非主属性来说，并非完全依赖候选键，这样会产生怎样的问题呢？

1. 数据冗余：如果一个球员可以参加m场比赛，那么球员的姓名和年龄就重复了 m - 1次。一个比赛也可能会有n个球员参加，比赛的时间和地点就重复了n - 1次。
2. 插入异常：如果我们想要添加一场新的比赛，但是这时还没有确定参加的球员都有谁，那么就没法插入（比赛信息和球员信息冗余）。
3. 删除异常：如果我要删除某个球员编号，如果没有单独保存比赛表的话，就会同时把比赛信息删除掉。
4. 更新异常：如果我们调整了某个比赛的时间，那么数据表中所有这个比赛的时间都需要进行调整，否则就会出现一场比赛时间不同的情况。

为了避免以上问题的出现，我们可以把球员比赛表设计为下面的三张表。

表名	属性（字段）
球员表player	球员编号、姓名和年龄等属性
比赛表game	比赛编号、比赛时间和比赛场地等属性
球员比赛关系表player_game	球员编号、比赛编号和得分等属性

1NF 告诉我们字段属性需要是原子性的，而2NF告诉我们一张表就是一个独立的对象，一张表只表达一个意思。

第2范式(2NF)要求实体的属性完全依赖主关键字，如果存在不完全依赖，那么这个属性和主关键字这一部分应该分离出来；形成一个新的实体，新实体与元实体之间是一对多的关系。

3.4 第三范式（3rd NF）

第三范式是在第二范式的基础上，确保数据表中的每一个非主键字段都和主键字段直接相关，也就是说，要求数据表中的所有非主键字段不能依赖于其他非主键字段。(即，不能存在非主属性A依赖于非主属性B，非主属任B依赖于主键C的情况，即存在“A→B一C”"的决定关系）通俗地讲，该规则的意思是所有非主键属性之间不能有依赖关系，必须相互独立。

这里的主键可以拓展为候选键。

举例1：

部门信息表：每个部门有部门编号、部门名称、部门简介等信息。

员工信息表：每个员工有员工编号、姓名、部门编号。列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中（消除部分依赖，这是2NF的要求）。

以上这个举例就满足第三范式。因为不存在部分依赖和传递依赖的问题。员工信息表中的所有非主键字段都依赖于主键字段，且非主键字段之间相互独立，不存在依赖关系。

举例2：

字段名称	字段类型	是否是主键	说明
id	INT	是	商品主键id （主键）
category_id	INT	否	商品类别编号
category_name	VARCHAR(30)	否	商品类别名称
goods_name	VARCHAR(30)	否	商品名称
price	DECIMAL(10,2)	否	商品价格

商品类别名称依赖于商品类别编号，不符合第三范式，也不符合第二范式。

修改：

表1：符合第三范式的 商品类别表 goods_category的设计

字段名称	字段类型	是否是主键	说明
id	INT	是	商品类别主键id
category_name	VARCHAR(30)	否	商品类别名称

表2：符合第三范式的 商品表goods 的设计

字段名称	字段类型	是否是主键	说明
id	INT	是	商品主键id
category_id	VARCHAR(30)	否	商品类别id
goods_name	VARCHAR(30)	否	商品名称
price	DECIMAL(10,2)	否	商品价格

商品表goods通过商品类别id字段（category_id）与商品类别表goods_category进行关联。

符合3NF后的数据模型通俗地讲，2NF和3NF通常以这句话概括：“每个非键属性依赖于键，依赖于整个键，并且除了键别无他物”。

这里的键就是主键，也可以是候选键，反正都是键。

3.5 小结

关于数据表的设计，有三个范式要遵循。

1）第一范式(1NF)，确保每列保持原子性。数据库的每一列都是不可分割的原子数据项，不可再分的最小数据单元，而不能是集合、数组、记录等非原子数据项。

2）第二范式(2NF)，确保每列都和主键完全依赖。尤其在复合主键的情况下，非主键部分不应该依赖于部分主键。

3）第三范式(3NF)，确保每列都和主键列直接相关，而不是间接相关。

范式的优点

数据的标准化有助于消除数据库中的数据冗余，第三范式(3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好的平衡。

范式的缺点

范式的使用，可能降低查询的效率。因为范式等级越高，设计出来的数据表就越多、越精细，数据的冗余度就越低，进行数据查询的时候就可能需要关联多张表，这不但代价昂贵，也可能使一些索引策略无效。

范式只是提出了设计的标准，实际上设计数据表时，未必一定要符合这些标准。开发中，我们会出现为了性能和读取效率违反范式化的原则，通过增加少量的冗余或重复的数据来提高数据库的读性能，减少关联查询join表的次数，实现空间换取时间的目的。因此在实际的设计过程中要理论结合实际，灵活运用。

范式本身没有优劣之分，只有适用场景不同。没有完美的设计，只有合适的设计，我们在数据表的设计中，还需要根据需求将范式和反范式混合使用。

4. 反范式化

4.1 概述

有的时候不能简单按照规范要求设计数据表，因为有的数据看似冗余，其实对业务来说十分重要。这个时候，我们就要遵循业务优先的原则，首先满足业务需求，再尽量减少冗余。

如果数据库中的数据量比较大，系统的UV和PV访问频次比较高，则完全按照MySQL的三大范式设计数据表，读数据时产生大量的关联查询，在一定程度上会影响数据库的读性能。如果我们想对查询效率进行优化，反范式优化也是一种优化思路。此时，可以通过在数据表中增加冗余字段来提高数据库的读性能。

范式化 VS 性能

1. 为满足某种商业目标 , 数据库性能比规范化数据库更重要
2. 在数据规范化的同时 , 要综合考虑数据库的性能
3. 通过在给定的表中添加额外的字段，以大量减少需要从中搜索信息所需的时间
4. 通过在给定的表中插入计算列，以方便查询

举例1：
员工的信息存储在 employees 表 中，部门信息存储在 departments 表 中。通过 employees 表中的department_id字段与 departments 表建立关联关系。如果要查询一个员工所在部门的名称：

select employee_id,department_name
from employees e join departments d
on e.department_id = d.department_id;

如果经常需要进行这个操作，连接查询就会浪费很多时间。可以在 employees 表中增加一个冗余字段department_name，这样就不用每次都进行连接操作了。

举例2：

我们有 2 个表，分别是 商品流水表（atguigu.trans ）和 商品信息表（atguigu.goodsinfo） 。商品流水表里有 400 万条流水记录，商品信息表里有 2000 条商品记录。

商品流水表：

商品信息表：

​ 两个表是符合第三范式要求的。但是，在我们项目的实施过程中，对流水的查询频率很高，而且为了获取商品名称，基本都会用到与商品信息表的连接查询。

为了减少表之间的连接，我们可以直接把商品名称字段加到流水表里面。这样一来，我们就可以直接从流水表中获取商品名称字段了。虽然增加了冗余字段，但是避免了关联查询，提升了查询的效率。

新的商品流水表如下所示：

4.2 反范式化的新问题

反范式可以通过空间换时间，提高查询的效率，但是反范式也会带来一些新问题：

• 存储空间变大了
• 一个表中字段做了修改，另一个表中冗余的字段也需要做同步修改，否则数据不一致
• 若采用存储过程来支持数据的更新、删除等额外操作，如果更新频繁，会非常消耗系统资源
• 在数据量小的情况下，反范式不能体现性能的优势，可能还会让数据库的设计更加复杂

4.3 反范式化的适用场景

当冗余信息有价值或者能大幅度提高查询效率的时候，我们才会采取反范式的优化。

1. 增加冗余字段的建议

增加冗余字段一定要符合如下两个条件。只有满足这两个条件，才可以考虑增加冗余字段。

​ 1）这个冗余字段不需要经常进行修改。

​ 2）这个冗余字段查询的时候不可或缺。

2. 历史快照、历史数据的需要

在现实生活中，我们经常需要一些冗余信息，比如订单中的收货人信息，包括姓名、电话和地址等。每次发生的 订单收货信息 都属于 历史快照 ，需要进行保存，但用户可以随时修改自己的信息，这时保存这些冗余信息是非常有必要的。

反范式优化也常用在 数据仓库 的设计中，因为数据仓库通常 存储历史数据 ，对增删改的实时性要求不强，对历史数据的分析需求强。这时适当允许数据的冗余度，更方便进行数据分析。

简单总结下数据仓库和数据库在使用上的区别：

1. 数据库设计的目的在于捕获数据，而数据仓库设计的目的在于分析数据；
2. 数据库对数据的增删改实时性要求强，需要存储在线的用户数据，而数据仓库存储的一般是历史数据；
3. 数据库设计需要尽量避免冗余，但为了提高查询效率也允许一定的冗余度，而数据仓库在设计上更偏向采用反范式设计。

5. BCNF(巴斯范式)

人们在3NF的基础上进行了改进，提出了巴斯范式(BCNF)，也叫做巴斯-科德范式(Boyce-Codd NormalFom)。BCNF被认为没有新的设计规范加入，只是对第三范式中设计规范要求更强，使得数据库冗余度更小。

所以，称为是修正的第三范式，或扩充的第三范式，BCNF不被称为第四范式。

若一个关系达到了第三范式，并且它只有一个候选键，或者它的每个候选键都是单属性，则该关系自然达到BC范式。一般来说，一个数据库设计符合3NF或BCNF就可以了。

偏向采用反范式设计。

5. BCNF(巴斯范式)

人们在3NF的基础上进行了改进，提出了巴斯范式(BCNF)，也叫做巴斯-科德范式(Boyce-Codd NormalFom)。BCNF被认为没有新的设计规范加入，只是对第三范式中设计规范要求更强，使得数据库冗余度更小。

所以，称为是修正的第三范式，或扩充的第三范式，BCNF不被称为第四范式。

若一个关系达到了第三范式，并且它只有一个候选键，或者它的每个候选键都是单属性，则该关系自然达到BC范式。一般来说，一个数据库设计符合3NF或BCNF就可以了。

---

以上就是本篇文章的所有内容，如果对你有所帮助；希望点赞支持一波！！
我是胡亦，期待与你的下次相遇~