关于表的规范化.docx

关于表的规范化.docx

《关于表的规范化.docx》由会员分享，可在线阅读，更多相关《关于表的规范化.docx（7页珍藏版）》请在冰豆网上搜索。

关于表的规范化

资料范本

本资料为word版本，可以直接编辑和打印，感谢您的下载

关于表的规范化

地点：

__________________

时间：

__________________

说明：

本资料适用于约定双方经过谈判，协商而共同承认，共同遵守的责任与义务，仅供参考，文档可直接下载或修改，不需要的部分可直接删除，使用时请详细阅读内容

规范化：

满足第一范式是表的最低要求，不满足第一范式要求的数据库（表）就不能称之为关系数据库。

在此基础上满足更高要求的称为第二范式，简记为2NF，其余依此类推，还有第三范式（3NF）、BC范式（BCNF）、第四范式（4NF）、第五范式（5NF）。

BCNF可以看作是修正了的第三范式。

把表从低范式，通过投影运算转换成若干高一级范式的过程，叫做表的规范化。

一般地说，表满足的范式级别越高，设计的表越是规范，表的质量越高，数据的冗余度越小，共享性越高，所占的存储空间越少，并将数据的不一致性减少到最低程度，这也是对表进行规范化的目的。

但是，高范式的数据库查询起来比较复杂。

所以，不应一味追求高范式，一般满足第三范式或BC范式就可以了

二、表的规范化

1、第一范式（1NF）

如前所述，第一范式要求表的每一个字段都是不可再分的最小单位。

例1：

学生（学号，姓名，学院，地址，选修课程成绩（课程号，课程名，成绩））表数据如下：

表一不满足第一范式的表

显然，这样的表是不满足第一范式的。

因为[选修课程成绩]字段还可分为3个字段即（课程号，课程名，成绩）。

如果不把它进行规范化，即转换成满足第一范式的表，将会产生很多问题，如：

删除异常，即本来只想删除成绩的，不得不把课程号和课程名也删除了！

转换的方法就是把可以拆分的字段进行拆分，即把[选修课程成绩]分解成3个字段：

[课程号]，[课程名]，[成绩]。

变成下面满足第一范式的表：

表二 满足第一范式的表

2、第二范式（2NF）

一个关系应满足1NF是最起码的条件。

但是，仅满足1NF的关系还可能存在一些问题。

例2：

表二中存在以下的问题：

l      问题1：

数据冗余度大。

张丽选几门课程，都必须输入所有几个她的相关信息，同时，如果有几千个人选修高等数学课，就得输入几千个“高等数学”。

如果要修改“高等数学”这个课程名称，对于几千个课程名中，只要漏改一个，将造成数据的不一致性。

l      问题2：

删除异常。

我们知道，这个表中的关键字为学号和课程号，它们不能为空值，而当李锋退学时，不可能只删除李锋的学号和姓名，只能删除了李锋的整条记录，这时相应的课程号为C004的法律也被删除，如果这个表中只有李锋一人选法律课，该记录删除后，下次将无法查询法律课的课程号。

l      问题3：

插入记录异常。

与删除异常相似，如果李锋刚入学，还没有选修任何一门课程，无法知道他选修的课程号，而课程号为关键字，不能为空，因此，李锋这个记录也不能输入。

造成出现这些问题的原因是因为这个表不满足第二范式。

l      如何判断一个表是否满足第二范式呢，判断方法是：

（1）、找出表的关键字。

（2）、如果只有一个关键字，若每一个非关键字都依赖于这个关键字，则表满足第二范式，否则不是。

什么是依赖（关系）呢？

例：

某表中有两个字段：

学号、姓名，对于每一个学号，只有一个姓名与之对应，则称姓名依赖于学号，或称学号唯一确定姓名，记作：

学号→姓名。

例3：

学生（学号，姓名，学院）表是否满足第二范式？

答：

满足。

