数据库笔记 第5章 数据库完整性

目录

5.1 实体完整性

5.1.1 定义实体完整性

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

5.2 参照完整性

5.2.1 定义参照完整性

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

5.3 用户定义的完整性

5.3.2 元组上的约束条件

5.4 完整性约束命名子句—就是给约束命名CONSTRAINT

5.5 域中的完整性约束

5.6 断言

5.7 触发器

5.7.1 定义触发器

5.7.2 激活触发器

5.7.3 删除触发器

---

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

• 数据的正确性：数据是符合现实世界语义，反映了当前实际状况的
• 数据的相容性：同一对象在不同关系表中的数据是符合逻辑的

为保证数据库的完整性，数据库管理系统必须能实现以下功能：

1. 提供定义完整性约束条件的机制
2. 提供完整性检查的方法
3. 进行违约处理

5.1 实体完整性

5.1.1 定义实体完整性

关系模型的实体完整性： CREATE TABLE中用PRIMARY KEY定义。单属性构成的码称为列级约束条件，多属性构成的码称为表级约束条件（联合主码）。

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

插入或更新操作时，DBMS按照实体完整性规则自动进行检查：

1）检查主码值是否唯一，如果不唯一则拒绝插入或修改（需要全面扫描，太慢了，一般的数据库管理系统会在主码上建立一个索引）；

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

5.2 参照完整性

5.2.1 定义参照完整性

关系模型的参照完整性定义：
① 在CREATE TABLE中用FOREIGN KEY短语定义哪些列为外码
② 用REFERENCES短语指明这些外码参照哪些表的主码

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

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

5.3 用户定义的完整性

5.3.1 属性上的约束条件

CREATE TABLE时定义属性上的约束条件
① 列值非空（NOT NULL）
② 列值唯一（UNIQUE）（隐含非空）
③ 检查列值是否满足一个条件表达式（CHECK）

5.3.2 元组上的约束条件

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

2、元组上的约束条件检查和违约处理：
· 插入元组或修改属性的值时，关系数据库管理系统检查元组上的约束条件是否被满足
· 如果不满足则操作被拒绝执行

5.4 完整性约束命名子句—就是给约束命名CONSTRAINT

1、完整性约束命名子句

   

2、修改表中的完整性约束—ALERT

！！不是删除这个命名，是删除这个约束。

5.5 域中的完整性约束

再说—先不管

5.6 断言

1、创建断言

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

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

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

2、删除断言的语句格式

DROP ASSERTION <断言名>;

5.7 触发器

◾ 使用户定义在关系表上的一类由事件驱动的特殊过程
◾ 任何用户用表的增、删、改操作均由服务器自动激活相应的触发器
◾ 触发器可以实施更为复杂的检查和操作，具有更精细和更强大的数据控制能力

5.7.1 定义触发器

5.7.2 激活触发器

触发器的执行，是由触发时间激活的，并由数据库服务器自动执行

♥  一个数据库上可能定义了多个触发器，遵循如下执行顺序：

    （1）执行该表上的before触发器；

    （2）激活触发器的SQL语句；

    （3）执行该表上的after触发器。

当有多个before或after触发器时，通常按照触发器创建时间的先后执行 或 触发器名字的字母排序执行

5.7.3 删除触发器

drop trigger <触发器名> on <表名>;