关系模式规范化的定义

到目前为止，规范化理论已经提出了六类范式。范式级别可以逐级升高，而升高规范化的过程就是逐步消除关系模式中不合适的数据依赖的过程，使模型中的各个关系模式达到某种程度的分离。一个低一级范式的关系模式，通过模式分解转为若干个高一级范式的关系模式的集合，这种分解过程叫作关系模式的规范化（Normalization）。

 

关系模式规范化的目的和原则

一个关系只要其分量都是不可分的数据项，就可称它为规范化的关系，但这只是最基本规范化。规范化的目的就是使结构合理，消除存储异常，使数据冗余尽量小，便于插入、最除和更新。

规范化的基本原则就是遵循“一事一地”的原则，即一个关系只描述一个实体或者实体间的联系。若多于一个实体，就把它“分离”出来。因此，所谓规范化，实质上是概念的单一化，即个关系表示一个实体。

 

关系模式规范化的步骤

规范化就是对原关系进行投影，消除决定属性不是候选键的任何函数依赖。具体可以分为以下几步。

（1）对1NF关系进行投影，消除原关系中非主属性对键的部分函数依赖，将1NF关系转换成若干个2NF关系。

（2）对2NF关系进行投影，消除原关系中非主属性对键的传递函数依赖，将2NF关系转换成若干个3NF关系。

（3）对3NF关系进行投影，消除原关系中主属性对键的部分函数依赖和传递函数依赖，也就是说，使决定因素都包含一个候选键，得到一组BCNF关系。

（4）对BCNF关系进行投影，消除原关系中的非平凡且非函数依赖的多值依赖，得到一组4NF的关系。

关系规范化的基本步骤如图所示。

 




 

 

一般情况下，我们说没有异常弊病的数据库设计是好的数据库设计，一个不好的关系模式也总是可以通过分解转换成好的关系模式的集合。但是在分解时要全面衡量，综合考虑，视实际情况而定。对于那些只要求查询而不要求插入、删除等操作的系统，几种异常现象的存在并不影响数据库的操作。这时便不宜过度分解，否则当对系统进行整体查询时，需要更多的多表连接操作，这有可能得不偿失。在实际应用中，最有价值的是3NF和BCNF，在进行关系模式的设计时，通常分解到3NF就足够了。

 

关系模式规范化的要求

关系模式的规范化过程是通过对关系模式的投影分解来实现的，但是投影分解方法不是唯的，不同的投影分解会得到不同的结果。在这些分解方法中，只有能够保证分解后的关系模式与原关系模式等价的方法才是有意义的。

判断对关系模式的一个分解是否与原关系模式等价可以有三种不同的标准。

（1）分解要具有无损连接性；

（2）分解要具有函数依赖保持性；

（3）分解既要具有无损连接性，又要具有函数依赖保持性。

 

 


参考资料：[1]陈志泊，王春玲，许福，范春梅.数据库原理及应用教程（第3版）[M].北京:人民邮电出版社，2014：159-160.

 

 

 

原文路径：http://wenku.baidu.com/link?url=KzN3v3voao4ovz_izsiujMN8vMZMiArzgYbrue8tVL5L_ydc1B_6_1eEy7vfoSiO2-ORTXAXzVBxzWAaXJxiR68z6g4GMD_1AlZWzx46MSG
 
了解关系模式规范化的作用
掌握第一范式-重点
掌握第二范式-重点
掌握第三范式-重点
回顾关系模式
关系模式：关系模式相当于一张二维表的框架，在这个框架下填入数据，称为关系模式的一个实例，或者叫关系（R）
R（A1，A2，A3..Ai）:R是关系名，Ai是关系的属性名。一个关系名对应一张表，关系名对应表名，属性对应表中的列名。
关系模型的简化表示法： R<U,F>
 
关系模式规范化的作用
关系型数据库的设计主要是关系模式的设计。关系模式设计的好坏直接影响关系型数据库设计的成败。将关系模式规范化是设计好关系型数据库的唯一途径。
关系模式的规范化主要有范式来完成。
 
关系模式
所谓范式（Normal Form, NF）是指规范化的关系模式。由规范化程度不同而产生不同的范式。根据满足条件不同，经常称某一关系模式R为“第几模式”。
 
为什么要设计规范化的数据库？
未经规范化的数据库一般都有下述缺点：
较大的数据冗余，数据一致性差，数据修改复杂，对表进行更新，插入，删除是会报异常。规范化的作用就在于尽量去除冗余，使数据保持一致，使数据修改简单，除去在表中进行插入、删除时产生的异常，规范化后的表一般都较小。
 
