范式定义
范式是“符合某一种级别的关系模式的集合,表示一个关系内部各属性之间的联系的合理化程度”,通俗理解就是一张数据表的表结构所符合的某种设计标准的级别。
数据库范式的作用
数据库范式分类介绍
1NF
)、第二范式(2NF
)、第三范式(3NF
)即可。通常设计关系数据库最多考虑到BCFN就可以。符合高一级范式的设计,必定符合低一级范式。
重点理解数据库三范式,关于BC范式、第四/第五范式做个了解即可。
有的地方将BC范式划分为第四范式,因此也就有了1NF、2NF、3NF、BCNF或4NF、5NF、6NF的说法。
总体上,关系数据库存在6种范式。
1. 第一范式(1NF):确保每列保持原子性
第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值,就说明该数据库表满足了第一范式。
强调的是列的含义的不可分割性,每一列都是不可分割的基本数据项。
1NF的定义为:符合1NF的关系中的每个属性都不可再分。(可以把”关系”理解为一张带数据的表,“关系模式”是这张数据表的表结构)。
举例:
学生表(学号、姓名、年龄、性别、地址)。地址可以细分为国家、省份、城市、市区、街道,那么该模式就没有达到第一范式。
第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性,本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分,那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储,这样在对地址中某一部分操作或分类的时候将非常方便。这样设计才算满足了数据库的第一范式,如下表所示。

在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。
1NF是所有关系型数据库的最基本要求,只要在RDBMS中已经存在的数据表,一定是符合1NF的。
第一范式存在的问题:冗余度大、会引起修改操作的不一致性、数据插入异常、数据删除异常。
2. 第二范式(2NF):确保表中的每列都和主键相关
第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言),通过和主键完全相关,确保所有的数据都是同一类相关的数据。
也就是在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中。
2NF在1NF的基础之上,消除了非主属性对于码的部分函数依赖。
码:关系中的某个属性或者某几个属性的组合,用于区分每个元组(可以把“元组”理解为一张表中的每条记录,也就是每一行)
- 函数依赖:可以理解为,在一张表中,在属性(或属性组)X的值确定的情况下,必定能确定属性Y的值,那么就可以说Y函数依赖于X,写作 X → Y。
也就是说,在表中,不存在任意两条记录,它们在X属性(或属性组)上的值相同,而在Y属性上的值不同。这也就是“函数依赖”名字的由来,类似于函数关系 y = f(x),在x的值确定的情况下,y的值一定是确定的。
-
完全函数依赖:在一张表中,若 X → Y,且对于 X 的任何一个真子集(假如属性组 X 包含超过一个属性的话),X ' → Y 不成立,那么我们称 Y 对于 X 完全函数依赖,记作:
- 部分函数依赖:假如 Y 函数依赖于 X,但同时 Y 并不完全函数依赖于 X,那么我们就称 Y 部分函数依赖于 X,记作:
- 传递函数依赖:假如 Z 函数依赖于 Y,且 Y 函数依赖于 X,(前提是 Y 不包含于 X,且 X 不函数依赖于 Y),则称 Z 传递函数依赖于 X ,记作:

- 码:设 K 为某表中的一个属性或属性组,若除 K 之外的所有属性都完全函数依赖于 K,则称 K 为候选码,简称为码。也就是:如果K确定时,则表除K之外的所有属性的值也都随之确定,则K就是码(也就是属性或属性组能唯一的标识当前行/元组)。若一个关系中有多个候选码,通常选择一个码作为主码
- 主属性:包含在任何一个码中的属性称为主属性。不包含在任何候选码中的属性称为非主属性或非码属性。
举例:
版本表(版本编码,版本名称,产品编码,产品名称),其中主键是(版本编码,产品编码),这个场景中,数据库设计并不符合第二范式,因为产品名称只依赖于产品编码。存在部分依赖。所以,为了使其满足第二范式,可以改造成两个表:版本表(版本编码,产品编码)和产品表(产品编码,产品名称)
3. 第三范式(3NF):确保每列都和主键列直接相关,而不是间接相关
第三范式需要确保数据表中的每一列数据都和主键直接相关,而不能间接相关。
第三范式对应表的主外键关系,将间接相关的列数据作为一个新表,外键关联到主表。
3NF在2NF的基础之上,消除了非主属性对于码的传递函数依赖。
举例:
订单表(订单编码,顾客编码,顾客名称),其中主键是(订单编码),这个场景中,顾客编码、顾客名称都完全依赖于主键,因此符合第二范式,但顾客名称依赖于顾客编码,从而间接依赖于主键,所以不能满足第三范式。如果要满足第三范式,需要拆分为两个表:订单表(订单编码,顾客编码)和顾客表(顾客编码,顾客名称)。
说明:3NF的模式肯定满足2NF。产生冗余和异常的两个重要原因是部分依赖和传递依赖。3NF模式中不存在非主属性对码的部分函数依赖和传递函数依赖,性能较好。1NF、2NF一般不适合作为数据库模式,通常需要转换为3NF或者更高级别的范式,这种变换过程称为关系模式规范化处理。
来源: