Mysql数据库三范式

数据库设计三范式

设计数据库表的时候所依据的规范，共三个规范：

第一范式：要求有主键，并且要求每一个字段原子性不可再分
第二范式：要求所有非主键字段完全依赖主键，不能产生部分依赖

第三范式：所有非主键字段和主键字段之间不能产生传递依赖

第一范式

数据库表中不能出现重复记录，每个字段是原子性的不能再分

不符合第一范式的实例：

第一范式1.PNG

存在问题:

最后一条记录和第一条重复（不唯一，没有主键）
联系方式字段可以再分，不是原子性的

第一范式2.PNG

关于第一范式，每一行必须唯一，也就是每个表必须有主键，这是数据库设计的最基本要求，主要采用数值型或定长字符串表示，关于列不可再分，应该根据具体的情况来决定。如联系方式，为了开发上的便利可能就采用一个字段。

第二范式

第二范式是建立在第一范式基础上的，另外要求所有非主键字段完全依赖主键，不能产生部分依赖

实例：

二1.PNG

确定主键：

二2.PNG

以上虽然确定了主键，但此表会出现大量的冗余，主要涉及到的冗余字段为“学生姓名”和“教师姓名”，出现冗余的原因在于，学生姓名部分依赖了主键的一个字段学生编号，而没有依赖教师编号，而教师姓名部分依赖了主键的一个字段教师编号，这就是第二范式部分依赖。

解决：

解决.PNG

如果一个表是单一主键，那么它就是复合第二范式，部分依赖和主键有关系

以上是典型的“多对多”设计

第三范式

建立在第二范式基础上的，非主键字段不能传递依赖于主键字段（不要产生传递依赖）

三1.PNG

上表中，班级名称字段存在冗余，因为班级名称字段没有直接依赖于主键，班级名称字段依赖于班级编号，班级编号依赖于学生编号，这就是传递依赖，解决的办法就是将冗余字段单独拿出来建立表：

解决三.PNG

以上设计是典型的一对多的设计，一存储在一张表中，多存储在一张表中，在多的那张表中添加外键指向一的一方

几个经典的设计：

一对一：

第一种方案：分两张表存储，共享主键
第二种方案：分两张表存储，外键唯一

一对多：

分两张表存储，在多的一方添加外键，
这个外键字段引用一的一方中的主键字段

多对多：

分三张表存储，在学生表中存储学生信息，在课程表中存储课程信息，
在学生选课表中存储学生和课程的关系信息

共享主键.PNG

外键唯一.PNG

实际开发中，数据库设计尽量遵循三范式，但是还是根据实际情况进行取舍，有时可能会拿冗余换速度，最终目的是要满足客户需求

作者：我可能是个假开发
链接：https://www.jianshu.com/p/3e97c2a1687b
来源：简书
中，数据库设计尽量遵循三范式，但是还是根据实际情况进行取舍，有时可能会拿冗余换速度，最终目的是要满足客户需求

作者：我可能是个假开发
链接：https://www.jianshu.com/p/3e97c2a1687b
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

1 MySQL三大范式详解(小白也能懂哦)

范式基础
范式的概念

设计数据库的时候需要遵从的一些规范，目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。
当然正常情况下我们满足前三个范式就可以设计一个比较规范的数据库

要遵循后边的范式，就必须先遵循前面的范式要求，比如第二范式就必须先遵循第一范式的，第三范式必须先遵循第二范式，以此类推

2 三大范式概念

第一范式(1NF)：每个列都不可以再拆分。
第二范式(2NF)：在第一范式的基础上，非主键列完全依赖于主键，而不能是依赖于主键的一部分。
第三范式(3NF)：在第二范式的基础上，非主键列只依赖于主键，不依赖于其他非主键。

3 三大范式举例

比如我们有一个表，以后的例子会对这个表进行三大范式的改造，然后把他变成规范的表：

1）进行第一范式的改造
第一范式(1NF)：每个列都不可以再拆分
我们可以看到表中有一列可以再分，那就是系，所以把他进行第一范式的改造就变成了：

