数据库的设计规范

前言

我是胡亦，一名热衷分享技术的博主。所谓无规矩不成方圆，数据库的设计也是同样；好的设计可以为我们带来性能上的提升。本篇文章主要通过一些举例来简单明了的讲解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，里面包含球员编号、姓名、年龄、比赛编号、比赛时间和比赛场地等属性，这里候选键和主键都为（球员编号，比赛编号），我们可以通过候选键（或主键）来决定如下的关系：

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

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

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

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

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

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

表名	属性（字段）
球员表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：
员工的信息存储在 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. 历史快照、历史数据的需要

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

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

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

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

5. BCNF(巴斯范式)

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

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

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

偏向采用反范式设计。

5. BCNF(巴斯范式)

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

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