函数依赖及数据库范式

1、函数依赖

　　（1）简介

　　　　定义：设U{A1，A2，…，An}是属性集合，R（U）是U上的一个关系，x、y是U的子集。若对于R（U）下的任何一个可能的关系，   均有x的一个值对应于y的唯一具体值，称y函数依赖于x，记作x→y。   其中x称为决定因素。进而若再有y→x，则称x与y相互依赖，记作x←→y。

　　　　函数依赖是从数学角度来定义的，在关系中用来刻画关系各属性之间相互制约而又相互依赖的情况。

　　　　比如描述一个学生可有学号、姓名、系等多个属性，由于一个学号对应一个且仅一个学生，一个学生就读于一个确定的系，因而当“学号”属性的值确定之后，“姓名”及“所在系”的值也就唯一地确定了，此时，就可以称“姓名”和“所在系”函数依赖于“学号”，或者说“学号”函数决定“姓名”和“所在系”，记作：学号→姓名、学号→所在系。

　　　　

　　（2）函数依赖的种类

　　　　函数依赖还可细分为多种依赖：  

　　　　● 部分函数依赖   

　　　　　　设关系模式 R（U）是属性集U上的关系，x、y是U的子集，x’是x的真子集，若x→y且x’→y，则称y部分依赖x，记作X→PY。显然，当且仅当x为复合属性组时，才有可能出现部分函数依赖。   

　　　　● 完全函数依赖   

　　　　　　设R（U）是属性集U上的关系，x、y是U的子集，x’是x的真子集。若对于R（U）的任何一个可能的关系，有x→y但不存在x’→y，则称y完全函数依赖于x，记作X→FY。 所谓完全依赖是说明在依赖关系的决定项（即依赖关系的左项）中没有多余属性，有多余属性就是部分依赖。   

　　　　　　例如设关系模式 R（学号，姓名，班号，课程号，成绩），（学号，班号，课程号）→成绩 是R的一个部分依赖关系。因为有（学号，课程号）→成绩 成立，并且不存在学号→成绩或课程号→成绩，所以（学号，课程号）→   成绩是完全依赖关系。   

　　　　● 传递函数依赖   

　　　　　　设R（U）是属性集U上的关系，x、y、z是U的子集，在R（U）中，若x→y，但y→x，若y→z，则x→z，称z传递函数依赖于x，记作X→TZ。   

例如课程名→职工号，并且有职工号→教师名称，在这种情况下，教师名称传递函数依赖于课程名。  

2、数据库范式

　　数据库的范式设计是为了优化关系数据库的关系模式，便于减少数据冗余以及冲突，而范式就是建立在函数依赖的基础之上。

　　目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。

　　在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式(3NF）就行了。

3、第一范式

　　定义：数据库表中的字段都是单一属性的，具有原子性，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。换句话说，第一范式要求数据库中的表都是二维表。

　　例如：

　　

　　图中位于下面的表就不能符合第一范式。

4、第二范式

　　定义：第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。

　　简而言之，第二范式就是在第一范式的基础上消除非主属性对主码的部分函数依赖。

5、第三范式

　　定义：第三范式就是属性不依赖于其它非主属性，也就是在满足2NF的基础上，任何非主属性不得传递依赖于主属性。

　　例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。

　　换句话说，第三范式是在2NF基础上消除了传递依赖。

6、鲍依斯-科得范式

　　定义：在第三范式的基础上，任何主属性不能对主键子集依赖，即主属性不依赖于主属性。

　　3NF去除了非主属性对主键的部分函数依赖和传递函数依赖。一般满足3NF的关系模式已能消除冗余和各种异常现象，获得较满意的效果，但无论2NF还是3NF都没有涉及主属性间的函数依赖，所以有时仍会引起一些问题。由此我们引入BC范式(BCNF，Boyeet和Codd提出)。

　　通常情况下，巴斯-科德范式被认为没有新的设计规范加入，只是对第二范式与第三范式中设计规范要求更强，因而被认为是修正第三范式，也就是说，它事实上是对第三范式的修正，使数据库冗余度更小。这也是BCNF不被称为第四范式的原因。

　　对于BCNF，在主码的任何一个真子集都不能决定于主属性。关系中U主码，若U中的任何一个真子集X都不能决定于主属性Y，则该设计规范属性BCNF。例如：在关系R中，U为主码，A属性是主码中的一个属性，若存在A->Y,Y为主属性，则该关系不属于BCNF。

　　还可以这么说：若一个关系达到了第三范式，并且它只有一个候选码，或者它的每个候选码都是单属性，则该关系自然达到BC范式。

　　当一个关系模式R∈BCNF，则在函数依赖范畴里，已实现了分离，消除了插入、删除的异常。一般关系型数据库设计中，达到BCNF就可以了！

　　小结：数据库范式可避免数据冗余和操作异常。但是不符合范式的设计却不一定是错误的，在数据库表中存在1：1或1：N关系这种较特殊的情况下，合并导致的不符合范式却是合理的。