对数据库中的加载数据进行逻辑验证的方法和系统

摘要

本发明涉及对数据库中的加载数据进行逻辑验证的方法和系统。提供了一种用于对数据库中的加载数据进行逻辑验证的系统，包括：规则引擎，被配置为响应于用于进行逻辑验证的新规则的添加和更新中的至少之一，找出变动规则，该变动规则包括新规则相对于现有规则的变动部分；对象容器，包含已利用现有规则进行了验证的一个或多个对象实例，其中对象实例仅包含从数据库中提取的与现有规则相关的数据；以及验证引擎，被配置为在确定所述变动规则涉及所述对象实例包含的数据以外的额外数据的情况下从数据库提取所述额外数据并加入到相应的对象实例中，并且利用所述新规则的至少一部分对所述对象容器中的相关对象实例进行逻辑验证。

说明书

技术领域

本发明涉及计算机领域，具体地说，本发明涉及一种用于对数据 库中的加载数据进行逻辑验证的方法和系统。

背景技术

在应用软件的生命周期中，通常会出现如下的在进行逻辑验证之前 预先得到数据对象集合的情况：例如，应用逻辑级别的输入/更新、加 载、批量加载、来自客户的数据迁移、来自测试者的出于大数据量目 的的数据加载。当前，这种匹配是通过人工方式或者使用内部工具来 完成的。

在应用中，每个访问者对业务对象有着不同的验证逻辑。例如，在 一个购物网站上，第一开发者可能要求从买家输入的出价需要高于商 品的底价，而第二开发者可能要求卖家输入的商品的型号必须是已知 型号。图2是示出了应用中的业务对象与数据库中的数据对象之间的 映射关系的示意图。一个业务对象可能涉及数据库中的多个表中的多 个列。从图2中可以看出，业务对象被映射到数据库中的数据对象的 表Object_1_Table，该表中的列分别取自数据库中的实际数据表 Element_1_Table、Element_2_Table、Element_3_Table等，并且来自 不同开发者的逻辑验证可能涉及Object_1_Table中的不同列。例如， 第1开发者的逻辑验证涉及到Element_1_Table的Attr_1列和 Element_2_Table的Attr_2列，第2开发者的逻辑验证涉及到 Element_1_Table的Attr_1列、Element_2_Table的Attr_2列和 Element_3_Table的Attr_3列，第3开发者的逻辑验证涉及到 Element_1_Table的Attr_1列、Element_3_Table的Attr_3列和 Element_3_Table的Attr_4列。

在现有技术中，当验证规则改变（诸如有验证规则的添加或更新） 时，需要利用新的验证规则对数据库中的数据进行重新验证。这种重 新验证针对的是整个数据对象表。此外，当发生批量加载、数据库迁 移或者SQL插入/更新时，需要对新插入或者更新的数据进行逻辑验 证。

批量加载数据通常要求进行业务逻辑验证。在进行逻辑验证时，需 要使应用离线，从而在后台对批量加载的数据进行逻辑验证。这样， 如何在新的数据或新的规则被加入后能够快速地完成逻辑验证使得应 用能够快速地回到在线状态就成为本技术领域的一个挑战。

发明内容

基于以上的描述，希望提供一种用于对数据库中的加载数据进行逻 辑验证的系统和方法，该系统和方法通过仅仅利用规则或数据的变动 部分来进行验证，能够减少验证的成本从而实现更高的性能。

根据本发明的一个方面，提供了一种用于对数据库中的加载数据进 行逻辑验证的系统，包括：规则引擎，被配置为响应于用于进行逻辑验 证的新规则的添加和更新中的至少之一，找出变动规则，该变动规则包括 新规则相对于现有规则的变动部分；对象容器，包含已利用现有规则进行 了验证的一个或多个对象实例，其中对象实例仅包含从数据库中提取的与 现有规则相关的数据；以及验证引擎，被配置为在确定所述变动规则涉 及所述对象实例包含的数据以外的额外数据的情况下从数据库提取所 述额外数据并加入到相应的对象实例中，并且利用所述新规则的至少 一部分对所述对象容器中的相关对象实例进行逻辑验证。

