1.3关系的完整性规则 课件(共19张PPT)-《网站数据库应用技术-SQL Server》同步教学(北京理工大学出版社)

资源下载
  1. 二一教育资源

1.3关系的完整性规则 课件(共19张PPT)-《网站数据库应用技术-SQL Server》同步教学(北京理工大学出版社)

资源简介

(共19张PPT)
数据库原理与应用
学习情境1:数据库系统分析
五、关系的完整性规则
关系的完整性规则也可称为关系的约束条件,它是对关系的一些限制和规定。通过这些限制保证数据库中的数据合理、正确和一致。关系的完整性规则包括实体完整性、参照完整性和域完整性三个方面。
1.5.1 域完整性
1.5.2 实体完整性
1.5.3 参照完整性
1.5.1 域完整性
由用户根据实际情况,对数据库中数据的内容所作的规定称为域完整性规则,也称用户定义完整性规则。通过这些规则限制数据库只接受符合完整性约束条件的数据值,不接受违反约束条件的数据,从而保证数据库的数据合理可靠。
例如,表中的性别数据只能是男和女。对年龄数据也应该有一定的限制,不能是任意值。
1.5.2 实体完整性
这条规则要求,在任何关系的任何一个元组中,主关键字的值不能为空值。
这条规定的现实意义是,关系模型对应的是现实世界的数据实体,而关键字是实体惟一性的表现,没有关键字就没有实体,所有关键字不能是空值。这是实体存在的最基本的前提,所以称之为实体完整性。
1.5.3 参照完整性
参照完整性规则也可称为引用完整性规则,这条规则是对关系外部关键字的规定,要求外部关键字取值必须是客观存在的,即不允许在一个关系中引用另一个关系里不存在的元组。
例如,前面给出的学生表和系表中,系编号是学生表外部关键字,系编号是系表的主关键字。根据参照完整性规则,要求学生表系编号的取值可以是以下两种情况:
1)取空值。表明该学生还未被分配到任何系。例如,某位学生还没有确定在哪个系,则该学生元组的系编号处可空着不写,待以后填写。注意,空值不是0或空格。
2)若取非空值,则它必须是系表中系编号存在的值,即学生表系编号的值必须和系表系编号的值保持一致,因为一个学生不能属于一个不存在的系。
1-6 关系的归范化
在关系数据库中,对于同一个问题,选用不同关系模式集合作为数据库模式,其性能的优劣是大不相同的,某些数据库模式设计常常带来存储异常,这是不利于实际应用的。为了区分数据库模式的优劣,人们常常把数据库模式分为各种不同等级的范式(Normal Form)。
在关系规范化中,通常将关系分为5个级别,即5种范式。满足最低条件的称为第一范式,简称1NF。1NF是关系模式应满足的最起码的条件。在第一范式的基础上进一步满足一些要求的可升级为第二范式,其余依次类推。通常,若关系R是第X范式就写成R XNF。
1.6.1 第一范式(1NF)
设R是一个关系模式,如果R中的每个属性都是不可分解的,则称R是第一范式,记为R 1NF。
第一范式要求不能表中套表,它是关系模式最基本的要求,数据库模式中的所有关系模式必须是第一范式。关于第一范式这个问题,在前面曾经给过一个例子,这里再给出如图所示的选课关系SC1,以此说明非第一范式的弊病。
该选课关系SCl不是1NF,因为其课程名中包含了若干门课程,是可以分解为若干单门课程的。对于这样的关系模式,如果要修改某个学生的选课情况,就要涉及到该学生原来的所有课程名,这是很不方便的。为了避免这样的问题,可以将选课关系SCl的课程名属性拆开,形成如图所示的SC2关系形式,显然,SC2 1NF。
1.6.2 第二范式(2NF)
如果关系模式R是第一范式,且每个非码属性都完全依赖于码属性,则称R是第二范式,记为R 2NF。
部分函数依赖关系是造成插入异常的原因。在第二范式中,不存在非码属性之间的部分函数依赖关系,即消除了部分函数依赖关系,因此第二范式解决了插入异常问题。
例如,关系模式SCD(学号,姓名,课程名,成绩,系名,系主任),它不是第二范式,因为该关系模式的主关键字是学号和课程名,对于非码属性姓名和系名来说,它们只依赖于学号,而与课程名无关,即该关系模式存在着数据冗余、更新异常、插入异常和删除异常等存储问题。
解决的办法是将非第二范式的关系模式分解出若干个第二范式关系模式。分解的方法是:
1)把关系模式中对码完全函数依赖的非主属性与决定它们的码放在一个关系模式中。
2)把对码部分函数依赖的非主属性和决定它们的主属性放在一个关系模式中。
3)检查分解后的新模式,如果仍不是2NF,则继续按照前面的方法进行分解,直到达到要求。
l.6.3 第三范式(3NF)
如果关系模式R是第二范式,且没有一个非码属性传递依赖于码,则称R是第三范式,记为R 3NF。
传递函数依赖关系是造成删除异常的原因。第三范式消除了传递函数依赖部分,因此解决了数据的删除异常问题。
例如,关系模式SD(学号,姓名,系名,系主任)是上例的分解结果,它仍然存在问题。该关系模式中存在着学号→系名,系名→系主任,即系主任传递依赖于学号,因此关系模式SD不是第三范式,它存在着删除异常问题。解决的办法就是消除其中的传递依赖,将关系模式SD进一步分解为若干个独立的第三范式模式。
分解的方法是:
①把直接对码函数依赖的非主属性与决定它们的码放在一个关系模式中。
②把造成传递函数依赖的决定因素连同被它们决定的属性放在一个关系模式中。
③检查分解后的新模式,如果不是3NF,则继续按照前面的方法进行分解,直到达到要求。
对于关系模式SD来说,姓名直接依赖主属性学号,可将它们放在一个关系模式中。系名决定系主任,系名是造成传递函数依赖的决定因素,将它们放在另一个关系模式中。得到的分解结果如下:
学生关系模式:S(学号,姓名,系名)
系关系模式: D(系名,系主任)
可以看出,S和D关系模式各自描述单一的现实事物,都不存在传递依赖关系,它们都是第三范式。
一个关系模式达到3NF,基本解决了“异常”问题,但还不能彻底解决数据冗余问题。因为3NF不能很好地处理模型中含有多个候选关键字和候选关键字是组合项的情况,因此需要更强的范式。
小结
本章从数据库设计人员的角度,介绍了关系数据库的基本原理。作为设计人员,首先必须正确理解客户需求,明确实体、属性和联系的基本情况,画出E-R图。E-R图是描述用户需求的概念模型,在此基础上必须将其转化为数据模型。目前,使用最为广泛的是关系型数据模型。在将E—R图转化为关系表时,必须正确标识出各种表的主码或外码,明确表与表之间的相互关系。

展开更多......

收起↑

资源预览