因为，这个表中只有一个关键字即学号，而其他字段（即非关键字）都依赖于学号，也就是说每一个学号只有一个姓名，一个学院与之对应。

例4：

学生（学号，姓名，学院，成绩）表是否满足第二范式？

答：

不满足。

因为，一个学生可能不只选一门课程，不止一个成绩，也就是说每一个学号不只有一个成绩与之对应，或者说，有一个非关键字段（即成绩）不依赖于学号。

（3）、如果有两个或两个以上的关键字，那么，把这些关键字看成是一个组合关键字，若每一个非关键字都能完全依赖于组合关键字，则表满足第二范式，否则不是。

例5：

成绩（学号，课程，成绩）表是否满足第二范式？

满足。

因为，非关键字（成绩）完全依赖于组合关键字（学号+课程），即只有一个成绩与（学号+课程）对应，或者说，一个学生选修一门课程，就只能有一个成绩。

称为部分依赖。

l      定义：

如果一个表满足1NF，且每一个非关键字都完全依赖于关键字，则这个表满足第二范式。

l      第一范式转换成第二范式的方法：

找出依赖关系，将能完全依赖于主键的字段从表中提取出来，同主键一起组成一个新的关系。

例7：

表二（学号，姓名，学院，地址，课程号，课程名，成绩）的依赖关系如下：

显然，不满足2NF。

院、地址）绩）

转换的过程就是拆分的过程，也是一个消除部分依赖的过程。

但是，要注意，拆分的结果应该包含原表的所有字段！

！

（即无损分解）

3、第三范式（3NF）

通过分析，发现表A仍然在一定程度上存在上面提及的三个问题，要消除和减少它们，还得把它分解成满足更高范式（即3NF）的表.

l      满足第三范式的判断方法：

判断表在满足第二范式的基础上是否有传递依赖的情况，如果有，不是第三范式，否则是。

l      将非第三范式规范为第三范式的方法：

把产生传递依赖关系的非关键字段抽出来，同关键字一起建立新的表。

例8：

表A（学号，姓名，学院，地址）中，存在地址传递依赖于学号的关系，即：

学号→学院，学院→地址。

把地址从原表中分出来，同关键字一起建立新的表形成表A1（学院、地址）,原表就可消除了传递依赖关系。

表A分解为：

表A1（学院、地址）

表A2（学号、姓名、学院）

小结：

表的规范化中，1NF是要满足每个字段都是不可再分的；2NF是在1NF的基础上消除部分依赖关系（只保留完全依赖），3NF是在2NF的基础上进一步消除传递依赖关系。

二：

在设计和操作维护数据库时，关键的步骤就是要确保数据正确地分布到数据库的表中。

使用正确的数据结构，不仅便于对数据库进行相应的存取操作，而且可以极大地简化应用程序的其他内容（查询、窗体、报表、代码等）。

正确进行表设计的正式名称就是"数据库规范化"。

数据冗余

数据应该尽可能少地冗余，这意味着重复数据应该减少到最少。

比如说，一个部门雇员的电话不应该被存储在不同的表中，因为这里的电话号码是雇员的一个属性。

如果存在过多的冗余数据，这就意味着要占用了更多的物理空间，同时也对数据的维护和一致性检查带来了问题，当这个员工的电话号码变化时，冗余数据会导致对多个表的更新动作，如果有一个表不幸被忽略了，那么就可能导致数据的不一致性。

规范化实例

为了说明方便，我们在本文中将使用一个SAMPLE数据表，来一步一步分析规范化的过程。

首先，我们先来生成一个的最初始的表。

表1-1

考察表1-1，我们可以看到，这张表一共有六个字段，分析每个字段都有重复的值出现，也就是说，存在数据冗余问题。

这将潜在地造成数据操作（比如删除、更新等操作）时的异常情况，因此，需要进行规范化。

第一范式

参照范式的定义，考察上表，我们发现，这张表已经满足了第一范式的要求。

（1NF:

字段具有原子性，不可再分；

