数据库三大范式
作者：互联网
数据的概念
对象object，也称为实体型。在现实世界中具有相同性质、遵循相同规则的一类事物的抽象称为对象。对象是实体集数据化的结果，比如学生、老师、课程等是对象。
实例instance 是指对象中的每一个具体的事物，例如学生张三、李四。
属性attribute 是实体的某一方面特征的抽象表示，例如学生的姓名、性别、班级、年龄等。
主码primary key 能够唯一标识一个实体。
次码secondary key 指实体中不能唯一标识实体的属性。
域domain 指属性的取值范围，比如性别中的男、女。
完整性 指存储在数据库中的所有数据值均正确的状态。如果数据库中存储有不正确的数据值，则该数据库称为已丧失数据完整性。
什么是范式
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。而通常我们用的最多的就是第一范式（1NF）、第二范式（2NF）、第三范式（3NF）。
当一个关系中的所有分类都是不可再分的数据项时，该关系是规范化的。不可再分的数据项，即不存在组合数据项和多项数据项。一个低一级的关系模式，通过模式分解可以转换为若干高一级范式的关系模式的集合，这个过程就叫规范化。二维数据表可以分为5级范式为1NF、2NF、3NF、4NF、5NF。第一范式满足最低的要求条件，第五范式满足最高要求的条件。
第一范式（1NF）：要求数据库表的每一列都是不可分割的原子数据项。
**概念：**所谓第一范式（1NF）是指在关系模型中，对于添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。
**说明：**在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。
例1：
不符合第一范式
| 学号 | 姓名 | 性别 | 学校信息 |
|---|---|---|---|
| 20210101 | 张幼仪 | 女 | 学士，大一 |
| 20210102 | 徐志摩 | 男 | 硕士，研一 |
| 20210103 | 陆小曼 | 女 | 博士，博一 |
| 20210104 | 林徽因 | 女 | 博士，博二 |
| 20210105 | 梁思成 | 男 | 硕士，研二 |
| 20210106 | 金岳霖 | 男 | 硕士，研三 |
符合第一范式
在上面的表中，“学校信息”列不满足原子性的要求，故不满足第一范式，调整如下
| 学号 | 姓名 | 性别 | 学历 | 年级 |
|---|---|---|---|---|
| 20210101 | 张幼仪 | 女 | 学士 | 大一 |
| 20210102 | 徐志摩 | 男 | 硕士 | 研一 |
| 20210103 | 陆小曼 | 女 | 博士 | 博一 |
| 20210104 | 林徽因 | 女 | 博士 | 博二 |
| 20210105 | 梁思成 | 男 | 硕士 | 研二 |
| 20210106 | 金岳霖 | 男 | 硕士 | 研三 |
例2：
不符合第一范式
| 学号 | 姓名 | 性别 | 学历 | 年级 | 电话 |
|---|---|---|---|---|---|
| 20210101 | 张幼仪 | 女 | 学士 | 大一 | 15234940672，15536895536 |
| 20210102 | 徐志摩 | 男 | 硕士 | 研一 | 15234940672，15536895536 |
符合第一范式
| 学号 | 姓名 | 性别 | 学历 | 年级 | 电话 |
|---|---|---|---|---|---|
| 20210101 | 张幼仪 | 女 | 学士 | 大一 | 15234940672 |
| 20210101 | 张幼仪 | 女 | 学士 | 大一 | 15536895536 |
| 20210102 | 徐志摩 | 男 | 硕士 | 研一 | 15234940672 |
| 20210102 | 徐志摩 | 男 | 硕士 | 研一 | 15536895536 |
可见，调整后的每一列都是不可再分的，因此满足第一范式（1NF）。
第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。
| 学号 | 姓名 | 性别 | 学历 | 年级 | 电话 | 省份 | 城市 | 详细地址 |
|---|---|---|---|---|---|---|---|---|
| 20210101 | 张幼仪 | 女 | 学士 | 大一 | 15234940672 | 北京 | 海淀区 | XXX小区 |
| 20210101 | 张幼仪 | 女 | 学士 | 大一 | 15536895536 | 山西 | 太原市 | YYY小区 |
| 20210102 | 徐志摩 | 男 | 硕士 | 研一 | 15234940672 | 北京 | 朝阳区 | YYY小区 |
| 20210102 | 徐志摩 | 男 | 硕士 | 研一 | 15536895536 | 北京 | 西城区 | YYY小区 |
上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。
第二范式（2NF）：确保表中的每列都和主键相关
**概念：**第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。例如在员工表中的身份证号码即可实现每个一员工的区分，该身份证号码即为候选键，任何一个候选键都可以被选作主键。在找不到候选键时，可额外增加属性以实现区分，如果在员工关系中，没有对其身份证号进行存储，而姓名可能会在数据库运行的某个时间重复，无法区分出实体时，设计辟如ID等不重复的编号以实现区分，被添加的编号或ID选作主键。（该主键的添加是在ER设计时添加，不是建库时随意添加）
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。（第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。）
比如要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所示。
订单信息表
| 订单编号 | 商品编号 | 商品名称 | 数量 | 单位 | 价格 | 客户 | 所属单位 | 联系方式 |
|---|---|---|---|---|---|---|---|---|
| 1001 | 1 | 卡车 | 1 | 辆 | ￥2,222 | 徐志摩 | 用友 | 123456789 |
| 1001 | 2 | 书 | 20 | 本 | ￥595 | 徐志摩 | 用友 | 123456789 |
| 1002 | 3 | 汽车 | 2 | 辆 | ￥25,154 | 李四 | 某某 | 254689336 |
这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。
而如果把这个订单信息表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中，就非常完美了。如下所示。
订单信息表
| 订单编号 | 客户 | 所属单位 | 联系方式 |
|---|---|---|---|
| 1001 | 徐志摩 | 用友 | 123456789 |
| 1001 | 徐志摩 | 用友 | 123456789 |
| 1002 | 李四 | 某某 | 254689336 |
订单项目表
| 订单编号 | 商品编号 | 数量 |
|---|---|---|
| 1001 | 1 | 1 |
| 1001 | 2 | 20 |
| 1002 | 3 | 2 |
商品信息表
| 商品编号 | 商品名称 | 单位 | 价格 |
|---|---|---|---|
| 1 | 卡车 | 辆 | ￥2,222 |
| 2 | 书 | 本 | ￥595 |
| 3 | 汽车 | 辆 | ￥25,154 |
这样设计，在很大程度上减小了数据库的冗余。如果要获取订单的商品信息，使用商品编号到商品信息表中查询即可。 说的通俗一点，就是能做为维度表的，要拆分出来作为维度表，比如常见的部门，人员，组织，物料，供应商等等。
第三范式（3NF）：确保每列都和主键列直接相关,而不是间接相关
**概念：**在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）
第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性，也就是在满足2NF的基础上，任何非主属性不得传递依赖于主属性。
第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。即属性不依赖于其它非主属性，属性直接依赖于主键。数据不能存在传递关系，即每个属性都跟主键有直接关系而不是间接关系。像：a–>b–>c 属性之间含有这样的关系，是不符合第三范式的。
例
Student 表
| 学号 | 姓名 | 性别 | 年龄 | 所在院校 | 院校地址 | 院校电话 |
|---|---|---|---|---|---|---|
| 20210101 | 张幼仪 | 女 | 23 | 清华 | 北京 | 123123132 |
| 20210102 | 陆小曼 | 女 | 25 | 清华 | 北京 | 123123132 |
| 20210103 | 徐志摩 | 男 | 24 | 复旦 | 上海 | 231354564 |
| 20210104 | 梁思成 | 男 | 24 | 复旦 | 上海 | 231354564 |
这样一个表结构，就存在上述关系。 学号–> 所在院校 --> (院校地址，院校电话)
这样的表结构，我们应该拆开来
1、学生信息表
| 学号 | 姓名 | 性别 | 年龄 |
|---|---|---|---|
| 20210101 | 张幼仪 | 女 | 23 |
| 20210102 | 陆小曼 | 女 | 25 |
| 20210103 | 徐志摩 | 男 | 24 |
| 20210104 | 梁思成 | 男 | 24 |
2、院校信息表
| 所在院校 | 院校地址 | 院校电话 |
|---|---|---|
| 清华 | 北京 | 123123132 |
| 复旦 | 上海 | 231354564 |
总结：三大范式只是一般设计数据库的基本理念，可以建立冗余较小、结构合理的数据库。如果有特殊情况，当然要特殊对待，数据库设计最重要的是看需求跟性能，需求>性能>表结构。所以不能一味的去追求范式建立数据库。
标签：范式,数据库,1NF,表中,主键,三大,属性 来源： https://blog.csdn.net/weixin_35353187/article/details/114680560