根据本发明的另一个方面，提供了一种用于对数据库中的加载数 据进行逻辑验证的方法，包括：响应于用于进行逻辑验证的新规则的添 加和更新中的至少之一，找出变动规则，该变动规则包括新规则相对于现 有规则的变动部分；在确定所述变动规则涉及对象容器中的对象实例包 含的数据以外的额外数据的情况下，其中所述对象容器包含已利用现有 规则进行了验证的一个或多个对象实例并且对象实例仅包含从数据库中 提取的与现有规则相关的数据，从数据库提取所述额外数据并加入到相 应的对象实例中；以及利用所述新规则的至少一部分对所述对象容器 中的相关对象实例进行逻辑验证。

根据本发明的另一个方面，提供了一种用于对数据库中的加载数 据进行逻辑验证的系统，包括：对象容器，包含已利用现有验证规则进 行了验证的一个或多个对象实例，其中对象实例仅包含从数据库中提取的 与现有验证规则相关的数据；验证引擎，被配置为对于与现有验证规则 相关的每个列，在数据库中为该列添加触发器，其中，所述触发器响 应于在数据库中该触发器被添加到的列中的数据的添加和更新中的至 少之一而发出触发信号；以及规则引擎，被配置为响应于所述触发器的 触发信号，从现有验证规则中找出由与添加或更新的数据相关的规则组 成的规则子集；其中，所述验证引擎还被配置为，响应于所述触发器的 触发信号，把在数据库中添加或更新的所述数据提取到所述对象容器 中形成具有第二标记的对象实例，并且利用所述规则子集仅对所述对 象容器中具有第二标记的对象实例进行逻辑验证，其中所述第二标记 不同于所述对象容器中的其它对象实例所具有的第一标记。

根据本发明的另一个方面，提供了一种用于对数据库中的加载数 据进行逻辑验证的方法，包括：对于与现有验证规则相关的每个列， 在数据库中为该列添加触发器；所述触发器响应于在数据库中该触发 器被添加到的列中的数据的添加和更新中的至少之一而发出触发信 号；以及响应于所述触发器的触发信号，从现有验证规则中找出由与添 加或更新的数据相关的规则组成的规则子集；把在数据库中添加或更 新的所述数据提取到对象容器中形成具有第二标记的对象实例，并且 利用所述规则子集仅对所述对象容器中具有第二标记的对象实例进行 逻辑验证，其中所述第二标记不同于所述对象容器中的其它对象实例 所具有的第一标记，其中，所述对象容器包含已利用现有验证规则进行 了验证的一个或多个对象实例，其中对象实例仅包含从数据库中提取的与 现有验证规则相关的数据。

采用根据本发明的用于对数据库中的加载数据进行逻辑验证的系 统和方法，通过在数据被改变或加载了新数据时或者在输入了新规则 时，识别必要的验证规则（下文所述的变动规则）并且仅仅针对该变 动规则所影响的数据部分来验证所述变动规则，从而使应用能够快速 完成验证并回到在线状态，提高了系统的性能。

另外，当批量数据被加载到系统中时，验证引擎仅仅对与已有验 证规则有关的数据进行逻辑验证，而不是对所有加载的数据进行逻辑 验证，因为有些加载数据可能与任何验证规则都无关。这样就降低了 进行逻辑验证的成本。

附图说明

通过结合附图对本公开示例性实施方式进行更详细的描述，本公开的 上述以及其它目的、特征和优势将变得更加明显，其中，在本公开示例 性实施方式中，相同的参考标号通常代表相同部件。

图1示出了适于用来实现本发明实施方式的示例性计算机系统/服务器 12的框图。

图2是示出了应用中的业务对象与数据库中的数据对象之间的映射 关系的示意图。

图3是示出了根据本发明的一个实施例的用于对数据库中的加载数据 进行逻辑验证的系统300的处理的示意图。

图4示意性地示出了对象容器中的数据对象的概念。

图5是示出了根据本发明的另一个实施例的用于对数据库中的加载数 据进行逻辑验证的系统300的处理的示意图。

图6是示出了根据本发明实施例的用于对数据库中的加载数据进行 逻辑验证的方法的流程图。

具体实施方式

下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中 显示了本公开的优选实施方式，然而应该理解，可以以各种形式实现本 公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是 为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给 本领域的技术人员。

