软件数据管理数据管理.docVIP

如何防止产生不正确的数据及丢失数据 开发者在设计阶段要考虑许多因素——如何正规化数据、如何创建易于使用的界面等等。但无疑地，开发者最重要的一个目标就是保证数据的准确性。本文讨论了如何通过“引用完整性”来防止数据库产生不正确的数据，以及如何防止丢失数据。 解决了正规化、主键和关系问题后，一些人可能会忽视引用完整性。假定你负责维护一个 重要数据库，其中存储着产品和订单数据。同时，假定你为主键使用了自然数据，并在某天更新了一位特定用户的主键值。不久，客户气冲冲地打来电话，因为发票 出错，或是因为承诺的时间并没有发货。另外，也可能是因为客户获得了订单，但一直没有拿到发票。错误可能要等到系统审计时才会发现——而且即便在审计时， 也有可能检测不到任何错误。 到底发生了什么？当你更改客户的主键值时，你实际忽略了为那个客户的相关记录更新外键值。换言之，你创建了“孤儿”——也就是不和主键值匹配的外键记录。在这种情况下，系统没办法将订单的细节与客户对应起来。 没有引用完整性的保障，就可能输入不匹配的外键值。关系模型不允许这些“孤儿”记录。尽管你的数据库系统可能允许创建“孤儿”，但开发者必须主动地防止它们。要防止“孤儿”，最简单的办法就是实现引用完整性。 什么是引用完整性？ 关系模型强制引用完整性。你必须启用系统的引用完整性特性来满足关系规则。虽然在表和表之间启用引用完整性是一个简单的操作，但你必须理解这样做（和不这样做）的后果。从技术上说，完整性规则负责维护关系（也因此维护着数据）。有3种类型的完整性： Entity（实体）——必须不重复地标识每一条记录。 Referential（引用）——每个外键值都必须在相关的表中有一个匹配的主键值（或者为Null）。 Business（业务）——这些规则是业务特有的，与关系数据库理论无关。 如果禁用引用完整性，你在任何时候都可输入数据，只要数据不会违反其他表或字段属性 的要求，例如验证规则和数据类型等。相反，引用完整性会强制规则，限制你在什么时候能修改、添加或删除数据。启用引用完整性后，除非在相关的表中存在一个 匹配的主键值，否则不能输入一个新的外键值。如果相关的表中有一个匹配的外键值，就不能更改主键值。另外，如果在相关的表中有匹配的外键值，就不能删除一 个主键值。在这种情况下删除主键记录会造成“孤儿”。 决定何时启用引用完整性 除非你有非常特别的理由，否则在每个数据库中都应启用引用完整性。但在启用引用完整性之前，必须满足几方面的条件： 要强制引用完整性的关系必须基于一个主键或者一个惟一性的索引。 不可在不同数据库的表之间强制引用完整性。所有表都必须在同一个数据库内。 关系必须基于数据类型相同的字段（有的系统允许在自动编号字段和一个编号字段之间建立关系）。 一个例子 只有亲身体验，才能完全掌握引用完整性。以一个书籍数据库为基础，使用你的系统在 Books和Publishers表之间启用引用完整性。图A展示了Microsoft Access中的对话框和Relationships窗口（请查阅文档，了解如何在自己系统中启用引用完整性）。 　　 图A 在Books和Publisher表之间启用引用完整性 在两个表之间启用了引用完整性之后，数据输入将受到更多的限制： 不可在Books.PublisherFK中输入新的外键值，除非首先在Publishers.Publisher中将新值作为主键值输入。 如果Books.PublisherFK中存在一个匹配的值（外键），那么不能在Publishers.Publisher中更改一个值（主键）。 Books.PublisherFK中存在一个匹配的值（外键），那么不能从Publishers.Publisher中删除一个值（主键）。 输入、删除和更改数据时，如果违反了引用完整性，会发生什么呢？下面以 Microsoft Access为例来实际体验一下。首先打开Books表，然后输入Nee Nees Truck的记录，如图B所示。保存记录时会产生一个错误，因为RabbitPress在Publishers表中不是一个主键值。必须先在 Publishers表中为RabbitPress输入一条记录，否则引用完整性不认为RabbitPress是一个外键值。 　 　 图B 系统拒绝RabbitPress成为一个外键 接着试验一下修改主键值。请打开Publishers表，选择Apress记录（或者Que 及Sybex），然后试着删除记录。这样也会出错，如图C所示。系统不允许你删除记录，因为Books表包含匹配的外键值。但可以删除OReilly的 记录，因为Books表中没有任何记录将OReilly作为外键使用。 　 　 图C 不能删