数据库三大范式是什么,数据库范式

关系规范化技术

关系规范化是一种基于函数依赖理论对关系进行分析及分解处理的形式化技术，它将一个有异常数据操作的关系分解成更小的、结构良好的关系，使该关系有最小的冗余或没有冗余。关系规范化给设计者提供了对关系属性进行合理定义的指导。有了规范化关系设计，我们对数据库可以实现高效的、正确的操作。

关系规范化技术涉及一系列规则，实施这些规则，可以确保关系数据库被规范到相应程度。规范化范式（Normal Forma,NF）是关系表符合特定规范化程度的模式。规范化范式的种类与函数依赖有着直接的联系。在关系中存在函数依赖时就有可能存在数据冗余，引出数据操作异常现象。数据冗余不仅浪费存储空间，而且会使数据库难以保持数据的一致性。

实施某种范式的规范化处理，可以确保关系数据库中没有各种类型的数据操作异常和数据不一致性。目前，关系数据库的规范化有6种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式（4NF）和第五范式（5NF）。满足最低规则要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规则要求的称为第二范式（2NF），其余范式依次类推。高级范式包含低级范式的全部规则要求。

在数据库应用中，一般只需满足第三范式（3NF）或巴斯-科德范式（BCNF）就足够了，而使用第四范式（4NF）和第五范式（5NF）的情形很少。下面分别介绍这5种范式。

1.第一范式(确保每列保持原子性)

在关系数据库中，第一范式（1NF）是对关系表的基本要求，不满足第一范式的二维表不是关系。第一范式指关系表的属性列不能重复，并且每个属性列都是不可分割的基本数据项。若一个关系表存在重复列或可细分属性列，则该关系表不满足规范化的1NF范式，该表存在冗余数据，对该表进行数据操作访问也必然会出现异常。解决非规范化关系的基本方法就是对关系进行分解处理，直到分解后的每个关系都满足规范化为止。

1.第一范式在关系数据库中，第一范式（1NF）是对关系表的基本要求，不满足第一范式的二维表不是关系。第一范式指关系表的属性列不能重复，并且每个属性列都是不可分割的基本数据项。若一个关系表存在重复列或可细分属性列，则该关系表不满足规范化的1NF范式，该表存在冗余数据，对该表进行数据操作访问也必然会出现异常。解决非规范化关系的基本方法就是对关系进行分解处理，直到分解后的每个关系都满足规范化为止。【例1】在图1（a）所示的“学生”关系表中，关系表中的“联系方式”属性是一个不明确的数据项，用户可以填写电话数据，也可以填写邮箱数据，即该属性列可以再细分“电话”“电子邮件”等。因此，该关系不满足关系规范化的1NF范式。若要使该关系表符合1NF范式，则必须对“联系方式”属性列进行拆分处理，如将“联系方式”拆分为“电话”“Email”属性后，“学生”关系将满足第一范式，如图1所示。

图1 “学生”关系表

 

2.第二范式(确保表中的每列都和主键相关)

如果关系满足第一范式，并消除了关系中的属性部分函数依赖，该关系满足第二范式。第二范式规则要求关系表中所有数据都要和该关系表的主键有完全函数依赖。如果一个关系中某些属性数据只和主键的一部分存在依赖关系，该关系就不符合第二范式。例如，关系(A,B,N,O,P)的复合主键为(A,B)，那么N、O、P这3个非键属性都不存在只依赖A或只依赖B的情况，则该关系满足第二范式。反之，该关系不满足第二范式。为了使关系满足第二范式，必须为那些部分依赖表主键的属性创建单独的关系表。

【例2】在图2（b）所示的“学生”关系表中，其主键为复合键(学号，课程号)，非键属性与主键的依赖关系如下。除成绩属性完全依赖复合主键外，姓名、系名、住址、电话、Email 属性只依赖于复合主键中的学号，即该关系存在部分函数依赖，不满足第二范式。

为了将图2（b）所示的“学生”关系规范化为满足2NF范式，其处理办法就是消除该关系中的部分函数依赖，将部分函数依赖的属性从原关系中移出，并放入一个新关系中，同时将这些属性的决定因子作为主键放到新关系中。将原“学生”关系分解为“学生”“课程成绩”关系，每个关系均满足2NF范式，如图

图2 满足2NF范式的“学生”关系表和“课程成绩”关系表

 

3.第三范式(确保每列都和主键列直接相关,而不是间接相关)

满足2NF范式的关系表在进行数据访问操作时，依然可能存在数据操作异常问题。例如，对图2中“学生”关系中某学生的“住址”进行更新，而其他同系学生的住址没有修改，则会出现数据不一致问题。此时的数据更新异常是因为“学生”关系表中存在属性传递函数依赖，该表不满足3NF范式导致的。

第三范式（3NF）要求关系先满足2NF范式，并且所有非主键属性均不存在传递函数依赖。例如，关系(A,N,O,P)的主键为 A，那么非键属性 N、O或 P都不能由单个的 N、O、P或它们的组合所决定。该关系满足3NF范式。【例2】图2所示的“学生”关系虽然满足2NF范式，但存在如下属性传递依赖。

学号→系名，系名→住址，故学号→住址因此，该“学生”关系不满足3NF 范式。若要使“学生”关系达到3NF 范式，则需要对该关系进行拆分处理，并使每个关系均不存在属性传递函数依赖。现将原“学生”关系拆分为“学生”“系信息”新关系。由于“课程成绩”关系本身不存在传递函数依赖，它不需进行分解处理。图4-45所示的关系表均满足3NF范式。

4.巴斯-科德范式(主属性内部不能有部分或传递依赖)

一个关系即使满足第三范式，也仍然有可能存在一些会引起数据冗余的属性依赖。因此，需要进一步将关系规范化提升到更高程度的范式，即巴斯-科德（Boyce-Codd）范式，也可称为BCNF范式。

该范式是在3NF范式基础上，要求关系中所有函数依赖的决定因子必须是候选键。

图4 满足3NF范式的关系表【例4】在图4所示的“学生”“系信息”“课程成绩”关系表中，所有属性之间的函数依赖决定因子均是该关系的主键，因此，它们均满足BCNF范式。

 

5.第四范式

一个满足BCNF范式的关系，可能存在多值依赖情况，从而导致数据冗余。当一个关系满足BCNF范式并消除了多值依赖时，该关系就满足4NF范式。【例5】图5所示的“学生”“系信息”“课程成绩”关系表均满足BCNF范式。但在“系信息”关系表中，存在如下多值依赖：系编号→→办公电话，系编号→→学生住址。系办公电话与学生住址不相关，故该关系存在多值依赖，不满足4NF范式。为使“系信息”关系满足4NF范式，需要将其拆分为“系编码”“电话目录”和“学生住址”关系。图4-46所示的关系表均满足4NF范式。

图5 满足4NF范式的关系表

 

6.第五范式

如果一个关系为消除其中连接依赖，进行投影分解，所分解的各个关系均包含原关系的一个候选键，则这些分解后的关系满足5NF范式。连接依赖是函数依赖的一种形式，其定义如下：对关系R及其属性的子集A,B,C,…,Z，当且仅当R的每个合法元组都与其在A,B,C,…,Z上投影的连接结果相同时，则称关系R满足连接依赖。【例6】图6所示的“系信息”关系表满足BCNF范式。但该关系中存在连接依赖(系编号，系名称)、(系编号，办公电话)、(系编号，学生住址)。为该关系消除连接依赖，进行关系投影分解，得到图6所示关系表。

 

图6 满足5NF范式的关系表从关系分解的结果来看，它们既满足4NF范式，同时又满足5NF范式。