所属技术领域的技术人员知道，本发明可以实现为系统、方法或计 算机程序产品。因此，本公开可以具体实现为以下形式，即：可以是完 全的硬件、也可以是完全的软件（包括固件、驻留软件、微代码等），还 可以是硬件和软件结合的形式，本文一般称为“电路”、“模块”或“系 统”。此外，在一些实施例中，本发明还可以实现为在一个或多个计算机 可读介质中的计算机程序产品的形式，该计算机可读介质中包含计算机 可读的程序代码。

可以采用一个或多个计算机可读的介质的任意组合。计算机可读介 质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存 储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半 导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质 的更具体的例子（非穷举的列表）包括：具有一个或多个导线的电连接、 便携式计算机磁盘、硬盘、随机存取存储器（RAM）、只读存储器 (ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑 磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任 意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存 储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或 者与其结合使用。

计算机可读的信号介质可以包括在基带中或者作为载波一部分传播 的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号 可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的 任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质 以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传 输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包 括——但不限于——无线、电线、光缆、RF等等，或者上述的任意合适 的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本发明操 作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言 —诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸 如”C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机 上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部 分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或 服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意 种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算 机，或者，可以连接到外部计算机（例如利用因特网服务提供商来通过因 特网连接）。

下面将参照本发明实施例的方法、装置（系统）和计算机程序产品的 流程图和/或框图描述本发明。应当理解，流程图和/或框图的每个方框以 及流程图和/或框图中各方框的组合，都可以由计算机程序指令实现。这 些计算机程序指令可以提供给通用计算机、专用计算机或其它可编程数 据处理装置的处理器，从而生产出一种机器，这些计算机程序指令通过 计算机或其它可编程数据处理装置执行，产生了实现流程图和/或框图中 的方框中规定的功能/操作的装置。

也可以把这些计算机程序指令存储在能使得计算机或其它可编程数 据处理装置以特定方式工作的计算机可读介质中，这样，存储在计算机 可读介质中的指令就产生出一个包括实现流程图和/或框图中的方框中规 定的功能/操作的指令装置(instruction means)的制造品 （manufacture）。

也可以把计算机程序指令加载到计算机、其它可编程数据处理装 置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设 备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算 机或其它可编程装置上执行的指令能够提供实现流程图和/或框图中的方 框中规定的功能/操作的过程。

图1示出了适于用来实现本发明实施方式的示例性计算机系统/服务器 12的框图。图1显示的计算机系统/服务器12仅仅是一个示例，不应对本 发明实施例的功能和使用范围带来任何限制。

如图1所示，计算机系统/服务器12以通用计算设备的形式表现。计算 机系统/服务器12的组件可以包括但不限于：一个或者多个处理器或者处 理单元16，系统存储器28，连接不同系统组件（包括系统存储器28和处 理单元16）的总线18。

总线18表示几类总线结构中的一种或多种，包括存储器总线或者存储 器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中 的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工 业标准体系结构（ISA）总线，微通道体系结构（MAC）总线，增强型ISA 总线、视频电子标准协会（VESA）局域总线以及外围组件互连（PCI） 总线。

计算机系统/服务器12典型地包括多种计算机系统可读介质。这些介 质可以是任何能够被计算机系统/服务器12访问的可用介质，包括易失性 和非易失性介质，可移动的和不可移动的介质。

系统存储器28可以包括易失性存储器形式的计算机系统可读介质，例 如随机存取存储器（RAM）30和/或高速缓存存储器32。计算机系统/服 务器12可以进一步包括其它可移动/不可移动的、易失性/非易失性计算 机系统存储介质。仅作为举例，存储系统34可以用于读写不可移动的、 非易失性磁介质（图1未显示，通常称为“硬盘驱动器”）。尽管图1中 未示出，可以提供用于对可移动非易失性磁盘（例如“软盘”）读写的磁 盘驱动器，以及对可移动非易失性光盘（例如CD-ROM,DVD-ROM或者 其它光介质）读写的光盘驱动器。在这些情况下，每个驱动器可以通过一 个或者多个数据介质接口与总线18相连。存储器28可以包括至少一个程 序产品，该程序产品具有一组（例如至少一个）程序模块，这些程序模块 被配置以执行本发明各实施例的功能。

具有一组（至少一个）程序模块42的程序/实用工具40，可以存储在 例如存储器28中，这样的程序模块42包括——但不限于——操作系统、 一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每 一个或某种组合中可能包括网络环境的实现。程序模块42通常执行本发 明所描述的实施例中的功能和/或方法。

计算机系统/服务器12也可以与一个或多个外部设备14（例如键盘、 指向设备、显示器24等）通信，还可与一个或者多个使得用户能与该计 算机系统/服务器12交互的设备通信，和/或与使得该计算机系统/服务器 12能与一个或多个其它计算设备进行通信的任何设备（例如网卡，调制 解调器等等）通信。这种通信可以通过输入/输出（I/O）接口22进行。 并且，计算机系统/服务器12还可以通过网络适配器20与一个或者多个 网络（例如局域网（LAN），广域网（WAN）和/或公共网络，例如因特 网）通信。如图所示，网络适配器20通过总线18与计算机系统/服务器 12的其它模块通信。应当明白，尽管图中未示出，可以结合计算机系统/ 服务器12使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱 动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及 数据备份存储系统等。

现在参看图3，图3是示出了根据本发明的一个实施例的用于对数据 库中的加载数据进行逻辑验证的系统300的处理的示意图。具体地，图 3中的示意图示出了系统300响应于用于进行逻辑验证的规则的添加或更 新而进行的处理。

根据本发明的系统300包括：规则引擎301、验证引擎302以及对象 容器303。在这里首先介绍对象容器303。在一个实施例中，对象容器303 可以位于内存中，包含已作为验证对象利用现有规则进行了验证的一个或 多个对象实例，其中对象实例仅包含从数据库中提取的与现有规则相关的 数据。

图4示意性地示出了对象容器中的数据对象的概念。图4的上部示出 了与规则1对应的数据对象1，这表示为了验证规则1需要验证表1的列 1_3、表2的列2_1、表3的列3_2和列3_3。图4的中部示出了与规则2 对应的数据对象1，这表示为了验证规则2需要验证表1的列1_1和列1_3、 表2的列2_2。当分别需要验证规则1和规则2时，通过把与规则1对应 的数据对象和与规则2对应的数据对象叠加，得到图4的下部示出的数据 对象1，其中列1_3是重合的。

在内存中的对象容器中存储的是数据对象的实例，即，基于数据对象 的数据结构的实际数据记录。因为在内存中并没有存储逻辑验证所需的所 有表的数据，而仅仅存储逻辑验证涉及到的列的数据，所以可以实现较小 的内存占用。此外，因为数据对象实例已在内存中，所以可以不必从数据 库中提取数据或者可以提取较少的差异数据就可以完成逻辑验证。

以下，通过一个例子来说明数据对象实例。假定存在下面的订单表和 用户表以及规则A。

订单表

OrderID UserID ProductID Status SubTotal ... 900001 500001 800001 Completed 219 ... 900002 500003 800002 Cancelled 319 ...

用户表

UserID UserType Email 500001 Registered ... 500002 Guest ... 500003 Guest   ... ... ...

规则A：如果订单总价大于300元，那么该订单的相关用户必须是注 册用户。

该规则A的验证涉及到用户表的UserType列，以及订单表和用户表 的主键列。因此，在这个例子中，数据对象由OrderID、UserID和UserType 这三个列组成，并且满足SubTotal>300的数据仅有：

表1

OrderID UserID UserType 900002 500003 Guest

该数据被实例化为一个数据对象实例，并被放入内存中的对象容器中 以由验证引擎进行逻辑验证。该对象实例例如可以为如下形式：

下面返回参照图3，继续对系统300进行说明。根据本发明的规则引 擎301被配置为响应于用于进行逻辑验证的新规则的添加和更新中的至 少之一，找出变动规则，该变动规则包括新规则相对于现有规则的变动部 分（S1）。

在系统的运行中，存在应用已经使用过的一些验证规则，它们被保存 在规则池中。规则池例如可以具有如下面的表所示的结构：

表2

规则实例ID 表的列名称 数据过滤条件 验证约束 1 User.UserType Order.SubTotal>300 UserType=’Registered’ 2 Order.Status Order.SubTotal>50 Order.Freight=’Free’ … … … …

表2中仅仅给出了规则池的一个例子，本领域技术人员完全可以想到用于 它的其它数据结构，例如xml文档。表2中的规则对应于上面所述的现有 规则。

一旦向系统300中加入了新的规则或者现有规则被更新（以下统称为 新规则），规则引擎301将分析该新规则，从而找出新规则相对于现有规 则的变动部分（即，变动规则）。

在根据本发明的一个实施例中，一个规则至少包含以下三个属性： 相关表的列名称、数据过滤条件以及验证约束。这对应于表2的第2 至4列，并且表2的第5列是可选的。列名称属性是该规则实例的验 证所涉及到的列的名称。数据过滤条件用于从数据库中过滤出满足条 件的数据，例如可以在if子句中，诸如“if TABLE1.TYPE=4”。验证 约束用于执行实际逻辑验证，诸如“range from 1-20”、“LessThan col.B ”、“Equal 0”等等。当满足验证约束时，代表逻辑验证成功；当不 满足验证约束时，则代表逻辑验证失败。

在根据本发明的一个实施例中，当出现一个新规则时，规则引擎301 被配置为通过在规则之间比较所述三个属性来找出所述变动规则。具 体地，比较这三个属性以识别哪个或哪些部分不同，并将分析结果输 出到验证引擎302。

验证引擎302被配置为在确定所述变动规则涉及所述对象实例包 含的数据以外的额外数据的情况下从数据库提取所述额外数据并加入 到相应的对象实例中（S2），并且利用所述新规则的至少一部分对所 述对象容器中的相关对象实例进行逻辑验证（S3）。

在根据本发明的一个实施例中，如果变动规则仅仅涉及验证约束 的不同（这意味着验证仍然针对的是现有的数据对象实例，即，对象 容器中的当前内容），则仅附加该验证约束，针对对象容器中的所有 对象实例，仅利用该验证约束进行验证。也就是说，所述验证引擎被 配置为在所述变动规则仅涉及不同的验证约束的情况下确定所述变动 规则不涉及所述对象实例包含的数据以外的额外数据。即，不必从数 据库提取额外的数据。这种情况的一个例子是：列名称和数据过滤条 件不变，原有验证约束是A<B<C，而新的验证约束是A=0。

另一方面，如果变动规则涉及到列名称和/或数据过滤条件，则验 证引擎302确定所述变动规则涉及所述对象实例包含的数据以外的额 外数据，此时，需要从数据库提取所述额外数据并加入到相应的对象 实例中。

具体地说，如果变动规则仅仅涉及数据过滤条件（这意味着该规 则仍然针对现有的数据对象，只是可能需要从数据库提取额外的数据 对象实例），则根据该新的数据过滤条件从数据库提取数据从而形成 新的数据实例。例如，当过滤条件从“if TABLE1.TYPE=4”变为“if TABLE1.TYPE=4or TABLE2.TYPE=4”，则在数据库中可能有新的 要验证的数据需要被提取。

如果变动规则涉及列名称，则需要参照图4的方式形成新的数据 对象，并从数据库中提取该数据对象的实例。这种情况的一个例子是： 原有验证约束是A<B<C，而新的验证约束是C<D。在这里，需要把列 D加入到数据对象，并且从数据库中的符合要求（满足数据过滤条件） 的记录中仅仅取回D列的值，并把它加入到内存中的对象容器中的对 应对象实例中。

从以上可见，图3中的步骤S2不一定会被执行。当有新的验证规则 被加入到系统中时，规则引擎能够比较它与现有规则，识别验证规则的变 动部分，并考虑验证该变动部分是否需要从数据库向对象容器加载额外数 据。如果不需要，则不提取数据而对现有数据对象实例进行直接验证，这 节省了数据库查询时间。即使需要提取额外数据来进行验证，也只需要提 取差异的值。例如，新规则要对列Table1.A、Table1.B和Table2.C的值 进行验证，但验证引擎发现Table1.A和Table1.B已经位于对象容器中（已 利用现有规则验证过），那么仅需从数据库提取Table2.C的值，这也节省 了数据库查询成本。

在使对象容器中的数据对象实例与新验证规则相适应之后，即， 在对象容器中的验证对象准备就绪之后，验证引擎302利用所述变动 规则对所述对象容器中的相关对象实例进行逻辑验证。例如，在新验 证约束是C<D的例子中，仅验证对于相关对象实例是否有C<D。这里， 相关对象实例指的是与新验证规则相关的对象实例。例如，促销活动 验证规则和员工出勤验证规则可能同时存在，它们所作用于的相关对 象实例可能同时存在于对象容器中，但是并无关联。例如，当促销活 动验证规则被新加入系统时，利用它仅对对象容器中的所有促销活动 对象实例进行逻辑验证。

在根据本发明的一个实施例中，可以为对象容器中的与新验证规 则对应的每个对象实例（即，相关对象实例）添加一个标记用来表示 是否需要验证，例如“validated=false”，然后仅对具有该标记的对象 实例进行验证，并且在验证结束后将该标记修改为“validated=true”。

下面利用一个简单的例子来具体说明图3中的系统300的处理。

例如，在一个购物网站的促销活动中，在已经存在的活动元素中 增加一个验证条件，这是因为元素的排列顺序影响促销活动的正常工 作。例如，“积分等级”这个元素在活动中的顺序就应该排在“用户 组”后面，即，100003.Sequence>100001.Sequence，否则促销活动条 件就会出错。例如，数据库中已经存在以下数据：

促销活动表（Activity）

ActivityID ActivityIDType Sequence   8000001 ProductRecommendation 1  

促销活动元素表(Component)

ComponentID ActivityID ComponentType ComponentValue Sequence ComponentNVP 100001 8000001 User 用户组 100 500001 100002 8000001 Product 商品目录 200 700001 100003 8000001 Promotion 积分等级 300 5

规则池中的现有规则限制了每个活动（Activity）对应的促销活动 元素（Component)的类型ComponentType必须为User、Product或 Promotion，并且每个元素的Sequence值必须大于0。也就是说， Activity.ActivityID，Component.ComponentID，Component. ComponentType，Component.Sequence这些列都已经在规则池中的现 有规则所涉及的“列名称”的范围内。现在，要为系统增加一个新的 验证规则N，不涉及新的列。

