一种数据查询方法及装置与流程

本申请涉及计算机技术领域，尤其涉及一种数据查询方法及装置。

背景技术：

随着信息技术的发展，数据库系统得到了广泛的应用，数据的存储量与日俱增。用户对数据库中数据的查询需求越来越复杂，涉及的已不仅是查询或操作一张数据关系表中的一条或几条记录，而是要对多张数据关系表中大量的数据(也即，多维数据)进行数据分析和信息综合。

目前，在多维数据的查询过程中，一种称为联机分析处理(onlineanalyticalprocessing，olap)的方式得到了广泛的应用。其中，olap具体又包含两种方式：基于多维数据库的molap和基于关系数据库的rolap。无论是molap或rolap，在对数据进行查询处理时，均是将数据库中的数据构成多维数据集(也称为cube，是一种以立方体的方式展现的多维视图)进行查询分析。然而，仅以一个cube中的数据进行查询分析的方式，在实际应用中的一些复杂的查询分析业务中，可能会导致分析结果的延展性较差。

现有技术中，为了增加分析结果的延展性，通常采用多个数据来源不同的cube之间进行关联，具体包括两种方式。

其中一种方式为：采用映射维表关联模型的方法，将需要关联的维表(数据库中用于存储维度值的数据表)预先建模，配置到多维数据集模型中。那么，在查询过程中，就可以依据维表与数据集之间的关联关系，进行查询。

另一种方式为：采用关系元数据直接配置的方法，这种方式是在创建数据库的数据表结构时进行关联，形成固定的数据表结构，并以固定的数据表结构的元数据进行关联数据的查询。如：用户想要查询“地区”和“总销量”之间 的关系，那么，用户就需要构建包含“地区”和“总销量”两个维度的数据表。

但是，对于上述两种方式而言，在第一种方式中，用户需要已知其所要查询的数据所存储的数据表(或该数据表中的字段)，并依据此定义相应的物理模型；在第二种方式中，用户需要根据其所关注的数据预先创建固定的数据表结构。显然，这两种方式均需要预先定义物理模型的关联关系，对于用户而言过于繁琐，不便于用户操作。

技术实现要素：

本申请实施例提供一种数据查询方法，用以解决现有技术中的对多维数据进行查询的过程中操作繁琐的问题。

本申请实施例提供的一种数据查询方法，应用于基于关系数据库的rolap，包括：

接收数据查询请求；

确定所述数据查询请求所对应的待查询数据的标识信息；

根据确定出的所述标识信息，在预先建立的多维数据关系模型中，确定该标识信息所对应的查询路径；

根据所述查询路径以及所述标识信息进行数据查询，生成查询结果。

本申请实施例提供的一种数据查询装置，应用于基于关系数据库的rolap，包括：

接收模块，用于接收数据查询请求；

确定模块，用于确定所述数据查询请求所对应的待查询数据的标识信息；

查询路径模块，用于根据确定出的所述标识信息，在预先建立的多维数据关系模型中，确定该标识信息所对应的查询路径；

查询处理模块，用于根据所述查询路径以及所述标识信息进行数据查询，生成查询结果。

本申请实施例提供一种数据查询方法及装置，通过该方法，当服务器接收 到了用户发出的数据查询请求后，将根据该数据查询请求进一步确定出用户所要查询的数据的维度或度量，并依据此，在相应的数据库中确定出符合该维度或度量的、预先建立的数据关系模型，其中，数据关系模型中包含了相互关联的多个多维数据集，那么，便可以根据用户所要查询的数据的维度或度量，在数据关系模型中的多个多维数据集中确定出与该维度或度量具有关联关系的各类数据。显然，与现有技术不同的是，对于用户而言，上述方式无需用户了解其要查询的数据所在的具体数据表或者具体的字段，同样，也无需用户自行定义数据表格式，用户只需提供所要查询的具有关联的数据，服务器就可以根据用户所提供的数据，在预先建立的数据关系模型中进行数据查询，从而便于用户操作，并有效地减少了现有的查询方式中过于繁琐的操作。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的数据查询过程；

