实体完整, 参照完整, 用户定义完整, 实现(重要)
语法: 定义完整性检查条件
数据库完整性
定义:
- 数据的正确性 → 复合现实世界语义
- 数据的相容性 → 数据库同一对象在不同关系表中的数据是符合逻辑的
与安全性区分:
完整性 → 防止数据库中存在不符合语义的、不正确的数据
安全性 → 拦截非法用户和非法操作, 防止恶意破坏和非法存取
完整性约束条件(完整性规则): 数据库中的数据必须满足的语义约束条件.
SQL标准使用实体完 整性, 参照完整性和用户定义完整性等一系列概念来描述完整性, 由SQL的数据定义语言实现
完整性检查: 一般在
INSERT、UPDATE、DELETE语句执行后, 或事务提交时检查违约处理: 拒绝执行该操作/级联执行其他操作
实体完整性
主码存在且唯一
主码在建表语句
CREATE TABLE中用PRIMARY KEY定义单属性码可以定义为列级/表级约束条件, 多属性码只能定义为表级约束条件
插入新元组或队主码列进行更新操作时, DBMS自动按照实体完整性规则自动进行检查, 包括检查主码值是否唯一, 检查主码的各个属性是否有空. 只要有一项不符合就拒绝插入或更新.
检查是否唯一: 全表扫描一遍/建立索引
参照完整性
外码要么留空要么为被参照关系中存在的主码值
外码在建表语句中用FOREIGN KEY定义, 用REFERENCES短语指明这些外码参照哪些表的主码.
一个参照完整性将两个表中的相应元组联系起来
对被参照表和参照表进行增删改操作时有可能破坏参照完整性, 必须检查(参照表新增行/参照表修改行的外码字段/被参照表删除行/被参照表修改行的主码字段)
被参照表（例如Student） | 参照表（例如SC） | 违约处理 |
可能破坏参照完整性 | 插入元组 | 拒绝 |
可能破坏参照完整性 | 修改外码值 | 拒绝 |
删除元组 | 可能破坏参照完整性 | 拒绝/级连删除/设置为空值 |
修改主码值 | 可能破坏参照完整性 | 拒绝/级连修改/设置为空值 |
拒绝执行 → 不执行
级联操作 → 当修改被参照表时造成了参照表中的参照完整性冲突, 就顺藤摸瓜删除或修改参照表中的不兼容元组.
设置为空值 → 将参照表中的不兼容外码改为空值(需要考虑定义表时是否允许外码列留空值)
用户定义的完整性
针对某一具体应用的数据必须满足的语义要求
属性上的/元组上的约束条件(针对行/列均可)
关系数据库管理系统提供了定义和检验用户定义完整性的机制, 不必由应用程序承担. 插入元组或修改属性的值时, 关系数据库管理系统检查约束条件是否被满足, 如果不满足则操作被拒绝执行.
还可以直接使用
CHECK+条件表达式来作为列级/表级完整性检查:还可以使用
CONSTRAINT为完整性约束命名: 其中<完整性约束条件>包括
NOT NULL、UNIQUE、PRIMARY KEY短语、FOREIGN KEY-REFERENCES短语、CHECK短语等. 若要修改则使用
ALTER TABLE. 断言和触发器
不做要求
断言
可以使用CREATE ASSERSION语句, 通过声明性断言来指定更具一般性的约束
可以定义涉及多个表的或聚集操作的比较复杂的完整性约束
断言创建之后, 任何对断言中涉及的关系的操作都会触发DBMS对断言的检查, 任何使得断言不为真的操作都会被拒绝
断言越复杂, 检测和维护断言的开销越高
创建/删除:
触发器
事件驱动的特殊过程, 特定事件发生后自动激活相应的触发器
创建/删除:
特定的系统事件(触发事件)发生时, 对触发器规则中的条件(触发条件)进行检查, 如果条件成立则执行规则中的动作(触发动作体), 否则不执行.
表的拥有者才能在表上创建触发器
只有基本表才可以定义触发器(视图不行)
行级触发器/语句级触发器
同一个表上的多个触发器执行顺序: 检测到触发事件 → 执行表上的BEFORE触发器 → 执行触发事件中激活触发器的SQL语句 → 执行表上的AFTER触发器