规则引擎301对比规则N涉及的列名称，发现已被现有规则涉及 的列名称所覆盖。于是，验证引擎302不访问数据库。将对象容器303 里所有的ProductRecommendationActivity实例（相关对象实例）设置 为validated=false。对象容器303中的ProductRecommendationActivity 实例例如可以是如下的形式：

然后，验证引擎302在对象容器303中直接用这个新的规则N验 证所有的ProductRecommendationActivity实例。

另一方面，在该促销活动的例子中，如果新添加的规则M要求所 有ActivityID=8000001的活动的Sequence都大于等于1，则需要查询 数据库找到所有ActivityID=8000001的记录，在对象容器303中把对 应的对象实例加上一个属性ActivitySequence并把这些对象实例标记 为validated=false。然后，验证引擎302利用这个新的规则M来验证 这些validated=false的数据。

在根据本发明的一个实施例中，规则引擎301被配置为把添加或更 新的规则加入到规则池中从而成为现有规则的一部分（例如，如表2 所示）。

在根据本发明的一个实施例中，验证引擎302还被配置为在所述变 动规则涉及新的列名称的情况下，在数据库中为该列添加触发器。这 里，新的列名称是指现有规则未曾涉及过的列的名称。

规则池的管理以及触发器的添加对于应对规则变动而言并无用处 并且是可选的，实际上，进行规则池的管理以及触发器的添加是为了 响应于数据的变动而进行自动逻辑验证。

