移动数据库中移动终端上跨节点约束的优化检查方法

专利名称：移动数据库中移动终端上跨节点约束的优化检查方法
技术领域：
本技术涉及在移动数据库系统中的移动主机上的跨节点约束的一种优化检查方法，尤其涉及移动数据库在断接状态(包括主动和被动断接状态)下，在一个移动主机节点上，只利用本地数据及全局约束信息，生成一个本地条件，仅通过验证本地数据是否满足这个本地条件来检查全局完整性约束的方法。该方法能够极大的提高移动数据库中完整性约束检查的效率。
背景技术：
移动设备和无线通讯技术的发展带动了移动计算环境的发展。为了支持移动环境中的各种数据应用，移动数据库应运而生。移动数据库能够满足在任意地点、任意时刻访问任意数据的要求。
如图1所示，为移动数据库系统的体系结构模型。在一个移动环境中，移动主机MH(101)通常是通过移动服务支持站点MSS(102)与固定网络(105)连接的。固定网络中有若干个移动服务支持站点MSS，每个MSS负责建立一个无线网络单元(106)。固定网络内还有固定主机FH(103)和中央数据库服务器DBS(104)。
如图2所示，为移动数据库系统软件分布图。在MH(101)上，有一个嵌入式数据库EDBMS(202)，它从DBS(104)处缓存了一部分数据到移动端的嵌入式数据库EDB(203)中，用户可以对该EDBMS(202)进行操作或建立自己的移动应用程序MA(201)。EDBMS(202)除了存储功能之外，还担负着与MSS(102)同步的功能，通过与MSS(102)上的同步服务器软件SS(204)通信完成数据的上载、下载、同步等问题。同步服务器软件SS(204)则通过数据库连接205与中央数据库DBS(104)连接，205可以是开放数据库连接(Open Database Connectivity，ODBC)，或者是Java数据库连接(JavaDatabase Connectivity，JDBC)等。
图2将移动数据库系统主要分为三部分移动主机MH(101)、移动支持站MSS(102)、中央数据库DBS(104)，对各部分详细说明如下1)移动主机MH(101)为大小不定的移动设备，包括手机、PDA等小型的资源和处理能力非常有限的手持设备，也包括笔记本电脑这类具有移动性的计算和存储资源比较丰富的设备。在移动主机上，数据存储在本地数据库中，在手持设备上即为一个嵌入式数据库，我们将其称为EDB(203)(虽然在笔记本电脑上的数据库不一定是嵌入式的，但由于功能是一样的，因而我们在此都以EDB(203)称呼，以便与中心数据库区分)。对于EDB(203)由嵌入式数据库管理系统EDBMS(202)对其进行管理，这是一个微小型数据库。它不仅具备基本的数据库管理功能，还能够与中央数据库进行数据交换，具备数据同步功能。在移动主机MH(101)上，我们不仅可以通过无线网络实时查询和操作固定网络中的最新数据，同时还能够在网络断接时对本地EDBMS(202)缓存的数据进行操作。移动设备的用户通过基于EDBMS(202)来定制移动应用程序MA(201)。
2)移动支持站MSS(102)位于高速固定网络(105)中。每个移动支持站MSS(102)负责建立一个无线网络单元(也称为无线蜂窝)(106)。单元内的MH(101)与MSS(102)之间通过无线网络(206)连接。除了无线通信接口之外，MSS(102)还具有有线通信接口，与固定网络(105)内的固定主机FH(103)、中央数据库DBS(104)、其他MSS(102)进行连接。这样MSS(102)能够支持多种通信协议，包括网络通信协议TCP/IP、GSM、WAP、HTFP等，也支持串口等通信方式。MSS(102)的重要功能主要由其上的同步服务器SS(204)来承担。同步服务器SS(204)提供的功能包括通过MSS(102)的各种有线和无线通信方式与DBS(104)和MH(102)进行交互，实现数据交换的功能；并且提供了同步与冲突处理机制来保证数据的正确处理。
3)中央数据库DBS(104)。在此，出于简化说明的目的，我们将高性能的数据库服务器与其数据库管理系统统称为DBS(104)。可以是如ORACLE、SYBASE等的大型数据库系统。DBS(104)上存储着大量数据，MH(101)上缓存的数据都来自于中央数据库，在MH(101)上所更新的数据最终也会通过同步服务器SS(204)的处理存储在中央数据库DBS(104)中。同步服务器SS(204)通过数据库连接(205)与DBS(104)进行连接，将MH(101)上的数据同步请求提交给DBS(104)，然后进行实际的数据存取。
尽管移动数据库技术能够有效的支持移动计算环境中的各种数据应用，但也给目前的数据库实现技术带来了新的挑战，如移动客户端的移动特性和频繁断接。如何在这样的移动环境下进行数据管理引起了大家的关注。
在传统数据库系统中，客户端始终与数据库服务器保持连接，任何断开连接的情况均被视为故障事务而进行处理。而在移动计算环境中，由于移动环境本身的条件限制，即出于移动计算机电源容量相当有限、无线网络通信开销较大、网络条件、移动性以及使用方式等原因，使得移动计算机在使用过程中不采用保持持续联网的工作方式，而是主动或被动的经常处于断接状态，且通常是移动端的主动断接。因而移动数据库系统的一个重要特点是能够在移动设备与网络断接的状态下提供本地查询、修改等能力。
这样移动数据库系统在数据处理上与传统数据库系统有了很大的不同。本发明针对移动数据库的断接特点提出一个移动主机MH(101)上跨节点完整性约束的优化检查方法，旨在对EDBMS(202)做出一定的改进，使其能够快速有效的进行跨节点的完整性约束检查。
首先，我们通过一个例子来说明移动环境中采取新的完整性约束检查机制的必要性。
有一个移动销售管理系统。每个销售人员有一个手持设备，定期从中央数据库DBS(104)上下载商品及价格信息，并记录由他经手的销售信息。作出如下设计在移动主机MH(101)存储关系commodity和discount_order，ordinary_order(销售记录分为两种，一种是普通的，一种是会员专用，两种关系属性有所不同)，中央数据库DBS(104)上存有关系vip。
移动主机MH(101)上的关系说明commodity(commodity，price)，//存储商品号及该商品的基本价格。
discount_order(customer，commodity，quantity)，//存储该推销员对vip贵宾客户销售商品的信息，客户customer购买了数量为quantity的商品commodity。
ordinary_order(commodity，quantity)，//卖出数量为quantity的商品commodity。
固定端上的关系说明vip(customer，quota_quantity)，//存有贵宾客户的信息客户customer及他每次以vip身份最多购买商品的最大数量。
因为移动主机MH(101)存储容量有限，它仅存有商品信息。而一家商户有很多贵宾客户信息，贵宾客户可以享受打折待遇。或者出于保密原因，或者由于移动主机存储容量有限，这些信息仅存储在固定网络的DBS(104)上。当一名客户要求以折扣价格购买商品时，移动推销员需要将移动主机与网络连接上，查询该用户是否是贵宾客户。如果是，即可用折扣价格购买，并将该条包含客户姓名的销售记录插入到discount_order中。如果不是，则只能以普通价格购买，关系ordinary_order用来存储对普通客户的销售记录，不需包含客户信息。
在实际操作中，大部分是普通用户，则对他们的销售是普通模式，生成的销售订单插入ordinary_order。约束验证所需信息也都来自本地，在此不过多讨论。
当向关系discount_order插入一条信息时，就会检查三个参考完整性完整性约束C1检查关系commodity中是否存在该商品记录，这里只需在移动主机自身就可检验。
完整性约束C2当向一个关系discount_order插入一条信息时，会检查在关系vip中是否存在该用户的一条记录，如果存在，则该参考完整性满足，如果不存在，则不满足该参考完整性，不能执行插入操作。
完整性约束C3贵宾客户customer每次以vip身份最多购买商品的最大数量quota_quantity，即向关系discount_order插入一条交易信息时，必须检查待插入记录属性quantity的值是否小于该客户在customer表中的quota_quantity值，如果是，则不允许插入。
对于约束C2和C3，传统的验证方法需要与主数据库连接才能进行验证。但是在移动数据库中直接这样做的话代价很大，包括移动事务并发控制、网络通信开销、连接操作、上下载操作、同步及冲突处理、还有由于移动主机与固定端的数据库不是同一种类，还需经过相应的内部协议及界面层转换。
为了尽可能节约以上这些开销，我们提出了一种断接状态下的移动数据完整性约束检查方法。

