[计算机]第8 章 完整性.pdfVIP

下载 第8章 完 整 性 8.1 引言 数据库中完整性( i n t e g r i t y )一词指数据的正确性和相容性 。正像第3章所说的，一个给 定的数据库可能受到多个完整性约束的限制 ,可能是简单的也可能是复杂的。比如，在供 应商-零件例子中，供应商号码可能是 Sn n n n ( n n n n 为1到4位整数 ) ，并且这一编号是唯一 的；状态值可能在 1~1 0 0的范围内；伦敦的供应商状态值必须是 2 0 ；发货量必须是 5 0 的倍 数；颜色为“红”的零件必须被存放在伦敦；等等。通常， D B M S 都被告知存在这样的约 束，当然，也能在一定程度上实现这样的约束（一般是通过拒绝违反这些约束的更新请 求来实现）。例如（再次引用 Tutorial D ）： （状态值必须在1 ~ 1 0 0范围内）。这个约束被命名为 S C 3 （供应商约束3 ，suppliers constraint 3 ）；这个约束将以此名在系统目录（ system catalog ）中注册，当系统对企图违反这个约 束的操作作出响应时，这个名字将在诊断提示信息中出现。此约束本身被指定为一个布 尔表达式，并且，其值不可为假。 注意：为明确起见，我们采用 Tutorial D 的代数形式；所以，这个布尔表达式常常采 取（虽然并非一成不变）如下的形式： I S _ E M P T Y ( . . . ) ，意思是数据库中没有违反这个约 束的元组（参见第 6章，6 . 9节）。这个例子的演算描述为 ： ( SX 是定义在供应商上的一个范围变量 ) 。 另外我们注意到以演算约束形式存在的布尔表达式必须是一个封闭的合式公式 (参见 第7 章，7 . 2节) ，并且常（但并非一成不变）采用 FORALL x ( . . . ) 的形式。这样，这个例子 约束所有的供应商状态值必须在指定的范围内。实际上，对于一个数据库系统，只要检 查新插入或更新的“供应商”记录就可以了，而不用检查所有的供应商记录。 当声明一个新的约束时，系统首先要确保当前系统满足这个约束。如果当前系统不满 足这个约束，这个新约束就被拒绝；反之，则被接受（也就是被存储在目录中），从此新 的约束开始生效。此后， D B M S就要监视每一个插入的“供应商”记录和会引起已存在供 应商记录状态值变动的操作。 当然，我们也要有能够解除已存在约束的方法。 例如： 实际上，用演算而不用代数形式的公式表示约束看起来要简单一些（特别是复杂的约束）。为了与本 书其他章节一致，这里只讨论代数形式，读者可以试着将下面的代数形式转化为演算形式。 180使用第二部分 关系数据模型 下载 注意：正像下面的讨论所指出的，我们将尤其关注声明完整性支持。遗憾的是，即使 现在，也几乎没有什么产品能在这方面做得很好。但在这一点上是不断进步的，虽然目 前一些数据库产品（尤其是非关系数据库）还特别强调一种与此相反的方法 —也就是 对约束的“过程支持” （procedural support ），通过存储过程和触发过程来实现 。但是， 建议一个 D B M S提供对约束的声明支持（ declarative support ），因为多达百分之九十的数据 库定义中包含约束。一个提供对约束的声明支持的数据库将在相当程度上减轻程序员的 负担并使他们的生产率更高。对约束的声明支持是相当重要的。 在进一步讨论这个问题之前 ,可以说：在关系模型中，完整性是在这些年里变化最大 的（可能应该说“演化”而不是“变化”）。正像第3章中提到的，最初，主码和外码（简 称为“码”）是人们关注的重点，逐渐地，完整性约束的重要性—普遍存在，且具有毫 无争议的重要性 —得到人们的普遍理解和广泛重视。同时，关于码的一些讨厌的细节 问题不断出现。本章的结构体现了这一重点的转变。我们先介绍完整性约束（仅在一定 程度上讨论），然后讨论“码”，因为在应用中