图5是示出了根据本发明的另一个实施例的用于对数据库中的加载 数据进行逻辑验证的系统300的处理的示意图。具体地，图5中的示意 图示出了系统300响应于数据库中的具有触发器的列中的数据的添加或 更新而进行的处理。

在图3所示的处理中，每当有新规则加入时，就在该规则所涉及 的数据库中的列上添加触发器。所述触发器响应于在数据库中该触发 器被添加到的列中的数据的添加或更新而发出触发信号。

在图5中，响应于所述触发器的触发信号，规则引擎301从规则池 中找出由与添加或更新的数据（以下称为新加载数据）相关的规则组 成的规则子集（S11）。也就是说，规则引擎301在规则池中检查与该 新加载数据相关的所有规则，以形成规则子集。所谓规则子集是相对 于规则池这个全集而言的子集。具体地，规则引擎301被配置为基于被 触发的触发器所在的列的名称与规则池中的各规则的列名称属性之间的 比较，从所述规则池中找出所述规则子集。例如，当新加载数据是上 述订单表中的一条订单记录时，添加在列Order.Status上的触发器被 触发，规则引擎在例如表2所示的规则池中查找第2列中的列名称包 含Order.Status的规则实例，从而找到规则实例2。

此外，响应于所述触发器的触发信号，验证引擎302把在数据库中 添加或更新的所述数据（新加载数据）提取到对象容器303中形成具 有第二标记的对象实例（S12）。处理S12与规则引擎301的处理S11 可以是并行或者串行地执行。