第一范式（1NF）
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系型数据库。
定义：在关系模型中的每一个具体关系R中，如果每个属性都是不可再分的，则称R属于第一范式（1NF），记作R属于1NF。
第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。
e.g.如下的数据库表是符合第一范式的：
字段1   字段2   字段3   字段4
而这样的数据库表是不符合第一范式的：
字段1   字段2   字段3（字段3.1，字段3.2）   字段4
如职工号，姓名，电话号码组成一个表（一个人可能有一个办公室电话和一个家里的电话号码）规范成为1NF。
总结：不能有重复的列，列不可再分。
不满足第一范式条件的关系为非范式关系，在关系数据库中，凡非范式关系必须要化成范式关系。
 
第二范式（2NF）
第二范式是在第一范式的基础上建立起来的，即满足第二范式必须先满足第一范式（1NF）。
定义：如果关系模式R属于1NF，且每一个非主属性都完全依赖于主码，则称关系R是属于第二范式的，记作R属于2NF。
第二范式（2NF）说明：要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖于主关键字的一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。
e.g.
假定选修课关系表为SelectCourse(学号，姓名，年龄，课程名称，成绩，学分)，关键字为组合关键字（学号，课程名称），因为存在如下决定关系：
（学号，课程名称）->（姓名，年龄，成绩，学分）
这个数据库表不满足第二范式，因为存在如下决定关系：
（课程名称）->（学分）
（学号）->（姓名，年龄）
即存在学分和姓名，年龄部分依赖于主关键字。
由于不符合2NF，这个选课关系表会存在如下问题：
（1）数据冗余：
同一门课程会有N个学生选修，“学分”就会重复N-1次；同一个学生选修了M门课程，那姓名和年龄会重复M-1次。
（2）更新异常：
若课程的学分更新，那必须把表中所有的学分值都更新，不然会出现同一课程出现不同的学分。
（3）插入异常：
假设要开设一门新的课程，但是目前还没有学生选修这门课程，由于没有学号导致数据无法录入到数据库中。
（4）删除异常：
假设一批学生已经完成课程的选修，这些选修记录就应该从数据库中删除，但是，同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。
所以我们将设计修改了一下，把选课关系表SelectCourse改为如下三个表：
学生：Student（学号，姓名，年龄）
课程：Course（课程名称，学分）
选课关系：SelectCourse（学号，课程名称，成绩）
这样的数据库表是符合第二范式的，消除了数据冗余，更新，插入，删除异常。
注：所有的单关键字的数据库表都符合第二范式，因为不可能存在组合关键字，也就不可能存在非主属性部分依赖于主关键字了。
 
第三范式
定义：如果关系模式R属于2NF，并且R中的非主属性不传递依赖与R的主码，则称关系R是属于第三范式的。(个人总结，非主属性必须直接依赖于主码，不能存在通过其他非主属性传递依赖于主码)
所谓传递依赖，就是A依赖于B，B依赖于C，则A传递依赖于C。
因此，满足第三范式的数据库表应该不存在如下依赖关系：
关键字段->非关键字段x->非关键字段y
e.g.
假定学生关系表为Student（学号，姓名，年龄，所在学院，学院地点，学院电话），关键字为单一的学号，所以肯定符合第二范式，但是因为存在非关键字学院地点和学院电话依赖于所在学院，即传递依赖于学号，所以此关系表不符合第三范式。同样会导致数据冗余，DDL操作异常等问题。
所以我们可以对其进行修改：
学生：（学号，姓名，年龄，所在学院）
学院：（学院，地点，电话）
这样的数据库表就符合第三范式了。
 
总结：
a. 规范化目的是使结构更合理，消除存储异常，减少数据冗余，便于插入，删除，更新。
b. 原则：遵从概念单一化“一事一地”原则，即一个关系模式描述一个实体或实体建的一种联系。
c. 方法：将关系模式投影，分解成两个或两个以上的关系模式。
d. 分解后的关系模式集合应当与原关系模式保持等价关系，即通过自然联接可以恢复原关系而不丢失信息，并保持属性间合理的联系。
注意：一个关系模式结合分解可以得到不同关系模式集合，也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现的。其根本膜表是节省存储空间，避免数据不一致性，提供对关系的操作效率，同事满足应用需求。实际上，并不一定要求全部模式都达到BCNF不可。有时候故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频率极高的数据库系统更是如此。在关系数据库中，除了函数依赖之外还有多值依赖，联接依赖的问题，从而提出了第四范式，第五范式等更高一级的规范化要求。
 
 
 
 
 
 
 
 
 
 

