数据的查询方法及查询装置制造方法及图纸

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

【技术实现步骤摘要】

本申请涉及数据库
，尤其涉及一种数据的查询方法及数据的查询装置。
技术介绍
随着社交网络和移动互联网的发展，数据呈现爆炸式增长，甚至过去数年里产生的数据量超越了以往数千年的数据量。数据成为企业最宝贵的资源，而数据挖掘、数据分析等技术的不断深入，使得企业决策越来越依赖于数据，全面、完整的数据将为决策提供更好的支持。企业可获得的数据往往涉及到各种不同的存储引擎和存储模式，例如，既有RDS(Relat1nal Database Service,关系型数据库服务)类型的数据库，包括Oracle、MySQL、OceanBase等存储引擎，也有KV (Key-Value,键值)类型的数据库,包括Tair、Hbase等存储引擎。如果某个上层业务需要查询所有这些数据库，则实现起来有一定难度。现有技术中，微软的Polybase技术通过将PDW(ParalIel Data Warehouse,并彳丁数据仓库)中的数据导出或导入到Hadoop，可以实现关联查询Hadoop数据和关系型数据库，从而能够部分实现上述功能。但是，将数据导入导出Hadoop仍需要相当的工作量，并且不能够适配所有的存储引擎(如Tai^OceanBase等并不适用)，影响了数据查询的完整性。
技术实现思路
有鉴于此，本申请提供一种数据的查询方法，所述数据保存在至少两个不同的数据库中，所述方法包括:接收基于业务模型的查询请求；所述业务模型包括业务元素；根据业务模型与存储模型的转换规则，将所述查询请求转换为匹配于所查询数据库的执行方式；所述存储模型包括所查询数据库的属性信息；所述转换规则包括业务元素与所查询数据库中属性的对应关系；按照所述执行方式访问对应的数据库。本申请还提供了一种数据的查询装置，所述数据保存在至少两个不同的数据库中，所述装置包括:请求接收单元，用于接收基于业务模型的查询请求；所述业务模型包括业务元素；转换单元，用于根据业务模型与存储模型的转换规则，将所述查询请求转换为匹配于所查询数据库的执行方式；所述存储模型包括所查询数据库的属性信息；所述转换规则包括业务元素与所查询数据库中属性的对应关系；数据库访问单元，用于按照所述执行方式访问对应的数据库。由以上技术方案可见，本申请的实施例通过业务模型和存储模型间的转换规则，将用户以业务模型为基础的查询请求转换为针对所查询数据库的执行方式，不仅避免了数据在不同数据库间的导入导出，而且能够对适用的数据库没有限制；同时在用户层面屏蔽了底层数据库的差异，提高了查询的便利性和完备性。【附图说明】图1是本申请实施例中业务模型的一种元数据描述示例图；图2是本申请实施例中数据的查询方法的流程图；图3是计算设备的一种硬件结构图；图4是本申请实施例中一种数据的查询装置的逻辑结构图。【具体实施方式】本申请的实施例提出一种新的数据的查询方法来解决现有技术中存在的问题。本申请的实施例中，按照业务需求，总结业务特征，生成面向业务的业务模型；依据被访问数据库的存储引擎、数据存储结构、存储模式等因素生成存储模型；在业务模型和存储模型之间建立转换规则，将用户从业务角度所做的查询转换为匹配于被访问数据库的查询指令，从而能够适配与任何类型的数据库；并且对用户而言只需关注于业务本身，屏蔽了底层的数据差异。业务模型通常由业务人员分析业务的具体场景，将完成业务场景所需的各项信息作为业务元素，并且结合业务特征总结这些业务元素之间的关联关系，从而生成描述业务场景的业务模型。在一种实施方式中，可以采用以元数据格式来描述业务场景的业务模型。例如，一个业务模型可以用如下元数据描述，其示意图请参见图1:业务元素子集:定义该业务模型中包括的各项业务元素；约束子集:定义业务元素的约束信息、和/或业务元素之间的约束信息；如业务元素的值域范围、某些业务元素不能同时使用等；实例子集:定义业务元素的实例信息，即使用业务元素描述的实例是哪些；流子集:定义数据流信息，即与业务元素相关的时序流程、动作等；映射子集:定义本业务模型与其他业务模型的映射关系，包括与其他模型之间的关联、对应以及相互转换的情形。以一种具体的业务场景——客户管理为例，总结业务特征抽象的业务模型——客户模型的元数据描述包括:业务元素子集:客户编号、客户名称、客户类型、客户联系方式；约束子集:客户编号、客户名称不能为空；客户类型为个人或机构二选一；实例子集:客户模型的实例有个人客户和机构客户。通过采用元数据语言，在更高的抽象层面统一了业务元素和业务模型的建模方法，提供了完整、共享、一致的业务元素和业务模型的视图。本申请的实施例中，存储模型描述所查询数据库的数据存储，包括定义一个数据存储所需的必要信息，还可以包括各类实际存储引擎共性的信息。具体而言，存储模型包括所查询数据库的属性信息，还可以包括存储数据源名称、存储数据源类型、存储sharding(分片)模式和/或存储数据区名称。所查询数据库的属性信息包括数据库中实体型所具有的属性；存储数据源名称包括用来建立到所查询数据库的连接所需的信息；存储数据源类型可以是所查询数据库的存储引擎等信息；存储sharding模式可以是读写分离、水平拆分等；存储数据区名称对关系型数据库可以是表，对KV存储可以是命名空间等。可以根据具体的应用场景需要来确定存储模型中具体要包括哪些信息。例如，如果需要查询的所有数据库都采用同样的sharding模式、具有同样的存储数据源类型，则存储模型中可以不包括这两项。存储模型可以人工生成，也可以由程序自动生成。本申请实施例中的数据查询方法应用于所查询的数据保存在至少两个不同的数据库中的场景。这些数据库的不同是指对这些数据库做相同的查询时，其具体的实现方式不同，例如，可以是所采用的存储引擎不同，也可以是存储引擎相同而数据的组织形式不同。本实施例中，数据查询方法的流程如图2所示。在步骤S210，接收基于业务模型的查询请求。本实施例中，向用户提供基于业务模型的查询方式。由于业务模型以业务元素为基础，用户的查询请求中通常包括基于业务元素的查询条件。如前所述，业务模型是针对业务场景抽象而成的，基于业务模型的查询方式可以使得用户关注于业务需求本身，而不必关心底层不同数据库之间的差异。查询请求的格式可以根据业务需求自行定义，也可以参照数据库的查询指令来定义。本实施例对此不作限定。在一种实施方式中，可以在查询请求包括两种基于业务元素的查询条件:基于业务元素的存储获取条件和结果过滤条件。其中，存储获取条件用来作为查询条件，将查询请求转换为匹配于所查询数据库的执行方式；而结果过滤条件用来作为在结果中进行过滤的条件，在从各个数据库获得的访问结果中进行筛选(即，在步骤S230中获得的查询结果中进行筛选)。例如，面向业务的查询请求可以以CQL(Cassandra Query Language,Cassandra查询语句)为载体，采用基于业务模型元数据的类sql (Structured Query Language,结构化查询语言)查询语言，来尽量完备、无歧义的描述查询语义。一种可能的CQL语句如下:SELECT FROM ID业务元素判断条件I ]上述语句的含义为:在业务模型中查找符合业务元素判断条件1、业务元素判断条件2 (可选)、业本文档来自技高网...

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

【技术特征摘要】

【专利技术属性】
技术研发人员：刘浩，邵帅，李春晓，侯柏平，
申请(专利权)人：阿里巴巴集团控股有限公司，
类型：发明
国别省市：开曼群岛;KY