比如说籍贯这个字段，里面是“湖北武汉”的话，它就违反了原子性，因为湖北武汉还可以再分的更具体，分为“湖北”和“武汉”

）

1、因为这张表中字段都是单一属性的，不可再分；

2、而且每一行的记录都是没有重复的；

3、存在主属性，而且所有的属性都是依赖于主属性；

4、所有的主属性都已经定义

事实上在当前所有的关系数据库管理系统（DBMS）中，都已经在建表的时候强制满足第一范式。

因此，这张SAMPLE表已经是一张满足第一范式要求的表。

考察表1-1，我们首先要找出主键。

可以看到，属性对是主键，其他所有的属性都依赖于该主键。

从一范式转化到二范式

根据第二范式的定义，转化为二范式就是消除部分依赖。

（2NF:

组合关键字的表，不存在组合关键字中的任意字段决定其它非关键字段（也就是说不能有两个组合键组成一个主键））

考察表1-1，我们可以发现，非主属性部分依赖于主键中的;非主属性，和都部分依赖于主键中的；

表1-1的形式，存在着以下潜在问题：

1．数据冗余：

每一个字段都有值重复；

2．更新异常：

比如字段的值，比如对值"TPMS"了修改，那么就要一次更新该字段的多个值；

3．插入异常：

如果新建了一个Project，名字为TPT,但是还没有Employee加入，那么将会空缺，而该字段是主键的一部分，因此将无法插入记录；

InsertintoSAMPLE（PRJNUM,PRJNAME,EMYNUM,EMYNAME,SALCATEGORY,SALPACKAGE）values（100003,'TPT',NULL,NULL,NULL,NULL）

4．删除异常：

如果一个员工200003,Kevin离职了，要将该员工的记录从表中删除，而此时相关的Salary信息C也将丢失,因为再没有别的行纪录下SalaryC的信息。

DeletefromsamplewhereEMYNUM=200003

SelectdistinctSALCATEGORY,SALPACKAGEfromSAMPLE

因此，我们需要将存在部分依赖关系的主属性和非主属性从满足第一范式的表中分离出来，形成一张新的表，而新表和旧表之间是一对多的关系。

由此，我们得到：

表1-2

表1-3

同时，我们把表1-1的主键，也就是表1-2和表1-3的各自的主键提取出来，单独形成一张表，来表明表1-2和表1-3之间的关联关系：

表1-4

这时候我们仔细观察一下表1-2,1-3,1-4,我们发现插入异常已经不存在了，当我们引入一个新的项目TPT的时候，我们只需要向表1-2中插入一条数据就可以了，当有新人加入项目TPT的时候，我们需要向表1-3,1-4中各插入一条数据就可以了。

虽然我们解决了一个大问题，但是仔细观察我们还是发现有问题存在。

从二范式转化到三范式

考察表前面生成的三张表，我们发现，表1-3存在传递依赖关系，即：

关键字段-->非关键字段-->非关键字段。

而这是不满足三范式的规则的，存在以下的不足：

1、数据冗余：

和的值有重复；

2、更新异常：

有重复的冗余信息，修改时需要同时修改多条记录，否则会出现数据不一致的情况；

3、删除异常：

同样的，如果员工200003Kevin离开了公司，会直接导致SalaryC的信息的丢失。

DeletefromEMPLOYEEwhereEMYNUM=200003

SelectdistinctSALCATEGORY,SALPACKAGEfromEMPLOYEE

因此，我们需要继续进行规范化的过程，把表1-3拆开，我们得到：

表1-5

和

表1-6

这时候如果200003Kevin离开公司，我们只需要从表1-5中删除他就可以了，存在于表1-6中的SalaryC信息并不会丢失。

但是我们要注意到除了表1-5中存在Kevin的信息之外，表1-4中也存在Kevin的信息，这很容易理解，因为Kevin参与了项目100001，TPMS，所以当然也要从中删除。

至此，我们将表1-1经过规范化步骤，得到四张表，满足了三范式的约束要求，数据冗余、更新异常、插入异常和删除异常。

