说明
范式来自英文Normal form，简称NF。要想设计—个好的关系，必须使关系满足一定的约束条件，此约束已经形成了规范，分成几个等级，一级比一级要求得严格。满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入(insert)、删除(delete)和更新(update)操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般来说，数据库只需满足第三范式(3NF）就行了。
这种官方介绍太复杂，下面进入简单定义模式。
一、第一范式
1NF是对属性的原子性，要求属性具有原子性，不可再分解；
表：字段1、 字段2(字段2.1、字段2.2)、字段3 …
如商品（编号，品名，进货，销售，备注），其中属性进货可再分为数量、单价，属性销售可再分为数量、单价。因为它的属性可再分，不具有原子性，它就不是一范式了
下面的学生信息表就符合第一范式。
| 学号 | 姓名 | 性别 | 出生年月日 |
|---|---|---|---|
| 0624233 | 罗伯特 | 男 | 2000-01-01 |
二、第二范式
2NF是对记录的惟一性，要求记录有惟一标识(主键)，即实体的惟一性，即不存在部分依赖；
表：学号、课程号、姓名、学分、成绩;
| 学号 | 姓名 | 课程号 | 学分 | 成绩 |
|---|---|---|---|---|
| 0624233 | 罗伯特 | 101 | 2 | 100 |
| 0624233 | 罗伯特 | 102 | 3 | 99 |
| 0624201 | 小芳 | 101 | 2 | 88 |
| 0624202 | 韩梅梅 | 102 | 3 | 66 |
这个表明显说明了两个事务:学生信息, 课程信息;由于非主键字段必须依赖主键，这里学分依赖课程号，姓名依赖与学号，所以不符合二范式。
可能会存在问题：
数据冗余:，每条记录都含有相同信息；删除异常：删除所有学生成绩，就把课程信息全删除了；插入异常：学生未选课，无法记录进数据库；更新异常：调整课程学分，所有行都调整。
正确做法:
学生：Student(学号, 姓名)；
学号(主键) |
姓名 |
|---|---|
| 0624233 | 罗伯特 |
| 0624201 | 小芳 |
| 0624202 | 韩梅梅 |
课程：Course(课程号, 学分)；
课程号(主键) |
学分 |
|---|---|
| 101 | 2 |
| 102 | 3 |
选课关系：StudentCourse(学号, 课程号, 成绩)。
学号(主键) |
课程号 | 成绩 |
|---|---|---|
| 0624233 | 101 | 100 |
| 0624233 | 102 | 99 |
| 0624201 | 101 | 88 |
| 0624202 | 102 | 66 |
三、第三范式
3NF是对字段的冗余性，要求任何字段不能由其他字段派生出来，它要求字段没有冗余，即不存在传递依赖；
表: 学号, 姓名, 年龄, 学院名称, 学院电话
因为存在依赖传递: (学号) → (学生)→(所在学院) → (学院电话) 。
| 学号 | 学生 | 所在学院 | 学院电话 |
|---|---|---|---|
| 0624233 | 0624233, 罗伯特, 18 | 计算机学院 | 110 |
| 0624201 | 0624201, 小芳, 17 | 信息管理学院(冗余) |
111 |
| 0624202 | 0624202, 李雷, 16 | 信息管理学院(冗余) |
111 |
可能会存在问题：
数据冗余:有重复值；更新异常：有重复的冗余信息，修改时需要同时修改多条记录，否则会出现数据不一致的情况 。
正确做法：
学生：(学号, 姓名, 年龄, 所在学院)；
| 学号 | 姓名 | 年龄 | 所在学院 |
|---|---|---|---|
| 0624233 | 罗伯特 | 18 | 计算机学院 |
| 0624201 | 小芳 | 17 | 信息管理学院 |
| 0624202 | 李雷 | 16 | 信息管理学院 |
学院：(学院, 电话)。
| 学院 | 电话 |
|---|---|
| 计算机学院 | 110 |
| 信息管理学院 | 111 |
四、反范式化
一般说来，数据库只需满足第三范式（3NF）就行了。
没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余，达到以空间换时间的目的。
〖例〗：有一张存放商品的基本表，“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。
在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。
五、范式化设计和反范式化设计的优缺点
5.1 范式化
优点：
可以尽量减少数据冗余(数据表更新快体积小)- 范式化的更新操作比反范式化更快
- 范式化的表通常比反范式化更小
缺点：
- 对于查询需要对多个表进行关联(
导致性能降低) - 更难进行索引优化
5.2 反范式化
优点：
- 可以减少表的关联
- 可以更好的进行索引优化
缺点：
- 存在数据冗余及数据维护异常
- 对数据的修改需要更多的成本
六、数据库入门学习材料
推荐慕课网 【数据库设计那些事】
-
第1章 需求分析
本章主要讲解在数据库设计过程中如何进行需求分析，以及在需求分中我们所要了解的主要内容是什么。
1-1 数据库设计简介 (04:56)
1-2 数据库设计的步骤 (03:39)
1-3 需求分析重要性简介 (03:59)
1-4 需求分析举例 (07:04) -
第2章 逻辑设计
本章主要讲解逻辑设的基本方法以及所要遵守的相关规范，并通过一些简单的例子使大家更容易了解逻辑设计规范的相关内容。
2-1 ER图 (04:36)
2-2 设计范式概要 (03:05)
2-3 第一范式 (01:35)
2-4 第二范式 (05:45)
2-5 第三范式 (05:18)
2-6 BC范式 (04:59) -
第3章 物理设计
本章主要讲解物理设计中我们所要注意的一些问题，并以MySQL为例说明了一些使用MySQL进行数据存储时的一些注意事项。
3-1 数据库物理设计要做什么 (04:02)
3-2 选择哪种数据库 (03:41)
3-3 MYSQL常用存储引擎 (05:25)
3-4 数据库表及字段的命名规则 (03:39)
3-5 数据库字段类型选择原则 (05:34)
3-6 数据库如何具体选字段类型 (06:39)
3-7 数据库设计其它注意事项 (07:05)
3-8 反范式化表设计 (06:06) -
第4章 维护优化
本章主要介绍数据库结构的维护及优化方法，并介绍了什么是水平拆分表及垂直拆分表。
4-1 数据库维护和优化要做什么 (02:30)
4-2 数据库如何维护数据字典 (02:30)
4-3 数据库如何维护索引 (05:12)
4-4 数据库中适合的操作 (05:38)
4-5 数据库表的垂直和水平拆分 (04:12)
参考
https://segmentfault.com/a/1190000013695030
https://www.zhihu.com/question/24696366
https://www.imooc.com/learn/117
