前言：
对于数据库范式，时常有据说过，始终没有具体去理解。个别数据库书籍或数据库课程会介绍范式相干内容，范式也经常出现在数据库考试题目中。不分明你是否对范式有比拟清晰的理解呢？本篇文章咱们一起来学习下数据库范式吧。
1. 数据库范式简介
为了建设冗余较小、结构合理的数据库，设计数据库时必须遵循肯定的规定。在关系型数据库中这种规定就称为范式。范式是合乎某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足肯定的范式。
范式的英文名称是 Normal Form，简称 NF。它是英国人 E.F.Codd 在上个世纪 70 年代提出关系数据库模型后总结进去的。范式是关系数据库实践的根底，也是咱们在设计数据库构造过程中所要遵循的规定和领导办法。
目前关系型数据库有六种常见范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯 - 科德范式（BCNF）、第四范式 (4NF）和第五范式（5NF，又称完满范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的根底上进一步满足更多标准要求的称为第二范式（2NF），其余范式以次类推。
2. 罕用范式详解
在设计数据库时，会参考范式要求来做，然而并不是说遵循的范式等级越高越好，范式过高尽管具备对数据关系有更好的约束性，然而也会导致表之间的关系更加繁琐，从而导致每次操作的表会变多，数据库性能降落。通常，在关系型数据库设计中，最高也就遵循到 BCNF，广泛还是 3NF。即个别状况下，咱们应用前三个范式曾经够用了。上面咱们来具体理解下罕用的前三个范式。
第一范式（1NF）
第一范式是最根本的范式。如果数据库表中的所有字段值都是不可合成的原子值，就阐明该数据库表满足了第一范式。简略的讲第一范式就是每一行的各个数据都是不可分割的，同一列中不能有多个值，如果呈现反复的属性就须要定义一个新的实体。
示例：假如一家公司要存储其员工的姓名和联系方式。它创立一个如下表：
两名员工（Jon&Lester）领有两个手机号码，因而公司将他们存储在同一表格中，如上表所示。那么该表不合乎 1NF，因为规定说“表的每个属性必须具备原子（单个）值”，Jon&Lester 员工的 emp_mobile 值违反了该规定。为了使表合乎 1NF，咱们应该有如下表数据：
第二范式（2NF）
第二范式在第一范式的根底之上更进一层。第二范式须要确保数据库表中的每一列都和主键相干，而不能只与主键的某一部分相干（次要针对联结主键而言）。也就是说在一个数据库表中，一个表中只能保留一种数据，不能够把多种数据保留在同一张数据库表中。
+----------+-------------+-------+
| employee | department | head |
+----------+-------------+-------+
| Jones | Accountint | Jones |
| Smith | Engineering | Smith |
| Brown | Accounting | Jones |
| Green | Engineering | Smith |
+----------+-------------+-------+上表形容了被雇佣者，工作部门和领导的关系。咱们把可能惟一示意数据库中表的一行的数据成为这个表的主键。表中 head 列不和主键相干。因而，该表是不合乎第二范式的，为了使下面的表合乎第二范式，须要将它拆分为两个表：
-- employee 为主键
+----------+-------------+
| employee | department |
+----------+-------------+
| Brown | Accounting |
| Green | Engineering |
| Jones | Accounting |
| Smith | Engineering |
+----------+-------------+
-- department 为主键
+-------------+-------+
| department | head |
+-------------+-------+
| Accounting | Jones |
| Engineering | Smith |
+-------------+-------+第三范式（3NF）
满足 2NF 的前提下，非主键外的所有字段必须互不依赖，即须要确保数据表中的每一列数据都和主键间接相干，而不能间接相干。
简而言之，第三范式（3NF）要求一个关系中不蕴含已在其它关系已蕴含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门无关的信息再退出员工信息表中。如果不存在部门信息表，则依据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。
3. 对于反范式
范式的长处是显著的，它防止了大量的数据冗余，节俭了存储空间，放弃了数据的一致性。范式化的表通常更小，能够更好地放在内存里，所以执行操作会更快。那么是不是只有把所有的表都标准为 3NF 后，数据库的设计就是最优的呢？这可不肯定。范式越高意味着表的划分更细，一个数据库中须要的表也就越多，用户不得不将本来相关联的数据摊派到多个表中。略微简单一些的查问语句在合乎范式的数据库上都可能须要至多一次关联，兴许更多，这岂但代价低廉，也可能使一些索引策略有效。
所以咱们在进行数据库设计时，并不会齐全依照范式要求来做，有时候也会进行反范式设计。通过减少冗余或反复的数据来进步数据库的读性能，缩小关联查问时，join 表的次数。
参考：
- https://segmentfault.com/a/1190000037544475
- https://www.zhihu.com/question/24696366
- https://en.wikipedia.org/wiki/Database_normalization