一种数据查询方法、系统及存储介质与流程

1.本技术涉及大数据应用技术领域，尤其涉及一种数据查询方法、系统及存储介质。


背景技术：

2.在大数据的应用领域中，数据中台可对数据进行采集、汇聚等智能化加工处理，并将沉淀加工后的数据资产转化为数据服务。数据中台可基于服务接口对外提供数据服务。例如，在政务办事场景中，可引入数据中台以为多种政务服务事项提供数据查询服务。
3.目前，通常需要为每个政务服务事项分别配置服务接口，数据开发工作量很大。


技术实现要素：

4.本技术的多个方面提供一种数据查询方法、系统、设备及存储介质，用以提高数据中台中服务接口的通用性，减少数据开发工作量。
5.本技术实施例提供一种数据系统，包括：
6.接口层，包含至少一个服务接口，所述服务接口用于接收至少一类数据查询请求，不同类数据查询请求中包含的需求数据项不完全相同；
7.数据模型层，用于为所述至少一个服务接口分别维护可查询数据项与数据模型中字段之间的路由信息；
8.服务处理层，用于根据所述至少一个服务接口各自对应的所述路由信息，确定与所述接口层接收到的数据查询请求中包含的需求数据项关联的目标数据模型中的目标字段；并基于所述目标字段下的字段值，确定所述需求数据项对应的查询结果。
9.本技术实施例还提供一种数据查询方法，包括：
10.通过目标服务接口接收数据查询请求，所述数据查询请求中包含需求数据项的标识信息，所述目标服务接口用于接收至少一类数据查询请求，不同类数据查询请求包含的需求数据项不完全相同；
11.基于预设的可查询数据项与数据模型中字段之间的路由信息，确定所述数据查询请求中包含的需求数据项关联的目标数据模型中的目标字段；
12.基于所述目标字段下的字段值，确定所述需求数据项对应的查询结果。
13.本技术实施例还提供一种数据查询系统，包括：业务子系统、数据子系统和云计算系统；
14.所述业务子系统，用于向所述数据子系统发起多类数据查询请求，向所述数据子系统中同一服务接口发送的不同类数据查询请求包含的需求数据项不完全相同；
15.所述数据子系统，用于通过目标服务接口接收数据查询请求；基于预设的可查询数据项与数据模型中字段之间的路由信息，确定所述数据查询请求中包含的需求数据项关联的目标数据模型中的目标字段；基于所述目标字段下的字段值，确定所述需求数据项对应的查询结果；所述目标服务接口用于接收至少一类数据查询请求；
16.所述云计算系统，用于将数据源接入所述数据模型。
17.本技术实施例还提供一种存储计算机指令的计算机可读存储介质，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行前述的数据查询方法。
18.在本技术实施例中，可提供通用的服务接口，服务接口对应的可查询数据项是可维护的且可涵盖多类数据查询请求所需的需求数据项，而服务接口可提供可查询数据项与数据模型中字段之间的路由信息，从而可快速准确地确定出与需求数据项关联的目标数据模型中的目标字段，并可基于目标字段下的字段值，确定需求数据项对应的查询结果。据此，本技术实施例中，多个政务服务事项可调用统一的服务接口，无需再为每个政务服务事项单独开发服务接口，这可节省大量的数据开发工作；而且，在统一的服务接口下可进行自动路由，从而可为多个政务服务事项各自所需的需求数据项准确供数，保证数据查询结果的准确性。
附图说明
19.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：
20.图1为本技术一示例性实施例提供的一种数据系统的结构示意图；
21.图2为本技术一示例性实施例提供的一种应用场景的示意图；
22.图3为本技术一示例性实施例提供的一种服务接口的配置方案的逻辑示意图；
23.图4为本技术一示例性实施例提供的一种数据查询方案的逻辑示意图；
24.图5为本技术另一示例性实施例提供的一种数据查询系统的结构示意图；
25.图6为本技术又一示例性实施例提供的一种数据查询方法的流程示意图。
具体实施方式
26.为使本技术的目的、技术方案和优点更加清楚，下面将结合本技术具体实施例及相应的附图对本技术技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
27.目前，政务办事场景可采用数据中台实现数据共享，但需要为每个政务服务事项单独开发服务接口，数据开发工作量很大。为改善该技术问题，本技术实施例的一些实施例中：可提供通用的服务接口，服务接口对应的可查询数据项是可维护的且可涵盖多类数据查询请求所需的需求数据项，而服务接口可提供可查询数据项与数据模型中字段之间的路由信息，从而可快速准确地确定出与需求数据项关联的目标数据模型中的目标字段，并可基于目标字段下的字段值，确定需求数据项对应的查询结果。据此，本技术实施例中，多个政务服务事项可调用统一的服务接口，无需再为每个政务服务事项单独开发服务接口，这可节省大量的数据开发工作；而且，在统一的服务接口下可进行自动路由，从而可为多个政务服务事项各自所需的需求数据项准确供数，保证数据查询结果的准确性。
28.以下结合附图，详细说明本技术各实施例提供的技术方案。
29.图1为本技术一示例性实施例提供的一种数据系统的结构示意图。如图1所示，该数据系统包括：接口层10、数据模型层30和服务处理层20。
30.本实施例提供的数据系统可应用于各种场景中，例如，政务办事场景、交通出行场
景、工业管理场景、农业管理场景、零售业场景或其它需要进行多部门数据共享的场景等，本实施例对应用场景不做限定。
31.本实施例中，接口层10可包含至少一个服务接口。对于任意一个服务接口来说，可用于接收至少一类数据查询请求，不同类数据查询请求中包含的需求数据项不完全相同。也即是，不同类数据查询请求中包含的需求数据项可以部分相同，也可以完全不同。本实施例中，数据系统可基于接口层10中的服务接口对外提供数据服务。实际应用中，本实施例提供的数据系统可实现为数据中台产品，当然，本实施例并不限于此。另外，在不同的应用场景中，数据查询请求包含的需求数据项可以是多种多样的，本实施例对此不做限定。
32.本实施例中，数据查询请求的发起方，可以是与本实施例提供的数据系统交互的业务中台产品，也可以是应用程序等，本实施例对发起方不做限定。
33.图2为本技术一示例性实施例提供的一种应用场景的示意图。参考图2，以政务办事场景为例，本实施例中，不同类数据查询请求可来自不同的政务服务事项。例如，图2中的事项1可以是准生证申办事项，事项2可以公积金审批事项，事项1对应的数据查询请求所需的需求数据项可以包括自然人的身份证号、姓名和婚姻状态，事项2对应的数据查询请求所需的需求数据项则可包括自然人的身份证号、姓名、婚姻状态及社保缴纳年限。这样，事项1和事项2将分别对应不同类数据查询请求。
34.图3为本技术一示例性实施例提供的一种服务接口的配置方案的逻辑示意图。
35.参考图3，为了支持服务接口可提供通用化的数据服务，本实施例中，数据模型层30，可为至少一个服务接口分别维护可查询数据项与数据模型中字段之间的路由信息。
36.其中，数据模型可来自多个部门，例如，民政部门、工商部门、社保部分等等。而一个服务接口对应的可查询数据项可与多个部门的数据模型关联，这可实现多个部门之间的数据打通，进而，本实施例中的数据系统可实现多个部门之间的数据共享。以政务办事场景为例，实际应用中，图2中的政务服务事项可能是面向公众的，也可能是面向政府部门的，例如，前述的准生证申办事项即为面向公众的，而公积金审批事项则可面向公积金审批部门的。对于面向政府部门的情况，不同政府部门之间可进行数据共享，以为对方正在进行的事项提供查询结果。
37.实际应用中，数据模型可以采用数据表等形式，本实施例中，数据模型层30，可进行数据模型的定义，例如，从数据字段结构、主外键设置、模型关系或质量规则等方面对数据模型进行定义，以保证数据模型的标准化。
38.本实施例中，数据模型可作为服务接口的数据来源基础，而且，数据模型可进行固化，而不再需要像传统方案那样随着需求数据项的变化而随时调整，这可保证数据模型的稳定性，降低数据模型的维护成本。
39.其中，数据模型层30中的维护操作包括但不限于创建、增加、删除等。也即是，本实施例中，数据模型层30可对服务接口提供的数据服务进行动态扩展。这为服务接口可承接的政务服务事项的扩展奠定了基础。后文中将对服务接口的扩展进行详述。
40.图4为本技术一示例性实施例提供的一种数据查询方案的逻辑示意图。
41.参考图4，以数据模型层30为基础，本实施例中，服务处理层20可根据至少一个服务接口各自对应的路由信息，确定与接口层10接收到的数据查询请求中包含的需求数据项关联的目标数据模型中的目标字段；并基于目标字段下的字段值，确定需求数据项对应的
查询结果。
42.正如前文提及的，数据模型层30中可为至少一个服务接口分别维护可查询数据项与数据模型中字段之间的路由信息，基于此，在接口层10接收到数据查询请求的情况下，服务处理层20可对数据查询请求进行自动路由，以确定数据查询请求中包含的需求数据项关联的目标数据模型中的目标字段。
43.参考图4，接口层10可将数据查询请求调配至合适的服务接口；服务处理层20可在该服务接口下查找数据查询请求中包含的需求数据项关联的目标数据模型中的目标字段。
44.实际应用中，数据查询请求中可包含服务接口的地址，接口层10可按照服务接口的地址将数据查询请求调配到相应的服务接口。当然，在一些可选的方案中，接口层10还可根据数据查询请求包含的需求数据项和各服务接口可提供的可查询数据项，为数据查询请求选择服务接口。例如，可将对应的可查询数据项能够覆盖数据查询请求所需的所有需求数据项的服务接口，作为接收该数据查询请求的服务接口。当然，本实施例并不限于此。
45.另外，参考图4，接口层10还可查看数据查询请求所调配到的服务接口对应的可查询数据项，若数据查询请求中存在为包含在该服务接口的可查询数据项范围内的需求数据项，则可直接返回无法查询的提示。若数据查询请求中的所有需求数据项均包含在该服务接口的可查询数据项范围内，则可向该服务接口下发数据查询任务。
46.服务处理层20可在服务接口对应的可查询数据项中，查找与接收到的数据查询请求中包含的需求数据项对应的目标可查询数据项，之后，可根据该服务接口对应的可查询数据项与数据模型中字段之间的路由信息，查找与目标可查询数据项关联的目标数据模型及目标字段，从而找到该数据查询请求所需的需求数据项的供数位置。
47.其中，本实施例中，一个可查询数据项关联的数据模型可以是一个或多个，一个需求数据项关联的数据模型中的字段也可以是一个或多个。另外，可查询数据项的含义可与数据模型中的字段含义一致。当然，可查询数据项的含义也可以是基于多个字段含义进行逻辑整合后产生的新的含义。本实施例对此不做限定。
48.在确定出需求数据项管理的目标字段后，服务处理层20可基于目标字段下的字段值，确定需求数据项对应查询结果。实际应用中，若数据查询请求中的需求数据项为多个，则可对多个需求数据项进行sql拼接，服务处理层20可对目标字段下的字段值进行封装，并作为查询结果返回给数据查询请求的发起方。
49.另外，服务处理层20还可在接口层10接收到的数据查询请求中的需求数据项的数值满足预设条件，则向数据查询请求的发起方推送提醒消息，以提醒发起方处理政务服务事项。例如，若需求数据项为一个月内港澳通行证是否到期，若查询结果为是，则可在市民登录指定应用程序时，判断市民是否购买近期去港澳的机票时，若是，则可通过短信、电话、app等推送方式提醒市民办理港澳通行证续签事项。
50.据此，本实施例中，可提供通用的服务接口，服务接口对应的可查询数据项可涵盖多类数据查询请求所需的需求数据项且是可维护的，而服务接口的背后可提供可查询数据项与数据模型中字段之间的路由信息，从而可快速准确地确定出与需求数据项关联的目标数据模型中的目标字段，进而可基于所述目标字段下的字段值，确定所述需求数据项对应的查询结果。据此，本技术实施例中，多个政务服务事项可调用统一的服务接口，无需再为每个政务服务事项单独开发服务接口，这可节省大量的数据开发工作；而且，在统一的服务
接口下可进行自动路由，从而可为多个政务服务事项各自所需的需求数据项准确供数，保证数据查询结果的准确性。
51.在上述或下述实施例中，服务处理层20可对接口层10中的服务接口进行扩展。以下将以目标服务接口为例，对扩展方案进行详细说明。应当理解的是，目标服务接口可以是接口层10中至少一个服务接口中的任意一个。另外，后续实施例中也将沿用目标服务接口，从单个服务接口的维度进行其它技术细节的阐述。
52.本实施例中，服务处理层20可在目标服务接口需要用于接收新一类数据查询请求的情况下，将新一类数据查询请求中包含的未配置在目标服务接口对应的可查询数据项中的需求数据项，添加为目标服务接口对应的可查询数据项。
53.例如，在政务办事场景中，若出现新的政务服务事项，则可从已有的服务接口中选择一个目标服务接口，并对该目标服务接口进行扩展，以满足该新的政务服务事项的数据服务需求。其中，可根据新的政务服务事项所需的需求数据项来选择目标服务接口，比如，可将覆盖新的政务服务事项所需的需求数据项最多的服务接口作为目标服务接口等。应当理解的是，政务服务事项所需的需求数据项通常是由官方规定的，实际应用中，发起方可按官方规定在数据查询请求中配置需求数据项的标识信息即可。
54.正如前文提及的，本实施例中，服务接口对应的可查询数据项是可扩展的，因此，当有新一类数据查询请求需要接入目标服务接口时，只需对目标服务接口的数据服务范围进行扩展，也即，为目标服务接口新增可查询数据项即可满足新一类数据查询请求的数据服务需求。这可有效减少数据开发工作，使得服务接口的配置工作更加便捷。
55.相应地，数据模型层30，可为添加的可查询数据项配置其与数据模型中字段之间的路由信息，以支持后续对添加的可查询数据项的路由过程。
56.除了上述目标服务接口需要用于接收新一类数据查询请求的情况下，可对目标服务接口的可查询数据项进行扩展外，还可在目标服务接口关联的数据模型增加的情况下，对目标服务接口的可查询数据项进行扩展。在目标服务接口关联的目标数据模型增加的情况下，可基于增加的数据模型的字段，确定可新增至目标服务接口的可查询数据项，进而实现目标服务接口的扩展。
57.本实施例中，服务处理层20可对目标服务接口对应的可查询数据项及可查询数据项与数据模型中字段之间的路由信息，封装为数据服务；并将数据服务发布至接口层10，以供接口层10对外呈现目标服务接口。接口层10中可配置数据资源目录，并在数据资源目录中呈现至少一个服务接口的元数据信息，例如，接口名称、接口地址、接口对应的数据服务的描述信息等。
58.对于前述的目标服务接口扩展的情况，服务处理层20可对相关内容进行重新封装，以更新目标服务接口。
59.据此，本实施例中，在服务接口需要用于接收新一类数据查询请求的情况下，只需对服务接口的可查询数据项进行增加以及路由信息的更新，即可实现对服务接口的扩展，而且，对服务接口关联的数据模型进行增加的情况下，也可方便地对服务接口进行动态扩展。这可有效提高服务接口的配置便捷性，减少数据开发量。
60.在上述或下述实施例中，数据模型层30和服务处理层20可相互配合，实现对服务接口的配置处理。
61.参考图3，数据模型层30和服务处理层20可配合进行目标服务接口对应的可查询数据项的配置过程。在该过程中，数据模型层30可将目标服务接口关联的至少一个目标数据模型转化为实体标签模型，实体标签模型中可包含实体、实体属性标签以及实体属性标签与至少一个目标数据模型中字段之间的关联信息；服务处理层20可从实体标签模型包含的实体属性标签中，确定至少一个目标实体属性标签，作为目标服务接口对应的可查询数据项。
62.例如，民政局对应的数据模型和公安局对应的数据模型中都包含婚姻状态字段，则可将该字段转化为婚姻状态标签，并可指定婚姻状态标签与民政局对应的数据模型中的婚姻状态字段关联。也即是，婚姻状态标签的查询结果以民政局对应的数据模型中的婚姻状态字段下的字段值为准。这可实现对数据模型的数据汇聚，从而保证本实施例中数据系统的供数标准化。
63.本实施例中，数据模型层30可对数据模型的字段进行整合，将数据模型转化为实体标签模型。在一种示例性方案中，一个服务接口可关联一个实体标签模型，实体标签模型中，可包含若干个实体，每个实体可具有实体标签模型中的实体属性标签。其中，实体可以是自然人或企事业单位等，当然，在不同的应用场景中，实体还可承载其它事物，本实施例并不限于此。
64.这样，在目标服务接口下，数据模型层30中产生的实体标签模型中可包含若干实体属性标签。服务处理层20可从目标服务接口对应的若干实体属性标签中，选择至少一个实体属性标签，作为目标服务接口的可查询数据项。其中，服务处理层20可将从目标服务接口对应的若干实体属性标签中的部分或全部实体属性标签，确定为目标服务接口的可查询数据项。
65.参考图1，服务处理层20还可从实体标签模型中包含的实体中，指定目标服务接口关联的实体。例如，数据模型层30中产生的实体标签模型中可能包含10万个自然人，服务处理层20可根据实际需要指定10万个自然人中的部分或全部，关联至目标服务接口。
66.正如前文提及的，服务接口对应的可查询数据项可作为服务接口对应的数据服务范围。据此，在一些示例性方案中，服务处理层20可根据目标服务接口需要接收的至少一类数据查询请求所需的所有需求数据项，确定目标服务接口对应的可查询数据项。例如，可查询数据项可覆盖与目标服务接口所需服务的所有需求数据项。当然，实际应用中，也可根据实际需要灵活确定目标服务接口对应的可查询数据项，本实施例在此不做限定。
67.在确定出可查询数据项的基础上，数据模型层30和服务处理层20可配合进行目标服务接口对应的可路由信息的配置过程。在该过程中，数据模型层30可根据至少一个目标实体标签与至少一个目标数据模型中字段之间的关联信息，生成目标服务接口对应的可查询数据项与数据模型中字段之间的路由信息。一种示例性的路由信息中可包含可查询数据项到数据模型，再到实体，再到字段的路径。
68.为了支持服务处理层20对数据查询请求进行自动路由，本实施例中，服务处理层20还可在目标服务接口对应的可查询数据项中，确定作为入参的第一类数据项和作为返回参数的第二类数据项。其中，第一类数据项可以是能够唯一标识实体的数据项。例如，实体为自然人时，可将身份证号等可查询数据项作为第一类数据项。当然，本实施例并不限于此。
69.参考图4，这样，数据查询请求中可包含实体的已知数据项的取值和目标需求数据项的标识信息。一种示例性的路由过程可以是：
70.根据目标服务接口对应的路由信息，确定与目标需求数据项关联的目标数据模型及目标字段；
71.根据实体的已知数据项的取值，确定待查询的目标实体；
72.查询目标实体在目标字段下的字段值，以确定目标需求数据项对应的查询结果。
73.例如，数据查询请求可以是，查找“身份证号＝100xxxxxxxxxxxx”的“自然人”的“婚姻状态”，其中，自然人为实体，身份证号为已知数据项的取值，婚姻状态为需求数据项的标识信息。这样，服务处理层20可根据身份证号关联的数据模型及字段，如公安局提供的一数据模型中的身份证号字段，确定待查询的目标实体，如实体a；服务处理层20还可根据婚姻状态关联的数据模型及字段，如民政局提供的一数据模型中的婚姻状态字段，查询张三在该婚姻状态字段下的字段值，如已婚，作为数据查询请求中婚姻状态对应的查询结果。也即是，该数据查询请求的查询结果为已婚。
74.当然，以上的可查询数据项和路由信息的配置方案以及对数据查询请求进行路由的方案均是示例性的，本实施例并不限于此，例如，在可查询数据项的配置过程中，服务处理层20也可根据实际需要预先确定目标服务接口对应的可查询数据项，在此基础上，再根据可查询数据项确定目标服务接口关联的数据模型，进而生成实体标签模型，等。
75.另外，基于实体标签模型这种方式，在进行前述实施例中的服务接口扩展处理过程中：数据模型层30可在目标服务接口关联的目标数据模型增加的情况下，将目标服务接口关联的原始数据模型和新增数据模型转化为实体标签模型；服务处理层20，可在实体标签模型中出现新增的实体属性标签的情况下，将新增的实体属性标签添加为目标服务接口对应的可查询数据项。
76.例如，服务接口b的原来的可查询数据项为“社保缴纳年限”和“学历”，若当前将民政局的数据模型新接入服务接口b，则服务接口b对应的实体标签模型中将新增“婚姻状态”这一实体属性标签，据此，可将“婚姻状态”添加为服务接口b的可查询数据项。
77.当然，本实施例中，可查询数据项的配置形式并不限于实体属性标签这一种，还可采用其它形式承载数据模型中字段的整合结果，本实施例并不限于此。
78.以下将以政务办事场景为例，对本技术的技术方案进行说明。
79.出生证申办事项和公积金审批事项中所需用到的市民信息存在重叠，例如，这两类事项都需要用到市民的姓名、学历、身份证号及婚姻状态，但公积金审批事项还需要市民缴纳社保年限信息。
80.为此，本实施例的数据系统中，可为这两类事项配置通用的服务接口a，该服务接口a对应的可查询数据项至少可包括姓名、学历、身份证号、婚姻状态及缴纳社保年限。
81.当市民通过政务办事应用程序进行出生证申办事项时，市民可在应用程序中输入身份证号即可提交申办请求，在该申办请求到达计划生育部门之前，可作为数据查询请求从本实施例提供的数据系统中查询所需的需求数据项。当然，在此之前，政府办事应用程序中已经将出生证申办事项关联至服务接口a。此时，数据查询请求中可以是从服务接口a，查询，身份证号＝100xxxxxxxxxxxx，自然人，的姓名、学历及婚姻状态。
82.对此，本实施例提供的数据系统可对数据查询请求进行自动路由，从服务接口a的
可根据身份证号确定出自然人b(实体)，并在可查询数据项中找到姓名、学历及婚姻状态，分别确定出这几个可查询数据项各自关联的数据模型及字段，以读取到自然人b的姓名、学历及婚姻状态对应的查询结果。
83.在此基础上，数据系统可自动将读取到的需求数据项对应的查询结果填写到申办请求中，并提供给计划生育部门，这样，市民只需简单地填写身份证号，而其它信息可实现自动填入，从而可减少材料填写时间。
84.公积金审批部门也可基于指定的应用程序进行公积金审批事项的处理，同样，公积金审批部门可根据本实施例提供的数据系统公布的服务接口的元数据信息，申请接入服务接口a，并针对社保部门发起数据调用权限申请，在社保部门同意的情况下，公积金审批事项可获得调用社保部门提供的数据模型的权限。
85.在此基础上，公积金审批部门发起的数据查询请求中可包括服务接口a的地址、待审批人的身份证号及姓名、所需的需求数据项包括学历、婚姻状态及缴纳社保年限信息。本实施例提供的数据系统可该数据查询请求进行自动路由，将数据查询请求调配至服务接口a；从服务接口a的可查询数据项中找出身份证号及姓名，并确定出自然人c(实体)；从服务接口a的可查询数据项中找出学历、婚姻状态及缴纳社保年限信息，并分别将这几个可查询数据项关联的目标数据模型和目标字段，例如，缴纳社保年限关联至社保部门提供的数据模型中的社保年限字段，由于公积金审批部门已经预先获得了社保部门的数据查询权限，因此，可顺利读取到自然人c的缴纳社保年限，而其它需求数据项也可得到准确供数。
86.从而，本实施例提供的数据系统，可为公积金审批事项提供数据服务。从市民角度，可减少已有材料的提交，例如，市民无需再自己去社保部门申请社保缴纳年限证明等材料。
87.而且，服务接口a的可查询数据项是可扩展的，因此，当有新的事项申请接入服务接口a时，可方便地为新的事项添加可查询数据项，以满足新的事项的数据服务需求，这可减少大量的数据开发工作，使得服务接口的复用率大大提高。
88.图5为本技术另一示例性实施例提供的一种数据查询系统的结构示意图。参考图5，该数据查询系统可包括：业务子系统50、数据子系统51和云计算系统52。
89.其中，数据子系统51可对应图1所示实施例中的数据系统。
90.本实施例中，业务子系统50可向数据子系统51发起多类数据查询请求，向数据子系统中同一服务接口发送的不同类数据查询请求包含的需求数据项不完全相同。业务子系统50可实现为业务中台产品，当然，本实施例并不限于此。
91.以政务办事场景为例，业务子系统50可通过数据子系统51查询可共享的数据信息，以进行政务服务事项的办理或审批。其中，可共享的数据信息可以是指数据子系统可提供的可查询数据项。
92.本实施例中，云计算系统52可用于将数据源接入数据子系统中的数据模型。云计算系统主要提供数据计算和存储等服务，例如，云计算系统52可提供数据库服务rds、大数据计算服务maxcompute等。基于此，数据子系统51可向云计算子系统52下发数据计算、查询任务，并接收云计算系统52返回的数据进行标准化的数据建模，以获得数据子系统51中的数据模型。
93.关于数据子系统51的相关技术内容可参考前述实施例中的描述，为节省篇幅，在
此不再赘述。但这不应造成对本技术保护范围的损失。
94.图6为本技术又一示例性实施例提供的一种数据查询方法的流程示意图。如图6所示，该方法包括：
95.步骤600、通过目标服务接口接收数据查询请求，数据查询请求中包含需求数据项的标识信息，目标服务接口用于接收至少一类数据查询请求，不同类数据查询请求包含的需求数据项不完全相同；
96.步骤601、基于预设的可查询数据项与数据模型中字段之间的路由信息，确定数据查询请求中包含的需求数据项关联的目标数据模型中的目标字段；
97.步骤602、基于目标字段下的字段值，确定需求数据项对应的查询结果。
98.在一可选实施例中，该方法还包括：
99.在目标服务接口需要用于接收新一类数据查询请求的情况下，将新一类数据查询请求中包含的未配置在目标服务接口对应的可查询数据项中的需求数据项，添加为目标服务接口对应的可查询数据项；
100.为添加的可查询数据项配置其与数据模型中字段之间的路由信息；
101.其中，目标服务接口为至少一个服务接口中的任意一个。
102.在一可选实施例中，该方法还包括：
103.将目标服务接口关联的至少一个目标数据模型转化为实体标签模型，实体标签模型中包含实体属性标签以及实体属性标签与至少一个目标数据模型中字段之间的关联信息；
104.从实体标签模型包含的实体属性标签中，确定至少一个目标实体属性标签，作为目标服务接口对应的可查询数据项；
105.其中，目标服务接口为至少一个服务接口中的任意一个。
106.在一可选实施例中，该方法还包括：
107.在目标服务接口对应的可查询数据项中，确定作为入参的第一类数据项和作为返回参数的第二类数据项。
108.在一可选实施例中，目标服务接口接收到的数据查询请求中包含实体的已知数据项的取值和目标需求数据项的标识信息，步骤基于目标服务接口下的可查询数据项与数据模型中字段之间的路由信息，确定数据查询请求中包含的需求数据项关联的目标数据模型中的目标字段，包括：
109.根据目标服务接口对应的路由信息，确定与目标需求数据项关联的目标数据模型及目标字段；
110.根据实体的已知数据项的取值，确定待查询的目标实体；
111.查询目标实体在目标字段下的字段值，以确定目标需求数据项对应的查询结果。
112.在一可选实施例中，该方法还包括：
113.在目标服务接口关联的目标数据模型增加的情况下，将目标服务接口关联的原始数据模型和新增数据模型转化为实体标签模型；
114.若实体标签模型中出现新增的实体属性标签，则将新增的实体属性标签添加为目标服务接口对应的可查询数据项。
115.在一可选实施例中，该方法还包括：
116.根据至少一个目标实体标签与至少一个目标数据模型中字段之间的关联信息，生成目标服务接口对应的可查询数据项与数据模型中字段之间的路由信息；
117.其中，单个目标实体标签关联的字段为一个或多个。
118.在一可选实施例中，该方法还包括：
119.将目标服务接口对应的可查询数据项以及可查询数据项与数据模型中字段之间的路由信息，封装为数据服务；
120.将数据服务发布至接口层，以产生目标服务接口。
121.在一可选实施例中，不同类数据查询请求对应不同的政务服务事项；数据模型。
122.在一可选实施例中，该方法还包括：
123.若接口层接收到的数据查询请求中的需求数据项的数值满足预设条件，则向数据查询请求的发起方推送提醒消息，以提醒发起方处理政务服务事项。
124.值得说明的是，上述关于数据查询方法的各实施例中的技术细节，可参考前述数据系统相关实施例中的描述，为节省篇幅，在此不再赘述，但这不应造成本技术保护范围的损失。
125.相应地，本技术实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述方法实施例中的各步骤。
126.需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤601至步骤602的执行主体可以为设备a；又比如，步骤601和602的执行主体可以为设备a，步骤600的执行主体可以为设备b；等等。
127.另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如601、602等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。
128.本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
129.本技术是参照根据本技术实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
130.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
131.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
132.在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
133.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
134.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
135.还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
136.以上所述仅为本技术的实施例而已，并不用于限制本技术。对于本领域技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。