函数依赖
在数据库中,函数依赖是指两个属性之间的一种关系,其中一个属性的值能够唯一确定另一个属性的值。在关系型数据库中,函数依赖是指一个或多个属性的值可以唯一地确定其他属性的值。
例如,在一个学生表中,学生的学号可以唯一确定该学生的姓名、性别、年龄等信息,因此可以说“学号决定了姓名、性别和年龄等属性”。
在关系型数据库中,函数依赖是数据库设计和规范化的基础,可以帮助确保数据的完整性和一致性。例如,一个属性的值取决于其他属性的值,如果这些依赖关系没有正确地定义和管理,就会导致数据的冗余、不一致和不完整。
完全函数依赖
属性集合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
第三范式要求关系表中的非主键属性不依赖于其他非主键属性。如果一个属性依赖于另一个非主键属性,就会导致数据冗余和更新异常。
例如,一个包含了“学号、课程编号、课程名称、教师名称、教师电话”等属性的表,如果将“教师名称、教师电话”分离到另一个表中,就可以消除冗余。