数据库设计/完整性规则和约束
约束是关系模型中一个非常重要的特性。事实上，关系模型支持对属性或表的明确定义的约束理论。约束很有用，因为它们允许设计者指定数据库中数据的语义。约束是强制 DBMS 检查数据是否满足语义的规则。
域限制关系中属性的值，是关系模型的约束。但是，如果仅使用域约束，则无法指定数据的现实世界语义。我们需要更具体的方法来陈述允许或不允许哪些数据值以及哪个格式适合属性。例如，员工 ID (EID) 必须唯一，或者员工出生日期在 [1950 年 1 月 1 日，2000 年 1 月 1 日] 范围内。此类信息在称为完整性约束的逻辑语句中提供。
完整性约束有几种类型，如下所述。
为了确保实体完整性，要求每个表都有一个主键。主键或其任何部分都不能包含空值。这是因为主键的空值意味着我们无法识别某些行。例如，在 EMPLOYEE 表中，Phone 不能作为主键，因为有些人可能没有电话。
参照完整性要求外键必须具有匹配的主键，或者必须为空。此约束是在两个表（父表和子表）之间指定的；它维护这些表中行之间的对应关系。这意味着从一个表中的一行到另一个表的引用必须有效。
公司客户/订单数据库中参照完整性约束的示例
- Customer(CustID, CustName)
- Order(OrderID, CustID, OrderDate)
为了确保没有孤立记录，我们需要强制参照完整性。孤立记录是指其外键 FK 值在相应实体（主键所在实体）中找不到的记录。回想一下，典型的连接是在 PK 和 FK 之间的。
参照完整性约束规定 Order 表中的客户 ID (CustID) 必须与 Customer 表中的有效 CustID 相匹配。大多数关系数据库都有声明式参照完整性。换句话说，在创建表时，参照完整性约束就会设置。
以下是来自课程/班级数据库的另一个示例
- Course(CrsCode, DeptCode, Description)
- Class(CrsCode, Section, ClassTime)
参照完整性约束规定 Class 表中的 CrsCode 必须与 Course 表中的有效 CrsCode 相匹配。在这种情况下，Class 表中的 CrsCode 和 Section 构成主键是不够的，我们还必须强制参照完整性。
设置参照完整性时，重要的是主键和外键必须具有相同的数据类型并来自同一个域，否则关系数据库管理系统 (RDBMS) 将不允许连接。RDBMS 是一个流行的数据库系统，它基于 E. F. Codd 在 IBM 圣何塞研究实验室提出的关系模型。关系数据库系统比其他数据库系统更容易使用和理解。
在 Microsoft (MS) Access 中，通过将 Customer 表中的主键连接到 Order 表中的 CustID 来设置参照完整性。参见图 9.1，了解如何在 MS Access 的“编辑关系”屏幕上完成此操作。
图 9.1。MS Access 中的参照访问，作者：A. Watt。
使用 Transact-SQL 时，参照完整性是在使用 FK 创建 Order 表时设置的。下面列出的语句显示了 Order 表中 FK 对 Customer 表中主键的引用。
CREATE TABLE Customer
( CustID INTEGER PRIMARY KEY,
CustName CHAR(35) )
CREATE TABLE Orders
( OrderID INTEGER PRIMARY KEY,
CustID INTEGER REFERENCES Customer(CustID),
OrderDate DATETIME )
在设置参照完整性时，可以添加其他外键规则，例如在删除或更改（更新）具有主键的记录（在父表（Customer 表）中）时如何处理子行（在 Orders 表中）。例如，MS Access 中的“编辑关系”窗口（参见图 9.1）显示了 FK 规则的两个附加选项：“级联更新”和“级联删除”。如果未选择这些选项，系统将阻止在父表（Customer 表）中删除或更新主键值，如果存在子记录。子记录是指任何具有匹配主键的记录。
在某些数据库中，在选择“删除”选项时，还存在一个名为“设置为 Null”的附加选项。如果选择此选项，将删除主键行，但子表中的外键将设置为 NULL。尽管这会创建一个孤立行，但它是可以接受的。
企业约束 - 有时称为语义约束 - 是用户或数据库管理员指定的附加规则，可以基于多个表。
以下是一些示例。
- 一个班级最多可以有 30 名学生。
- 一名教师每个学期最多可以教授四门课程。
- 一名员工不能参与超过五个项目。
- 一名员工的工资不能超过其经理的工资。
业务规则是在收集需求时从用户那里获得的。需求收集过程非常重要，其结果应在构建数据库设计之前由用户进行验证。如果业务规则不正确，则设计将不正确，最终构建的应用程序将无法按用户预期的方式运行。
以下是业务规则的一些示例
- 一名教师可以教授许多学生。
- 一个班级最多可以有 35 名学生。
- 一门课程可以教授很多次，但只能由一名教师教授。
- 并非所有教师都教授课程。
业务规则用于确定基数和连接性。基数通过表示与相关实体的一个实例相关联的实体实例的最小和最大数量来描述两个数据表之间的关系。在图 9.2 中，您可以看到基数由关系符号上的最内层标记表示。在此图中，基数在右侧为 0（零），在左侧为 1（一）。
图 9.2。关系符号上连接性和基数的位置，作者：A. Watt。
另一方面，关系符号的最外层符号表示两个表之间的连接性。连接性是指两个表之间的关系，例如一对一或一对多。唯一一次为零是在 FK 可以为空时。在参与方面，这些实体之间关系有三个选项：0（零）、1（一）或多。例如，在图 9.2 中，连接性在该线的外部左侧为 1（一），在外部右侧为多。
图 9.3 显示了表示一对多关系的符号。
图 9.3。
在图 9.4 中，显示了内部（表示基数）和外部（表示连接性）标记。该符号的左侧读取为最小 1 和最大 1。在右侧，它读取为：最小 1 和最大多。
图 9.4。
连接两个表的线，在 ERD 中，表示表之间的关系类型：识别或非识别。识别关系将有一条实线（其中 PK 包含 FK）。非识别关系由一条虚线表示，并且 PK 中不包含 FK。有关更多解释，请参阅第 8 章中讨论弱关系和强关系的部分。
图 9.5。识别和非识别关系，作者 A. Watt。
在可选关系中，FK 可以为空，或者父表不需要有相应的子表出现。图 9.6 中所示的符号说明了一种类型，它有一个零和三个叉（表示多），解释为零或多。
图 9.6。
例如，如果您查看图 9.7 右侧的订单表，您会注意到客户不需要下订单才能成为客户。换句话说，多边是可选的。
图 9.7。零到多可选关系符号的示例用法，作者 A. Watt。
图 9.7 中的关系符号也可以这样读取
- 左侧：订单实体必须包含客户表中至少一个相关实体，最多一个相关实体。
- 右侧：客户可以下至少零个订单，最多下多个订单。
图 9.8 显示了另一种类型的可选关系符号，它有一个零和一个，表示零或一。一边是可选的。
图 9.8。
图 9.9 给出了零到一符号如何使用的示例。
图 9.9。零到一可选关系符号的示例用法，作者 A. Watt。
在强制关系中，一个实体出现需要一个相应的实体出现。这种关系的符号显示只有一个，如图 9.10 所示。一边是强制的。
图 9.10
请参见图 9.11 以了解只有一个强制符号如何使用的示例。
图 9.11。一个和只有一个强制关系符号的示例，作者 A. Watt。
图 9.12 说明了多边为强制的一对多关系符号的样子。
图 9.12。
请参阅图 9.13 以了解如何使用一对多符号的示例。
图 9.13。一对多强制关系符号的示例，作者 A. Watt。
到目前为止，我们已经看到关系符号的最内侧（图 9.14 中符号的左侧）可以具有 0（零）基数和多（显示在图 9.14 中符号的右侧）的连接性，或一个（未显示）。
图 9.14
然而，它不能具有 0（零）的连接性，如图 9.15 所示。连接性只能是 1。
图 9.15。
连接性符号显示最大值。因此，如果您从逻辑上考虑，如果左侧的连接性符号显示 0（零），那么表之间将没有连接。
读取关系符号的方式，例如图 9.16 中的符号，如下所示。
- 订单表中的 CustID 必须在客户表中至少出现 0 次，最多出现 1 次。
- 0 表示订单表中的 CustID 可以为空。
- 最左边的 1（在代表连接性的 0 之前）表明，如果订单表中存在 CustID，它只能在客户表中出现一次。
- 当您看到基数的 0 符号时，您可以假设两件事：T
- 订单表中的 FK 允许空值，并且
- FK 不是 PK 的一部分，因为 PK 必须不包含空值。
图 9.16。客户表和订单表之间的关系，作者 A. Watt。
- 业务规则
- 从用户收集需求时获得，用于确定基数
- 基数
- 表示与一个相关实体出现相关联的实体出现的最小和最大数量
- 连接性
- 两个表之间的关系，例如一对一或一对多
- 约束
- 强制 DBMS 检查数据是否满足语义的规则
- 实体完整性
- 要求每个表都有一个主键；主键或其任何部分都不能包含空值
- 识别关系
- 主键包含外键；在 ERD 中由实线表示
- 完整性约束
- 逻辑语句，说明允许或不允许哪些数据值，以及哪个格式适合属性
- 强制关系
- 一个实体出现需要一个相应的实体出现。
- 非识别关系
- 主键中不包含外键；在 ERD 中由虚线表示
- 可选关系
- FK 可以为空，或者父表不需要有相应的子表出现
- 孤儿记录
- 其外键值在相应的实体中找不到的记录 - 实体，主键所在的位置
- 参照完整性
- 要求外键必须具有匹配的主键，或者必须为空
- 关系数据库管理系统 (RDBMS)
- 一种流行的数据库系统，基于 E. F. Codd 在 IBM 圣何塞研究实验室提出的关系模型
- 关系类型
- ERD 中两个表之间关系的类型（识别或非识别）；这种关系由连接两个表的线表示。
阅读以下描述，然后回答最后的第 1-5 题。
图 9.17 中的游泳俱乐部数据库旨在保存注册游泳课程的学生的信息。存储以下信息：学生、注册、游泳课程、举办课程的游泳池、课程的教练以及各种游泳课程级别。使用图 9.17 回答问题 1 到 5。
图 9.17。问题 1-5 的 ERD。（作者 A. Watt 绘制。）
主键在下面标识。以下数据类型在 SQL Server 中定义。
tblLevels
Level - Identity PK
ClassName - text 20 - 不允许空值
tblPool
Pool - Identity PK
PoolName - text 20 - 不允许空值
Location - text 30
tblStaff
StaffID - Identity PK
FirstName - text 20
MiddleInitial - text 3
LastName - text 30
Suffix - text 3
Salaried - Bit
PayAmount - money
tblClasses
LessonIndex - Identity PK
Level - Integer FK
SectionID - Integer
Semester - TinyInt
Days - text 20
Time - datetime（格式化为时间）
Pool - Integer FK
Instructor - Integer FK
Limit - TinyInt
Enrolled - TinyInt
Price - money
tblEnrollment
LessonIndex - Integer FK
SID - Integer FK（LessonIndex 和 SID）主键
Status - text 30
Charged - bit
AmountPaid - money
DateEnrolled - datetime
tblStudents
SID - Identity PK
FirstName - text 20
MiddleInitial - text 3
LastName - text 30
Suffix - text 3
Birthday - datetime
LocalStreet - text 30
LocalCity - text 20
LocalPostalCode - text 6
LocalPhone - text 10
在 SQL Server 或访问中实现此模式（您需要选择可比数据类型）。提交您在数据库中 ERD 的屏幕截图。
- 解释每种关系的关系规则（例如，tblEnrollment 和 tblStudents：学生可以注册多个课程）。
- 假设以下规则，识别每种关系的基数
- 游泳池可能永远不会有课程，也可能会有课程。
- 级别表必须始终与至少一个课程相关联。
- 员工表可能从未教授过课程。
- 所有学生必须注册至少一个课程。
- 课程必须有学生注册。
- 该课程必须有有效的池。
- 该课程可能没有指定讲师。
- 该课程必须始终与现有级别相关联。
- 哪些表格是弱表格，哪些表格是强表格（在前面的章节中介绍过）？
- 哪些表格是非标识表格，哪些是标识表格？
图 9.3、9.4、9.6、9.8、9.10、9.12、9.14 和 9.15 由 A. Watt 绘制。