最近在学习数据库过程中，发现几本教材大都是按照数据库系统概论->关系数据库基础->SQL语言->关系数据库理论（大都是介绍规范化）介绍，第二部分的关系数据库基础主要谈到了基本算术运算关系和域运算，比如交并差，投影，选择，除法，元组关系演算等等，没有介绍如何合理设计一个数据库，可是如果作为一个数据库designer，必须了解如何设计与简化数据库，这都是数据模式规范化的内容。
如果不考虑数据库规范化，那么我们经常遇到的各种关系二维表，大都是易于理解与查阅，但是效率不高，主要体现在：
1.数据冗余度高，比如一个关系R（学号，学生姓名，课程，教室）中，假若一个学生选修N个课程，那么该学生的学号、姓名就要被重复记录N次，显然冗余度过大，浪费存储空间（但是便于我们直观的理解）。
2.数据修改复杂，再如上例中，假如需要修改学号，一个学生又修了N门课，那么需要修改N次姓名，效率何在？准确性谁能保证？
3.数据插入，删除异常，比如上例中，我暂时不知道某学生的学号，但是其他信息都知道，但我还是没法插入进去，如果删除的话，假如所有学生中只有一位学生选修了张三老师的课，那么现在需要删除该学生所在元祖的话，张三也会被删掉，这样一来，张三就从关系R中彻底消失了！
于是，这种低效率的关系表需要简化，需要拆分，需要规范化！
在规范化之前，需要阐明一些基本概念，因为规范化定义中会用到这些概念，这些基本概念名词定义听起来都文绉绉的，不过其实含义都很简单很明确，下面是一些基本概念：
1.函数依赖
对于关系R(U)，X,Y是U的子集，若对于一个具体关系r，r中有任意两个元组s,t，且s(X)=t(X)能导致s(Y)=t(Y)，则称X决定Y，Y依赖于X，记为X->Y。
含义就是：如果对于r中属性X中的每一个具体值，都有唯一的具体指Y与其对应，那么称Y依赖于X。类似于函数中的单值映射关系，反映了表中属性之间的决定关系。
2.完全函数依赖，部分函数依赖
若关系R（U）中，X->Y，且对于X的任意一个真子集X‘，X’不能->Y，那么说明Y完全依赖于X，否则，称为Y部分依赖于X。
3.函数依赖集
表中函数依赖的集合称为函数依赖集。
4.候选码形式定义
若在关系R（U，F）中，X是属性或属性集，U完全依赖于X，则X为R的候选码，简称码。
这是形式化的定义，定义暗指：候选码具有唯一确定性，能够唯一决定表中任一行，其次，候选码是具有最小性的，因为定义中强调了U完全依赖于候选码X，也就是X的子集是不能决定每一行的，那么便会得到以下结论：若X和Y都是候选码（或者两者有一个是），那么不能说（X，Y）是候选码，因为（X，Y）的真子集X或Y可以决定U，此时U不是完全依赖于（X，Y）。
下面先讨论第一、第二、第三范式。
第一范式（1NF）：
如果关系R中的属性值都是不可再分的最小数据单位，则称为第一范式，记为R∈1NF。
根据定义，我们分别从横向和纵向去看，发现第一范式具有两个特点：
①不存在重复组，也就是每行的元祖不能又“内含”多个“小组”。
②不存在组合属性，也就是每个属性是单一的，明确的，不能属性里面又包含“小属性”。
1NF是很常见的，也是很容易设计的，只要保证每行每列都是单一的，不重复的即可。
第二范式（2NF）：
若R中每个非属性组都完全依赖于R的任一候选码，且R∈1NF，则称为第二范式，R∈2NF。
根据定义，若判断某关系R是否为2NF，首先看是否存在非主属性对候选码的部分函数依赖，一旦存在，则不是2NF。那么如果不是2NF，应该如何分解使其满足2NF呢？
可以利用投影运算将其分解成三个关系（设候选码为XY)，第一个是只依赖于X的子模式，第二个是只依赖于Y的子模式，第三个是完全函数依赖于XY的子模式。
由于2NF仅仅是消除了非主属性对候选码的部分函数依赖，还是存在一些问题的。
①数据冗余②修改复杂③插入删除异常。
之所以存在这些问题，因为2NF没有消除非主属性对候选码的传递函数依赖！因此需要继续分解……这就引入了下面的第三范式。
第三范式（3NF）：
若关系R的任何一个非主属性都不传递函数依赖于任一候选码，则R∈3NF。
上述定义只是说明3NF中不存在非主属性间的函数依赖，但是不代表主属性间不存在函数依赖，也就是3NF中主属性间可能存在函数依赖。
还有一个性质，那就是3NF必然是2NF。
要判别一个关系R是否为3NF，那么可以进行一下步骤：
①找出候选码和非主属性
②看看是否存在非主属性对候选码的部分函数依赖，若存在，说明不是2NF，也就不会是3NF，否则进行下一步。
③判断非主属性间是否存在函数依赖，若不存在，则是3NF。
这么看来，经过上述2NF和3NF规范化后，似乎已经很“彻底”了，不过我们发现第二和第三范式只是将非主属性对候选码部分函数依赖和传递函数依赖消除了，还未消除主属性本身对候选码的部分函数依赖或者传递函数依赖，所以后来就有人提出了3NF的改进形式：BCNF。
……未完待续……