图2为本申请实施例提供的事实表和各关联数据表的示意图；

图3为本申请实施例提供的数据关系模型的示意图；

图4为本申请实施例提供的数据查询装置结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例所提供的数据查询方法，是基于关系数据库的rolap模型，其中供查询的数据属于分析型数据，由相应的服务器从关系型数据库获取数据，服务器与该关系型数据库之间相关联。

在本申请的一种方式下，服务器接收来自用户的查询请求，并从关系型数据库中获取相应的数据反馈给用户。

在另一种方式下，服务器以业务平台的方式提供数据查询服务，供不同的使用者(既可以是个人用户，也可以是企业用户)所使用，当然，不同的使用者可将各自的数据提供至上述的服务平台上，供其他使用者进行查询。这里并不构成对本申请的限定。

具体而言，本申请实施例所提供的一种数据查询方法，如图1所示，具体包括以下步骤：

s101，接收数据查询请求。

当用户需要进行数据的查询时，便可以发出相应的查询请求，在实际应用中，查询请求中包含了用户所要查询的数据和/或与数据相关的信息(如：维度)，例如：用户所要查询的201x年的收入数据、公司上半年销售额数据等具体的数据，又例如：用户所要查询的商品类目、某地区的生产量等维度信息。

其中，维度是一种数据的属性信息，在本申请实施例的一种方式下，维度与键相类似，可以包括诸如用户名、性别、用户类型、销售额、地区等等用来划分不同种类数据的信息。

需要说明的是，在实际应用场景中，相应的服务器与数据库相关联，可提供数据查询功能，在用户侧，用户可以通过相应的浏览器访问至服务器所提供的查询功能，又或者，用户可通过客户端的方式获得服务器所提供的查询功能。这里并不构成对本申请的限定。

s102，确定所述数据查询请求所对应的待查询数据的标识信息。

在本申请实施例中，待查询数据的标识信息，包括：所要查询的维度及其对应的度量值，或维度。其中，度量值可以认为是一种具体的数据值。换言之， 用户在进行数据查询时，既可以针对某维度下具体的一种数据值进行查询，如：用户可针对维度“日期”、度量值“10月”进行查询；也可以针对单一的某一维度进行查询，如：用户可针对维度“产品号”进行查询。这里并不构成对本申请的限定。

当服务器接收到了用户发出的数据查询请求后，就将确定出该数据查询请求所对应的待查询数据的标识信息，从而，根据标识信息进行数据的查询。

当然，在实际应用中，用户可以通过诸如浏览器的界面或客户端界面输入相应的查询请求。这里并不构成对本申请的限定。

s103，根据确定出的所述标识信息，在预先建立的多维数据关系模型中，确定该标识信息所对应的查询路径。

考虑到实际应用中，在较为复杂的查询需求的情况下，一个多维数据集(如：cube)中的数据可能难以充分提供全面的查询结果，在这些复杂的查询需求下，用户需要尽可能多的查询结果，以充分且明确地反映出事件的状态。故在本申请实施例中，服务器会预先建立相应的多维数据关系模型，该多维数据关系模型中的各多维数据集之间的关系包括：父子关系，也即，多维数据关系模型中包含父多维数据集(以下称为主数据集)和子多维数据集(以下称为子数据集)。可以认为，多维数据关系模型中包含了相互关联的多个多维数据集，基于多维数据关系模型，可以从多个角度为用户提供出综合式的数据，以满足用户复杂的查询需求。

基于此，本申请实施例中所提及的查询路径，具体是指，在多维数据关系模型中，与用户的标识信息所对应的数据库具有关联关系的各个数据集之间的关系链。

通过上述的查询路径，就可以查询出与用户所要查询的数据具有关联关系的不同数据，具体而言，将执行下述步骤s104。

s104，根据所述查询路径以及所述标识信息进行数据查询，生成查询结果。

根据查询路径，可以确定出至少一个多维数据集，并在确定出的多维数据 集中，查询标识信息所对应的数据，这样，便得到了相互关联的多维数据集中与标识信息具有关联关系的多维数据。

