数据库之六大范式详解
关系数据库中的关系满足一定要求的，满足不同程度要求的为不同的范式。满足最低要求的叫第一范式，简称1NF；在第一范式的基础上满足进一步要求的称为第二范式，简称2NF，其余范式以此类推。对于各种范式之间有如下关系：
如下图所示：
1. 第一范式 1NF
定义： 属于第一范式关系的所有属性都不可再分，即数据项不可分。
理解： 第一范式强调数据表的原子性，是其他范式的基础。如下图所示数据库就不符合第一范式：
上表将商品这一数据项又划分为名称和数量两个数据项，故不符合第一范式关系。改正之后如下图所示：
上表就符合第一范式关系。
但日常生活中仅用第一范式来规范表格是远远不够的，依然会存在数据冗余过大、删除异常、插入异常、修改异常的问题，此时就需要引入规范化概念，将其转化为更标准化的表格，减少数据依赖。
规范化： 一个低一级的关系模式通过模式分解可以转化为若干个高一级范式的关系模式的集合，这个过程叫做规范化。
2. 第二范式 2NF
定义： 若某关系R属于第一范式，且每一个非主属性完全函数依赖于任何一个候选码，则关系R属于第二范式。
此处我们需要理解非主属性、候选码和完全函数依赖的概念。
候选码： 若关系中的某一属性组的值能唯一地标识一个元组，而其子集不能，则称该属性组为候选码。若一个关系中有多个候选码，则选定其中一个为主码。
以下所有内容中，主码或候选码都简称为码。
例如下图所示的学生表中，学号和姓名都可以唯一标识一个元组，故该表的候选码为学号和姓名，主码我们可以随便选定其中一个，则选学号为主码。
| 学号 | 姓名 | 年龄 | 性别 |
|---|---|---|---|
| 101 | 刘晨 | 19 | 女 |
| 102 | 王琪 | 21 | 男 |
| 103 | 张宇 | 20 | 男 |
| 104 | 李琛 | 19 | 女 |
| 105 | 欧阳慧 | 20 | 女 |
主属性： 所有候选码的属性称为主属性。不包含在任何候选码中的属性称为非主属性或非码属性。
在上面的学生表中，学号和姓名就是该关系的主属性，年龄和性别就是非主属性。
函数依赖： 设R(U)是属性集U上的关系模式，X、Y是U的子集。若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称Y函数依赖于X或X函数确定Y。
完全函数依赖： 设R(U)是属性集U上的关系模式，X、Y是U的子集。如果Y函数依赖于X，且对于X的任何一个真子集X’，都有Y不函数依赖于X’，则称Y对X完全函数依赖。记作：如果Y函数依赖于X，但Y不完全函数依赖于X，则称Y对X部分函数依赖。
理解： 第二范式是指每个表必须有一个（有且仅有一个）数据项作为关键字或主键（primary key），其他数据项与关键字或者主键一一对应，即其他数据项完全依赖于关键字或主键。由此可知单主属性的关系均属于第二范式。
判断一个关系是否属于第二范式：
- 找出数据表中的所有码；
- 找出所有主属性和非主属性；
- 判断所有的非主属性对码的部分函数依赖。
以上面的学生表为例，表中的码为学号（码可以为学号或者姓名，此处假定码为学号），非主属性为性别、年龄（其余都为主属性），当学号确定时，性别、年龄也都惟一的被确定为，故学生表的设计满足第二范式（学生表为单主属性的关系）。
3. 第三范式 3NF
定义： 非主属性既不传递依赖于码，也不部分依赖于码。
定义： 关系模式R
中，若每一个决定因素都包含码，则R
属于BCFN。
理解： 根据定义我们可以得到结论，一个满足BC范式的关系模式有：
- 所有非主属性对每一个码都是完全函数依赖；
- 所有主属性对每一个不包含它的码也是完全函数依赖；
- 没有任何属性完全函数依赖于非码的任何一组属性。
例如有关系模式C(Cno, Cname, Pcno)，Cno, Cname, Pcno依次表示课程号、课程名、先修课。可知关系C只有一个码Cno，且没有任何属性对Cno部分函数依赖或传递函数依赖，所以关系C属于第三范式，同时Cno是C中的唯一决定因素，所以C也属于BC范式。
5. 第四范式 4NF
定义： 限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。
理解： 显然一个关系模式是4NF，则必为BCNF。也就是说，当一个表中的非主属性互相独立时（3NF），这些非主属性不应该有多值，若有多值就违反了4NF。
6. 第五范式 5NF
第五范式是在第四范式的基础上做的进一步规范化。第四范式处理的是相互独立的多值情况，而第五范式则处理相互依赖的多值情况。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/209117.html原文链接：https://javaforall.net