发明内容
针对传统约束检查机制的不足，我们为移动数据库系统提出一种移动主机MH(101)上跨节点约束的优化检查方法，对EDBMS(202)中的约束检查机制做出改进。该方法的核心是在一个移动主机MH(101)上只利用本地数据及全局约束信息，生成一个本地条件，仅通过验证本地数据是否满足这个本地条件来检查全局完整性约束。该方法能够极大的提高移动数据库中完整性约束检查的效率。基于这个核心，如图3所示，我们对具体的跨节点检查流程在“具体实施方式
”中进行阐述。
参照附图以及下面的详细说明，将会清楚的理解本发明的其他目的、特征和优点。
通过下面的详细说明，本领域普通技术人员将会清楚的理解本发明的目的、特征及优点。


附图中图1示出能够应用本发明的移动数据库系统的体系结构模型。
图2示出能够应用本发明的移动数据库系统的软件分布图。
图3示出本发明的流程图——应用于移动数据库系统的LTC约束检查流程图。
具体实施例方式
上面在“背景技术”一节中结合图1、图2介绍了移动数据库的体系结构、软件分布以及采用新的完整性约束检查机制的必要性。
1、下面首先介绍本发明的核心部分——完整性约束的本地检查方法(LTC检查)。
LTC检查是一个用本地信息验证全局完整性的方法。这个方法生成一个本地测试条件——如果本地数据满足这个条件，那么全局约束就会被满足。如果不能满足，则需要进一步执行传统的完整性约束检查。下面对LTC检查进行概述。(以下“本地”即指移动主机(101))首先必须满足以下条件1)对本地关系L进行修改；2)一个完整性约束C覆盖了本地和远程关系；3)假定修改之前L没有违背这个约束。
这个测试条件能在编译时一次生成，并能在运行时使用进行修改的元组来实例化。因为优化生成条件仅是在本地数据上，所以这种方法不会产生并发问题。
在此，我们使用一阶逻辑描述完整性约束断言语言。完整性约束断言的这种逻辑形式使得本地测试条件和验证它的正确性更为方便。一个完整性约束断言有以下描述形式(C)XYZ[(L(X)∧R1(Y1)∧...∧Rk(Yk)∧g(X，Y，Z，c))(S1(Y1’，Z1’)∨...∨Sn(Yn’，Zn’))]说明L代表本地关系；R1，...Rk，S1，...，Sn代表远程关系；X＝{X1，...，Xt}是仅在L和g中出现的受全称量词约束的变元集合。
Y＝{Y1，...，Yu}是仅在R1，...，Rk，Si，...，Sn和g中出现的受全称量词约束的变元集合。
Z＝{Z1，...，Zv}是仅在S1，...，Sn和g中出现的受存在量词约束的变元集合。
c＝{c1，...，cw}是仅在g中出现的常量集合。
g(X，Y，Z，c)是“＝”连接符合非等于连接符“＜，＞，＝，＝”。
YiY，是在关系Ri中出现的变元集合，1＝i＝k；Yi’Y，是在关系Si中出现的受全称量词约束的变元集合，1＝i＝n；Zi’Z，是在关系Si中出现的受存在量词约束的变元集合，1＝i＝n；对这个完整性约束有以下限制1)受存在量词约束的变元仅能够出现在完整性约束断言对应蕴含公式的远程关系上。
2)受全称量词约束的变元出现在一个远程关系上，断言或者等于一个常量，或者出现在本地的一些关系上，等价于出现在本地的一个关系上的一个变元。
3)出现在g里的受存在量词约束的变元等于一个常量或一个受全称量词约束的变元。
为了确保约束的实际验证，必须保证1)、2)、3)的完整性约束上的限制。
在一个完整性约束断言C中，对每个在X，Y，和Z里的变元，令变元的个体域是变元出现的关系的列的域。如果对于X和Y里的变元的所有的值的分配，都存在Z中的一个变元的值的分配，满足如果1)在关系L里有一个值被分配给X的元组；2)对每个Ri，C里1≤i≤k，关系Ri中有一个元组值被分配给Yi；3)谓词g满足使用常量c和分配给X，Y，和Z的值。
这样对一些Si，C中1≤i≤n，关系Si中有一个元组，它的值分配给Yi’和Zi’。
本发明提出的LTC约束检查方法对于一个完整性约束CX YZ[(L(X)∧R1(Y1)∧...∧Rk(Yk)∧g(X，Y，Z，c))(S1(Y1’，Z1’)∨...∨Sn(Yn’，Zn’))]，令v是在本地关系L上被操作后的元组。则本地测试条件如下(LTC(C，v))XYZ[L(X)∧(g(v，Y，Z，c)g(X，Y，Z，c))]。
如果关系L满足LTC(C，v)，那么元组v在L中不违背约束C。注意只有关系L被包含在LTC(C，v)中，这个测试条件并不引用任何远程关系R1，...，Rk，S1，...Sn。
这样，考虑一个完整性约束C和在关系L操作之后的一个元组v。如果在修改操作前之前数据库满足完整性约束谓词，且如果本地测试条件LTC(C，v)通过本地关系L满足，那么数据库在得到新元组v的修改操作之后满足完整性约束断言C。
LTC方法在编译时间里获得，通过将v作为一个参数来替代使用得到元组的实际值。当一个元组在执行的时候，被实际的作用到本地关系L中，LTC(C，v)通过这个元组来示例，且使用本地关系来评估。为了本地验证LTC(C，v)，需要从蕴含式(g(v，Y，Z，c)g(X，Y，Z，c))里消除Y和Z里的受全称量词约束的变元。消除Y和Z里的受全称量词约束的变元导致了X里的变元上的一个约束的集合成为了本地关系中覆盖元组的选择条件。
2、蕴含式复杂度及性能LTC条件有一个包含g的蕴含式，g是算术谓词的连接。如果本地关系L包含一个满足这个蕴含式的元组，那么我们说本地关系满足测试。为了评估测试条件，蕴含式的可满足性需要被简化为在关系L上的一个查询。因而我们需要从蕴含式Y和Z里消除变元。Y和Z里的变元对应于远程关系。上例中说明了消除变元的必要。如果g包含了等式谓词，那么消除受全称量词约束的变元是传递等式就很简单。这个传递的花费与g中等式的数量是线性关系。但如果蕴含式中包含了多个不等式，则用数学方法比较简化蕴含式的复杂度是O(n3)，这里n是g中不等式的数量。所以考虑到移动端有限的资源条件，蕴含式复杂度如果在一定范围之内，根据LTC条件进行验证将会减少联机概率，大大提高运行效率。
3、下面基于以上方法——完整性约束的本地检查方法(LTC)，结合图3说明本发明的具体实施流程。
本发明允许一个全局约束可以跨越了一个或多个移动数据库结点以及主数据库接点，但我们只在一个移动数据库节点上通过存取本地数据及这个全局的约束信息就能够测试一致性是否满足。这个方法生成一个本地条件——如果本地数据满足这个条件，那么全局约束就会被满足。如果不能满足，则需要在移动节点重新联机时，进一步执行约束检查。该方法按以下几个步骤进行移动数据库的数据完整性约束检查(其流程如图3所示)1)首先用户对移动数据库做修改操作；2)对这个修改操作进行约束判断如果它所涉及的关系不包含完整性约束，则跳过完整性约束检查，直接进行修改操作。否则我们需要对其进行进一步检查操作。
3)检查该修改操作的关系中是否包含非本地关系。如果不存在，可以按照原有的完整性约束检查机制进行验证。如果存在非本地关系，则进行蕴含式复杂度计算。
4)由于移动系统计算资源有限，且不同移动设备的计算能力不同，预先根据系统资源配置设定系统承受值，如果这个蕴含式复杂度超过了系统承受值，则要求联机做全局完整性约束检查。如果在系统承受范围之内，则执行LTC检查。如果满足LTC条件，则全局约束得到满足。如果LTC条件不能得到满足，则也要求联机进行进一步检查。
5)对上一步中需要做联机约束检查的作连接同步操作，然后进行进一步的验证。
6)根据以上几点及联机检查的结果，有以下几种约束检查的结果状态状态1使用原有检查机制，执行本地检查，满足完整性约束；状态2使用原有检查机制，执行本地检查，不满足完整性约束；状态3执行LTC本地检查，满足完整性约束；状态4本地未能检查出完整性约束，也不能即时进行执行联机检查；状态5本地未能检查出完整性约束，联机但不成功；
状态6本地未能检查出完整性约束，联机成功，检查得知满足完整性约束；状态7本地未能检查出完整性约束，联机成功，检查得知不满足完整性约束记录所有的检查结果，约束检查过程结束。
最后需要根据检查结果状态值来决定是否执行这个移动端的本地修改。如果检查结果满足所有的完整性约束条件，则允许执行本地修改；否则，因为移动数据库的实现与它将要应用的领域有一定关系，所以应结合领域特点及各状态做出相应实现。这不属于完整性约束检查内容，不再详述。
根据以上流程，我们针对“背景技术”中的移动销售管理系统给出了具体的验证过程示例。此处着重描述该验证示例的LTC验证过程。
在准备向关系discount_order插入一条订单记录时，首先确定该关系上的完整性约束。与之关联有两条参考完整性约束C1和C2、C3需要检查。由于约束C1中只有本地关系参与，因此可以直接进行检查。对于C2、C3，由于该约束包含了远程关系vip，为了尽量避免移动事务操作和减小网络代价，希望能够采用移动主机测试条件LTC先进行本地检查。
检查1)按照前面的方法，可以将约束C2表述如下customer，commodity，quantitycustomer’，quota_quantity[(discount_order(customer，commodity，quantity)∧(customer＝customer’))vip(customer，quota_quantity)]这里移动主机上的本地关系就是关系discount_order，r就是customer＝customer’。首先计算蕴含式复杂度，这里r中只包含等式谓词，复杂度是O(n)，移动主机计算代价很小，那么可以进移动主机本地测试。
被插入的元组的参数为＜customerv，commodityv，quantityv＞。那么根据移动主机本地测试条件LTC，本地测试即为customer，commodity，quantitycustomer’[discount_order(customer，commodity，quantity)∧((customer’＝customerv)(customer＝customer’))]假定元组(customer105，commodityAA，50)被插入到关系discount_order中，那么参数变元就会被customev代替，生成了以下测试条件(MT1)customer，commodity，quantitycustomer’[discount_order(customer，commodity，quantity)∧((customer’＝customer105)(customer’＝customer))]然后，将受全称量词约束的变元从测试条件(MT1)中消除，最后得出一个仅包含了移动主机本地关系变元的测试条件。变元quota_quantity因为不在(MT1)中出现，因而可以被消除；而变元customer’可以通过传递等式customer’＝customer105被消除。这样我们得出customer，commodity，quantity 根据这个式子，我们就可以在discount_order关系中查询是否已经存在一个元组，它的customer属性值就是customer105。如果这个查询得出一个非空的集合，那么(customer105，commodityAA，50)就没有违背约束C2。否则的话，如果原来不存在这样一条customer属性值customer105记录，我们还必须根据移动数据库系统的实际应用，申请联机检查，在合适的情况下与固定端连接来进行统一的参考完整性约束检查。
测试2)按照前面的方法，可以将约束C3表述如下customer，commodity，quantity，customer’，quota_quantity[(discount_order(customer，commodity，quantity)∧(customer＝customer’)∧vip(customer，quota_quantity))(quantity＜quota_quantity)]亦即customer，commodity，quantity，customer’，quota_quantity[(discount_order(customer，commodity，quantity)∧(customer＝customer’)∧vip(customer，quota_quantity)∧(quantity＞＝quota_quantity))FALSE]这里移动主机上的本地关系仍然是关系discount_order，g就是(customer＝customer’)∧vip(customer，quota_quantity)∧(quantity＞＝quota_quantity).
被插入的元组的参数为＜customerv，commodityv，quantityv＞。那么移动主机本地测试即为customer，commodity，quantitycustomer’，quota_quantity[ discount_order(customer，commodity，quantity)∧((customer’＝customerv∧quantityv＞＝quota_quantity)(customer＝customer’)∧(quantity＞＝quota_quantity)))]假定元组(customer105，commodityAA，50)被插入到关系discount_order中，那么参数变元就会被customerv代替，生成了以下测试条件(MT2)customer，commodity，quantitycustomer’[discount_order(customer，commodity，quantity)∧((customer’＝customer105∧50＞＝quota_quantity)(customer’＝customer∧quantity＞＝quota_quantity)]然后，将受全称量词约束的变元从测试条件(MT2)中消除，最后得出一个仅包含了移动主机本地关系变元的测试条件。因而可以被消除；而变元customer’可以通过传递等式customer’＝customer105被消除，quota_quantity也可通过传递不等式50＞＝quota_quantity消除。这样我们得出customer，commodity，quantity[discount_order(customer，commodity，quantity)∧customer＝customer105∧quantity＞＝50]根据这个式子，我们就可以在discount_order关系中查询是否已经存在一个元组，它的customer属性值就是customer105，并且quantity值大于或等于50。如果这个查询得出一个非空的集合，那么(customer105，commodityAA，50)就没有违背约束C3。否则的话，约束条件在移动主机不能检查出是否满足，我们还必须根据移动数据库系统的实际应用，申请联机检查，在合适的情况下与固定端连接来进行统一的参考完整性约束检查。
上面说明了一种移动数据库中移动主机上跨节点约束的优化检查方法。本领域普通技术人员应理解，在不脱离本发明范围的情况下，可以对本发明各成分的内容或安排进行各种改变和修改。本发明完全符合发明专利申请要件，故依法提出发明专利申请，请详查并批准授予专利权，以保障发明者的权益。
权利要求
1.一种移动数据库中移动主机上跨节点约束的优化检查方法，包括用户通过移动主机上的嵌入式数据库管理系统EDBMS对嵌入式数据库EDB做修改操作；对这个修改操作进行约束判断，以决定跳过完整性约束检查还是需要进行完整性约束检查；检查该修改操作的关系中是否包含非本地关系，以决定按原有的完整性约束检查机制检查还是进行蕴含式复杂度计算；蕴含式复杂度计算，以决定是否执行LTC检查；LTC检查，即为本地检查全局约束方法，如果满足LTC条件，则全局约束得到满足，如果LTC条件不能得到满足，则也要求联机进行进一步检查；确定是否做联机检查；联机约束检查，如需要联机约束检查则联机与同步服务器通信进行全局约束检查；记录约束检查的结果状态。
2.如权利要求1所述的方法，还包括对用户输入的修改操作进行约束判断如果它所涉及的关系不包含完整性约束，则跳过完整性约束检查，直接进行修改操作，否则我们需要对其进行进一步检查操作。
3.如权利要求1所述的方法，还包括检查该修改操作的关系中是否包含非本地关系如果不存在，可以按照原有的完整性约束检查机制进行验证，如果存在非本地关系，则进行蕴含式复杂度计算。
4.如权利要求1所述的方法，还包括蕴含式复杂度计算由于移动系统计算资源有限，且不同移动设备的计算能力不同，预先根据系统资源配置设定系统承受值，如果这个蕴含式复杂度超过了系统承受值，则要求联机做全局完整性约束检查；如果在系统承受范围之内，则执行LTC检查；如果满足LTC条件，则全局约束得到满足；如果LTC条件不能得到满足，则也要求联机进行进一步检查。
5.如权利要求1所述的方法，还包括LTC检查允许一个全局约束可以跨越了一个或多个移动数据库的结点以及中央数据库结点，但我们只在一个移动数据库节点上通过存取本地数据及这个全局的约束信息就能够测试一致性是否满足，这个方法生成一个本地条件——如果本地数据满足这个条件，那么全局约束就会被满足，如果不能满足，则需要在移动节点重新联机时，进一步执行约束检查。
6.如权利要求1所述的方法，还包括确定是否做联机约束检查通过计算蕴含式复杂度，判断蕴含式复杂度是否小于移动系统承受度设定值，如果小于，可根据系统特点确定是否做联机检查；通过执行LTC检查，如本地数据不能确定满足全局约束，可根据系统特点确定是否做联机检查。
7.如权利要求6所述的方法，还包括联机约束检查若需要做联机约束检查，则作连接同步操作，然后按传统方法进行进一步的验证。
8.如权利要求1所述的方法，还包括记录约束检查的结果状态，约束检查过程结束，根据以上几点及联机检查的结果，有以下几种约束检查的结果状态状态1使用原有检查机制，执行本地检查，满足完整性约束；状态2使用原有检查机制，执行本地检查，不满足完整性约束；状态3执行LTC本地检查，满足完整性约束；状态4本地未能检查出完整性约束，也不能即时进行执行联机检查；状态5本地未能检查出完整性约束，联机但不成功；状态6本地未能检查出完整性约束，联机成功，检查得知满足完整性约束；状态7本地未能检查出完整性约束，联机成功，检查得知不满足完整性约束。
全文摘要
本技术涉及在移动数据库系统中的移动主机上的跨节点约束的一种优化检查方法，尤其涉及移动数据库在断接状态(包括主动和被动断接状态)下，在一个移动主机节点上，只利用本地数据及全局约束信息，生成一个本地条件，仅通过验证本地数据是否满足这个本地条件来检查全局完整性约束的方法。该方法能够极大的提高移动数据库中完整性约束检查的效率。
文档编号G06F17/30GK1862531SQ20051006926
公开日2006年11月15日 申请日期2005年5月13日 优先权日2005年5月13日
发明者蒋宁 申请人:蒋宁