第五章 数据库完整性

第五章 数据库完整性

• 数据库的完整性

  • 指数据的正确性和相容性
  • 正确性
    • 指数据是符合现实世界语义，反映了当前实际状况的
  • 相容性
    • 指数据库同一对象在不同关系表中的数据是符合逻辑的
  • 防止数据库中存在不符合语义的数据，也就是防止数据库存在不正确的数据
    • 防范对象
      • 不合语义的，不正确的数据

• 数据的安全性

  • 保护数据库防止恶意的破坏和非法的存取
    • 防范对象
      • 非法用户和非法操作

• 数据库在完整性方面应具备的功能

  • 提供定义完整性约束条件的机制
  • 提供完整性检查的方法

• 违约处理

5.1 实体完整性

5.1.1 定义实体完整性

• 关系模型的实体完整性
  • 设置主码，让每条记录是相互可区分的，SQL中在CREATE,TABLE中用PRIMARY KEY定义。
• 主码是单属性构成的有两种说明方法
  • 定义为列级约束条件
  • 定义为表级约束条件
• 主码是多属性的只能有一种说明方法
  • 定义为表级约束条件

5.1.2 实体完整性检查和违约处理

• 完整性检查的内容

  关系数据库管理系统按照实体完整性规则自动进行检查。检查内容主要包括：

  • 检查主码值是否唯一，如果不唯一则拒绝插入或修改。
  • 检查主码的各个属性是否为空，只要有一个为空就拒绝插入或修改。

5.2 参照完整性

5.2.1 定义参照完整性

• 参照完整性定义
  • 在CREATE TABLE中用FOREIGN KEY短语定义哪些列为外码，用REFERENCES短语指明这些外码参照哪些表的主码。

5.2.2 参照完整性检查和违约处理

一个参照完整性将两个表中的相应元组联系起来，对被参照表和参照表进行增删改操作时都有可能破坏参照完整性，必须进行完整性检查

• 参照完整性违约处理规则
  • 拒绝（NOACTION）执行
    • 不允许该操作执行。该策略一般设置为默认策略。
  • 级联（CASCADE）操作
    • 当删除或修改被参照表（Student）的一个元组导致与参照表（SC)的不一致时，删除或修改参照表中的所有导致不一致的元组。
  • 设置为空
    • 值当删除或修改被参照表的一个元组时造成了不一致，则将参照表中的所有造成不一致的元组的对应属性设置为空值。

5.3 用户定义的完整性

​ 用户定义的完整性就是针对某一具体应用的数据必须满足的语义要求。目前的关系数据库管理系统都提供了定义和检验这类完整性的机制，使用了和实体完整性、参照完整性相同的技术和方法来处理它们，而不必由应用程序承担这一功能。

5.3.1属性上的约束条件

1. 属性上约束条件的定义

   在CREATE TABLE中定义属性的同时，可以根据应用要求定义属性上的约束条件，即属性值限制，包括：

   • 列值非空（NOTNULL）。
   • 列值唯一（UNIQUE）。
   • 检查列值是否满足一个条件表达式（CHECK短语）。

2. 属性上约束条件的检查和违约处理

   当往表中插入元组或修改属性的值时，关系数据库管理系统将检查属性上的约束条件是否被满足，如果不满足则操作被拒绝执行。

5.3.2 元组上的约束条件

1. 元组上约束条件的定义

   • 在CREATETABLE语句中可以用CHECK短语定义元组上的约束条件，即元组级的限制。
   • 同属性值限制相比，元组级的限制可以设置不同属性之间的取值的相互约束条件。

2. 元组上约束条件的检查和违约处理

   当往表中插入元组或修改属性的值时，关系数据库管理系统将检查元组上的约束条件是否被满足，如果不满足则操作被拒绝执行。

5.4 完整性约束命名子句

• 完整性约束命名子句

  CONSTRAINT<完整性约束条件名>

  <完整性约束条件><完整性约束条件>包括NOT NULL、UNIQUE、PRIMARY KEY、FOREIGN KEY、CHECK短语等。

