，第 一数据库320)可以将生成的当前数据存储为该电信企业的操作的一部分，而OLAP数据库 (例如，第二数据库340)可以存储历史数据用于分析。然而，这两个数据库中的部分数据可 能会重叠。该OLTP数据库通常会比OLAP数据库（这些数据因此不能在该OLAP数据库中 可用）具有更多的当前数据，而OLAP数据库可能比OLTP数据库（这些数据因此不能在该 OLTP数据库中可用）具有更多地数据。
[0021] 由于缺乏一定数据在一个数据库或者在另一个数据库的有效性，有时查询可能需 要存储在两个数据库中的数据。例如，查询可能需要存储在第一数据库中的第一数据以及 存储在第二数据库中的第二数据。例如，电信企业可能会想确定到目前为止一周以内的一 个或多个客户的呼叫量。可以将之前六天的呼叫信息在OLAP数据库（例如，第二数据库 340)中存储为历史数据，而将今天的还没有传输到OLAP数据库（例如，传输可能发生在每 天的午夜）的呼叫信息仍然存储在OLTP数据库（例如，第一数据库320)中。因此，请求这 些信息的查询可能需要来自OLAP数据库和OLTP数据库的数据
[0022] 为了解决这个问题，查询（此处称为"主查询"）可包括指向特定数据库的子查询。 尤其，例如，可以由第一执行引擎310 (例如，通过查询执行器312)发起该主查询，但是该主 查询可以包括指向第二执行引擎330的子查询。可以配置该子查询用于请求从第二数据库 340得到的第二数据，这样第一执行引擎310能使用第二数据以及从第一数据库320提取的 第一数据充分执行主查询。如下将详细所述，可以通过查询连接器函数（query connector function)将子查询与主查询连接。
[0023] 在120中，将子查询发送给第二执行引擎330用于在第二数据库340执行以提取 第二数据。可以由查询执行器312将该子查询发送给该第二执行引擎330。该第二执行引 擎330可以执行该子查询以从该第二数据库340中提取该第二数据。
[0024] 在130中，可以由第一执行引擎310处的查询执行器312接收该第二数据。可以 用流格式直接从该第二执行引擎330中接收该第二数据，而不是在第一执行引擎310接收 该第二数据之前将该第二数据暂时存储在表中。将该流第二数据直接馈送到主查询中。因 此，该第一执行引擎310可以将第二执行引擎330的查询结果视为主查询的直接数据源。
[0025] 在140,剩下的主查询可以由第一执行引擎310处的查询执行器312执行。图2描 述了执行剩余主查询的方法的实施例。在210,可以从第一数据库320中提取第一数据。例 如，如主查询所指定的，该第一执行引擎310可以访问第一数据库320以提取从第一数据库 320获得的数据。从第一数据库320提取的该第一数据可以作为主查询的另外直接数据源。 在220,可以使用该第一数据和第二数据执行由该主查询指定的至少一个操作。例如，可以 将该第一数据和第二数据合并、结合、分类、过滤等。视情况而定，可以返回主查询的结果。
[0026] 如上所述，可以通过查询连接器函数（QCF)将子查询与主查询连接。配置该QCF 用于在没有任何中间实体化时以流逐元组的格式使得/允许将该第二数据从第二执行引 擎330传递到第一执行引擎310的主查询。因此，可以避免在中间将数据存储在磁盘（例 如，临时表的形式）上的开销。
[0027] QCF是返回元组序列以对查询（此处为主查询）反馈的一种表函数。该查询连接 器函数将查询（此处为子查询）作为其参数，并且执行如下。从发起该查询的执行引擎（此 处为第一执行引擎310)，该QCF可以使用某些连接信息（例如，URL、驱动器、鉴权等）发起 到目标数据库（此处，通过第二执行引擎330到第二数据库340)的开放数据库互连（ODBC) 或Java数据库互连（JDBC)连接。接下来，该QCF使得该第二执行引擎330执行作为参数 传入到QCF的查询（此处为子查询）。接下来，该QCF根据产生关系模式（如依据ODBC/ JDBC ResultSetMetadata)逐个生成输出元组以对该主查询进行反馈。这些输出元组组成 第二数据，并且可以由第一执行引擎馈送到主查询。
[0028] 在一示例实现中，PostgreSQL可以是OLTP执行引擎，Vertica可以是OLAP执 行引擎。在PostgreSQL引擎中，该QCF可以根据PostgreSQL的设置返回函数来实现，该 PostgreSQL的设置返回函数是能够从传入的查询中生成元组以及能够逐个输出元组的一 类表函数。在查询执行的过程中多次调用此功能，每次调用返回一个元组。通过扩展该 PostgreSQL的函数扫描机制以开启QCF输出，因此可以逐元组不断地对该查询进行反馈。 函数扫描有两种级别：函数扫描级别和查询执行器级别。包含函数调用信息的数据结构把 这两个级别连接起来，可以由查询执行器发起，并且被传入到QCF/从QCF传出用于交换函 数调用相关的信息。在Vertica引擎中，用户定义的变换函数（UDTF)可用于读取从传入查 询返回的行以及返回查询结果的零个或多个行。UDTF循环处理输入的元组，但是在这种用 法中，该函数的输入可以被认为是单一元组。
[0029] 现在描述涉及电信企业DBMS的用例实例。该DBMS包括三个数据库：可操作数据 库（ODB)、操作型数据存储（ODS)和企业数据仓库（EDW)。集成计费系统处理客户验证、收 费、电话上的账号更新功能、消息传送、数据通信等。具有OLTP系统工作负载特性的ODB系 统可支持该集成计费系统。账单系统记录要被列入到帐单的客户行为的细节并由ODS系统 支持。在以写为中心但由只扩展操作为主的情景下，该ODB系统包括OLTP和OLAP之间的 工作负载特性。该EDW系统记录历史数据用于商业情报、客户行为描述和欺诈检测等。该 EDW系统运行具有由并行数据库所支持的查询内并行的大型分析查询，并且从而具有OLAP 系统的工作负载特性。
[0030] 该ODB系统可以维护表（"账号"）用于保管客户账号信息，具有属性，例如，客户 _id、姓名、服务_计划、结余等。该ODS系统可以维护呼叫细节记录（CDR)表用于记录CDR 信息，具有属性，例如客户_id、呼叫_时间、呼叫_持续时间、呼叫_目的地等。该EDW数 据库可以维护从ODS数据库（例如，以每天的频率）导入的历史原始数据以及推导出的概 要信息，有一个被称为"每日_agg"的表并且具有属性，例如客户_id、日期、容量、持续时间 等。
[0031] 使用该集成计费系统接收的每个⑶R来更新ODB和0DS。在由电信企业执行的"智 能"计费策略之下，在"打的越多、省的越多"的原则下，考虑过去一周的呼叫量来计算每次 呼叫的成本。因此，用于获取过去一周呼叫量的查询会需要来自ODB系统和EDW系统的信 息。使用ODB系统和EDW系统作为数据源，使用结构化查询语言（SQL)中的查询连接器函 数来实现应用于ODB系统的查询，如下：
[0034] 斜体字指示查询连接器函数"qcf"和其传入参数，该查询连接器函数"qcf"为指 向EDW系统的子查询。将子查询的结果返回到ODB执行引擎并且直接馈送到该查询中用于 充分执行。尤其，来自于ODB的"账号"表与子查询的查询结果合并以提供查询的呼叫量。
[0035] 作为另外一个实施例，用于总结从上周（7天）到"现在"（不到一天）的呼叫状态 的查询可能需要合并从EDW和ODS提取的信息。可以利用如下查询从ODS系统提取当天呼 叫量的概要：
[0036] SELECT customer_id, COUNT(*)FROM cdr GROUP BY
[0037] customer_id
[0038] 相应地，如下，对EDW发起的查询可以合并从ODS提取的Q3的结果，将该结果与从 该EDW提取的上周的集合求和。此外，查询连接器函数以及传入参数（即，上述对ODS系统 的查询）用斜体字突出显示。
[0039]
[0040] 图4示出根据本发明实施例的处理涉及多个数据源查询的计算系统。计算系统 400可以包括一个或多个计算机和/或被一个或多个计算机执行。例如，这些计算机可以 是：服务器计算机、工作站计算机、桌面计算机、笔记本电脑、移动设备等，并且可以为分布 式系统的一部分。如例如关于处理系统300描述的，计算机可以包括：一个或多个控制器以 及一个或多个机器可读存储介质。
[0041] 此外，计算系统400的用户可以通过可以被视为或不被视为计算系统400 -部分 的一个或多个其他计算机与该计