转载自解决数据冗余,插入,删除更新异常——数据依赖与规范化
 
 在对数据库进行一些操作的时候我们可能会遇到以下的一些问题:
 
数据冗余(想修改一个属性,就要更新多行数据)
插入异常(想要插入数据,结构因为表设计的问题,导致不能成功插入)
删除异常(只想删除其中的某些数据 ,结果把不该删的也删了)
更新异常(想更新一条数据,结果工作量大,还容易出错)
 
其实这就是因为有数据依赖的原因,因为彼此之间有一些依赖关系,所以导致我们的操作总是牵涉颇多,处理不干净
 
数据依赖的几个重要函数依赖:
 
1. 完全函数依赖
 
比如在学生课程(学号,课程号,成绩)关系中,"学号,课程号"是主码,只有学号不能确定成绩,只有课程号也不能确定成绩,因此"成绩"完全函数依赖与(学号,课程号)
 
2. 部分函数依赖
 
比如在学生课程(学号,课程号,学生姓名,成绩)关系中,"学号,课程号"是主码,只有学号是可以确定学生姓名的,因此存在部分依赖
 
3. 传递函数依赖
 
在学生关系(学号,姓名,性别,所在系,系主任)中,学号可以确定所在系,所在系可以确定系主任,因此学号可以确定系主任,这就是传递函数依赖
 要消除表中一些不必要的依赖关系,则就需要对关系模式进行规范化,而规范化的过程实际上可以理解为模式分解,对于不同的规范化程度呢,我们可用范式来衡量。
 范式是符合某一种级别的关系模式的集合，是衡量关系模式规范化程度的标准，达到的关系才是规范化的。
 目前有6中范式：
 
第一范式（1NF）：每个属性都是不可再分的
第二范式（2NF）：不存在非主属性对主属性的部分函数依赖
第三范式（3NF）：不存在非主属性对主码的传递函数依赖
BC范式（BCNF）：不存在任何属性完全函数依赖与非码的任一组属性
第四范式
第五范式
 
一般来说，满足前三个范式，就已经很满意了

数据库范式能帮忙解决数据冗余问题
 1.第一范式（1NF）
 关系里的属性不能够拆分。
 
 
 第一个不符合第一范式，第二个表才符合。
 2.第二范式（2NF）
 在1NF的基础上，且每一个非主属性完全函数依赖于任何一个候选码
 就是说主属性决定不了非主属性，但是非主属性依赖于候选码
 
 候选码：学号+姓名+课名
 那么主属性：学号 姓名 课名
 非主属性：系名，系主任、分数
 首先这个表是第一范式，但是很明显非主属性不完全依赖候选码。比如系名就跟学号和姓名和课名没多大关系。
 所以我们拆成
 
 先看第一个表，学号跟课名是候选码。
 主属性：学号、课名。非主属性：分数。
 分数取决于学号+课名。
 但是课名决定不了分数，还得加分数。
 第二个表格
 候选码：学号
 主属性：学号
 非主属性：姓名，系名，系主任。
 学号可以决定学号，但是学号决定了系名和系主任。
 所以也是第二范式。
 分数
 3.第三范式（3NF）
 3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。也就是说， 如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。
 传递依赖
 在上面拆成的第二个表中是符合2NF，但是系主任取决于系名，系名取决于学号。这种就是传递依赖。所以这个表不符合3NF。
 
 把它拆成以上两个表，就不会存在传递依赖了。
 
总结一下：
 1NF是为了解决属性可再拆分的数据冗余。
 2NF是为了解决部分非主属性不依赖所有候选码。
 部分非主属性只取决于部分候选码，那么就要拆表。拆成所有非主属性取决于所有候选码
 3NF是为了解决 非主属性虽然取决于所有候选码，但是部分非主属性之间有依赖关系 比如说 地名跟邮政编码一般都是会有依赖关系的，就会形成传递依赖。

在对数据库进行一些操作的时候我们可能会遇到以下的一些问题:
 
