第二章 关系数据库 - 第三节 关系的完整性
概述
本节内容聚焦于关系数据库中的完整性约束，尤其是关系的完整性。完整性是数据库设计中保证数据质量和一致性的关键原则。通过学习本节，考生将系统理解关系完整性的定义、分类及其实现方式，掌握如何利用完整性约束保证数据库中数据的准确性和可靠性。重点包括实体完整性、参照完整性和用户自定义完整性约束的概念及实现原理。
学习目标：
- 理解关系完整性的基本概念与分类
- 掌握实体完整性和参照完整性的定义与实现方法
- 能够识别和解决完整性约束中的常见问题
- 通过典型案例分析，提升实际应用能力
核心概念
关系完整性
关系完整性是指数据库中数据符合特定的规则和限制，确保数据的有效性和一致性。它是关系数据库管理系统（RDBMS）通过约束机制实现的，用于防止无效数据的插入、更新或删除。
实体完整性
实体完整性约束保证关系中每个元组的主键字段不能为空且唯一。主键是用来唯一标识一个元组的属性集合，实体完整性确保数据实体的唯一标识性。
参照完整性
参照完整性约束保证外键字段的值必须存在于其对应的主键字段中，确保数据之间的关联关系正确且有效。通过外键约束维护关系间的数据一致性。
用户自定义完整性（域完整性、业务规则）
用户自定义完整性包括域完整性（如数据类型、取值范围限制）和通过触发器、检查约束等实现的业务规则，满足特定应用需求。
原理分析
实体完整性的实现原理
实体完整性通过定义主键约束来实现。主键字段必须满足两个条件：
- 非空性：主键值不能为NULL，因为NULL表示未知或不存在，无法唯一标识元组。
- 唯一性：不同元组的主键值不能重复，确保每条记录唯一。
数据库系统通过索引和约束机制自动维护主键的唯一性和非空性，插入或更新数据时若违反这两个条件则操作失败。
参照完整性的实现原理
参照完整性通过外键约束实现。外键是一个或多个属性，其值必须匹配被参照关系的主键值。实现机制包括：
- 插入或更新外键值时，系统检查对应的主键是否存在。
- 删除或更新主键时，如果存在依赖的外键引用，必须根据设置的操作规则（CASCADE、SET NULL、RESTRICT等）来处理关联数据。
这种约束防止了数据孤立和不一致，维护数据间的正确关联。
用户自定义完整性的实现原理
用户自定义完整性通过CHECK约束、触发器、存储过程等实现。例如，限制某字段数值范围、格式、业务逻辑条件等。数据库在数据操作时自动验证，确保数据符合业务规则。
详细内容
1. 实体完整性详细讲解
实体完整性是关系数据库设计的基础。主键的定义要求每个元组能被唯一标识，避免数据重复和模糊。
主键选择原则
- 主键应简洁且稳定，避免使用会频繁变化的属性
- 主键值必须唯一且非空
- 可使用单个属性或多个属性的组合（复合主键）
主键约束的实现
- 在SQL中使用PRIMARY KEY声明
- 数据库自动创建唯一索引加速查询
非空约束（NOT NULL）
- 主键字段隐含非空约束，不能插入NULL
实例说明
- 学生表中学号（StuID）为主键，确保每位学生唯一识别。
2. 参照完整性详细讲解
参照完整性保证了数据间的关联性和一致性。外键约束是关联两个关系的桥梁。
外键的定义
- 外键是子表中的属性，引用父表的主键
- 保证子表外键值必须在父表存在
操作规则
- ON DELETE CASCADE：删除父表记录时，自动删除对应子表记录
- ON DELETE SET NULL：删除父表记录时，子表外键值置空
- ON DELETE RESTRICT/NO ACTION：禁止删除父表存在引用的记录
实现机制
- 插入或修改子表外键时检查父表主键存在
- 删除或修改父表主键时根据规则处理子表数据
实例说明
- 课程表（Course）主键CourseID，学生选课表（SC）外键CourseID引用课程表，保证选课记录的合法性。
3. 用户自定义完整性详细讲解
用户自定义完整性是满足具体业务需求的关键。
域完整性
- 限制字段的数据类型，如整数、字符串、日期
- 限制字段取值范围，如年龄在0-120之间
业务规则约束
- 如订单表中订单金额必须大于0
- 触发器实现复杂约束，如自动更新状态字段
实现方式
- CHECK约束
- 触发器（Trigger）
- 存储过程（Stored Procedure）
实例说明
- 员工表中性别字段只允许'M'或'F'，使用CHECK约束。
4. 关系完整性约束的维护与优化
约束检查时机
- 立即检查（Insert/Update/Delete时）
- 延迟检查（事务提交时）
性能影响
- 约束检查增加数据操作时的开销
- 合理设计索引可提升约束检查效率
冲突处理策略
- 设计合理的约束优先级和触发器顺序
- 利用事务回滚保证数据一致性
实例分析
实例一：学生选课系统中的实体完整性
背景：
学生表（Student）中StuID为主键，确保每个学生唯一。若允许StuID为空或重复，查询和管理学生数据将混乱。
分析：
- 通过主键约束，StuID不能为空且唯一
- 插入重复StuID时数据库拒绝操作
结论：
实体完整性保证了学生数据的唯一性和准确性，避免数据冗余和错误。
实例二：订单与客户表的参照完整性
背景：
订单表（Orders）包含客户ID（CustID）作为外键，引用客户表（Customers）的主键CustID。
分析：
- 插入订单时必须保证CustID在客户表已存在
- 删除客户记录时，设置ON DELETE CASCADE，自动删除该客户所有订单
结论：
参照完整性维护了订单与客户数据的正确关联，防止孤立订单产生。
实例三：员工信息中的自定义完整性约束
背景：
员工表（Employee）中薪资字段Salary设置CHECK约束，限定薪资必须大于0。
分析：
- 插入或更新薪资为负数时数据库报错
- 触发器自动调整薪资超过上限的情况
结论：
用户自定义完整性保证了业务逻辑的正确实施，防止无效数据输入。
常见误区
误区：主键字段可以包含NULL值
- 说明：主键必须非空，否则无法唯一标识记录。
- 正确做法：定义主键时自动隐含非空约束。
误区：外键字段可以指向不存在的主键
- 说明：违反参照完整性，导致数据孤立。
- 正确做法：插入外键前确保引用的主键存在。
误区：删除父表数据不考虑子表影响
- 说明：可能导致子表外键悬挂，破坏数据一致性。
- 正确做法：合理设置删除规则，如CASCADE或RESTRICT。
误区：忽略用户自定义完整性导致业务规则失效
- 说明：数据虽符合结构约束，但不满足业务需求。
- 正确做法：使用CHECK约束和触发器实现业务逻辑。
误区：完整性约束过多导致性能严重下降
- 说明：不合理的约束设计可能影响性能。
- 正确做法：权衡完整性和性能，优化索引和约束设计。
应用场景
学生管理系统
- 通过实体完整性保证学生信息唯一
- 通过参照完整性维护班级与学生的关系
电子商务平台
- 订单与客户信息通过外键关联，保证订单有效性
- 业务规则约束订单状态和金额的合理性
医院信息系统
- 病人记录主键保证唯一标识
- 医生与病历之间的参照完整性维护
银行账户管理
- 账户表主键唯一性保证账户不重复
- 交易记录外键关联账户，保证交易数据一致
企业人力资源系统
- 员工编号作为主键
- 工资、职位等字段通过自定义约束保证数据合法性
知识拓展
约束的分类扩展
- 唯一约束（UNIQUE）区别于主键约束的使用场景
- 默认值约束（DEFAULT）保证字段默认赋值
触发器与完整性
- 利用触发器实现复杂的完整性约束，例如级联更新
事务与完整性
- 事务的原子性保证完整性约束的正确执行
完整性约束与数据库设计范式
- 完整性约束与范式理论相辅相成，指导规范设计
NoSQL数据库中的完整性
- 对比关系数据库，NoSQL中完整性约束的不同实现与挑战
总结回顾
本节重点围绕关系数据库中的完整性约束展开，系统讲解了关系完整性的三个核心方面：实体完整性、参照完整性和用户自定义完整性。通过定义主键和外键约束，数据库保证数据的唯一性和关联性，防止无效和孤立数据的产生。用户自定义完整性进一步确保数据符合特定业务需求。完整性约束的合理设计与实现，是数据库系统保证数据质量、支持业务流程的关键。通过典型案例分析和常见误区讲解，帮助考生深入理解并掌握完整性约束的理论与实践应用，为全国计算机等级考试四级数据库原理部分的学习和复习提供坚实基础。