2） 进行第一范式的改造

第一范式(1NF)：每个列都不可以再拆分
我们可以看到表中有一列可以再分，那就是系，所以把他进行第一范式的改造就变成了：

3. 进行第二范式的改造

第二范式(2NF)：在第一范式的基础上，非主键列完全依赖于主键，而不能是依赖于主键的一部分。
这第二范式不好理解，那么我们先了解几个概念：

1）.函数依赖：如果通过A属性(属性组)，可以确定唯一B属性的值，那么B依赖于A。比如上图的姓名，完全依赖于学号
2）.完全函数依赖：如果A是一个属性组，则B属性值的确定需要依赖于A属性组中的所有的属性值。属性组是指多个字段，那么比如我们要想知道一个分数，就必须依赖于学号和课程名称两个属性才能确定一个分数，其他的属性是不能确定某一个分数的
3）.部分函数依赖：如果A是一个属性组，则B属性值的确定需要依赖A属性组的某一些字段即可，例如学号和课程名称为一个属性组，那么学生姓名其实就只需要学号就可以确定
4）.传递函数依赖：如果A属性(属性组),可以确定唯一个B属性的值，再通过B属性的值又可以唯一确定C属性的值，例如一个学号确定一个系名，一个系名对应一个系主任
5）.主键：在一张表中，一个属性或者属性组，被其他所有属性完全依赖，则称这个属性为该码的表，比如上图的学号和课程名称组成的属性组
其实第二范式就是还可以理解为
在第一范式的基础上消除非主键对主键的部分依赖
那么我们上图的主键为学号加课程名称组成的属性组，对于上图，我们可以看到，除了分数其他的都对主键是部分依赖，那么我们可以按照下图的方式进行改正：

经过第二范式的改造把一个表分成两个表，那么我们发现其实第二范式为我们消除了很多冗余的部分，比如改造前张无忌的姓名系名系主任在表中出现了三次，而改造后在两表才出现一次

4. 进行第三范式的改造：

第三范式(3NF)：在第二范式的基础上，非主键列只依赖于主键，不依赖于其他非主键。
根据第二点我们说的概念,修改后变成：

第一范式

第一范式：所有属性都是不可分割的原子值。 
也就是每个属性都是不可再分的。 
例如下图就不符合第一范式的要求 

实际上，1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。如果我们要在RDBMS中表现表中的数据，就得设计为下图的形式： 

第二范式（2NF）

第二范式：在第一范式的基础上，要求非主属性都要和码有完全依赖关系 
所谓完全依赖是指不能存在仅依赖码一部分的属性，必须是依赖全部属性。（区别于部分依赖） 
如果有哪些数据只和码的一部份有关的话，它就不符合第二范式。同时可以得出：如果一个数据表的码只有单一一个字段的话，它就一定符合第二范式(前提是该数据表符合第一范式)。 
（码可以由多个字段组成联合码，所以码可以是多属性） 
2NF在1NF的基础之上，消除了非主属性对于码的部分属性依赖。

首先来看看下图 

（1）每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大

（2）假如学校新建了一个系，但是暂时还没有招收任何学生（比如3月份就新建了，但要等到8月份才招生），那么是无法将系名与系主任的数据单独地添加到数据表中去的 ——插入异常

（3）假如将某个系中所有学生相关的记录都删除，那么所有系与系主任的数据也就随之消失了（一个系所有学生都没有了，并不表示这个系就没有了）。——删除异常

（4）假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据。——修改异常

所以这张表肯定不符合设计规范。我们来通过第二范式修改。 
首先什么是依赖？

依赖 
若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。 
例如，对于上图中的数据，找不到任何一条记录，它们的学号相同而对应的姓名不同。所以我们可以说姓名函数依赖于学号，写作 学号 → 姓名。但是反过来，因为可能出现同名的学生，所以有可能不同的两条学生记录，它们在姓名上的值相同，但对应的学号不同，所以我们不能说学号函数依赖于姓名。

然后什么是码？