在三范式之上，还存在着更为严格约束的BC范式和四范式，但是这两种形式在商业应用中很少用到，在绝大多数情况下，三范式已经满足了数据库表规范化的要求，有效地解决了数据冗余和维护操作的异常问题。

（3NF:

在2NF的基础上，数据表中如果不存在非关键字段对任一候选字段的传递函数依赖则符合第三范式（也就是说违反了数据冗余）

帐号身份证号姓名密码

1001410101001李梅100001

身份证号和姓名共同决定了密码，姓名是依赖于身份证号的，这样就违反了第三范式）

.第四范式（4NF）

（1）第四范式（4NF）的定义

在4.3.5中我们曾分析了关系CTB虽然属于BCNF，但还存在着数据冗余、插入异常和删除异常的弊端，究其原因就是CTB中存在非平凡的的多值依赖，而决定因素不是关键字。

因而必须将CTB继续分解，如果分解成两个关系模式CTB1（C，T）和CTB2（C，B），则它们的冗余度会明显下降。

从多值依赖的定义分析CTB1和CTB2，它们的属性间各有一个多值依赖C→→T，C→→B，都是平凡的多值依赖。

因此，含有多值依赖的关系模式中，减少数据冗余和操作异常的常用方法是将关系模式分解为仅有平凡的多值依赖的关系模式。

定义4.9设有一关系模式R（U），U是其属性全集，X、Y是U的子集，D是R上的数据依赖集。

如果对于任一多值依赖X→→Y，此多值依赖是平凡的，或者X包含了R的一个候选关键字，则称R是第四范式的关系模式，记为R∈4NF。

由此定义可知：

关系模式CTB分解后产生的CTB1（C，T）和CTB2（C，B）中，因为C→→T，C→→B均是平凡的多值依赖，所以CTB1和CTB2都是4NF。

经过上面的分析可以得知：

一个BCNF的关系模式不一定是4NF，而4NF的关系模式必定是BCNF的关系模式，即4NF是BCNF的推广。

（2）4NF的分解

把一个关系模式分解为4NF的方法与分解为BCNF的方法类似，就是把一个关系模式利用投影的方法消去非平凡且非函数依赖的多什依赖，并具有无损连接性。

[例7]设有关系模式R（A，B，C，E，F，G），数据依赖集D＝｛A→→BGC，B→AC，C→G｝，将分解为4NF。

解：

利用A→→BGC，可将R分解为的R的＝｛ABCG，AEF｝。

利用B→AC分解得：

R＝｛ABC，BG，AEF｝。

由此得到的三个关系模式（ABC）、（BG）和（AEF）都属于4NF，但此分解丢失了函数依赖C→G。

若最后一次分解利用函数依赖C→G来做，则R＝｛ABC，CG，AEF｝，由此得到的三个关系模式（ABC），（CG）和（AEF）都是属于4NF的关系模式，且保持了所有的数据依赖。

这说明，4NF的分解结果不是惟一的，结果与选择数据依赖的次序有关。

任何一个关系模式都可无损分解成一组等价的4NF关系模式，但这种分解不一定具有依赖保持性。

数据依赖和多值依赖是两种最重要的数据依赖。

如果只考虑函数依赖，则属于BCNF的关系模式的规范化程度已经是最高的了。

如果考虑多什依赖，则属于4NF的关系模式化程度是最高的。

事实上，数据依赖中除函数依赖和多什依赖之外，还有其他数据依赖。

函数依赖是多值依赖的一种特殊情况，而多值依赖实际上又是连接依赖的一种特殊情况。

但连接依赖不像函数依赖和多值依赖那样可由语义直接导出，而是在关系的连接运算时才反映出来。

存在连接依赖的关系模式仍可能遇到数据冗余及插入、修改、删除异常的问题。

如果消除了属于4NF的关系模式中存在的连接依赖，则可以进一步达到5NF的关系模式