• 修改表中的完整性限制

  使用ALTER TABLE语句修改表中的完整性限制

5.5 域中的完整性限制

域是一组具有相同数据类型的值的集合，即属性的取值范围。SQL可以用CREATE DOMAIN语句建立一个域以及域应该满足的完整性约束条件，然后用域定义属性。

5.6 断言

1. 创建断言的语句格式

   CREATE ASSERTION<断言名>

   每个断言都被赋予一个名字，中的约束条件与WHERE子句的条件表达式类似。

2. 删除断言的语句格式

   DROP ASSERTION<断言名>；

   如果断言很复杂，则系统在检测和维护断言上的开销较高，这是在使用断言时应该注意的。

5.7 触发器

触发器(trigger）是用户定义在关系表上的一类由事件驱动的特殊过程。

• 说明
  • 触发器保存在数据库服务器中。
  • 任何用户对表的增、删、改操作均由服务器自动激活相应的触发器。
  • 触发器可以实施更为复杂的检查和操作，具有更精细和更强大的数据控制能力。

5.7. 1 定义触发器

触发器又叫做事件一条件-动作（event-condition-action）规则。

• 语句格式

  CREATE TRIGGER<触发器名>
  /*每当触发事件发生时，该触发器被激活*/
  (BEFORE|AFTER}<触发事件>ON<表名>
  /*指明触发器激活的时间是在执行触发事件前或后*/
  /*REFERENCING指出引用的变量*/
  REFERENCING NEWOLD ROW AS<变量>
  /*定义触发器的类型，指明动作体执行的频率*/
  FOR EACH(ROW|STATEMENT)
  [WHEN<触发条件>]<触发动作体>
  /*仅当触发条件为真时才执行触发动作体*/
  
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11

• 语法说明

  • 只有表的拥有者，即创建表的用户才可以在表上创建触发器，并且一个表上只能创建一定数量的触发器。

  • 触发器名

    • 触发器名可以包含模式名，也可以不包含模式名。同一模式下，触发器名必须是唯一的，并且触发器名和表名必须在同一模式下。

  • 表名

    • 触发器只能定义在基本表上，不能定义在视图上。当基本表的数据发生变化时，将激活定义在该表上相应触发事件的触发器，因此该表也称为触发器的目标表。

  • 触发事件

    • INSERT、DELETE或UPDATE也可以是这几个事件的组合。

    • UPDATE OF<触发列，…>，即进一步指明修改哪些列时激活触发器

    • AFTER/BEFORE是触发的时机。

      AFTER表示在触发事件的操作执行之后激活触发器。

      BEFORE表示在触发事件的操作执行之前激活触发器。

  • 触发器类型

    • 行级触发器（FOR EACH ROW）和语句级触发器（FOR EACHSTATEMENT)

  • 触发条件

    • 触发器被激活时，只有当触发条件为真时触发动作体才执行，否则触发动作体不执行。如果省略WHEN触发条件，则触发动作体在触发器激活后立即执行。

  • 触发动作体

    • 触发动作体可以是一个匿名PL/SQL过程块，也可以是对已创建存储过程的调用。
    • 如果是行级触发器，用户都可以在过程体中使用NEW和OLD引用事件之后的新值和事件之前的旧值。
    • 如果是语句级触发器，则不能在触发动作体中使用NEW或OLD进行引用。
    • 如果触发动作体执行失败，激活触发器的事件就会终止执行，触发器的目标表或触发器可能影响的其他对象不发生任何变化。
    • 注意：不同的RDBMS产品触发器语法各部相同。

5.7.2 激活触发器

触发器的执行，是由触发事件激活的，并由数据库服务器自动执行。一个数据表上可能定义了多个触发器，遵循如下的执行顺序；

1. 执行该表上的BEFORE触发器；
2. 激活触发器的SQL语句；
3. 执行该表上的AFTER触发器。

5.7.3 删除触发器

删除触发器的SQL语法如下：

DROP TRIGGER<触发器名>ON<表名>；
1

触发器必须是一个已经创建的触发器，并且只能由具有相应权限的用户删除。