例如：用户要查询公司全年的销售量数据，并假设在数据库中，记录有销售总额数据的数据表(即，可作为多维数据集a)和销售量数据的数据表(可作为多维数据集b)相互关联，且记录有销售总额数据的数据表与记录有销售量数据的数据表之间具有父子关系，那么，就可以确定出多维数据集a至b的关系链路(即，查询路径)，那么，对于用户而言，最终将获得销售量数据以及相应的销售总额数据。

显然，这样的查询结果可以更加全面的为用户提供相关联的数据，以使得用户得到充分的数据进行后续的操作(数据分析、数据决策等)。

通过上述步骤，当服务器接收到了用户发出的数据查询请求后，将根据该数据查询请求进一步确定出用户所要查询的数据的维度或度量，并依据此，在相应的数据库中确定出符合该维度或度量的、预先建立的数据关系模型，其中，数据关系模型中包含了相互关联的多个多维数据集，那么，便可以根据用户所要查询的数据的维度或度量，在数据关系模型中的多个多维数据集中确定出与该维度或度量具有关联关系的各类数据。显然，与现有技术不同的是，对于用户而言，上述方式无需用户了解其要查询的数据所在的具体数据表或者具体的字段，同样，也无需用户自行定义数据表格式，用户只需提供所要查询的具有关联的数据，服务器就可以根据用户所提供的数据，在预先建立的数据关系模型中进行数据查询，从而便于用户操作，并有效地减少了现有的查询方式中过于繁琐的操作。

在实际应用中，服务器预先建立多维数据关系模型的过程具体包括：预先选定数据库中的事实表，将选定出的所述事实表作为主数据集，并确定该主数据集中的各属性信息，根据所述各属性信息，在所述数据库中确定各属性信息对应的各关联数据表，其中，所述关联数据表包括事实表和/或维表；将确定出的各关联数据表作为子数据集，建立各子数据集与所述主数据集之间的数据关 系，形成所述多维数据关系模型。

需要说明的是，在本申请实施例的多维数据关系模型中，主数据集并非由子数据集构成，而是主数据集与子数据集之间具有从属关系，这里并不构成对本申请的限定。

其中，上述的事实表，具体可以是数据库中的用于存储数据的数据表(事实表中可包含数据的维度和度量值)，事实表中包含多种数据，在一种实际应用场景下，作为主数据集的事实表可由用户提供的数据指令而形成，服务器将按照用户的数据指令，将相应的数据汇总生成事实表，并将该事实表确定为主数据集，当然，这里并不构成对本申请的限定。

上述的维表，具体可以是数据库中用于存储维度的数据表，维表中通常没有具体的度量值，仅包含不同的维度，例如：一张以日期作为维度的维表中，可以包含进一步细分的日、月、年等子维度。

确定了主数据集之后，服务器将根据主数据集中的各属性信息(也即，数据的维度)，来确定各关联数据表(也即，子数据集)。这里需要说明的是，本申请实施例中的关联数据表，是与作为主数据集的事实表具有关联关系的数据表。

具体而言，根据所述各属性信息，在所述数据库中确定各属性信息对应的各关联数据表，具体包括：针对每一属性信息，在所述数据库中确定包含有该属性信息的各数据表，并将确定出的各数据表作为为关联数据表。

可见，对于数据库中的各数据表，若其中包含有上述事实表中的某个属性信息(也即，维度)，那么，就可以将该数据表确定为与上述事实表具有关联关系的关联数据表。

例如：如图2所示，显示了数据库中的事实表(也即，主数据集)和与该事实表具有关联关系的各关联数据表。

其中，图2中的数据表a就是事实表(后续称为事实表a，事实表a中既包含有不同维度，也包含有各维度下的度量值，其中的度量值仅起到示例的 作用，并不作为对本申请的限定)，该事实表a就可以作为主数据集。可见，事实表a中包含多种维度(也即，上述的属性信息)：即，订单号、销售员号、客户号、产品号、日期标识、地区名称、数量、总价。根据不同的维度，可以在数据库中确定出包含该维度的关联数据表，正如图2中所示的数据表b1～b6。显然，对于数据表b1～b6，其中均包含有事实表a的某项维度，从而，可以确定数据表b1～b6就是与上述事实表a具有关联关系的关联数据表。

