MySQL之范式

1、范式

范式的英文名称是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的值，这样即消除了数据的冗余，又不会影响查找，知足第三范式。

2、范式的优势和缺点

范式的优势

• 范式化的更新操做一般要比反范式化要快。
• 当数据较好地范式化时，就只有不多或者没有重复的数据，因此只须要修改更少的数据。
• 范式化的表一般都比较小，能够更好的放在内存中，因此执行操做会更快。
• 不多有多余的数据意味着检索列表数据时更少须要DISTINCT或者GROUP BY语句。

范式的缺点

范式化的缺点就是一般须要关联。稍微复杂一些的查询语句在符合范式的数据库上均可能须要至少一次关联，也许更多，这不但代价昂贵，也可能使一些索引策略无效。