三大范式_三范式原则

文章目录
前言
一、三大范式
1.第一范式（1NF）
2.第二范式（2NF）
3.第三范式（3NF）
二、五大约束
二、关于范式的一些其他了解
前言
本篇文章主要给大家详细解释三大范式以及在面试时如果面试官问到三大范式时大家可以依据当时情况自己去扩展谈论范式的由来和范式有几种，范式难道就真的只有我们常见的三大范式吗？还有经常与三大范式一起讨论的五大约束，在这里也会给大家做一些详细解释，希望可以帮助到大家！
一、三大范式
1.第一范式（1NF）
原子性：强调的是列的原子性，即数据库中每一列的字段都是单一属性，不可再分的。并且这个单一属性必须是由基本的数据类型所构成的，如整数、字符串等。下面给大家举个例子：

这是一张员工表：

员工ID 姓名 性别 部门 联系电话
101 周星星 女 销售部 15015246623
现在我们来分析上表，这张员工表是不符合第一范式标准的，每个员工只有一个员工ID，也确实只有一个姓名，一个性别，只属于一个部门，但是在我们的实际生活中，每个人真的只有一个联系电话吗？这里我们就假设最少的情况，每个人都有个人电话和家庭电话，那么联系电话这一字段就是可再分的。这张表的结构设计就没有达到第一范式。
解决方案：我们只需要把联系电话这一字段分为个人电话字段和家庭电话字段，就完全符合了第一范式（如下表）。

员工ID 姓名 性别 部门 个人电话 家庭电话
101 周星星 女 销售部 15015246623 663323
2.第二范式（2NF）
依赖性：在满足1NF的基础上再满足依赖性的两个约束：一张表必须有一个主键；非主键类必须完全依赖于主键，而不能只依赖主键的一部分。
这是一张商品供销信息表：

商品 供销商 价格 重量 分类 供销商电话
啤酒 饮品1厂 3 300ml 液体 18016253155
啤酒 饮品2厂 5 300ml 液体 18055231233
可乐 饮品2厂 5 250ml 液体 18055231233
需要清楚几点：
1.商品与供销商是多对多的关系
2.该表中关键字是一组组合关键字<商品，供销商>，只有商品和供销商两个字段结合才可标识出一件商品
3.存在以下部分依赖的关系
商品—->价格，重量，分类
供销商—->供销商电话

由以上存在的部分依赖关系就可知道该商品表不符合第二范式了，价格，重量，分类只依赖于商品这个主键，而供销商电话也只依赖于供销商这个主键，已经完全违背了第二范式非主键列必须完全依赖于主键而不能只依赖于主键的一部分这一原则了。
解决方案：把上表商品表拆分为商品表和供销商表两张表，既满足了非主键字段必须完全依赖主键这一条件又减少了供销商电话重复这一冗余。

商品 供销商 价格 重量 分类
啤酒 饮品1厂 3 300ml 液体
啤酒 饮品2厂 5 300ml 液体
可乐 饮品2厂 3 250ml 液体
供销商 供销商电话
饮品1厂 18016253155
饮品2厂 18055231233
3.第三范式（3NF）
在满足2NF的基础上，另外再满足一个条件：非主键列必须直接依赖于主键，不能存在传递依赖。
这是一张学生课表：

课程编号 课程名字 上课时间 任课老师 老师电话 老师职位
101 马克思理论基础 8:00 Lily 18016253155 讲师
102 经济学 14:00 Lucy 18055231233 教授
主键：课程编号
大致一看，上表中的非主键列确实完全是依赖于主键（课程编号）的，符合第二范式2NF。但是问题是：老师电话，老师职位直接依赖的是任课老师（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。
解决方案：依然是通过拆分，把上述学生课表拆分为课程表和教师表。

课程表：

课程编号 课程名字 上课时间 任课老师
101 马克思理论基础 8:00 Lily
102 经济学 14:00 Lucy
教师表：

