数据的查询方法及查询装置.pdf

本申请提供一种数据的查询方法，所述数据保存在至少两个不同的数据库中，所述方法包括：接收基于业务模型的查询请求；所述业务模型包括业务元素；根据业务模型与存储模型的转换规则，将所述查询请求转换为匹配于所查询数据库的执行方式；所述存储模型包括所查询数据库的属性信息；所述转换规则包括业务元素与所查询数据库中属性的对应关系；按照所述执行方式访问对应的数据库。通过本申请的技术方案，避免了数据在不同数据库间的导入导出，而且能够对适用的数据库没有限制；同时在用户层面屏蔽了底层数据库的差异，提高了查询的便利性和完备性。

权利要求书
1.  一种数据的查询方法，所述数据保存在至少两个不同的数据库中，其特征在于，所述方法包括：
接收基于业务模型的查询请求；所述业务模型包括业务元素；
根据业务模型与存储模型的转换规则，将所述查询请求转换为匹配于所查询数据库的执行方式；所述存储模型包括所查询数据库的属性信息；所述转换规则包括业务元素与所查询数据库中属性的对应关系；
按照所述执行方式访问对应的数据库。

2.  根据权利要求1所述的方法，其特征在于，所述业务模型以元数据格式描述业务场景，还包括以下各项中的至少一项：业务元素的约束信息、业务元素间的约束信息、业务元素的实例信息、数据流信息、与其他业务模型的映射关系。

3.  根据权利要求1所述的方法，其特征在于，所述存储模型描述所查询数据库的数据存储，还包括以下各项中的至少一项：存储数据源名称、存储数据源类型、存储分片sharding模式、存储数据区名称。

4.  根据权利要求1所述的方法，其特征在于，所述将查询请求转换为匹配于所查询数据库的执行方式，包括：按照所查询数据库的存储引擎类型，将所述查询请求转换为匹配于所述存储引擎类型的执行方式。

5.  根据权利要求1至4任意一项所述的方法，其特征在于：所述查询请求包括基于业务元素的存储获取条件和结果过滤条件；
所述将所述查询请求转换为匹配于所查询数据库的执行方式，包括：以存储获取条件作为查询条件，将所述查询请求转换为匹配于所查询数据库的执行方式；
所述方法还包括：在从各个数据库获得的访问结果中，按照结果过滤条件进行筛选。

6.  一种数据的查询装置，所述数据保存在至少两个不同的数据库中，其 特征在于，所述装置包括：
请求接收单元，用于接收基于业务模型的查询请求；所述业务模型包括业务元素；
转换单元，用于根据业务模型与存储模型的转换规则，将所述查询请求转换为匹配于所查询数据库的执行方式；所述存储模型包括所查询数据库的属性信息；所述转换规则包括业务元素与所查询数据库中属性的对应关系；
数据库访问单元，用于按照所述执行方式访问对应的数据库。

7.  根据权利要求6所述的装置，其特征在于，所述业务模型以元数据格式描述业务场景，还包括以下各项中的至少一项：业务元素的约束信息、业务元素间的约束信息、业务元素的实例信息、数据流信息、与其他业务模型的映射关系。

8.  根据权利要求6所述的装置，其特征在于，所述存储模型描述所查询数据库的数据存储，还包括以下各项中的至少一项：存储数据源名称、存储数据源类型、存储分片sharding模式、存储数据区名称。

9.  根据权利要求6所述的装置，其特征在于，所述转换单元具体用于：按照所查询数据库的存储引擎类型，将所述查询请求转换为匹配于所述存储引擎类型的执行方式。

10.  根据权利要求6至9任意一项所述的装置，其特征在于：所述查询请求包括基于业务元素的存储获取条件和结果过滤条件；
所述转换单元具体用于：以存储获取条件作为查询条件，将所述查询请求转换为匹配于所查询数据库的执行方式；
所述装置还包括：筛选单元，用于在从各个数据库获得的访问结果中，按照结果过滤条件进行筛选。