数据冗余(想修改一个属性，就要更新多行数据)
插入异常(想要插入数据,结构因为表设计的问题，导致不能成功插入)
删除异常(只想删除其中的某些数据 ，结果把不该删的也删了)
更新异常(想更新一条数据,结果工作量大，还容易出错)
 
其实这就是因为有数据依赖的原因，因为彼此之间有一些依赖关系，所以导致我们的操作总是牵涉颇多，处理不干净
 
数据依赖的几个重要函数依赖：
 
1. 完全函数依赖
 比如在学生课程(学号,课程号,成绩)关系中，"学号,课程号"是主码，只有学号不能确定成绩，只有课程号也不能确定成绩，因此"成绩"完全函数依赖于(学号、课程号)
 
2. 部分函数依赖
 比如在学生课程(学号,课程号,学生姓名,成绩)关系中，"学号、课程号"是主码，只要有学号就可以确定学生姓名的，因此存在部分依赖
 
3. 传递函数依赖
 在学生关系(学号,姓名,性别,所在系,系主任)中，只要有学号就可以确定所在系，有所在系也可以确定系主任，因此学号可以确定系主任，这就是传递函数依赖
 要消除表中一些不必要的依赖关系，则就需要对关系模式进行规范化，而规范化的过程实际上可以理解为模式分解，对于不同的规范化程度呢，我们可用范式来衡量。
 范式是符合某一种级别的关系模式的集合，是衡量关系模式规范化程度的标准，达到的关系才是规范化的。
 目前有6中范式：
 
第一范式（1NF）：每个属性都是不可再分的
第二范式（2NF）：不存在非主属性对主属性的部分函数依赖
第三范式（3NF）：不存在非主属性对主码的传递函数依赖
BC范式（BCNF）：不存在任何属性完全函数依赖于非码的任一组属性
第四范式
第五范式
 一般来说，满足前三个范式，就已经很满意了

 
 
 
   
  
转自https://blog.csdn.net/weixin_36027342/article/details/82769388
 
 

在对数据库进行一些操作的时候我们可能会遇到以下的一些问题:
 
数据冗余(想修改一个属性,就要更新多行数据)
插入异常(想要插入数据,结构因为表设计的问题,导致不能成功插入)
删除异常(只想删除其中的某些数据 ,结果把不该删的也删了)
更新异常(想更新一条数据,结果工作量大,还容易出错)
 
其实这就是因为有数据依赖的原因,因为彼此之间有一些依赖关系,所以导致我们的操作总是牵涉颇多,处理不干净
 
数据依赖的几个重要函数依赖:
 
1. 完全函数依赖
 比如在学生课程(学号,课程号,成绩)关系中,"学号,课程号"是主码,只有学号不能确定成绩,只有课程号也不能确定成绩,因此"成绩"完全函数依赖与(学号,课程号)
 
2. 部分函数依赖
 比如在学生课程(学号,课程号,学生姓名,成绩)关系中,"学号,课程号"是主码,只有学号是可以确定学生姓名的,因此存在部分依赖
 
3. 传递函数依赖
 在学生关系(学号,姓名,性别,所在系,系主任)中,学号可以确定所在系,所在系可以确定系主任,因此学号可以确定系主任,这就是传递函数依赖
 要消除表中一些不必要的依赖关系,则就需要对关系模式进行规范化,而规范化的过程实际上可以理解为模式分解,对于不同的规范化程度呢,我们可用范式来衡量。
 范式是符合某一种级别的关系模式的集合，是衡量关系模式规范化程度的标准，达到的关系才是规范化的。
 目前有6中范式：
 
第一范式（1NF）：每个属性都是不可再分的
第二范式（2NF）：不存在非主属性对主属性的部分函数依赖
第三范式（3NF）：不存在非主属性对主码的传递函数依赖
BC范式（BCNF）：不存在任何属性完全函数依赖与非码的任一组属性
第四范式
第五范式
 一般来说，满足前三个范式，就已经很满意了