数据库的完整性是指数据的正确性和相容性。数据的正确性是指数据是符合现实世界语义、反映当前实际状况的；数据的相容性是指数据库同一对象在不同关系表中的数据是符合逻辑的。
数据的完整性是为了防止数据库中存在不符合语义的数据，也就是防止数据库中存在不正确的数据。数据的安全性是保护数据库防止恶意破坏和非法存取。
为维护数据库的完整性，数据库管理系统必须能够实现如下功能。
提供定义完整性约束条件的机制
提供完整性检查的方法
进行违约处理
关系数据库管理系统使得完整性控制成为其核心支持的功能，从而能够为所有用户和应用提供一致的数据库完整性。
实体完整性
①进程控制
关系模型的实体完整性在CREATE TABLE中用PRIMARY KEY定义。对单属性构成的码有两种说明方法，一种是定义为列级约束条件，另一种是定义为表级约束条件。对多个属性构成的码只有一种说明方法，即定义为表级约束条件。
②实体完整性检查和违约处理
用PRIMARY KEY短语定义了关系的主码后，，每当用户程序对基本表插入一条记录或对主码列进行更新操作时，关系数据库管理系统将按照实体完整性规则自动进行检查。包括：
检查主码值是否唯一，如果不唯一则拒绝插入或修改。
检查主码的各个属性是否为空，只要有一个为空就拒绝插入或修改。
从而保证了实体完整性。
参照完整性
①定义参照完整性
关系模型的参照完整性在CREATE TABLE中用FOREIGN KEY短语定义哪些列为外码，用REFERENCES短语指明这些外码参照哪些表的主码。
②参照完整性检查和违约处理
参照完整性将两个表中的相应元组联系起来了。因此，对被参照表和参照表进行增、删、改操作时有可能破坏参照完整性，必须进行检查以保证这两个表的相容性。
有4种可能破坏参照完整性的情况，如下表所示。
当上述的不一致发生时，系统可以采用以下策略加以处理。
拒绝执行(默认策略)
级联操作
设置为空值
用户定义的完整性
用户定义的完整性就是针对某一具体应用的数据必须满足的语义要求。目前的关系数据库管理系统都提供了定义和检验这类完整性的机制。
①属性上的约束条件
(1)属性上约束条件的定义
在CREATE TABLE中定义属性的同时，可以根据应用要求定义属性上的约束条件，即属性值限制，包括：
列值非空(NOT NULL)。
列值唯一(UNIQUE)。
检查列值是否满足一个条件表达式(CHECK短语)。
(2)属性上约束条件的检查和违约处理
当往表中插入元组或修改属性的值时，关系数据库管理系统将检查属性上的约束条件是否被满足，如果不满足则操作被拒绝执行。
②元组上的约束条件
(1)元组上约束条件的定义
与属性上约束条件的定义类似，在CREATE TABLE语句中可以用CHECK短语定义元组上的约束条件，即元组级的限制。同属性值限制相比，元组级的限制可以设置不同属性之间的取值的相互约束条件。
(2)元组上约束条件的检查和违约处理
当往表中插入元组或修改属性的值时，关系数据库管理系统将检查元组上的约束条件是否被满足，如果不满足则操作被拒绝执行。
完整性约束命名子句
SQL还在CREATE TABLE语句中提供了完整性约束命名子句CONSTRAINT，用来对完整性约束条件命名，从而可以灵活地增加、删除一个完整性约束条件。
①完整性约束命名子句
CONSTRAINT<完整性约束条件名><完整性约束条件>
<完整性约束条件>包括NOT NULL、UNIQUE、PRIMARY KEY、FOREIGN KEY、CHECK短语等。
②完整性约束命名子句
可以使用ALTER TABLE语句修改表中的完整性限制。例：
ALTER TABLE Student
DROP CONSTRAINT C4;
修改表的约束条件时，可以先删除原来的约束条件，再增加新的约束条件。
断 言
在SQL中可以使用数据定义语言中的CREATE ASSERTION语句，通过声明性断言来指定更具一般性的约束。
①创建断言的语句格式
CREATE ASSERTION <断言名><CHECK 子句>
每个断言都被赋予一个名字，<CHECK 子句>中的约束条件与WHERE子句的条件表达式类似。
②删除断言的语句格式
DROP ASSERTION<断言名>;
如果断言很复杂，则系统在检测和维护断言上的开销较高，这是在使用断言时应该注意的。
触 发 器
触发器是用户定义在关系表上的一类由事件驱动的特殊过程。触发器类似于约束，但是比约束更加灵活，可以实施更为复杂的检查和操作，具有更精细和更强大的数据控制能力。
①定义触发器
触发器又叫做事件-条件-动作规则。SQL使用CREATE TRIGGER命令建立触发器，其一般格式为
下面对定义触发器的各部分语法进行详细说明。
(1)只有表的拥有者，即创建表的用户才可以在表上创建触发器，并且一个表上只能创建一定数量的触发器。
(2)触发器名
触发器名可以包含模式名，也可以不包含模式名。同一模式下，触发署名必须是唯一的，并且触发器名和表名必须在同一模式下。
(3)表名
触发器只能定义在基本表上，不能定义在视图上。
(4)触发事件
触发事件可以是INSERT、DELETE或UPDATE，也可以是这几个事件的组合。AFTER/BEFORE是触发的时机。
(5)触发器类型
触发器按照所触发动作的间隔尺寸可以分为行级触发器和语句级触发器。
(6)触发条件
触发器被激活时，只有当触发条件为真时触发动作体才执行，否则触发动作体不执行。如果省略WHEN触发条件，则触发动作体在触发器激活后立即执行。
(7)触发动作体
触发动作体既可以是一个匿名PL/SQL过程块，也可以是对已创建存储过程的调用。
如果触发动作体执行失败，激活触发器的事件就会终止执行，触发器的目标表或触发器可能影响的其他对象不发生任何变化。
②激活触发器
触发器的执行是由触发事件激活，并由数据库服务器自动执行的。一个数据表上可能定义了多个触发器同一个表上的多个触发器激活时遵循如下的执行顺序：
执行该表上的BEFORE触发器。
激活触发器的SQL语句。
执行该表上的AFTER触发器。
③删除触发器
DROP TRIGGER <触发器名> ON <表名>;
触发器必须是一个已经创建的触发器，并且只能由具有相应权限的用户删除。
触发器是一种功能强大的工具，但在使用时要慎重，因为在每次访问一个表时都可能触发一个触发器，这样会影响系统的性能。
小 结
数据库的完整性是为了保证数据库中存储的数据是正确的。所谓正确是指符合现实世界语义的。本章讲解了关系数据库管理系统完整性实现的机制，包括完整性约束定义机制、完整性检查机制和违背完整性约束条件时关系数据库管理系统应采取的动作等。
在关系系统中，最重要的完整性约束是实体完整性和参照完整性，其他完整性约束条件则可以归入用户定义的完整性。
数据库完整性的定义一般由SQL的数据定义语言来实现。它们作为数据库模式的一部分存入数据字典中，在数据库数据修改时关系数据库管理系统的完整性检查机制将按照数据字典中定义的这些约束进行检查。
完整性机制的实施会影响系统性能。因此，许多数据库管理系统对完整性机制的支持比对安全性的支持要晚得多，也弱得多。随着硬件性能的提高以及数据库技术的发展，目前的关系数据库管理系统都提供了定义和检查实体完整性、参照完整性和用户定义的完整性的功能。
对于违反完整性的操作一般的处理是采用默认方式，如拒绝执行。对于违反参照完整性的操作，本书讲解了不同的处理策略。用户要根据应用语义来定义合适的处理策略，以保证数据库的正确性。
实现数据库完整性的一个重要方法是触发器，触发器和前面介绍的各种完整性约束不同之处是，完整性控制是当被限制的对象发生变化时系统就去检查该对象变化后能否满足完整性约束条件，如果不能满足就进行违约处理，违约处理通常比较简单。而触发器功能就要强得多，因为触发器规则中的动作体可以很复杂，通常是一段SQL存储过程，触发器不仅可以用于数据库完整性检查，也可以用来实现数据库系统的其他功能，包括数据库安全性，以及更加广泛的应用系统的一些业务流程和控制流程、基于规则的数据和业务控制功能等。不过也要特别注意，一个触发器的动作可能激活另一个触发器，最坏的情况是导致一个触发链，从而造成难以预见的错误。
