规范化过程主要为克服数据库逻辑结构中的什么？

规范化过程主要为克服数据库逻辑结构中的什么？

• 来源:网络
• 更新日期:2020-08-28

摘要：规范化过程主要为克服数据库逻辑结构中的插入异常、删除异常以及冗余度大的缺陷。数据库规范化能够让数据库设计者更好地了解组织内部当前的数据结构，最终得到一系列的数据实

规范化过程主要为克服数据库逻辑结构中的插入异常、删除异常以及冗余度大的缺陷。数据库规范化能够让数据库设计者更好地了解组织内部当前的数据结构，最终得到一系列的数据实体。数据库规范化通过对数据库表的设计，可以有效降低数据库冗余程度。

数据库规范化过程

关系数据库的规范化说的通俗一些就是对表的规范化。

规范化的必要性：

根据项目的需求，我们会创建相应的数据库表格来完成项目中的数据的存储。这已经成为做项目的固定流程了，但是在真正的开始处理业务需求的时候，就会意识到自己的表格设置的不合理，导致数据的重复存储，插入异常，删除异常，更新异常等问题，这时就需要来重新的规划表格，既浪费时间，又消耗人力财力，十分不划算，因此规范化是十分有必要的，所以今天就在这里教给大家规范表的方法。

在教规范化数据库方法之前，先给大家介绍知识:

关键知识点函数依赖

函数依赖的定义：

设R(U)是属性集上的一个子集，X和Y是U的子集，若对于R(U)上的任意一个可能的关系r,如果r中不可能存在两个元组，它们在X上的属性值相等，而在Y上的属性值不相等，则称X函数决定于Y或Y函数依赖与X,记作X->Y。

定义可能有些难以理解，我在这里简单的解释一下：函数依赖描述的是两个集合之间的一种映射关系，这种映射关系与函数是一样的，例如 y = x^2，在这里对于x来说，一个x就对应一个y值，但是不存在，一个x对应多种y值的情况，所以就可以说y函数依赖于x,然而对于y来说，存在一个y值对应多个x值的情况，所以说x并不函数依赖于y。这就是函数依赖。

接下来我们介绍几种特殊的函数依赖：

完全函数依赖

定义：

如果X->Y，并且对于任意一个X的真子集X’都不存在,X’->Y，那么我们就说 X->Y这种函数依赖属于完全函数依赖。

简单的解释一下： 函数z = x + y，对于z来说：z函数依赖于x和y，但是z并不单独依赖于x或单独依赖于y，这就说明z函数依赖于x和y的这种依赖就是完全函数依赖。

部分函数依赖：

定义：

如果X->Y，但是Y不完全依赖于X，则称这种依赖为部分完全依赖。 也就是说：函数z = x + 0y 是可以看成 ,也就是说z函数依赖于x和y，但是z又单独依赖于x，那么这就是部分函数依赖。

传递函数依赖：

定义：

如果X->Y, Y -> Z ,并且不成立，Y->X也不成立。则称Z传递函数依赖于X。

这个比较简单，函数组z = x^2, x = 2y可以化简为z = 4y ^2，很容易看出：z是函数依赖于x，x依赖于y，并且z->x不成立，这就是传递函数依赖。

关键知识点之二-----键

候选键：一个属性（字段）或一个属性组（多个字段）能够完全决定于关系模式（表）中的其他属性（字段）。也就是说其他属性（字段）完全依赖于该属性（字段）或属性组（多个字段）。

主键：如果候选键多于一个，则选择其中一个作为主键。被选做主键的属性或属性组在该关系模式（表）中的每一个元祖（行）中的值是不允许重复和取值为null的。

主属性：报完在任何一个候选键中的属性，称为主属性。如果候选键是由多个属性共同组成的，那么这些属性组中每一个属性都是主属性。

非主属性：不包含在任何键中的属性称为非主属性。

外键：某属性或属性组在当前关系模式（表）中不是主键，但是另一个关系模式（表）中充当主键的身份，则称该属性或属性组为外键。

在介绍完了上述的基本知识点之后，我们来开始学习数据库表的规范过程：

想要规范表，就首先需要一个标准，来衡量表是否已经规范。这个标准就是----范式。

范式一共有六种：第一范式（1NF），第二范式(2NF)，第三范式(3NF)，BC范式(BCNF)，第四范式(4NF)，第五范式(5NF)。

在上面六中范式中，在一般的情况下我们需要将表规范到BCNF就已经十分完美了，在真正的项目中其实只需要达到3NF就足够了。

接下来重点介绍前4中范式：

第一范式：关系模式R中的所有属性都是不可分的数据项。

简单来说就是只要你能把表建出来，这个表就已经满足了第一范式了。例如student表（student_id, course_id, student_name, age, sex, grade, sdept, sdept_director），在这个表中很明显grade这一项是受student_id, course_id,共同决定的，所以应该让这两项联合做为主键。

第二范式：在满足第一范式的基础上，满足非主属性都完全依赖于R的主键。

这就需要用到前面讲的内容了，要判断非主属性是否完全依赖于主键。如果不满足就重 更改表的结构。例如student表（student_id, course_id, student_name, age, sex, grade, sdept_id, sdept_director)因为student_id, course_id两项联合做为主键，但是对于其他的字段name, age, sex这些 属性来说，它们是完全依 赖于student_id这一属性的，所以它们对于student_id, course_id共同作为主键是部分 依赖的。这就不满足第二范式的定义了，所以应该把 grade拿出来，将这一个大表拆成 两份小表:student(student_id, name, age, sex, sdept_id, sdept_director)， student_score(student_id, course_id, grade);

第三范式：在满足第二范式的情况下去除传递依赖。

例如：student表（student_id, student_name, age, sex, sdept, sdept_director）,很明显每一个专业决定一个专业主任,所以sdept_director传递依赖于student_id，所以应该再拆分一个表student（student_id, student_name, age, sex）和sdept(sdept_id, sdept_name, sdept_director),这样就满足了第三范式。

BC范式：在满足第三范式的情况下，再满足一下三点：

1、所有的主属性完全依赖于其他不包含自己的候选键；
2、所有的非主属性完全依赖于每一个候选键；
3、没有任何属性完全函数依赖于任何一组非主属性。

之前的三个范式都是对非主属性进行各种约束，BC范式是在他们基础上，再对主属性进行约束，解决了主属性之间的部分依赖的问题，以及不存在主属性完全依赖于非主属性的问题。 我们的student表 student（student_id, student_name, age, sex），主键是student_id,所以主属性是student_id,很显然前两条都已经满足，因为学生的姓名可能重复，所以student_id与student_name之间没有函数依赖关系，所以student表满足BC范式。