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

数据库规范化过程

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

规范化的必要性：

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

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

关键知识点函数依赖

函数依赖的定义：

定义可能有些难以理解，我在这里简单的解释一下：函数依赖描述的是两个集合之间的一种映射关系，这种映射关系与函数是一样的，例如 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范式。

以上就是数据库的规范化过程

相关推荐：《mysql教程》以上就是规范化过程主要为克服数据库逻辑结构中的什么？的详细内容，更多请关注小潘博客其它相关文章！