摘要：本论文主要讨论基于Client/Server数据完整性约束及其如何实施企业业务规则，并以PowerBuilder为例，介绍了数据完整性约束的实现技术。
关键词：Client/Server;数据完整性约束;企业业务规则
中图分类号：G250.74 文献标识码:A
DBMS已从早期的、分散的一个计算模型、网络/文件服务计算模型(针对文件)发展到现在的Client/Server计算模型(针对表中的一行)。Client/Server模型是非对等的(decoupled)，客户发出服务请求，服务器作出响应，提供服务，即所谓的“请求驱动”。DB的Client/Server系统由Database Server、客户应用程序和网络组成。
由于现在的数据库都是开放、多用户共享，因此维护数据库的正确性至关重要。数据库的完整性描述为数据库内容的完整性约束集合，其中完整性约束指数据库的一个状态是否合理。DBS检查数据的状态和状态转换，判定它们是否合理，是否应予接受。对一个数据库操作，要判定其是否符合完整性约束，全部断言无矛盾时才可以执行。完整性约束的形式化定义I=(O,P,A,R),其中O是完整性约束所涉及的数据对象集合，P是对象所满足的谓词，A是触发检查的条件，R是约束不满足时的反应动作。
1 常见的数据完整性约束
根据分类角度不同，可将完整性约束分为如下几类：
a. 域、元组、集合完整性；b. 立即约束和推迟(到EOT)约束；c. 状态约束和状态演变约束。d. 标准和定制的数据完整性约束。
在实际的系统中，一般将数据完整性约束分为标准的数据完整性约束和定制的数据完整性约束。标准的数据完整性约束是DBS已经实现的内部规则，包括域完整性、实体完整性和引用完整性。
域完整性(Field Integrity)保证一个数据库不包含无意义的或不合理的值，即保证表的某一列的任何值是该列域(即合法的数据集合)的成员。方法是限制列的数据类型、精度、范围、格式和长度等。
实体完整性(Entity Integrity)保证一个表中的每一行必须是唯一的(元组的唯一性)。为保证实体完整性，需指定一个表中的一列或一组列作为它的主键(Primary Key)。一个表中每行的主键必须确实含有一个值。一个表只能含有一个主键，如需要从其它列中除去重复的值，可以将一个或一组非主键列指定为一个候选键或唯一值键。
引用完整性(Reference Integrity)定义了一个关系数据库中不同的列和不同的表之间的关系(主键与外键)。要求一列或一组列中的值必须要与相关的一列或一组列中的值相匹配。从属的一列或一组列称之为外键(Foreign Key)。被引用的列或一组列称之为父键，父键必须是一个主键或唯一键。外键属于子表或明细表，父键属于父表或主表。若父键和外键属于同一表，则称之为自引用完整性。子表某行的外键必须与主表的主键相匹配，只要依赖于某主键的外键仍存在，主表中包含该主键的行就不能删除。
由于每个公司的数据库都有自己独特的业务规则集，所以系统必须有一种方式来实现定制的业务规则即定制的数据完整性约束。定制的数据完整性约束可由如下几种方法实施。
一种最原始的方法是将每一个完整性约束编入要访问数据库的每个应用程序中，缺点是在每个相关的数据库应用程序中，开发者都要对相同的完整性规则进行编码、测试和排错。若某一规则变动，所有相关的应用程序都得改动。
用户定义的数据类型(User-defined Data Type)是由标准数据类型导出的新数据类型，它比标准的数据类型更准确地限定了数据输入的范围，可以通过定义约束(Check) 对输入的数据进行限制，定义缺省（Default）对输入的数据类型进行限制，定义规则（Rule）对用户输入的数据进行检验，最后可以定义存储过程(Stored Procedure)和触发器（Trigger）来保证逻辑上相关的数据表之间的数据完整性和一致性。
2 Client/Server模型下实施企业规则的准则
在Client/Server系统中，前端和后端都提供数据完整性约束。在前端可进行域完整性约束，并能定制业务规则。在后端几乎可以实现上述所列的所有的完整性约束。E.F.Codd在衡量关系数据库的十二条准则之第十条指出关系完整性约束条件必须用数据子语言定义并存储在数据字典中，而不是在应用程序中。这样，当完整性约束改变时，只要修改数据字典即可，完整性的改变一般不会在逻辑上影响应用程序的活动。
前端应用程序也可以进行某些完整性检查并实施企业规则，但是这些做法不能用于取代在数据库里的完整性约束定义。如果数据库设计者完全正确地说明了所有的约束和企业规则，则任何违反约束和规则的数据操作都会引起数据库错误。前端应用程序的任务是尽量减少产生数据库错误的可能性，只有从这个意义上说，前端应用程序才应当包含完整性检查和实施事务规则。当数据库没有完整性约束时，前端应用程序必须实施企业规则。
由此我们得出在实施企业规则时须遵循如下准则：
a. 集中在数据库中实施企业规则；b. 减少对数据库请求的次数，尽量减少返回结果
我们在实施企业规则时，应将所有的企业规则定义在数据字典中，应用程序在向数据库提交SQL语句之前尽量减少由用户引起数据库错误的可能性，使应用程序运行顺畅，对用户友好，开销少。
3 PowerBuilder数据完整性约束的实现技术
PowerBuilder提供了丰富的构件，能很方便地开发出界面友好、功能强大的应用程序。下面以PowerBuilder为例，说明开发工具如何实现数据完整性约束，PowerBuilder的其它构件也提供类似实现完整性约束的方法。
◆利用列的编辑风格(Edit Style)限制列的长度、格式、值域等。PowerBuilder提供无线按钮(Radio Button)、检查框(Check Box)、下拉式数据窗口(DropDown DataWindow)、下拉式列表框(DropDown List)、编辑屏蔽(Edit Mask)和编辑(Edit)等编辑风格来检查列的数据类型。
◆利用列的有效性验证规则(Validation Rule)对输入数据进行限制。在Validation Rule对话框内，可输入规则定义(Rule Definition)和有效性规则出错信息(Validation Error Message)。
◆可在ItemChanged事件的Script程序里对输入数据进行进一步的有效性验证，若输入数据不能通过在ItemChanged事件里所设置的检查，则返回动作码1，拒绝输入数据。
◆当应用程序调用函数Update()更新数据库之前，触发UpdateStart事件。该事件是用于进行数据有效性验证的最后一次机会。若输入数据的有效性验证失败，则返回动作码1，拒绝数据更新。
◆针对那些数据库要求必须具备值的列(即那些具有NOT NULL约束的列)，可将对应的数据窗口的列置为必备域(Required Field)。但是必备域的约束对用户来说并不友好，用户必须输入一个值，否则无法离开该列。一种替代的办法是在UpdateStart事件里检查列(在数据库中为NOT NULL列)的值是否为NULL。
◆利用自定义有效性验证函数进行常规的数据检查，有助于应用程序的标准化和简化。这些函数可以用在列的有效性验证规则，也可以用在Itemchanged事件的Script程序中。一般自定义有效性验证函数被设计成全局函数、返回布尔型结果。
值得注意的是有效性验证规则对数据窗口类的所有实例都通用，而在Itemchanged事件的Script程序里进行有效性验证与具体的数据窗口密切相关。有些有效性验证需进行数据库查询，若需要很高的系统代价，尽量避免使用。
4 结语
本文讨论了分布计算环境下的数据完整性约束的概念及其实现技术。另外，基于Browser/Server计算模式下的应用系统同样需要考虑数据完整性约束的问题，且其与基于Client/Server的数据完整性约束相类似。
参考文献
[1]李昭原主编.数据库技术新发展 清华大学出版社，1999
[2]周龙镶编著.数据库管理系统实现技术 中国地质大学出版社，2000