通过计算机网络从数据库获取和集成数据的方法及系统 本申请要求美国临时专利申请第60/273,816号的优先权。该临时申请递交于2001年3月6日，名称为“通过计算机网络从数据库实时查询、获取和集成数据的方法和系统”，其公开内容通过引用而完整地纳入本文。技术领域
此发明总体上涉及数据的获取。更确切地说，此发明涉及通过计算机网络从一个或多个数据库获取和集成数据的方法和系统。技术背景
随着企业对企业(B2B)技术的愈加普及，一些公司开发了B2B软件平台并且在此过程中定义了标准协议，以便在一些合作伙伴企业之间进行自动的标准化数据交换。通常，这些标准协议被设计成用来描述基于纸张的过程，例如订单，帐单等等，以便于更有效地处理这些过程，从而降低相关的成本。企业的目标是降低营运成本。
因特网作为企业与企业之间的通信工具的进步，使得许多公司之间可以利用B2B软件平台来连接简单的企业过程和交易，如订单、帐单等。但是，这仍然不能够让一个价值链中的所有企业之间实现真正的合作及信息共享从而作出关于何时何地以及如何进行这些交易的智能决策。
防火墙外的B2B交易自动化，和20世纪80年代建立的内部交易自动化公司以及20世纪90年代后期建立的电子商务自动交易系统具有相似之处。企业内部交易系统和电子商务交易系统采用了不同的技术，前者使用的是CICS(顾客信息控制系统)和COBOL语言，后者使用地是电子商务服务器和JAVA语言。其结果是一样的，即实现了标准化的交易和过程从而节省了操作费用。
简单的交易操作提供了低层次的自动化，但这并不能减少所涉及的企业过程中的所有费用。历史显示，一旦定义了简单的交易，企业问题将会变得需要更复杂的决策和智能。
今日之计算机网络环境和技术，诸如电子数据交换(EDI)、电子邮件、文件传送协议等，通常被用于供应链企业之间的信息共享以便于进行预测、计划和执行。然而，当信息必须在很短时间内诸如以小时为单位甚至于实时地来进行获取和产生时，这些技术所能够完成的往往比预期的低。
有许多系统被引入来试图解决以上提到的情形。例如，有一个系统被引入来解决计划问题，诸如通过联网直接连接零售业者和供货者之间的计算机来作资源的连接，从而进行零售业预测以及存货管理。预测是通过对一个订单进行一系列的审阅来计算的。而这种预测基本上是基于单个企业与单个企业之间来进行的。
另一个例子是一个允许从单个企业外部进行数据访问的系统。系统的交互层允许系统看见所有供应链接企业的数据而不是单个企业。这对于供应链企业的计划非常有好处。从供应链所获得的数据被存储于数据库。接着数据被通过一定的参数进行处理从而提供供应信息用于供应链计划。基本上，用一定的参数，诸如生产能力、企业资源规划(ERP)和财政支持等，可以建立起一个预测模型来评估供应链计划所需的信息。数据在被用于计划之前先进行了收集和计算。系统之设计使之能够缩短进行大量不同数据的收集和计算的时间。这对于预测和计划很有用。但是，系统仅仅能够获取具有一定时间延迟的计算数据，它不能提供进行实时供应链决策的及时而准确的数据。当用户所需的特定的数据在预测模型中不能提供时，计算所得的数据将确乏完成要求所需的灵活性。发明内容
因此，迫切需要提供一种以更有效的方式通过计算机网络从数据库实时地查询、获取和集成数据的方法和系统。
本发明提出了一种通过计算机网络从多个数据库获取和集成数据的方法和系统。本发明的一个示例性实施方式包括：一个具有一个整合服务器和几个数据代理器的系统。整合服务器能够通过计算机网络如因特网与数据代理器进行通信。每一个数据代理器能够和多个数据源进行近程通信。一个用户可以通过整合服务器获取来自不同数据源的数据，这些数据是整合服务器使相应的数据代理器从相关联的数据源中获取的。
按照该示例性实施方式，当一个用户向整合服务器发出一个获取一定数据的请求后，整合服务器会将该请求转换成一个内部查询。然后对照一个规则集合对该内部查询进行匹配。每一条规则指定了如何利用一个或多个数据源来部份地满足一个内部查询。对于与该内部查询匹配的规则集合，产生一个子查询。所有产生的子查询然后由相应的数据代理器使用以获取数据。可选择地，所有产生的子查询可以被进行优化从而更有效地从相应的数据源获取数据。当所请求的数据从所有相关的数据代理器获得后，这些数据于是被连接、融合和集合，产生最终结果，该结果即是内部查询结果。
该说明书的其余部份的相关内容，包括附图以及权利要求书，将描述本发明的其它特征和优点。本发明的进一部的特征和优点以及各种实施方式的结构和操作，将参照附图进行详细说明，其中类似的参考号码指示相同的或相似的功能。附图说明
图1是用来说明本发明的一个示例性实施方式的简化方块图；
图2是用来说明本发明的一个示例性实施方式执行的数据集成过程的流程图；
图3是根据本发明的一个示例性实施方式的输入查询请求的说明性例子；
图4是根据本发明的一个示例性实施方式的查询定义文件的说明性例子；
图5是根据本发明的一个示例性实施方式的规则定义文件的说明性例子；
图6是根据本发明的一个示例性实施方式的数据源定义文件；
图7a和7b是根据本发明的一个示例性实施方式的数据源对应文件。具体实施方式
现在使用几个示例性实施方式来描述本发明。图1是用来说明本发明的一个示例性实施方式的简化方块图。参考图1，系统10是本发明的一个示例性实施方式。系统10包括一个整合服务器12，多个数据代理器14和多个数据源16。数据源16包括例如数据库和可以提供数据的应用程序。一般情况下，可以按照一个或多个预定标准将数据源16分成不同的组。例如数据源16a-c位于同一台计算机并属于同一个公司可以被分成一组。然而，应该理解到，数据源16不必驻留在单个计算机系统中。本领域内普通技术人员应当知道其它的方法来组织一组数据源。此外，同一组中的数据源16可以彼此不同。例如，在一组数据源中的某一个数据源可能是一个厂商如IBM生产的数据库产品，而另一个数据源可能是另外一个厂商如Oracle生产的数据库产品。可以将每一个数据代理器设计为与特定组的数据源16通信，获取和整合所需的数据源中的数据。
系统10一般以下述示例性的方式工作。当用户18想要获取某些数据，用户18向整合服务器12发出一个请求。在一个示例性实施方式中，用户18使用计算机上的图形用户界面通过计算机网络20a(如因特网)向整合服务器12传送该请求。以XML格式对该请求进行编码，以便从用户18传递到整合服务器12。在一个替代的实施方式中，用户18可以不通过任何计算机网络，而直接与整合服务器12交互。
收到请求后，整合服务器12对该请求进行处理，并确定通过哪一个或哪几个数据代理器14可以取得所需的数据。确定了数据代理器14以后，整合服务器12通过计算机网络20b和这些数据代理器14通信，以获取用户请求的数据。这里的计算机网络20b，例如也可以是因特网。因此，计算机网络20a、20b可以是相同的或不同的网络系统。
所确定的每一个数据代理器14进一步处理从整合服务器12收到的请求并且从相应的数据源16取回所请求的数据。然后，数据代理器14将获取的数据进行集成并转发给整合服务器12。可以按照XML格式或SOAP格式对集成的数据进行格式化，然后使用多种传输协议(例如包括HTTP)，通过计算机网络10b转发给整合服务器12。基于这里公开的内容，本领域普通技术人员将知道可以使用其他格式和传输协议实现数据代理器14和整合服务器12之间的数据传输。
从所有相关的数据代理器14收到获取的数据后，整合服务器12对所有获得的数据进行集成，并提交给用户18。关于每个数据代理器14和整合服务器12怎样获取和如何对用户请求的数据进行集成的细节，将在以下进一步描述。
以下对系统10在更为实际的环境中的工作做进一步的说明。在某一示例性实施方式中，位于一个公司内部计算机网络中的数据代理器14，能够与公司的内部数据源进行本地通信，内部数据源是例如数据库或应用程序。当该公司的一个客户希望获得有关的特定信息例如他/她的订单时，该客户向整合服务器12发出请求。整合服务器12处理这个请求并将该请求通过一定的方式(例如内部网)传送给数据代理器14。数据代理器14从公司数据源中取得用户请求的信息，然后对信息进行集成，以便传送给整合服务器12。随后，整合服务器12将信息转发给客户。
图2的流程图进一步解释了用户18发出的请求是怎样被处理的，以及一个或多个数据代理器14是怎样获取和集成数据的。参照图2，用户18使用请求表格或图形用户界面输入数据请求。请求表格含有多个不同的域。为请求不同类型的数据，用户18可以使用不同的请求表格。在一个示例性实施方式中，请求表格(以及表格中的信息)被转换成为以XML格式编码的输入查询请求，以便传送给整合服务器12。图3是输入查询请求的一个例子。
从用户18收到输入查询请求以后，整合服务器12将该输入查询请求分析或转换成为内部查询。特别地，对每一个输入查询请求有一个相应的请求模板，该模板可由整合服务器12实例化为内部查询。内部查询用查询定义文件表示。查询定义文件由两部份组成，首部和尾部。首部表示查询输出格式，它描述了当响应于内部查询获取了数据时将要显示的数据结构以及将要采取的数据融合方式。尾部表示了查询输入格式，它指定将要获取什么种类的数据以及获取这些数据所需的必要输入变量或参数。尾部由查询输入格式的合取集合组成。图4是一个查询定义文件的例子。关于查询定义文件的目的和用法将在下面进一步描述。
一旦创建了内部查询(和相应的查询定义文件)，就对照一个规则集合对内部查询进行评估。这个规则集合指定在哪里和如何满足不同的内部查询。例如，一条规则可以指定某个特定内部查询可以由第一和第二个数据源满足；另一条规则可以指定同一特定内部查询可以由第三和第四个数据源满足。更一般地讲，一条规则可以说明在一个内部查询的尾部中的数据集合的子集如何得到满足。可以使用一个规则集合的并集来指定如何满足一个完整的内部查询。这个规则集合可以是按照数据源的结构、依赖关系和内容来设计的。在一个示例性实施方式中，这个规则集合保存在位于整合服务器12上的规则定义文件中。规则定义文件中的每一条规则也有一个首部。和查询定义文件的尾部类似的是，规则定义文件中的规则集合的各首部也表示查询输入格式，即它指定将要获取什么种类的数据和获取这些数据所需的必要输入变量或参数。这种类似功能的使用将在以后讨论。图5是一个规则定义文件的例子。
参照图2，对照规则定义文件中的规则集合内的每条规则，对内部查询进行评估。更具体地说，对内部查询的相应的查询定义文件进行检查，以确定它的尾部是否能与规则定义文件中的规则的首部匹配。也就是说，如果查询定义文件中的某个输入查询的尾部能够与规则集合中的某条规则的首部匹配，则认为这条规则是与该内部查询匹配的规则。需要说明的是，一条规则和一个查询定义文件中定义的输入查询相匹配并不要求查询定义文件中的输入查询的尾部的子集和规则定义文件中该规则的首部完全一致。只要查询定义文件中的输入查询尾部的一个子集与某一规则的首部的一部份或全部相同就可以认为查询和规则匹配。也就是说，规则的首部可以是查询定义文件尾部的超集，查询定义文件中的尾部也可以是规则首部的超集。
对每一组匹配的规则，整合服务器12产生一个子查询。对每一个内部查询，可能会产生一个或多个子查询。每一个子查询确定了内部查询所需数据的数据源以及访问这些数据源的数据代理器14。可选择地，整合服务器12也可以分析这些子查询并形成查询执行计划来优化子查询在相应的数据代理器14上的执行过程。这部份的内容将在下面进一步描述。
对于每一个子查询，整合服务器12确定是否存在一组数据代理器能执行该子查询。这可能会涉及一个或多个数据代理器。需要找出所有有关的数据代理器14。每一个数据代理器都有一个对应的数据源定义文件。图6展示了一个数据源定义文件的例子。整合服务器12检查每一个数据源定义文件以确认相应的数据代理器14能够返回与之有关的子查询所需要的数据。有些原因可能会造成某个数据代理器不能参与子查询的执行。
如果确定了有关的数据代理器可以参与执行子查询，整合服务器12就把子查询改写成为数据代理器请求并发送给数据代理器执行。在一个示例性实施方式中，整合服务器12将子查询编码成为XML格式的数据代理器请求，并通过因特网转发给相应的数据代理器。
收到数据代理器请求以后，每个数据代理器寻找与子查询对应的数据源对应文件。数据源对应文件用于将符合查询要求的本地数据映射成为希望得到的格式。而且，数据源对应文件中也包含与数据源建立连接所需的信息，数据代理器将使用这些信息访问数据源。例如，一个数据源可能是数据库，另一个数据源可能是一个需要通过应用程序界面访问的应用程序。图7a和7b是数据源对应文件的例子。
每个子查询由一组数据代理器请求来实现，即由一组对应的数据代理器从相应的数据源取回要求的数据。每个数据代理器对取回的数据进行连接并按照所需的格式编码后传送给整合服务器12。在一个示例性实施方式中，连接后的数据被编码成为XML格式。
收到与每个子查询相应的数据代理器的执行结果后，整合服务器12对收到的数据执行连接、融合和集合操作。融合操作是按照查询定义文件首部中定义的一组属性值对数据进行组合。集合操作是将从相应的数据代理器返回的组合好的数据放在一起。
应该说明的是，由于系统的限制以及其他的要求，一个内部查询可能会得到大量的返回数据。相应的数据代理器和整合服务器12不一定一次处理完所有的这些数据。因此，从数据代理器一次返回的数据量和整合服务器一次处理的数据量是可以配置的。
如上所述，整合服务器12可以分析子查询并制定查询执行计划来优化子查询在相应的数据代理器14上的执行过程。例如，一个内部查询有三个匹配规则的集合，因此产生三个子查询。三个子查询彼此相同只是各自访问不同的数据源组合。例如，第一个子查询需要访问数据源A和数据源B；第二个子查询需要访问数据源A和数据源C；第三个子查询需要访问数据源A和数据源D。如果不进行优化，与三个子查询相应的数据代理器请求将分别独立执行。这样就会对数据源A执行三次重复的访问。
可选择的是，整合服务器12可以如下方式优化子查询的执行。第一，识别出所有子查询共用的一个数据源，再识别出所有数据源共有的关键字。第二，执行第一个子查询，从公共数据源中提取关键字的所有可取值的集合，同时也提取其它数据。第三，把关键字值集并行地发送到与各子查询相关的数据代理器以提取子查询的结果，然后，通过把这些子查询的结果集合，产生出合适的最终结果。这种方式的数据提取与集合的运算称为星形集合。
前述的优化过程将以上一个例子作进一步的阐述，我们进一步作如下假定。第一，数据源A是用作存放零部件及其描述的信息，而所有的零部件信息已以零部件号码作为索引。第二，数据源B、C、D是用作存放供货商B、C、D的零部件数量的信息，这些信息同样以零部件号码作了索引。引用上述的优化算法，数据源A是三个子查询的公共数据源，而零部件号码是数据源A、B、C、D的公共关键字。利用这些已知条件，先对数据源A执行第一个子查询，得到了一列以零部件号码为索引的数据，而这列数据代表了第一个子查询所要求的零部件号码的信息。利用这列数据，对其余的数据源B、C、D执行相应的子查询，就得到了相关的信息。事实上，对数据源B、C、D的子查询可以并行地执行。就第一个子查询而言(它需要访问数据源A和B)，从数据源A得到的结果要与从数据源B得到的结果进行连接，连接的结果代表了选定零部件的有关信息，包括了如零部件的描述及可从供货商B得到的供货量等等。同样地，就第二个子查询而言(它需要访问数据源A和C)，从数据源A得到的结果要与从数据源C得到的结果进行连接，连接的结果代表了选定零部件的有关信息(具体与上同)。如此类推，就第三个子查询而言(它需要访问数据源A和D)，从数据源A得到的结果要与从数据源D得到的结果进行连接，连接的结果代表了选定零部件的有关信息(具体与上同)。最后，所有的连接结果融合在一起，融合的目标是使得对于一个零部件号码而言，从数据源B、C、D提取的数据被整合在一起，与内部查询的要求符合。
在一个示例性实施方式中，本项发明是以控制逻辑的形式，通过模块化或集成化软件来实现。然而，根据本文的公开内容，本领域内的普通技术人员将可以知道，本发明也可用其它方法和/或技术，如纯硬件或软硬件结合来实现。
仅出于阐述的目的，本文列举了一些例子和实施方式，这些信息将会引发本领域内熟练的技术人员做出各种修改或变化，而这些修改或变化属于本申请的实质，应纳入后附权利要求的范围。本文引用的所有出版物、专利和专利申请，都依其原目的完整地通过参考纳入本文。