说明书数据的查询方法及查询装置
技术领域
本申请涉及数据库技术领域，尤其涉及一种数据的查询方法及数据的查询装置。
背景技术
随着社交网络和移动互联网的发展，数据呈现爆炸式增长，甚至过去数年里产生的数据量超越了以往数千年的数据量。数据成为企业最宝贵的资源，而数据挖掘、数据分析等技术的不断深入，使得企业决策越来越依赖于数据，全面、完整的数据将为决策提供更好的支持。
企业可获得的数据往往涉及到各种不同的存储引擎和存储模式，例如，既有RDS(RelationalDatabaseService，关系型数据库服务)类型的数据库，包括Oracle、MySQL、OceanBase等存储引擎，也有KV(Key-Value，键值)类型的数据库，包括Tair、Hbase等存储引擎。如果某个上层业务需要查询所有这些数据库，则实现起来有一定难度。
现有技术中，微软的Polybase技术通过将PDW(ParallelDataWarehouse，并行数据仓库)中的数据导出或导入到Hadoop，可以实现关联查询Hadoop数据和关系型数据库，从而能够部分实现上述功能。但是，将数据导入导出Hadoop仍需要相当的工作量，并且不能够适配所有的存储引擎(如Tair、OceanBase等并不适用)，影响了数据查询的完整性。
发明内容
有鉴于此，本申请提供一种数据的查询方法，所述数据保存在至少两个 不同的数据库中，所述方法包括：
接收基于业务模型的查询请求；所述业务模型包括业务元素；
根据业务模型与存储模型的转换规则，将所述查询请求转换为匹配于所查询数据库的执行方式；所述存储模型包括所查询数据库的属性信息；所述转换规则包括业务元素与所查询数据库中属性的对应关系；
按照所述执行方式访问对应的数据库。
本申请还提供了一种数据的查询装置，所述数据保存在至少两个不同的数据库中，所述装置包括：
请求接收单元，用于接收基于业务模型的查询请求；所述业务模型包括业务元素；
转换单元，用于根据业务模型与存储模型的转换规则，将所述查询请求转换为匹配于所查询数据库的执行方式；所述存储模型包括所查询数据库的属性信息；所述转换规则包括业务元素与所查询数据库中属性的对应关系；
数据库访问单元，用于按照所述执行方式访问对应的数据库。
由以上技术方案可见，本申请的实施例通过业务模型和存储模型间的转换规则，将用户以业务模型为基础的查询请求转换为针对所查询数据库的执行方式，不仅避免了数据在不同数据库间的导入导出，而且能够对适用的数据库没有限制；同时在用户层面屏蔽了底层数据库的差异，提高了查询的便利性和完备性。
附图说明
图1是本申请实施例中业务模型的一种元数据描述示例图；
图2是本申请实施例中数据的查询方法的流程图；
图3是计算设备的一种硬件结构图；
图4是本申请实施例中一种数据的查询装置的逻辑结构图。
具体实施方式
本申请的实施例提出一种新的数据的查询方法来解决现有技术中存在的问题。本申请的实施例中，按照业务需求，总结业务特征，生成面向业务的业务模型；依据被访问数据库的存储引擎、数据存储结构、存储模式等因素生成存储模型；在业务模型和存储模型之间建立转换规则，将用户从业务角度所做的查询转换为匹配于被访问数据库的查询指令，从而能够适配与任何类型的数据库；并且对用户而言只需关注于业务本身，屏蔽了底层的数据差异。
业务模型通常由业务人员分析业务的具体场景，将完成业务场景所需的各项信息作为业务元素，并且结合业务特征总结这些业务元素之间的关联关系，从而生成描述业务场景的业务模型。
在一种实施方式中，可以采用以元数据格式来描述业务场景的业务模型。例如，一个业务模型可以用如下元数据描述，其示意图请参见图1：
业务元素子集：定义该业务模型中包括的各项业务元素；
约束子集：定义业务元素的约束信息、和/或业务元素之间的约束信息；如业务元素的值域范围、某些业务元素不能同时使用等；
实例子集：定义业务元素的实例信息，即使用业务元素描述的实例是哪些；
流子集：定义数据流信息，即与业务元素相关的时序流程、动作等；
映射子集：定义本业务模型与其他业务模型的映射关系，包括与其他模型之间的关联、对应以及相互转换的情形。
以一种具体的业务场景——客户管理为例，总结业务特征抽象的业务模型——客户模型的元数据描述包括：
业务元素子集：客户编号、客户名称、客户类型、客户联系方式；
约束子集：客户编号、客户名称不能为空；客户类型为个人或机构二选一；
实例子集：客户模型的实例有个人客户和机构客户。
通过采用元数据语言，在更高的抽象层面统一了业务元素和业务模型的建模方法，提供了完整、共享、一致的业务元素和业务模型的视图。
本申请的实施例中，存储模型描述所查询数据库的数据存储，包括定义一个数据存储所需的必要信息，还可以包括各类实际存储引擎共性的信息。具体而言，存储模型包括所查询数据库的属性信息，还可以包括存储数据源名称、存储数据源类型、存储sharding(分片)模式和/或存储数据区名称。
所查询数据库的属性信息包括数据库中实体型所具有的属性；存储数据源名称包括用来建立到所查询数据库的连接所需的信息；存储数据源类型可以是所查询数据库的存储引擎等信息；存储sharding模式可以是读写分离、水平拆分等；存储数据区名称对关系型数据库可以是表，对KV存储可以是命名空间等。
可以根据具体的应用场景需要来确定存储模型中具体要包括哪些信息。例如，如果需要查询的所有数据库都采用同样的sharding模式、具有同样的存储数据源类型，则存储模型中可以不包括这两项。
存储模型可以人工生成，也可以由程序自动生成。
本申请实施例中的数据查询方法应用于所查询的数据保存在至少两个不同的数据库中的场景。这些数据库的不同是指对这些数据库做相同的查询时，其具体的实现方式不同，例如，可以是所采用的存储引擎不同，也可以是存储引擎相同而数据的组织形式不同。本实施例中，数据查询方法的流程如图2所示。
在步骤S210，接收基于业务模型的查询请求。
本实施例中，向用户提供基于业务模型的查询方式。由于业务模型以业务元素为基础，用户的查询请求中通常包括基于业务元素的查询条件。如前所述，业务模型是针对业务场景抽象而成的，基于业务模型的查询方式可以使得用户关注于业务需求本身，而不必关心底层不同数据库之间的差异。
查询请求的格式可以根据业务需求自行定义，也可以参照数据库的查询 指令来定义。本实施例对此不作限定。
在一种实施方式中，可以在查询请求包括两种基于业务元素的查询条件：基于业务元素的存储获取条件和结果过滤条件。其中，存储获取条件用来作为查询条件，将查询请求转换为匹配于所查询数据库的执行方式；而结果过滤条件用来作为在结果中进行过滤的条件，在从各个数据库获得的访问结果中进行筛选(即，在步骤S230中获得的查询结果中进行筛选)。
例如，面向业务的查询请求可以以CQL(CassandraQueryLanguage，Cassandra查询语句)为载体，采用基于业务模型元数据的类sql(StructuredQueryLanguage，结构化查询语言)查询语言，来尽量完备、无歧义的描述查询语义。
一种可能的CQL语句如下：
SELECT[业务元素，业务模型]FROM[业务模型]
ID业务元素判断条件1[AND业务元素判断条件2]
[WHERE业务元素判断条件3[AND业务元素判断条件4]]
上述语句的含义为：在业务模型中查找符合业务元素判断条件1、业务元素判断条件2(可选)、业务元素判断条件3(可选)和业务元素判断条件4(可选)的业务元素或业务模型。其中，业务元素判断条件1和业务元素判断条件2为存储获取条件，业务元素判断条件3和业务元素判断条件4为结果过滤条件。
在步骤S220，根据业务模型与存储模型的转换规则，将所述查询请求转换为匹配于所查询数据库的执行方式。
业务模型到存储模型之间的转换规则将业务模型中的业务元素与所查询数据库中存储的数据联系起来，并且将面向业务的查询请求转换为所查询面向数据库的查询指令，从而将从用户接收的查询请求转换为匹配于数据库的执行方式。
转换规则中包括业务元素与所查询数据库中属性的对应关系。例如，一个名称为CsCustomer的业务模型，包括业务元素UserType；一个名称为 cs_customer的存储模型，包括属性user_type；则业务模型CsCustomer到存储模型cs_customer的转换规则可以是：「CsCustomer,UserType,cs_customer,user_type,oneToOneMapping」，含义为Customer业务模型中的UserType业务元素在cs_customer存储模型中的user_type属性字段里，这个业务元素与属性之间是一一映射的(即在数据库中是什么值，在业务模型里就是什么值)。在根据转换规则将查询请求转换为匹配于所查询数据库的执行方式时，会按照业务元素与属性的对应关系，将查询条件、或者还包括查询对象由业务元素描述转换为由数据库的属性描述。
根据具体的业务场景、所采用的业务模型和存储模型，转换规则中还可以包括将查询请求转换为对数据库访问指令所需的其他规则。例如，要查询的数据库采用不同存储引擎(如包括Oracle数据库和Tair数据库的情形)，则转换规则中，还会包括所查询数据库的存储数据源类型；在根据转换规则将查询请求转换为匹配于所查询数据库的执行方式时，会按照所查询数据库的存储引擎类型，将查询请求转换为匹配于该存储引擎类型的执行方式。
转换规则可以人工生成，也可以由程序根据业务模型和存储模型自动生成，本申请实施例对如何生成转换规则不作限定。
需要说明的是，匹配于所访问的数据库的执行方式，可以是直接访问该数据库、对该数据库进行直接查询的执行方式，也可以是通过调用某个数据库中间件对所访问数据库进行访问的执行方式，本实施例中不作限定，只要能够从被访问的数据库中获得查询结果即可。
在步骤S230，按照转换后的执行方式访问对应的数据库。
在将用户基于业务模型的查询请求转换为与所查询数据库对应的执行方式后，按照上述执行方式访问对应的数据库，获得查询结果。
在一种实施方式中，可以增加对所查询数据库的执行模式的控制。例如，在某个所查询数据库的并发访问量超过一定程度时延迟后续查询请求的执行；当某个所查询数据库有多个物理存储备份时，将当前的查询请求路由到访问量较少的备份上；等等。
可见，本申请的实施例中，通过面向业务的业务模型和面向存储的存储模型间的转换规则，将用户以业务模型为基础的查询请求转换为针对所查询数据库的执行方式，不仅避免了数据在不同数据库间的导入导出，而且能够对适用的数据库没有限制；同时在用户层面屏蔽了底层数据库的差异，提高了查询的便利性和完备性。
与上述流程实现对应，本申请的实施例还提供了一种数据的查询装置，应用在具有网络功能的计算设备上，如服务器、电脑、手机等。该装置可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为逻辑意义上的装置，是通过所在设备的CPU将对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，除了图3所示的CPU、内存以及非易失性存储器之外，信标数据传输装置所在的装置通常还包括用于进行通信的芯片等其他硬件。
图4所示为本实施例提供的一种数据的查询装置，所查询的数据保存在至少两个不同的数据库中，所述装置包括请求接收单元、转换单元和数据库访问单元，其中：请求接收单元用于接收基于业务模型的查询请求；所述业务模型包括业务元素；转换单元用于根据业务模型与存储模型的转换规则，将所述查询请求转换为匹配于所查询数据库的执行方式；所述存储模型包括所查询数据库的属性信息；所述转换规则包括业务元素与所查询数据库中属性的对应关系；数据库访问单元用于按照所述执行方式访问对应的数据库。
可选的，所述业务模型以元数据格式描述业务场景，还包括以下各项中的至少一项：业务元素的约束信息、业务元素间的约束信息、业务元素的实例信息、数据流信息、与其他业务模型的映射关系。
可选的，所述存储模型描述所查询数据库的数据存储，还包括以下各项中的至少一项：存储数据源名称、存储数据源类型、存储分片sharding模式、存储数据区名称。
在一种实施方式中，所述转换单元具体用于：按照所查询数据库的存储引擎类型，将所述查询请求转换为匹配于所述存储引擎类型的执行方式。
所述查询请求中，可以包括基于业务元素的存储获取条件和结果过滤条件；此时，所述转换单元具体用于：以存储获取条件作为查询条件，将所述查询请求转换为匹配于所查询数据库的执行方式；所述装置还包括：筛选单元，用于在从各个数据库获得的访问结果中，按照结果过滤条件进行筛选。
从以上各种方法和装置的实施方式中可以看出，相对于现有技术通过将数据在不同数据库间导入导出，本申请的实施例建立业务模型和存储模型，用户基于业务模型进行查询，通过业务模型和存储模型间的转换规则来将用户的查询请求转换为对数据库的访问指令，从而能够实现对各种数据库的统一查询，使得查询数据更为全面；同时向用户屏蔽了底层数据库的差异，使得查询更为便利。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包 括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。