共计 3031 个字符，预计需要花费 8 分钟才能阅读完成。
一、范式
范式的英文名称是 Normal Form，它是英国人 E.F.Codd（关系数据库的老祖宗）在上个世纪 70 年代提出关系数据库模型后总结进去的。范式是关系数据库实践的根底，也是咱们在设计数据库构造过程中所要遵循的规定和领导办法。目前有迹可寻的共有 8 种范式，顺次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常所用到的只是前三个范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。
第一范式（1NF）
第一范式其实是关系型数据库的根底，即任何关系型数据库都是合乎第一范式的。简略的将第一范式就是每一行的各个数据都是不可分割的，同一列中不能有多个值，如果呈现反复的属性就须要定义一个新的尸实体。
上面数据库便不合乎第一范式：
+------------+-------------------+
| workername | company |
+------------+-------------------+
| John | ByteDance,Tencent |
| Mike | Tencent |
+------------+-------------------+下面形容的数据所表白的意思是，Mike 在 Tencent 工作，而 John 同时在 ByteDance 和 Tencent 工作（假如这是可能的）。然而这种表达方式并不合乎第一范式，即列的数据必须是不可分的，要满足第一范式，必须是上面的这种模式：
+------------+-----------+
| workername | company |
+------------+-----------+
| Mike | Tencent |
| John | ByteDance |
| John | Tencent |
+------------+-----------+第二范式（2NF）
首先，一个数据库要满足第二范式必须要先满足第一范式。
咱们先看一个表格：
+----------+-------------+-------+
| employee | department | head |
+----------+-------------+-------+
| Jones | Accountint | Jones |
| Smith | Engineering | Smith |
| Brown | Accounting | Jones |
| Green | Engineering | Smith |
+----------+-------------+-------+ 这个表形容了被雇佣者，工作部门和领导的关系。这个表所示意的关系在现实生活中是齐全可能存在的，当初让咱们思考一个问题，如果 Brown 接任 Accounting 部门的领导，咱们须要怎么对表进行批改？这个问题将会变得十分麻烦，因为咱们会发现数据都耦合在一起了，你很难找到一个很好的能惟一确定每一行的判断条件来执行你的 UPDATE 语句。 而咱们把可能惟一示意数据库中表的一行的数据成为这个表的主键。 因而，没有主键的表是不合乎第二范式的，也就是说合乎第二范式的表须要规定主键。
因而咱们为了使下面的表合乎第二范式，须要将它拆分为两个表：
+----------+-------------+
| employee | department |
+----------+-------------+
| Brown | Accounting |
| Green | Engineering |
| Jones | Accounting |
| Smith | Engineering |
+----------+-------------+
+-------------+-------+
| department | head |
+-------------+-------+
| Accounting | Jones |
| Engineering | Smith |
+-------------+-------+在这两个表中，第一个表的主键为 employee，第二个表的主键为 department。在这种状况下，实现下面的问题就显得非常简单了。
第三范式（3NF）
一个关系型数据库要满足第三范式必须要先满足第二范式。
将第三范式前，咱们同样先看两个表：
+-----------+-------------+---------+-------+
| studentid | studentname | subject | score |
+-----------+-------------+---------+-------+
| 1 | Mike | Math | 96 |
| 2 | John | Chinese | 85 |
| 3 | Kate | History | 100 |
+-----------+-------------+---------+-------+
+-----------+-----------+-------+
| subjectid | studentid | score |
+-----------+-----------+-------+
| 101 | 1 | 96 |
| 111 | 3 | 100 |
| 201 | 2 | 85 |
+-----------+-----------+-------+ 下面的两个表格的主键别离为 studentid 和 subjectid，很显然两个表都合乎第二范式。
然而咱们会发现这两个表有反复冗余的数据 score。因而第三范式就是要打消冗余的数据，具体到下面的状况，就是两个表只有一个可能存在 score 这一列数据。那么怎么将这两个表分割起来呢，这里就呈现了外键。 如果两个表中有冗余反复的列，而且这个表中的一个非主键列在另一个表中是主键，那么咱们为了打消冗余列能够把这个非主键列作为分割两个表的桥梁，也就是外键。 通过观察能够发现，studentid 在第一个表中是主键，在第二个表中是非主键，所以他就是第二个表的外键。因而上述情况咱们有了以下合乎第三范式的写法：
+-----------+-------------+---------+
| studentid | studentname | subject |
+-----------+-------------+---------+
| 1 | Mike | Math |
| 2 | John | Chinese |
| 3 | Kate | History |
+-----------+-------------+---------+
+-----------+-----------+-------+
| subjectid | studentid | score |
+-----------+-----------+-------+
| 101 | 1 | 96 |
| 111 | 3 | 100 |
| 201 | 2 | 85 |
+-----------+-----------+-------+能够发现在设定了外键之后，第一个表即便删除了 score 列，也能够通过 studentid 在第二个表中查找到相应的 score 的值，这样即打消了数据的冗余，又不会影响查找，满足第三范式。
二、范式的长处和毛病
范式的长处
- 范式化的更新操作通常要比反范式化要快。
- 当数据较好地范式化时，就只有很少或者没有反复的数据，所以只须要批改更少的数据。
- 范式化的表通常都比拟小，能够更好的放在内存中，所以执行操作会更快。
- 很少有多余的数据意味着检索列表数据时更少须要 DISTINCT 或者 GROUP BY 语句。
范式的毛病
范式化的毛病就是通常须要关联。略微简单一些的查问语句在合乎范式的数据库上都可能须要至多一次关联，兴许更多，这岂但代价低廉，也可能使一些索引策略有效。
