这篇文章给大家分享的是有关数据库规范化的必要性是什么的内容。小编觉得挺实用的，因此分享给大家做个参考。一起跟随小编过来看看吧。

创新互联公司是一家集网站建设,公安企业网站建设,公安品牌网站建设,网站定制,公安网站建设报价,网络营销,网络优化,公安网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。

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

数据库规范化过程

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

规范化的必要性：

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

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

关键知识点函数依赖

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

感谢各位的阅读！关于数据库规范化的必要性是什么就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到吧！

分享标题：数据库规范化的必要性是什么
路径分享：http://ybzwz.com/article/iejdsc.html