数据库完整性

数据库的完整性是指数据的正确性和相容性。

数据的完整性和安全性是两个不同概念

  • 数据的完整性

    • 防止数据库中存在不符合语义的数据，也就是防止数据库中存在不正确的数据

    • 防范对象：不合语义的、不正确的数据

  • 数据的安全性

    • 保护数据库防止恶意的破坏和非法的存取

    • 防范对象：非法用户和非法操作

为维护数据库的完整性，DBMS必须：

  • 提供定义完整性约束条件的机制

  • 提供完整性检查的方法

  • 违约处理

实体完整性

定义实体完整性

  • 关系模型的实体完整性

    • CREATE TABLE中用PRIMARY KEY定义

  • 单属性构成的码有两种说明方法

    • 定义为列级约束条件

    • 定义为表级约束条件

  • 对多个属性构成的码只有一种说明方法

    • 定义为表级约束条件

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

插入或对主码列进行更新操作时，RDBMS按照实体完整性规则自动进行检查。包括：

  • 检查主码值是否唯一，如果不唯一则拒绝插入或修改

  • 检查主码的各个属性是否为空，只要有一个为空就拒绝插入或修改

参照完整性

定义参照完整性

关系模型的参照完整性定义

  • 在CREATE TABLE中用FOREIGN KEY短语定义哪些列为外码

  • 用REFERENCES短语指明这些外码参照哪些表的主码

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

可能破坏参照完整性的情况及违约处理

被参照表
参照表
违约处理

可能破坏参照完整性

插入元组

拒绝

可能破坏参照完整性

修改外码值

拒绝

删除元组

可能破坏参照完整性

拒绝/级联删除/设置为空值

修改主码值

可能破坏参照完整性

拒绝/级联删除/设置为空值

参照完整性违约处理

  1. 拒绝(NO ACTION)执行 默认策略

  2. 级联(CASCADE)操作

  3. 设置为空值（SET-NULL）

对于参照完整性，除了应该定义外码，还应定义外码列是否允许空值

用户定义的完整性

  • 用户定义的完整性就是针对某一具体应用的数据必须满足的语义要求

  • RDBMS提供，而不必由应用程序承担

属性上的约束条件

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

  • 列值非空（NOT NULL）

  • 列值唯一（UNIQUE）

  • 检查列值是否满足一个布尔表达式（CHECK）

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

元组上的约束条件

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

  • 在CREATE TABLE时可以用CHECK短语定义元组上的约束条件，即元组级的限制

  • 同属性值限制相比，元组级的限制可以设置不同属性之间的取值的相互约束条件

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

  • 插入元组或修改属性的值时，RDBMS检查元组上的约束条件是否被满足

  • 如果不满足则操作被拒绝执行

完整性约束命名子句

  1. 完整性约束命名子句

CONSTRAINT <完整性约束条件名><完整性约束条件>

<完整性约束条件>包括NOT NULL,UNIQUE,PRIMARY KEY,FOREIGN KEY,CHECK短语等。 2. 修改表中的完整性限制 可以使用ALTER TABLE语句修改表中的完整性约束。

域中的完整性限制

SQL支持域的概念，并可以用CREATE DOMAIN语句建立一个域以及该域应该满足的完整性约束条件。

断言

  • SQL中，可以使用 CREATE ASSERTION语句，通过声明性断言来指定更具一般性的约束。

  • 可以定义涉及多个表的或聚集操作的比较复杂的完整性约束。

  • 断言创建以后，任何对断言中所涉及的关系的操作都会触发关系数据库管理系统对断言的检查，任何使断言不为真值的操作都会被拒绝执行

  1. 创建断言的语句格式

  • CREATE ASSERTION<断言名><CHECK 子句>

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

  1. 删除断言的语句格式为

  • DROP ASSERTION <断言名>;

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

触发器

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

  • 触发器保存在数据库服务器中

  • 任何用户对表的增、删、改操作均由服务器自动激活相应的触发器

  • 触发器可以实施更为复杂的检查和操作，具有更精细和更强大的数据控制能力

定义触发器

CREATE TRIGGER <触发器名>              /*每当触发事件发生时，该触发器被激活*/ 
{BEFORE | AFTER} <触发事件> ON <表名>  /*指明触发器激活的时间是在执行触发事件前或后*/
REFERENCING NEW|OLD ROW AS<变量>       /*REFERENCING指出引用的变量*/
FOR EACH {ROW | STATEMENT}             /*定义触发器的类型，指明动作体执行的频率*/
[WHEN <触发条件>]<触发动作体>          /*仅当触发条件为真时才执行触发动作体*/

触发器又叫做事件-条件-动作（event-condition-action）规则。当特定的系统事件发生时，对规则的条件进行检查，如果条件成立则执行规则中的动作，否则不执行该动作。规则中的动作体可以很复杂，通常是一段SQL存储过程。 定义触发器的语法说明

  1. 表的拥有者才可以在表上创建触发器

  2. 触发器名

  • 触发器名可以包含模式名，也可以不包含模式名

  • 同一模式下，触发器名必须是唯一的

  • 触发器名和表名必须在同一模式下

  1. 表名

  • 触发器只能定义在基本表上，不能定义在视图上

  • 当基本表的数据发生变化时，将激活定义在该表上相应触发事件的触发器

  1. 触发事件

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

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

  • AFTER/BEFORE是触发的时机 AFTER表示在触发事件的操作执行之后激活触发器 BEFORE表示在触发事件的操作执行之前激活触发器

  1. 触发器类型

  • 行级触发器（FOR EACH ROW）

  • 语句级触发器（FOR EACH STATEMENT）

  1. 触发条件

  • 触发器被激活时，只有当触发条件为真时触发动作体才执行；否则触发动作体不执行。

  • 如果省略WHEN触发条件，则触发动作体在触发器激活后立即执行。

  1. 触发动作体

  • 触发动作体可以是一个匿名PL/SQL过程块 也可以是对已创建存储过程的调用

  • 如果是行级触发器，用户都可以在过程体中使用NEW和OLD引用事件之后的新值和事件之前的旧值

  • 如果是语句级触发器，则不能在触发动作体中使用NEW或OLD进行引用

  • 如果触发动作体执行失败，激活触发器的事件就会终止执行，触发器的目标表或触发器可能影响的其他对象不发生任何变化

激活触发器

  • 触发器的执行，是由触发事件激活的，并由数据库服务器自动执行

  • 一个数据表上可能定义了多个触发器，遵循如下的执行顺序: （1） 执行该表上的BEFORE触发器; （2） 激活触发器的SQL语句; （3） 执行该表上的AFTER触发器。

删除触发器

删除触发器的SQL语法： DROP TRIGGER <触发器名> ON <表名>; 触发器必须是一个已经创建的触发器，并且只能由具有相应权限的用户删除。

《数据库系统概论（第5版）》王珊 萨师煊 著

Previous数据库安全性Next数据库恢复技术

Last updated