然后，验证引擎302利用所述规则子集仅对所述对象容器中具有 第二标记的对象实例进行逻辑验证，其中所述第二标记不同于所述对 象容器中的其它对象实例所具有的第一标记。这里，第二标记例如为 “validated=false”，第一标记例如为“validated=true”。

在根据本发明的一个实施例中，验证引擎302被配置为在对所述 对象容器中具有第二标记的对象实例进行逻辑验证之后，把这些对象 实例的第二标记修改为第一标记。通过这样做，在有新数据被加载到 系统中时，不会对已验证过的数据进行重复验证。

采用上述技术方案，当数据被加载到系统中时，验证引擎仅仅对 带有“validated=false”标记的数据进行验证，而不是对所有加载的数 据进行逻辑验证，因为有些加载数据可能与任何验证规则都无关。这 样就降低了进行逻辑验证的成本。

在另一个实施例中，可以不考虑上述变动规则，而是对现有规则 所涉及的所有列添加触发器。在该实施例中，一种用于对数据库中的 加载数据进行逻辑验证的系统包括：对象容器、验证引擎和规则引擎。 该对象容器包含已利用现有验证规则进行了验证的一个或多个对象实 例，其中对象实例仅包含从数据库中提取的与现有验证规则相关的数据。 该验证引擎被配置为对于与现有验证规则相关的每个列，在数据库中 为该列添加触发器，其中，所述触发器响应于在数据库中该触发器被 添加到的列中的数据的添加和更新中的至少之一而发出触发信号。该 规则引擎被配置为响应于所述触发器的触发信号，从现有验证规则中找 出由与添加或更新的数据相关的规则组成的规则子集。其中，所述验 证引擎还被配置为，响应于所述触发器的触发信号，把在数据库中添加 或更新的所述数据提取到所述对象容器中形成具有第二标记的对象实 例，并且利用所述规则子集仅对所述对象容器中具有第二标记的对象 实例进行逻辑验证，其中所述第二标记不同于所述对象容器中的其它 对象实例所具有的第一标记。这样，即使不与图3所示的处理相结合 地执行处理，对于新添加或更新的数据，能够仅仅利用与其相关的规 则进行验证，从而节约了验证成本，提高了系统的性能。