任课老师 老师电话 老师职位
Lily 18016253155 讲师
Lucy 18055231233 教授
二、五大约束
经常有听到三大范式五大约束这种说法，上面我们已经详细说明了三大范式，这里我们就来简单说明一下大家常说的五大约束，到底是哪五个约束呢？
1.PRIMARY KEY(primary key):设置主键约束；
2.UNIQUE(unique)：设置唯一性约束，不能有重复值；
3.DEFAULT(default)：默认值约束，height DOUBLE(3,2) height不输入是默认为(1,2)。
4. NOT NULL(not null)：设置非空约束，该字段不能为空；
5. FOREIGN KEY (foreign key):设置外键约束。

二、关于范式的一些其他了解
范式（Normal Form）是英国人在上个世纪70年代提出关系数据库模型后总结出来的，范式是关系数据库理论的基础，也是我们在设计数据库结构过程中必须要遵循的规则和指导方法。目前有迹可寻的共有8种范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF，但是我们只要理解前三个范式就完全够用了，其他范式只是简单了解一下。

数据库三范式是什么？(3NF详解)

什么是范式？
范式是数据库设计时遵循的一种规范，不同的规范要求遵循不同的范式。

最常用的三大范式
第一范式(1NF)：属性不可分割，即每个属性都是不可分割的原子项。(实体的属性即表中的列)

第二范式(2NF)：满足第一范式；且不存在部分依赖，即非主属性必须完全依赖于主属性。(主属性即主键；完全依赖是针对于联合主键的情况，非主键列不能只依赖于主键的一部分)

第三范式(3NF)：满足第二范式；且不存在传递依赖，即非主属性不能与非主属性之间有依赖关系，非主属性必须直接依赖于主属性，不能间接依赖主属性。（A -> B, B ->C, A -> C）

举例说明3NF：
1NF
属性不可再分，即表中的每个列都不可以再进行拆分。

如下学生信息表(student)：

id、name(姓名)、sex_code(性别代号)、sex_desc(性别描述)、contact(联系方式)

primary key(id)

如果在查询学生表时经常用到学生的电话号，则应该将联系方式(contact)这一列分为电话号(phone)和地址(address)两列，这样才符合第一范式。

修改使表满足1NF后：

判断表是否符合第一范式，列是否可以再分，得看需求，如果将电话号和地址分开才能满足查询等需求时，那之前的表设计就是不满足1NF的，如果电话号和地址拼接作为一个字段也可以满足查询、存储等需求时，那它就满足1NF。

2NF
在满足1NF的前提下，表中不存在部分依赖，非主键列要完全依赖于主键。(主要是说在联合主键的情况下，非主键列不能只依赖于主键的一部分)

如下学生成绩表(score)：

stu_id(学生id)、kc_id(课程id)、score(分数)、kc_name(课程名)

primary key(stu_id, kc_id)

表中主键为stu_id和kc_id组成的联合主键。满足1NF；非主键列score完全依赖于主键，stu_id和kc_id两个值才能决定score的值；而kc_name只依赖于kc_id，与stu_id没有依赖关系，它不完全依赖于主键，只依赖于主键的一部分，不符合2NF。

修改使表满足2NF后：

成绩表(score)   primary key(stu_id)

将原来的成绩表(score)拆分为成绩表(score)和课程表(kc)，而且两个表都符合2NF。

3NF：
在满足2NF的前提下，不存在传递依赖。(A -> B, B -> C, A->C)

如下学生信息表(student)：

primary key(id)

表中sex_desc依赖于sex_code，而sex_code依赖于id(主键)，从而推出sex_desc依赖于id(主键)；sex_desc不直接依赖于主键，而是通过依赖于非主键列而依赖于主键，属于传递依赖，不符合3NF。

修改表使满足3NF后：

学生表(student)   primary key(id)

性别代码表(sexcode)   primary key(sex_code)

将原来的student表进行拆分后，两个表都满足3NF。

什么样的表越容易符合3NF？
非主键列越少的表。(1NF强调列不可再分；2NF和3NF强调非主属性列和主属性列之间的关系)

如代码表(sexcode)，非主键列只有一个sex_desc；

或者将学生表的主键设计为primary key(id,name,sex_code,phone)，这样非主键列只有address，更容易符合3NF。

参考链接：三大范式（小白视角，一看就懂）_Java喵喵的博客-CSDN博客_三范式

　　　　   数据库三范式是什么？(3NF详解)_小鱼星空的博客-CSDN博客_3nf范式

今天的文章三大范式_三范式原则分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。