关系数据库规范化理论

本文来源于：http://blog.sina.com.cn/s/blog_4d73b3a7010008st.html

关系型数据库在设计时应该遵守一定的规则，即遵循数据库的范式理论。数据库的数据是一切操作的基础，如果数据库设计不好，利用其它方法来提高数据库性能的效果都将是有限的。而设计的关键是如何使数据库能合理地存储用户的数据，方便用户进行数据处理。

规范化理论是将一个不合理的关系模式如何转化为合理的关系模式理论，规范化理论是围绕范式而建立的。规范化理论认为，一个关系型数据库中所有的关系，都应满足一定的规范。规范化理论把关系应满足的规范要求分为几级，满足最低要求的一级叫做第一范式(1NF)，在第一范式的基础上提出了第二范式(2NF)，在第二范式的基础上又提出了第三范式(3NF)，以后又提出了BCNF范式，4NF，5NF。范式的等级越高，应满足的约束条件也越严格。规范的每一级别都依赖于它的前一级别，例如若一个关系模式满足2NF，则一定满足1NF。

下面我按照范式设计级别依次介绍1NF（第一范式）、2NF（第二范式）、3NF（第三范式）和BCNF，4NF(第四范式)和5NF(第五范式)。

第一范式（1NF）：在数据库表中，要求每个属性值都是不可再分的，则该关系满足第一范式。

如：某关系表SC由 STUDENT_ID(学生编号)和COURSE(课程名称)两个属性组成。这样的关系模式在实际应用过程中会存在这样问题，一个学生可以同时选择多门课程，现将此关系中STUDENT_ID作为关键字，COURSE字段中存在了多个值的情况，象这样：

STUDENT_ID	COURSE
001	中国文化史概要、音乐欣赏
002	音乐欣赏、程序设计

这样的关系即不满足第一范式的要求。实际应用中，在设计表时，都应该满足第一范式要求。

STUDENT_ID	COURSE
001	中国文化史概要
001	音乐欣赏
002	音乐欣赏
002	程序设计

解决方法：

 

 

 

第二范式（2NF）：如果某关系满足第一范式，而且它的所有非关键字属性都完全依赖于整个主关键字（不存在部分依赖），则该关系满足第二范式。

如：关系LESSON（课程表）：由SNO，CNO，GRADE，CREDIT四个属性组成，其中SNO为学号、CNO为课程号、GRADEGE为学生成绩、CREDIT为学分。根据这个关系，关键字为组合关键字（SNO、CNO）。

在应用中使用这个关系模式可能存在以下问题：

a.更新异常。若调整了某课程的学分，相应的元组CREDIT值都要更新，有可能会出现同一

门课学分不同的情况。

c.插入异常。如计划开新课，由于没人选修，没有学号关键字，只能等有人选修才能把课程

和学分存入。

d.删除异常。若学生已经结业，从当前数据库删除选修记录。某些门课程新生尚未选修，则

此门课程及学分记录无法保存。

分析原因：非关键字属性CREDIT仅依赖于CNO这个字段，也就是CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。

解决方法：将其实原有关系分成两个关系STUDENT（SNO、CNO、GRADE），LESSON（CNO、CREDIT）。这样的两个关系都满足第二范式的要求。

第三范式（3NF）：如果某关系模式满足第二范式，而且它的任何一个非主属性都不传递依赖于任何关键字，则满足第三范式。

例：关系S1(SNO、SNAME、DNO、DNAME、LOCATION) ，属性依次代表学号、姓名、所在系编号、系名称、系地址。 关键字SNO决定各个属性，满足2NF。但这样的关系肯定会使数据有大量的冗余，有关学生DNO，DNAME，LOCATION三个属性将重复插入、删除和修改。

分析原因：关系中存在传递依赖造成的。即SNO决定DNO，DNO决定LOCATION,但SNO不能直接决定LOCATION, 而是通过DNO传递依赖实现的，所以不满足第三范式。

解决方法：将其分为两个关系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION）。

BCNF：如果关系R的所有属性中，若每个决定因素都包含候选关键字，则称关系R属于BCNF。

例：关系SLT(SID、LESSON、TEACHER)，SID为学生编号、LESSON为课程名称、TEACHER为授课教师，其中SID为关键字，经分析该关系满足第三范式，分析(SID、LESSON)决定授课教师，(SID、TEACHER)决定课程，TEACHER决定LESSON，由于TEACHER不是关键字，所以不满足BCNF。

解决方法：；C（SID、TEACHER），T（TEACHER、LESSON）。

第四范式（4NF）：若关系模式R每个非平凡多值依赖X→→Y,X都含有候选键，则该关系模式满足第四范式。

如：关系RR（SBM、CZDM、SCCJ），其中SBM设备名称、CZDM厂站代码、SCCJ生产厂家。

分析：对于设备名称，无论生产厂家是谁，都会有一组值对应厂站代码即SBM→→CZDM，同理对设备名称，无论厂站代码是谁，都会有一组值对应生产厂家即SBM→→SCCJ。由于两个多值依赖的左端都不含候选键，所以不满足第四范式。

解决方法：RR_1(SBM、SCCJ)，RR_2(SBM、CZDM)。

第五范式（5NF）：如果关系模式中，每一个连接依赖，都包含由关系中候选键，则称为该关系模式满足第五范式。

例如有一个关系R1中

A	B	C
A1	B1	C1
A2	B1	C2
A1	B2	C1
A2	B2	C2

分析：在关系中A、B、C均为关键字。从上表中可以看出，表中存在大量冗余的数据。

解决方法：可以将其拆分成下面的三个关系RA、RB、RC。

RA	RB	RC
A	B	B	C	C	A
A1	B1	B1	C1	C1	A1
A1	B2	B1	C2	C1	A2

满足第五个范式。

将一个关系分解成多个关系，要使得分解有意义，起码的要求是分解后不丢失原来的信息。这些信息不仅包括数据本身，而且包括由函数依赖所表示的数据之间的相互制约。进行分解的目标是达到更高一级的规范化程度，但是分解的同时必须考虑两个问题：无损联接性和保持函数依赖。有时往往不可能做到既有无损联接性，又完全保持函数依赖。需要根据需要进行权衡。

小结：

规范化目的是使结构更合理，消除插入、修改、删除异常，使数据冗余尽量小，便于插入、删除和更新。

原则：遵从概念单一化 “一事一地”原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。

方法：将关系模式投影分解成两个或两个以上的关系模式。

要求：分解后的关系模式集合应当与原关系模式“等价”，即经过自然联接可以恢复原关系而不丢失信息，并保持属性间合理的联系。

注意：一个关系模式结这分解可以得到不同关系模式集合，也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空间，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。

现在做数据库设计，很少有人可以做到很符合范式的。一般说来，第一范式大家都可以遵守，如果设计的数据库能遵守前三个范式，就可以啦，因为范式越高，可能也会BCNF的范式出现机会较少，而且会破坏完整性，你可以在做设计之时不考虑它。希望大家在设计数据库时，一定要全面考虑各方面的问题，根据实际情况出发，然后再确定是否应该满足更高范式。