下面利用一个简单的例子来具体说明图5中的系统300的处理。

假定在其它的数据库中的用户的一些历史订单，需要导入到新数 据库的时候，就需要使用已经存在的验证规则来检查新导入的订单是 否有效。比如订单中的注册用户、商品数据是否一致，而不需要关心 其它的诸如促销优惠等的信息。

假定新增的数据如前面的订单表中所示。这两条新加载数据触发 了现有规则添加在列Order.UserID上的触发器，把Order.UserID作 为相关列名称发送给规则引擎301。

规则引擎301用列名称Order.UserID在规则池中进行比较，找到 了列名称属性中含有Order.UserID的规则实例，诸如具有如下目的的 规则实例X：对于订单总价大于300元的订单，需要判断与该订单相 关的用户是否为注册用户，如果为非注册用户，则此订单数据不合法。

于是，这个规则实例成为本次逻辑验证所用的规则。根据这条规 则实例的数据过滤条件（Order.SubTotal>300），对新加载数据进行 过滤，找到其中只有一个订单记录的总额在300元以上（即，上面的 订单表中的OrderID=90002的订单记录）。于是，这个数据记录被过 滤出来，作为准备要放入对象容器中的数据。验证引擎根据这个规则 实例里的preElement，在数据库中查找这个订单90002对应的用户， 并获得该用户的UserType。这样，提取出的数据对象具有表1所示的 结构和内容。

提取的数据可以被实例化为一个数据对象实例，并被放入内存中的 对象容器中并把验证标记设为validated=false。该对象实例例如可以为 如下形式：

验证引擎使用这次验证要用的规则实例X，对对象容器中所有 validated=false的对象实例进行验证。得到如下结果：OrderID=900002 的订单所对应的UserType=Guest，验证结果为内容不合法。然后，返 回该结果。此外，在验证之后，把该对象实例的标记“validated=false ”修改为“validated=true”。