当然，与现有技术中不同的是，在本申请实施例中，关联数据表既可以是维表、也可以是事实表，换言之，对于如图2所示的各关联数据表b1～b6而言，不仅仅包含有事实表a中的维度，还可以包含不同维度下的具体度量值(各关联数据表b1～b6中具体的度量值并未在图2中的示出，这里并不构成对本申请的限定)。

在实际应用中，不同的子数据集(即，关联数据表)可能具有自身的子数据集，在这样的情况下，服务器就会确定出完整的数据关系模型，具体而言，建立各子数据集与所述主数据集之间的数据关系，具体包括：将包含有所述属性信息的各关联数据表，确定为与所述主数据集相关联的一级子数据集；

并采用如下方法确定所述主数据集的各级子数据集：确定每一级子数据集中包含的子属性信息，确定包含有所述子属性信息的各关联数据表，将包含有所述子属性信息的各关联数据表，作为所述一级子数据集的下一级子数据集，直至不能根据子属性信息确定出关联数据表。

例如：如图3所示，为服务器所确定出的完整的数据关系模型，其中，包含一个主数据集和5个子数据集，子数据集1自身具有两个子集：子数据集2和3；子数据集4自身具有一个子集：子数据集5。

在确定了完整的数据关系模型的基础上，便可以针对用户所需的数据进行查询。若所述标识信息落入多个数据集，则确定该标识信息所属的查询路径，具体包括：确定所述标识信息所落入的各数据集，在所述多维数据关系模型中，确定所述标识信息所落入的各数据集的共同上级数据集，分别确定所述标识信 息所落入的每一数据集至所述共同上级数据集的各路径，将确定出各路径作为所述标识信息所属的查询路径。

现仍以图3为例进行说明，假设，用户所要查询的维度分别存储在子数据集2和3中，那么，服务器在进行数据查询时，首先将确定出该数据所在的子数据集，即子数据集2和3中，之后，将追溯至这两个子数据集的共同上级数据集，也即，图3中的子数据集1。从而，可以确定出本次用户所要查询的数据的查询路径为：子数据集1-子数据集2，以及，子数据集1-子数据集3。

在另一示例中，假设用户所要查询的维度落入在子数据集2和子数据集5中，那么，服务器在进行数据查询时，将首先确定出子数据集2和子数据集5，并向上层关系进行追溯，直到追溯至其共同上级数据集，从图3中可见，子数据集2和子数据集5的共同上级数据集就是主数据集。所以，本次的查询路径为：主数据集-子数据集1-子数据集2，以及主数据集-子数据集4-子数据集5。

基于此，在确定了查询路径之后，查询过程具体为：根据所述查询路径以及所述标识信息进行数据查询，具体包括：根据所述查询路径，确定该查询路径所对应的各数据集；在确定出的所述各数据集中，根据所述标识信息，查询所述标识信息所对应的数据。这样一来，所查询到的数据就是具有关联关系的数据。

延续上例，结合图3所示的数据关系模型，假设用户所要查询的维度m和n分别落入在子数据集2和子数据集5中，那么，服务器所确定出的查询路径为：主数据集-子数据集1-子数据集2，以及主数据集-子数据集4-子数据集5，之后，将分别从主数据集、子数据集1、子数据集2中，获取与维度m相关的数据，同时，分别从主数据集、子数据集4、子数据集5中，获取与维度n相关的数据。这样一来，最终所查询到相关联的维度m和n的数据。

当然，在本申请实施例中的一种方式下，服务器将根据确定出的查询路径，生成相应的结构化查询语言(structuredquerylanguage，sql)，并根据标识信息完成对用户所需的数据的查询。

