DBMS - 关系模型约束
关系型数据库被广泛使用；它们提供了结构化且可靠的方式来存储和访问数据。为了确保数据的完整性和一致性，关系型数据库主要依赖于某些称为约束的规则。这些约束用于维护不同表和记录中数据的质量和可靠性。
在本章中，我们将了解关系模型约束的类型，并辅以实际示例和解释，以加深理解。
关系模型约束
关系模型约束是一组应用于数据库结构和数据的规则，用于维护逻辑一致性。它们确保数据根据数据库模式中定义的规则是有效的。这些约束可以分为以下三种主要类型 −
- 固有模型约束 − 由关系模型本身的特性隐含。
- 基于模式的约束 − 在数据库模式中明确定义，并由数据库系统强制执行。
- 基于应用的约束 − 通过外部应用逻辑管理，因为它们无法直接在模式中表达。
关系模型约束的类型
关系模型约束可以分为以下类型 −
- Domain Constraints
- Key Constraints
- Entity Integrity Constraint
- Referential Integrity Constraint
让我们详细了解每一种约束。
Domain Constraints
Domain constraints 用于规定数据库中的每个属性必须只包含来自预定义集合的值，该集合称为 domain。这确保表中的每个列都保存特定类型和格式的数据。
例如，考虑一个 EMPLOYEE 表，其中 Age 列只允许 18 到 65 之间的整数值。此 domain constraint 确保插入如 “17” 或 “70” 这样的值会违反规则并被系统拒绝。
如果我们将 Age 定义为 INTEGER CHECK (Age BETWEEN 18 AND 65)，则任何尝试插入 Age = 17 的操作都会触发错误。Domain constraints 用于通过防止不适当的数据类型或超出范围的值来维护数据准确性。
Key Constraints
Key constraints 用于关系中的每条记录。它可以被唯一标识。这种唯一性通过 keys 实现。
Keys 可以分为以下类型 −
- Superkey − 任何一组唯一标识关系中元组的属性集合。
- Candidate key − 最小 superkey。移除任何属性都会破坏唯一性。
- Primary key − 选定的 candidate key，用于唯一标识表中的每个元组。
例如，考虑下面的 STUDENT 表 −
| Name | SSN | Home Phone | Address | Office Phone | Age | GPA |
|---|---|---|---|---|---|---|
| Dick Davidson | 422-11-2320 | NULL | 3452 Elgin Road | (817)749-1253 | 25 | 3.53 |
| Barbara Benson | 533-69-1238 | (817)839-8461 | 7384 Fontana Lane | NULL | 19 | 3.25 |
| Rohan Panchal | 489-22-1100 | (817)376-9821 | 265 Lark Lane | (817)749-6492 | 28 | 3.93 |
| Chung-cha Kim | 381-62-1245 | (817)375-4409 | 125 Kirby Road | NULL | 18 | 2.89 |
| Benjamin Bayer | 305-61-2435 | (817)373-1616 | 2918 Bluebonnet Lane | NULL | 19 | 3.21 |
SSN（Social Security Number）作为 primary key，因为每个学生必须有唯一的 SSN。Primary key constraint 保证没有两个学生可以有相同的 SSN。
这很重要，因为 primary keys 有助于维护每条记录的身份。如果 STUDENT 表没有 primary key，则区分重复记录将变得困难，这会导致潜在的数据歧义。
Entity Integrity Constraint
Entity integrity constraint 规定，关系的主键必须始终具有非 NULL 值。这是必要的，因为 primary keys 用于标识元组，而 NULL 值会使标识变得不可能。
考虑一个名为 CUSTOMER 的表。如果 Customer_ID 被定义为主键，则任何尝试插入 “Customer_ID = NULL” 的记录都会违反 entity integrity constraint，并被系统拒绝。
实际中，我们可以考虑银行系统中的 Customer 关系，其 primary keys 表示账户号码。如果一条记录的 Account_ID = NULL，则无法引用或链接此记录。
Referential Integrity Constraint
Referential integrity constraint 规定，表之间的关系保持一致。一个表中的 foreign key 必须匹配另一个表中的 primary key 值，或者为 NULL。此约束可以保持不同表中记录之间的逻辑连接。
假设我们有一个 EMPLOYEE 表，其中包含 Dno 列。这里，它引用 DEPARTMENT 表中的 Dnumber。如果 Dno 设置为 DEPARTMENT 表中不存在的值，则违反 referential integrity constraint。
详细场景 − 查看 Employee 表 −
| Fname | Minit | Lname | SSN | Bdate | Address | Sex | Salary | Super_ssn | Dno |
|---|---|---|---|---|---|---|---|---|---|
| John | B | Smith | 123456789 | 1965-01-09 | 731 Fondren, Houston, TX | M | 30000 | 333445555 | 5 |
| Franklin | T | Wong | 333445555 | 1955-12-08 | 638 Voss, Houston, TX | M | 40000 | 888665555 | 5 |
| Alicia | J | Zelaya | 999887777 | 1968-01-19 | 3321 Castle, Spring, TX | F | 25000 | 987654321 | 4 |
| Jennifer | S | Wallace | 987654321 | 1941-06-20 | 291 Berry, Bellaire, TX | F | 43000 | 888665555 | 4 |
| Ramesh | K | Narayan | 666884444 | 1962-09-15 | 975 Fire Oak, Humble, TX | M | 38000 | 333445555 | 5 |
| Joyce | A | English | 453453453 | 1972-07-31 | 5631 Rice, Houston, TX | F | 25000 | 333445555 | 5 |
| Ahmad | V | Jabbar | 987987987 | 1969-03-29 | 980 Dallas, Houston, TX | M | 25000 | 987654321 | 4 |
| James | E | Borg | 888665555 | 1937-11-10 | 450 Stone, Houston, TX | M | 55000 | NULL | 1 |
查看 Department 表 −
| Dname | Dnumber | Mgr_ssn | Mgr_start_date |
|---|---|---|---|
| Research | 5 | 333445555 | 1988-05-22 |
| Administration | 4 | 987654321 | 1995-01-01 |
| Headquarters | 1 | 888665555 | 1981-06-19 |
有效插入 − 如果 DEPARTMENT 中存在 Dnumber = 4，则允许添加 Dno = 4 的 EMPLOYEE。
违反示例 − 插入 Dno = 99 的 EMPLOYEE，而 DEPARTMENT 中不存在 Dnumber = 99，将被拒绝。
此约束在维护父表和子表之间的关系时特别有用。因此，删除被员工引用的部门必须受到限制或级联删除以维护完整性。
处理约束违规
在本节中，我们将了解哪些操作可能会导致约束违规，以及可以采取哪些预防措施来防止此类操作。
插入违规
插入操作可能会因为以下原因违反各种约束：
- 域约束违规 − 在定义为整数类型的 Age 列中插入非整数值将被拒绝。
- 键约束违规 − 在 STUDENT 表中添加一个具有重复 Ssn 的元组，而 Ssn 是 primary key，将导致错误。
- 实体完整性违规 − 尝试插入 primary key 值为空（NULL）的行，将违反实体完整性约束。
- 参照完整性违规 − 插入一个 EMPLOYEE，其 Dno 值与 DEPARTMENT 中的任何 Dnumber 不匹配。
删除操作与参照完整性
删除一个元组可能会触发约束违规，特别是参照完整性。例如，删除被 EMPLOYEE 元组的 Dno 引用的 DEPARTMENT 记录，将导致参照完整性问题。
我们可以通过Restrict 操作来解决这个问题，例如如果会导致违规则阻止删除。或者使用cascade，即自动删除所有依赖记录。还有另一种解决方案：Set NULL / Default，即将依赖记录中的外键修改为 NULL 或默认值。
更新操作
更新记录可能会影响 primary key 和 foreign key。修改 primary key 类似于删除原记录并插入新记录，这可能会违反现有约束。更新操作可以分为两种类型：
- Safe Update − 更改员工薪资不会影响 primary key 或 foreign key，是允许的。
- Risky Update − 将 EMPLOYEE 中的 Ssn 修改为已存在的 Ssn，将违反 primary key 约束。
其他约束和业务规则
我们已经学习了这些规则，但还有一些基于应用程序的约束，或称为业务规则。这些规则包括那些无法在 schema 中轻松定义的规则，例如：
- “员工的薪资不得超过其主管的薪资。”
- “员工每周总工作时间不得超过 56 小时。”
这些通常使用 application logic 或 triggers 来强制执行。
结论
在本章中，我们详细解释了关系模型约束如何在数据库中维护数据完整性和一致性方面发挥关键作用。我们了解了不同类型的约束，如 domain constraint、key constraint、entity integrity constraints 和 referential integrity constraints。我们讨论了这些约束在实际中的示例。我们还回顾了如何处理约束违规以及基于应用程序的规则的重要性。