码 
设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K（这个“完全”不要漏了），那么我们称 K 为候选码，简称为码。在实际中我们通常可以理解为：假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码。一张表中可以有超过一个码。（实际应用中为了方便，通常选择其中的一个码作为主码） 
如图中我们可以知道该表的码是（学号、课名）

对于第二范式，所有的非主属性要依赖于全部主属性。 
由图中我们可以得到两个主属性：学号 和 课程 
“学号“和”课程“就组成了联合主键。（一个表只有一个主键。 主键可以由一个字段，也可以由多个字段组成）

因为我们可以通过学号来确定一个学生的姓名 系名 系主任 这三个属性，无法确定课程和分数属性。 
通过学生的学号和课程两个属性，可以确定分数。 

对于（学号，课名） → 姓名，有 学号 → 姓名，存在非主属性 姓名 对码（学号，课名）的部分依赖。 
对于（学号，课名） → 系名，有 学号 → 系名，存在非主属性 系名 对码（学号，课名）的部依赖。 
对于（学号，课名） → 系主任，有 学号 → 系主任，存在非主属性 系主任 对码（学号，课名）的部分依赖。

所以表3存在非主属性对于码的部分函数依赖，最高只符合1NF的要求，不符合2NF的要求。

所以做出修改 

删除某个系中所有的学生记录 
该系的信息仍然全部丢失。——无改进 
所以我们要使用第三范式。

第三范式（3NF）

第三范式：任何非主属性不依赖于其它非主属性。 
3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。

对于选课表，码为（学号，课名），主属性为学号和课名，非主属性只有一个，为分数，不可能存在传递函数依赖，所以选课表的设计，符合3NF的要求。

对于学生表，主码为学号，主属性为学号，非主属性为姓名、系名和系主任。因为 学号 → 系名，同时 系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖，所以学生表的设计，不符合3NF的要求。

为了让数据表设计达到3NF，我们必须进一步进行模式分解为以下形式： 
选课（学号，课名，分数） 
学生（学号，姓名，系名） 
系（系名，系主任）

新的函数依赖关系如图 

修改后的表 

第二范式和第三范式就是为了消除非主属性对码的部分函数依赖和传递函数依赖

BC范式

BC范式在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。 

主属性：包含在任何候选码中的属性成为主属性。
要了解 BCNF 范式，那么先看这样一个问题： 
若： 
某公司有若干个仓库； 
每个仓库只能有一名管理员，一名管理员只能在一个仓库中工作； 
一个仓库中可以存放多种物品，一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。 
那么关系模式 仓库（仓库名，管理员，物品名，数量） 属于哪一级范式？

答：已知函数依赖集：仓库名 → 管理员，管理员 → 仓库名，（仓库名，物品名）→ 数量 
码：（管理员，物品名），（仓库名，物品名） 
主属性：仓库名、管理员、物品名 
非主属性：数量 
∵ 不存在非主属性对码的部分函数依赖和传递函数依赖。∴ 此关系模式属于3NF。

基于此关系模式的关系（具体的数据）可能如图所示： 

好，既然此关系模式已经属于了 3NF，那么这个关系模式是否存在问题呢？我们来看以下几种操作： 
先新增加一个仓库，但尚未存放任何物品，是否可以为该仓库指派管理员？——不可以，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空。 
某仓库被清空后，需要删除所有与这个仓库相关的物品存放记录，会带来什么问题？——仓库本身与管理员的信息也被随之删除了。 
如果某仓库更换了管理员，会带来什么问题？——这个仓库有几条物品存放记录，就要修改多少次管理员信息。 
从这里我们可以得出结论，在某些特殊情况下，即使关系模式符合 3NF 的要求，仍然存在着插入异常，修改异常与删除异常的问题，仍然不是 ”好“ 的设计。

造成此问题的原因：存在着主属性对于码的部分函数依赖与传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。

解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。

仓库（仓库名，管理员） 
库存（仓库名，物品名，数量）

这样，之前的插入异常，修改异常与删除异常的问题就被解决了。