考虑到实际应用中，用户在进行数据查询时，所需的数据结果的展示方式有可能不同，如：某些用户想要将所查询的销售量和销售额度数据以列的方式显示，并将时间数据以行的方式显示等等。

基于此，为了让用户获得其所要的数据结果，因此，所述方法还包括：接收用户发出的展示指令，根据所述展示指令，将所述查询结果中包含的数据进行格式转化，转化为所述展示指令所对应的数据格式。

其中，所述展示指令所对应的数据格式包括：图形展示格式、多维列表格式中的至少一种。其中，图形展示格式包括但不限于：饼图、柱状图、折线图、立方图等等具有图形结构的视图。

也就是说，在本申请实施例中，用户可以自行定义其所需的数据结果的展示方式，并将相应的定义设置(也即，展示指令)发送给服务器，这样一来，服务器便可以根据用户所需的展示方式，对查询到的数据进行处理。最终返回给用户。

综上所述，本申请实施例中，通过多维数据集之间的关联关系，避免了现有技术中对数据库中的数据进行物理建模(如：构造特定的数据表格式等)的方式，从而，无需用户了解具体数据的存储方式，数据所存储的具体的数据表或字段。一方面，降低用户的使用门槛，另一方面，涉及数据互联等应用场景时，灵活性大大提高。此外，由于数据关系模型中被关联的多维数据集是一种副本拷贝，后续维度/度量等元数据配置变更，不会相互影响，保持了逻辑模型的稳定性。

基于同样的思路，本申请实施例还提供一种数据查询装置，如图4所示。

在图4中，所述数据查询装置包括：接收模块401、确定模块402，查询路径模块403以及查询处理模块404，其中，

所述接收模块401，用于接收数据查询请求。

所述确定模块402，用于确定所述数据查询请求所对应的待查询数据的标识信息。

所述检测模块403，用于根据确定出的所述标识信息，在预先建立的多维数据关系模型中，确定该标识信息所对应的查询路径。

查询处理模块404，用于根据所述查询路径以及所述标识信息进行数据查询，生成查询结果。

在本申请实施例中，所述装置还包括：数据关系模块，用于预先选定数据库中的事实表，将选定出的所述事实表作为主数据集，并确定该主数据集中的各属性信息，根据所述各属性信息，在所述数据库中确定各属性信息对应的各关联数据表，其中，所述关联数据表包括事实表和/或维表；将确定出的各关联数据表作为子数据集，建立各子数据集与所述主数据集之间的数据关系，形成所述多维数据关系模型。

进一步地，数据关系模块，具体用于针对每一属性信息，在所述数据库中确定包含有该属性信息的各数据表，并将确定出的各数据表作为为关联数据表。

基于此，数据关系模块，具体用于将包含有所述属性信息的各关联数据表，确定为与所述主数据集相关联的一级子数据集；并执行如下操作确定所述主数据集的各级子数据集：

确定每一级子数据集中包含的子属性信息，确定包含有所述子属性信息的各关联数据表，将包含有所述子属性信息的各关联数据表，作为所述一级子数据集的下一级子数据集，直至不能根据子属性信息确定出关联数据表。

在一种实施方式中，若所述标识信息落入多个数据集，则查询处理模块404，具体用于确定所述标识信息所落入的各数据集，在所述多维数据关系模型中，确定所述标识信息所落入的各数据集的共同上级数据集，分别确定所述标识信息所落入的每一数据集至所述共同上级数据集的各路径，将确定出各路径作为所述标识信息所属的查询路径。

所述查询处理模块404，具体用于根据所述查询路径，确定该查询路径所对应的各数据集，在确定出的所述各数据集中，根据所述标识信息，查询所述标识信息所对应的数据。

此外，所述装置还包括：数据格式处理模块405，用于接收用户发出的展示指令，根据所述展示指令，将所述查询结果中包含的数据进行格式转化，转化为所述展示指令所对应的数据格式，其中，所述展示指令所对应的数据格式包括：图形展示格式、多维列表格式中的至少一种。

在本申请实施例中，上述的待查询数据的标识信息包括：所要查询的维度及其对应的度量值，或维度。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设 备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。