函数依赖
在数据库中，函数依赖是指两个属性之间的一种关系，其中一个属性的值能够唯一确定另一个属性的值。在关系型数据库中，函数依赖是指一个或多个属性的值可以唯一地确定其他属性的值。
例如，在一个学生表中，学生的学号可以唯一确定该学生的姓名、性别、年龄等信息，因此可以说“学号决定了姓名、性别和年龄等属性”。
在关系型数据库中，函数依赖是数据库设计和规范化的基础，可以帮助确保数据的完整性和一致性。例如，一个属性的值取决于其他属性的值，如果这些依赖关系没有正确地定义和管理，就会导致数据的冗余、不一致和不完整。
完全函数依赖
属性集合X对于Y是完全依赖，是指在R中，如果X的任何一个真超集都不满足函数依赖Y，则称Y完全依赖于X。简单来说，就是X中任何一个属性被去掉，Y就不能被唯一确定了。
比如教务处要确定某个学生某门课程的成绩，这里需要知道该学生的学号和课程名称，即
（X,Y）->Z，二者缺一不可。这表示Z完全依赖于集合（X,Y）。
部分函数依赖
属性集合X对于Y是部分依赖，是指在R中，存在X的真子集X’使得X’ ->
Y，即Y依赖于X的一个真子集，而不是X本身。简单来说，就是X中某些属性被去掉，Y依然能被唯一确定。
比如教务处要确定某学生的平均成绩，这就不需要课程名称，只需要学号。那么U就部份依赖于集合（X,Y）。
传递函数依赖
属性集合X对于Y是传递依赖，是指在R中，存在Z使得X -> Z，且Z -> Y，即Y依赖于X的非直接子集。简单来说，就是X间接决定了Y。
候选键
候选键是关系模型中的一组属性，可以唯一地标识关系模型中的每一个元组。
候选键的属性个数最小化，也就是说，不能存在多余的属性。
候选键的属性不能是空值（NULL）。
在一个关系模型中，可能会存在多个候选键，这些候选键中的任何一个都可以被选作主键。
候选键是在满足第一范式的基础上进行的规范化处理。
注意：函数依赖中，入度为0的属性一定包含在候选键集合中。
其中，构成候选键的属性称为主属性，其他属性称为非主属性
数据库三范式
1NF
第一范式（1NF）：强制属性具有原子性
第一范式要求一个关系中的所有属性必须是原子性的，即属性不能再分解。一个关系即为一个表，一个属性就是表中的一个列。如果一个属性包含了多个值，就会导致数据冗余、不一致等问题，影响数据库的性能。
例如，一个包含了“姓名、性别、年龄”三个属性的表，如果将“姓名”列中的姓和名分开存储，就不符合第一范式。
2NF
第二范式要求关系表中的属性必须完全依赖于主键，即任何非主键属性都必须依赖于全部主键而非部分主键。如果一个属性只依赖于部分主键，就会出现数据冗余和更新异常。
例如，一个包含了“订单编号、产品编号、产品名称、产品单价、订购数量、总价”等属性的表，如果将“产品名称、产品单价”分离到另一个表中，就可以消除冗余。
3NF
第三范式要求关系表中的非主键属性不依赖于其他非主键属性。如果一个属性依赖于另一个非主键属性，就会导致数据冗余和更新异常。
例如，一个包含了“学号、课程编号、课程名称、教师名称、教师电话”等属性的表，如果将“教师名称、教师电话”分离到另一个表中，就可以消除冗余。