数据库中的函数依赖的完全函数依赖：表示属性的值只和另一个属性或属性集合有关。部分函数依赖：表示属性的值取决于多个属性，而且其中一些属性可以被移除而不影响该属性的值。传递函数依赖：表示属性的值由其他属性之间通过传递关系所决定。
一、数据库中的函数依赖
在关系型数据库中，函数依赖是指一个或多个属性（列）值的变化是否会导致其他属性（列）值的变化。根据不同的依赖关系类型，可以分为以下几种：
1、完全函数依赖
表示属性的值只和另一个属性或属性集合有关，任何其他属性没有影响力。
设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。
比如说：C可以通过AB得到，并且C不可以仅通过A得到，也不可以仅通过B得到，那么就说C完全依赖AB。
实例：通过{学生学号，选修课程名}可以得到{该生本门选修课程的成绩}，而通过单独的{学生学号}或者单独的{选修课程名}都无法得到该成绩，则说明{该生本门选修课程的成绩}完全依赖于{学生学号，选修课程名}
2、部分函数依赖
表示属性的值取决于多个属性，而且其中一些属性可以被移除而不影响该属性的值。
设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。
比如说：C可以通过AB得到，并且C也可以仅通过A得到，仅通过B得到，那么就说C部分依赖AB。
实例：通过{学生学号，课程号}可以得到{该生姓名}，而通过单独的{学生学号}已经能够得到{该生姓名}，则说明{该生姓名}部分依赖于{学生学号，课程号}； 又比如， 通过{学生学号，课程号}可以得到{课程名称}，而通过单独的{课程号}已经能够得到{课程名称}，则说明{课程名称}部分依赖于{学生学号，课程号}。（部分依赖会造成数据冗余及各种异常。）
3、传递函数依赖
表示属性的值由其他属性之间通过传递关系所决定。
设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。
比如说：B可以通过A得到，C可以通过B得到，那么就称C传递依赖A。
实例：在关系R（学号，宿舍，费用）中，通过{学号}可以得到{宿舍}，通过{宿舍}可以得到{费用}，而反之都不成立，则存在传递依赖{学号}->{费用}。（传递依赖也会造成数据冗余及各种异常。）
二、数据库三大范式
1、名列前茅范式
数据库每一列都是不可分的基本数据项（原子数据项）。
就比如说，下面一个数据表：
上表所示的地址，就不符合名列前茅范式，以为地址那一列可以分为省份和市区，故可以修改为：
2、第二范式
第二范式要求在满足名列前茅范式的基础上，非码属性必须完全依赖于候选字，也就是要消除部分依赖。
就比如说：
如上图加粗字体所示，可能对于同一个订单，含有不同的产品，因此主键必须是产品号和订单号联合组成。但可以发现产品数量、产品价格与订单号、产品号都有关，不过订单时间与订单金额仅与订单号有关，这就违反了第二范式。故可以修改为：
3、第三范式
第三范式要求在满足第二范式的基础上，任何非主属性不依赖于其他非主属性，即在第二范式的基础上消除传递依赖。第三范式要求数据表的每一列都与主键直接相关，而不是间接相关。
就比如说：
从上表可以看出，所有属性都完全依赖于学号，故符合第三范式，但是班主任性别和班主任年龄直接依赖于班主任姓名，而不是主键学号，故不符合第三范式。可修改为：
延伸阅读1：数据库模式分解简介
- 把一个关系模式分解成若干个关系模式的过程，称为关系模式的分解。
- 把低一级的关系模式分解为若干个高一级的关系模式的方法不是少数的。
- 只有能够保证分解后的关系模式与原关系模式等价，分解方法才有意义。
一站式研发项目管理平台 PingCode
支持敏捷\瀑布、知识库、迭代计划&跟踪、需求、缺陷、测试管理，同时满足非研发团队的流程规划、项目管理和在线办公需要。