在这里，仅仅对新加载数据的对象实例（instance1）进行了验证，对 于以前验证过的对象实例（instance2、instance3等）不进行验证，从而 降低了逻辑验证的成本。

图6是示出了根据本发明实施例的用于对数据库中的加载数据进行 逻辑验证的方法的流程图。图6中的方法包括步骤S61-S64。

在步骤S61中，响应于用于进行逻辑验证的新规则的添加和更新中 的至少之一，找出变动规则，该变动规则包括新规则相对于现有规则的变 动部分。在确定所述变动规则涉及对象容器中的对象实例包含的数据以 外的额外数据的情况下（步骤S62中判断结果为是），从数据库提取 所述额外数据并加入到相应的对象实例中（S63）。在步骤S64中，利 用所述新规则的至少一部分对所述对象容器中的相关对象实例进行逻 辑验证。这里，所述对象容器包含已作为验证对象利用现有规则进行了 验证的一个或多个对象实例，其中对象实例仅包含从数据库中提取的与现 有规则相关的数据。

根据本发明的一个实施例，该方法还包括把添加或更新的规则加 入到规则池中从而成为现有规则的一部分。根据本发明的一个实施例， 所述规则至少包含以下三个属性：相关表的列名称、数据过滤条件以 及验证约束。根据本发明的一个实施例，在所述变动规则仅涉及不同 的验证约束的情况下，确定所述变动规则不涉及所述对象实例包含的 数据以外的额外数据（步骤S62中的判断为否）。根据本发明的一个 实施例，在所述变动规则涉及新的列名称的情况下，在数据库中为该 列添加触发器。根据本发明的一个实施例，找出添加或更新的规则相对 于现有规则的变动部分包括：通过在规则之间比较所述三个属性来找出添 加或更新的规则相对于现有规则的变动部分。

根据本发明的一个实施例，所述触发器响应于在数据库中该触发 器被添加到的列中的数据的添加或更新而发出触发信号。响应于所述触 发器的触发信号，从所述规则池中找出由与添加或更新的数据相关的规 则组成的规则子集；并且响应于所述触发器的触发信号，把在数据库中 添加或更新的所述数据提取到所述对象容器中以形成具有第二标记的 对象实例，并且利用所述规则子集仅对所述对象容器中具有第二标记 的对象实例进行逻辑验证，其中所述第二标记不同于所述对象容器中 的其它对象实例所具有的第一标记。

根据本发明的一个实施例，该方法还包括：在对所述对象容器中 具有第二标记的对象实例进行逻辑验证之后，把这些对象实例的第二 标记修改为第一标记。根据本发明的一个实施例，从所述规则池中找 出由与添加或更新的数据相关的规则组成的规则子集包括：基于被触 发的触发器所在的列的名称与规则池中的各规则的列名称属性之间的比 较，从所述规则池中找出所述规则子集。根据本发明的一个实施例， 所述数据过滤条件用于从数据库中过滤出满足条件的数据，并且满足 所述验证约束代表逻辑验证成功。

在另一个实施例中，一种用于对数据库中的加载数据进行逻辑验 证的方法，在该方法中，对于与现有验证规则相关的每个列，在数据库 中为该列添加触发器。所述触发器响应于在数据库中该触发器被添加 到的列中的数据的添加和更新中的至少之一而发出触发信号。响应于 所述触发器的触发信号，从现有验证规则中找出由与添加或更新的数据 相关的规则组成的规则子集，把在数据库中添加或更新的所述数据提 取到所述对象容器中形成具有第二标记的对象实例，并且利用所述规 则子集仅对所述对象容器中具有第二标记的对象实例进行逻辑验证， 其中所述第二标记不同于所述对象容器中的其它对象实例所具有的第 一标记。所述对象容器包含已利用现有验证规则进行了验证的一个或多 个对象实例，其中对象实例仅包含从数据库中提取的与现有验证规则相关 的数据。

附图中的流程图和框图显示了根据本发明的多个实施例的系统、方 法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上， 流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部 分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的 逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框 中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个 连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序 执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每 个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能 或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机 指令的组合来实现。

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷 尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例 的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改 和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实 施例的原理、实际应用或对市场中的技术的技术改进，或者使本技术领 域的其它普通技术人员能理解本文披露的各实施例。