关系模式的规范化

原文路径: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不可。有时候故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高,查询频率极高的数据库系统更是如此。在关系数据库中,除了函数依赖之外还有多值依赖,联接依赖的问题,从而提出了第四范式,第五范式等更高一级的规范化要求。

 

 

 

 

 

 

 

 

 

 

  • 45
    点赞
  • 121
    收藏
    觉得还不错? 一键收藏
  • 7
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 7
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值