文章目录
求关系模式最高达到第几范式的步骤
通俗理解1NF,2NF,3NF.
如何求关系模式的候选码
如何求闭包
函数依赖

求关系模式最高达到第几范式的步骤

根据给定的U和F,首先求它的候选码
根据候选码判断关系F中的函数关系是否满足第二范式,若不满足则为关系模式的规范化最高为第一范式
然后判断是否存在非主属性传递依赖,如果存在则不满足第二范式,如果不存在则关系模式的规范化最高为第三范式.

通俗理解1NF,2NF,3NF.


1NF的定义:
 一个关系模式R的所有属性都是不可分的基本数据项.

1NF容易理解就不多解释了,在这里举两道简单的题帮助理解.

规范化的关系模式中，所有属性都必须是( C)。

A.相互关联的

B.互不关联的

C.不可分解的

D长度可变的
关系数据库中的每个关系必须最低到达__第一范式__,且该范式中的每个属性都是__不可再分__的。



2NF的定义:
 在1NF的基础上,关系中每一个非主属性完全函数依赖于码. 
 所以满足第二范式则一定满足第一范式.
 对这个非主属性完全函数依赖于码不清楚可以看最后**函数依赖中的图**来理解.



3NF的定义:
 在满足2NF的基础上,满足每个非主属性既不部分依赖于码也不传递依赖于码.
满足3NF的同时一定满足2NF.



如何求关系模式的候选码

首先对于给定的R(U)和函数依赖集F,可以将它的属性化分为4类:
L类:仅出现在F的函数依赖左部的属性.
R类:仅出现在F的函数依赖右部的属性.
N类:在F的函数依赖左部和右部未出现的属性.
LR类:在F的函数依赖左部和右部均出现那的属性.

下图的题中:A->C

C->A

B->AC

D->AC

L:找出这些式子中只在箭头左边的

R:找出式子在只出现在箭头右边的

N:找出所有的R中既没有出现箭头在左边又没有出现在箭头右边的

LR:找出既出现在箭头左边又出现在箭头右边的

如下图所示.
那么求出这些L,R,N,LR类后我们根据三个定理来确定候选码的成员:

定理1:对于给定的关系模式R以及其函数依赖集F,若X(x∈R)是L类,则X必为R的任一候选码的成员.
定理2:对于给定的关系模式R以及其函数依赖集F,若X(x∈R)是R类,则X不在任何候选码中.
定理3:设有关系模式R以及函数依赖集F,如果X是R的N类属性,则X必包含在R的任一候选码中.
推论2:如果X是R的N类和L类组成的属性集,且X+包含了所有的属性,则X是R的唯一候选码.

简单的来说就是对于在 L和N类中的都是候选码的成员:



确定了候选码的成员后如何确定最后的候选码呢?我们看到上面有这个B+或者(BD)+这在求B的闭包,下面我们来了解以下如何求闭包吧.
如何求闭包
闭包就是由一个属性直接或间接推导出所有属性的集合.引用: http://blog.sina.com.cn/s/blog_7f6c91720101jkhm.html.了解了闭包的概念后我们要学会如何求闭包,

步骤如下:





当我们求出所由候选码成员的闭包后,我们根据上面的推论2,

推论2:如果X是R的N类和L类组成的属性集,且X+包含了所有的属性,则X是R的唯一候选码.

假设上图中BC为候选码的成员,求到的(BC)+的闭包为ABCE;

而U={A,B,C,D,E},并没有全部包含所有属性,所以它不是关系模式R的码.

F={A->E,AC->B,B->A,D->A,D->C}

下面我来求一下D的闭包(D)f+

根据D->A,D->c将A,C 目前(D)+=ACD;

(ACD)={A,C,D,AD,AC,CD}

A->E   AC->B   变成(D)f+=(ABCDE)
(D)f+包含了R中的所有属性,所以D为R的码.
函数依赖
求出码后我们就根据2NF,3NF中的函数依赖来判断关系模式的规范化最高为?

1.这个中AB为候选码,但是存在非主属性依赖于B,不满足所有非主属性完全依赖于码.
2.再看一道题



最后总结两个常考的知识点

在一个关系R中，若X→Y，并且X的任何真子集都不能函数决定Y，则称X→Y为___完全___函数依赖
若X→Y，并且X的一个真子集也能够函数决定Y，则称X→Y为___部分___函数依赖。
一个关系模式R中的候选码可能有多个.