数据库原理与应用第3章 数据库设计_2版.ppt

封锁协议 有了两种基本封锁，还需要什么约定？ 封锁协议的概念 何时申请加锁、持锁时间、何时释放等规则。 不同的封锁协议所达到的系统一致性不同。 三个级别的封锁协议 一级封锁协议 内容：事务T在修改数据R之前必须先对其加X 锁，直至事务结束。 评价：是否可解决 丢失修改？ 可重复读？ 读脏数据？ 可防止 × 不能保证 × 不能防止 三个级别的封锁协议 二级封锁协议 内容： 读数据前加S锁，读完即释放 写数据前加X 锁直至事务结束 评价：是否可解决 丢失修改？ 可重复读？ 读脏数据？ 可防止 × 不能保证 可防止 三个级别的封锁协议 三级封锁协议 内容： 读数据前加S锁直至事务结束 写数据前加X 锁直至事务结束 评价：是否可解决 丢失修改？ 可重复读？ 读脏数据？ 可防止 能保证 可保证 3. 死锁与死锁解决方案 采用封锁的方法固然可以有效地防止数据的不一致性，但封锁本身会引起一些麻烦，即死锁和活锁的问题，其中最主要的就是死锁问题。 活锁：如果事务T1封锁了数据对象R后，事务T2页请求封锁R，于是T2等待。接着T3也请求封锁R。当T1释放了加在R上的锁后，系统首先批准了T3的请求，T2只得继续等待。接着T4也请求封锁R，T3释放R上的锁后，系统又批准了T4的请求，…，因此，事务T2就有可能这样永远地等待下去，以上这种情况就称为活锁。 避免活锁的简单办法是采用先来先服务的策略。当多个事务请求封锁同一数据对象时，封锁子系统按封锁请求的先后次序对这些事务排队，该数据对象上的锁一旦释放，首先批准申请队列中的第一个事务获得锁。 3. 死锁与死锁解决方案 死锁：在事务和锁的使用过程中，死锁是一个不可避免的现象。如当两个事务分别锁定了两个单独的对象，这时每一个事务都要求在另外一个事务锁定的对象上获得一个锁，因此每一个事务都必须等待另外一个事务释放占有的锁，这时，就发生了死锁。这种死锁是最典型的死锁形式。如下图所示。 3.4 完整性设计 3.4.1 完整性约束 1．实体完整性（Entity Integrity）规则：若属性A是基本关系R的主属性，则属性A不能取空值。 对于实体完整性规则说明如下： 实体完整性规则能够保证实体的唯一性。实体完整性规则是针对基本表而言的。一个基本表通常对应现实世界的一个实体集，而现实世界中的一个实体是可区分的，即它们具有某种唯一性标识。相应地，关系模型中以主码作为唯一性标识。 实体完整性规则能够保证实体的可区分性。主码中的属性即主属性不能取空值，所谓空值就是“无意义”的值，用“NULL”表示。如果主属性取空值，就说明存在某个不可标识的实体，即存在不可区分的实体，这不符合现实世界的情况。 3.4.1 完整性约束 2.参照完整性（Referential Integrity）规则：若属性(或属性组)F是基本关系R的外码，它与基本关系S的主码相对应，则对于R中每个元组在F上的值必须为：或者取空值(F的每个属性值均为空值)，或者等于S中某个元组的主码值。 例：学生实体和选修实体可以用下面的关系表示，其中主码用下划线标识。 学生（学号，姓名，性别，所在系，班号，出生日期） 选修（学号，课程号，成绩） 这两个关系之间存在着属性的引用，即选修关系引用了学生关系的主码“学号”。显然，选修关系中的“学号”值必须是确实存在的某个学生的学号，即选修关系中的“学号”属性的取值需要参照学生关系的“学号”属性取值。 对于上例，按照参照完整性规则，选修关系中每个元组的“学号”属性只能取两种值，空值或学生关系中某个元组的“学号”值。但由于此例中，“学号”属性不仅是选修关系的外码，同时又是该表的主属性，因此不允许取空值，即只能够取学生关系中某个元组的“学号”值。 3．用户定义的完整性 任何关系数据库系统都应该支持实体完整性和参照完整性。除此之外，不同的关系数据库系统根据其应用环境的不同，往往还需要一些特殊的约束条件，用户定义的完整性就是针对某一具体数据库系统的约束条件。 用户定义的完整性约束反映某一具体应用所涉及的数据必须满足的语义要求。如某个属性必须取唯一值、某些属性值之间应满足一定的函数关系、某个属性的取值范围等。关系模型应提供定义和检验这类完整性的机制，以便于使用统一的、系统的方法处理它们，而不要由应用程序承担这一功能。 3.4.1 完整性约束 3.4.2 完整性设计中应注意的问题 1. 修改关系中主码的问题：当用户欲修改关系中某个元组的主码值时，由于可能存在参照与被参照的问题，系统如何处理就是因主码修改而产生问题。这个问题一般有以下两种处理策略： 不允许修改主码：不允许用户修改关系中任何元组的主码值，如果需要修改某个元组的主码值，必须先删除该元组，然后再把具有新主码值的元组插入到关系中。 允许修改主码：允许用