CN113901046A - 虚拟维度表构建方法及装置 - Google Patents

Abstract

本公开提供一种虚拟维度表构建方法及装置，方法包括从目标业务场景中抽取拟分析的目标对象，并获取目标对象的维度信息；基于目标对象的维度信息，确定目标对象所在的业务场景；根据目标对象的维度信息、以及目标对象所在的业务场景，确定目标对象在每个业务场景的所有属性信息；通过目标对象在每个业务场景的所有属性信息，分别构建一级维度表，以及二级维度表。本公开的方法能够从业务角度出发，在维度模型分类思路中引入数据域划分，定义了多个关联的虚拟维度组，既能保证维度一致性，也能保证单张维度表过宽造成的数据更新慢的问题，完美解决了现有理论和工程层面的技术矛盾。

Description

虚拟维度表构建方法及装置

技术领域

本公开涉及数据库技术领域，尤其涉及一种虚拟维度表构建方法及装置。

背景技术

数据仓库整合了企业相关的所有数据，其中的数据模型更是企业各类分析场景和决策支持的重要支持。

在kimball维度建模理论中，维度设计要满足一致性原则，简单讲就是相同含义的列以及相同的领域内容都是全局一致的，比如借款金额这个字段，数仓全局所有表只要存在这个列，字段名都为prc_amt，且字段类型、取值全都一致，这个即为一致性维度。那么在工程角度，怎么设计才是一张好的一致性维度表呢？

同一个对象必须对应一张全局唯一的维度表，这张维度表在整个数据仓库是可以共用的，这样避免了多个表存在相同维度字段，减少了数据不一致的风险；同时对于数仓元数据管理也是足够精简明确的，对使用者友好。

但是这样做也有两点弊端：

1、因为同一对象只存在一张维度表，维度表字段会普遍比较多，即很多维度表都是宽表，这样该表的更新会变的非常慢，依赖于此维度表的下游数据，必须等此维度表的所有字段更新完毕后才能启动(可能某个下游任务只依赖其中以两个字段，但是必须得等所有字段更新完成)；

2、如果某一字段出错，将会导致整张维度表不能正常产出，下游所有任务都将受到影响。

因此，如何提出一种解决上述问题的技术方案是本领域技术人员目前需要解决的技术问题。

公开于本申请背景技术部分的信息仅仅旨在加深对本申请的一般背景技术的理解，而不应当被视为承认或以任何形式暗示该信息构成已为本领域技术人员所公知的现有技术。

发明内容

本公开实施例提供一种，能够从业务角度出发，在数据域划分思路中引入维度模型分类，定义了多个关联的虚拟维度组，完美解决了现有技术的矛盾。

本公开实施例的第一方面，提供一种虚拟维度表构建方法,所述虚拟维度表构建方法包括：

从目标业务场景中抽取拟分析的目标对象，并获取所述目标对象的维度信息；

基于所述目标对象的维度信息，确定所述目标对象所在的业务场景；

根据所述目标对象的维度信息、以及所述目标对象所在的业务场景，确定所述目标对象在每个业务场景的所有属性信息；

通过所述目标对象在每个业务场景的所有属性信息，分别构建一级维度表，以及二级维度表，

其中，所述一级维度表为主表，包括主表的主键和所述二级维度表的外键；所述二级维度表为副表，包括每个业务场景对应的维度表。

在一种可选的实施方式中，

所述确定所述目标对象在每个业务场景的所有属性信息的方法包括：

获取所述目标对象所在的业务场景，基于预先设定的业务场景与用户属性信息的对应关系，枚举所述目标对象所在的业务场景中，所有的属性信息和度量信息；

其中，所述业务场景与所述用户属性信息是一一对应的，不同业务场景下，所述目标对象的属性信息和度量信息不同。

在一种可选的实施方式中，

所述通过所述目标对象在每个业务场景的所有属性信息，分别构建一级维度表，以及二级维度表的方法包括：

通过所述目标对象在每个业务场景的所有属性信息，确定所述目标对象对应的主表，所述主表包括多个字段，所述多个字段至少包括主表的主键、以及所述业务场景对应的外键，所述主表所包括的多个字段构成所述一级维度表；

通过所述目标对象所在的每个业务场景，分别构建所述每个业务场景对应的用户维度表，并将所述用户维度表关联到主表的外键字段，所述用户维度表，以及所述用户维度表关联到主表的外键字段构建所述二级维度表。

在一种可选的实施方式中，

所述方法还包括更新所述一级维度表和二级维度表，

所述更新所述一级维度表和所述二级维度表的方法包括：

基于预先构建的数据仓库中所有的历史数据，以及所述一级维度表和所述二级维度表中最近一个维度处理时间周期的数据，

获取所述一级维度表和所述二级维度表中待更新数据；

基于所述一级维度表和所述二级维度表中最近一个维度处理时间周期的数据，将其添加至所述一级维度表和所述二级维度表中，以完成更新所述一级维度表和所述二级维度表。

在一种可选的实施方式中，

所述业务场景包括注册、申请、审核、借款以及催收业务场景中的至少一个；

主表的主键包括user_id，业务场景对应的外键包括register_user_id、apply_user_id、audit_user_id、trade_user_id、collection_user_id。

本公开实施例的第二方面，提供一种虚拟维度表构建装置，所述虚拟维度表构建装置包括：

第一单元，所述第一单元用于从目标业务场景中抽取拟分析的目标对象，并获取所述目标对象的维度信息；

第二单元，所述第二单元用于基于所述目标对象的维度信息，确定所述目标对象所在的业务场景；

第三单元，所述第三单元用于根据所述目标对象的维度信息、以及所述目标对象所在的业务场景，确定所述目标对象在每个业务场景的所有属性信息；

第四单元，所述第四单元用于通过所述目标对象在每个业务场景的所有属性信息，分别构建一级维度表，以及二级维度表，

其中，所述一级维度表为主表，包括主表的主键和所述二级维度表的外键；所述二级维度表为副表，包括每个业务场景对应的维度表。

在一种可选的实施方式中，

所述第三单元还用于：

获取所述目标对象所在的业务场景，基于预先设定的业务场景与用户属性信息的对应关系，枚举所述目标对象所在的业务场景中，所有的属性信息和度量信息；

其中，所述业务场景与所述用户属性信息是一一对应的，不同业务场景下，所述目标对象的属性信息和度量信息不同。

在一种可选的实施方式中，

所述第四单元还用于：

通过所述目标对象在每个业务场景的所有属性信息，确定所述目标对象对应的主表，所述主表包括多个字段，所述多个字段至少包括主表的主键、以及所述业务场景对应的外键，所述主表所包括的多个字段构成所述一级维度表；

通过所述目标对象所在的每个业务场景，分别构建所述每个业务场景对应的用户维度表，并将所述用户维度表关联到主表的外键字段，所述用户维度表，以及所述用户维度表关联到主表的外键字段构建所述二级维度表。

在一种可选的实施方式中，

所述装置还包括第五单元，所述第五单元用于更新所述一级维度表和所述二级维度表：

基于预先构建的数据仓库中所有的历史数据，以及所述一级维度表和所述二级维度表中最近一个维度处理时间周期的数据，

获取所述一级维度表和所述二级维度表中待更新数据；

基于所述一级维度表和所述二级维度表中最近一个维度处理时间周期的数据，将其添加至所述一级维度表和所述二级维度表中，以完成更新所述一级维度表和所述二级维度表。

在一种可选的实施方式中，

所述业务场景包括注册、申请、审核、借款以及催收业务场景中的至少一个；

主表的主键包括user_id，业务场景对应的外键包括register_user_id、apply_user_id、audit_user_id、trade_user_id、collection_user_id。

本公开实施例提供一种虚拟维度表构建方法,所述虚拟维度表构建方法包括：

从目标业务场景中抽取拟分析的目标对象，并获取所述目标对象的维度信息；

基于所述目标对象的维度信息，确定所述目标对象所在的业务场景；

根据所述目标对象的维度信息、以及所述目标对象所在的业务场景，确定所述目标对象在每个业务场景的所有属性信息；

通过所述目标对象在每个业务场景的所有属性信息，分别构建一级维度表，以及二级维度表，

其中，所述一级维度表为主表，包括主表的主键和二级维度表的外键；所述二级维度表为副表，包括每个业务场景对应的维度表。

本公开实施例的虚拟维度表构建方法能够实现如下有益效果：

1、最大限度的做到了维度一致性原则，保证同一粒度的维度只有一张表；

2、统一进行元数据管理，一个业务领域的同一维度只有一张表，用户在使用的时候能够很容易的查询到，不存在跨表的数据不一致性问题；

3、虚拟组的维度表各自更新，不会产生大宽表，保证下游业务更新的及时性；如果发生某个业务领域的维度表发生异常，其他领域的维度表字段不受影响；4、实施简单明确，如果需要跨虚拟组维度，可以很快的整合。

附图说明

图1为本公开实施例虚拟维度表构建方法的流程示意图；

图2为本公开实施例虚拟维度表构建装置的结构示意图。

具体实施方式

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

本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。

应当理解，在本公开的各种实施例中，各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本公开实施例的实施过程构成任何限定。

应当理解，在本公开中，“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

应当理解，在本公开中，“多个”是指两个或两个以上。“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。“包含A、B和C”、“包含A、B、C”是指A、B、C三者都包含，“包含A、B或C”是指包含A、B、C三者之一，“包含A、B和/或C”是指包含A、B、C三者中任1个或任2个或3个。

应当理解，在本公开中，“与A对应的B”、“与A相对应的B”、“A与B

相对应”或者“B与A相对应”，表示B与A相关联，根据A可以确定B。根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其他信息确定B。A与B的匹配，是A与B的相似度大于或等于预设的阈值。

取决于语境，如在此所使用的“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。

下面以具体地实施例对本公开的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

图1示例性地示出本公开实施例虚拟维度表构建方法的流程示意图，如图1所示，所述方法包括：

步骤S101、从目标业务场景中抽取拟分析的目标对象，并获取所述目标对象的维度信息；

示例性地，在业务场景里抽象出要分析的对象，即实体。该实体被定义为维度。例如：在金融信贷行业，用户就是个非常重要的对象，这个对象有多个属性，所以我们可以抽象出用户维度信息。

步骤S102、基于所述目标对象的维度信息，确定所述目标对象所在的业务场景；

梳理该维度所在的业务场景，做好场景划分：梳理出该对象(实体)所贯穿的业务场景，例如：在金融信贷行业，用户作为一个对象，涉及到的场景分别是注册、申请、审核、借款、催收这五个场景。

在一种可选的实施方式中，

所述业务场景包括注册、申请、审核、借款以及催收业务场景中的至少一个；

需要说明的是，本公开实施例中业务场景只是示例性地说明，本公开实施例对业务场景的类型和数量并不进行限定。

步骤S103、根据所述目标对象的维度信息、以及所述目标对象所在的业务场景，确定所述目标对象在每个业务场景的所有属性信息；

示例性地，按每个场景枚举所有属性：每个场景中，枚举出这个对象的所有属性和度量字段。例如：用户在注册场景下，会产生手机号、注册验证码、性别等信息；

而在申请场景下会产生身份证信息、年龄、职业等信息；在借款场景下会产生借款笔数、借款总金额、分期数、利率等信息。

按照这种形式，枚举每个业务场景下的所有属性信息和度量信息。

步骤S104、通过所述目标对象在每个业务场景的所有属性信息，分别构建一级维度表，以及二级维度表，

其中，所述一级维度表为主表，包括主表的主键和二级维度表的外键；所述二级维度表为副表，包括每个业务场景对应的维度表。

主要有两步，第一步是按照上述梳理，设计一张主维度表结构，这个表结构里有主表的主键，其他字段为不同场景下的主键id，数据其实都是一样的，只是按不同场景定义不同的字段名。

第二步是构建每个场景对应的维度表，定义没张表的主键字段，命名仍旧为主维度表的主键id。

例如：第一步定义用户维度主表为user表，共有6个字段，第一个字段为主表的主键user_id，其余5个字段分别按5个场景分为register_user_id、apply_user_id、audit_user_id、trade_user_id、collection_user_id，其中同一个用户这6个字段的值都是相同的；这5个字段将分别作为其他五张分场景的用户表的外键。

第二步是分别构建5个场景的5张用户维度表，注册场景用户维度表register_user，主键为user_id，关联到主表的外键字段register_user_id，以此类推。

在一种可选的实施方式中，

所述确定所述目标对象在每个业务场景的所有属性信息的方法包括：

获取所述目标对象所在的业务场景，基于预先设定的业务场景与用户属性信息的对应关系，枚举所述目标对象所在的业务场景中，所有的属性信息和度量信息；

其中，所述业务场景与所述用户属性信息是一一对应的，不同业务场景下，所述目标对象的属性信息和度量信息不同。

在一种可选的实施方式中，

所述通过所述目标对象在每个业务场景的所有属性信息，分别构建一级维度表，以及二级维度表的方法包括：

通过所述目标对象在每个业务场景的所有属性信息，确定所述目标对象对应的主表，所述主表包括多个字段，所述多个字段至少包括主表的主键、以及所述业务场景对应的外键，所述主表所包括的多个字段构成所述一级维度表；

通过所述目标对象所在的每个业务场景，分别构建所述每个业务场景对应的用户维度表，并将所述用户维度表关联到主表的外键字段，所述用户维度表，以及所述用户维度表关联到主表的外键字段构建所述二级维度表。

在一种可选的实施方式中，

所述方法还包括更新所述一级维度表和二级维度表，

所述更新所述一级维度表和所述二级维度表的方法包括：

基于预先构建的数据仓库中所有的历史数据，以及所述一级维度表和所述二级维度表中最近一个维度处理时间周期的数据，

获取所述一级维度表和所述二级维度表中待更新数据；

基于所述一级维度表和所述二级维度表中最近一个维度处理时间周期的数据，将其添加至所述一级维度表和所述二级维度表中，以完成更新所述一级维度表和所述二级维度表。

在一种可选的实施方式中，

所述业务场景包括注册、申请、审核、借款以及催收业务场景中的至少一个；

主表的主键包括user_id，业务场景对应的外键包括register_user_id、apply_user_id、audit_user_id、trade_user_id、collection_user_id。

本公开实施例提供一种虚拟维度表构建方法,所述虚拟维度表构建方法包括：

从目标业务场景中抽取拟分析的目标对象，并获取所述目标对象的维度信息；

基于所述目标对象的维度信息，确定所述目标对象所在的业务场景；

根据所述目标对象的维度信息、以及所述目标对象所在的业务场景，确定所述目标对象在每个业务场景的所有属性信息；

通过所述目标对象在每个业务场景的所有属性信息，分别构建一级维度表，以及二级维度表，

其中，所述一级维度表为主表，包括主表的主键和二级维度表的外键；所述二级维度表为副表，包括每个业务场景对应的维度表。

本公开实施例的虚拟维度表构建方法能够实现如下有益效果：

1、最大限度的做到了维度一致性原则，保证同一粒度的维度只有一张表；

2、统一进行元数据管理，一个业务领域的同一维度只有一张表，用户在使用的时候能够很容易的查询到，不存在跨表的数据不一致性问题；

3、虚拟组的维度表各自更新，不会产生大宽表，保证下游业务更新的及时性；如果发生某个业务领域的维度表发生异常，其他领域的维度表字段不受影响；

4、实施简单明确，如果需要跨虚拟组维度，可以很快的整合。

图2示例性地示出本公开实施例虚拟维度表构建装置的结构示意图，如图2所示，所述装置包括：

第一单元21，所述第一单元21用于从目标业务场景中抽取拟分析的目标对象，并获取所述目标对象的维度信息；

第二单元22，所述第二单元22用于基于所述目标对象的维度信息，确定所述目标对象所在的业务场景；

第三单元23，所述第三单元23用于根据所述目标对象的维度信息、以及所述目标对象所在的业务场景，确定所述目标对象在每个业务场景的所有属性信息；

第四单元24，所述第四单元24用于通过所述目标对象在每个业务场景的所有属性信息，分别构建一级维度表，以及二级维度表，

其中，所述一级维度表为主表，包括主表的主键和二级维度表的外键；所述二级维度表为副表，包括每个业务场景对应的维度表。

在一种可选的实施方式中，

所述第三单元23还用于：

获取所述目标对象所在的业务场景，基于预先设定的业务场景与用户属性信息的对应关系，枚举所述目标对象所在的业务场景中，所有的属性信息和度量信息；

其中，所述业务场景与所述用户属性信息是一一对应的，不同业务场景下，所述目标对象的属性信息和度量信息不同。

在一种可选的实施方式中，

所述第四单元24还用于：

通过所述目标对象在每个业务场景的所有属性信息，确定所述目标对象对应的主表，所述主表包括多个字段，所述多个字段至少包括主表的主键、以及所述业务场景对应的外键，所述主表所包括的多个字段构成所述一级维度表；

通过所述目标对象所在的每个业务场景，分别构建所述每个业务场景对应的用户维度表，并将所述用户维度表关联到主表的外键字段，所述用户维度表，以及所述用户维度表关联到主表的外键字段构建所述二级维度表。

在一种可选的实施方式中，

所述装置还包括第五单元，所述第五单元用于更新所述一级维度表和所述二级维度表：

基于预先构建的数据仓库中所有的历史数据，以及所述一级维度表和所述二级维度表中最近一个维度处理时间周期的数据，

获取所述一级维度表和所述二级维度表中待更新数据；

基于所述一级维度表和所述二级维度表中最近一个维度处理时间周期的数据，将其添加至所述一级维度表和所述二级维度表中，以完成更新所述一级维度表和所述二级维度表。

在一种可选的实施方式中，

所述业务场景包括注册、申请、审核、借款以及催收业务场景中的至少一个；

主表的主键包括user_id，业务场景对应的外键包括register_user_id、apply_user_id、audit_user_id、trade_user_id、collection_user_id。

需要说明的是，本公开装置实施例的有益效果可以参考上述方法实施例的有益效果，本公开在此不再赘述。

本公开还提供一种程序产品，该程序产品包括执行指令，该执行指令存储在可读存储介质中。设备的至少一个处理器可以从可读存储介质读取该执行指令，至少一个处理器执行该执行指令使得设备实施上述的各种实施方式提供的方法。

其中，可读存储介质可以是计算机存储介质，也可以是通信介质。通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。计算机存储介质可以是通用或专用计算机能够存取的任何可用介质。例如，可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(ApplicationSpecific Integrated Circuits，简称：ASIC)中。另外，该ASIC可以位于用户设备中。当然，处理器和可读存储介质也可以作为分立组件存在于通信设备中。可读存储介质可以是只读存储器(ROM)、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在上述终端或者服务器的实施例中，应理解，处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application SpecificIntegrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本公开所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

最后应说明的是：以上各实施例仅用以说明本公开的技术方案，而非对其限制；尽管参照前述各实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本公开各实施例技术方案的范围。

Claims (10)

1.一种虚拟维度表构建方法，其特征在于，所述虚拟维度表构建方法包括：

从目标业务场景中抽取拟分析的目标对象，并获取所述目标对象的维度信息；

基于所述目标对象的维度信息，确定所述目标对象所在的业务场景；

根据所述目标对象的维度信息、以及所述目标对象所在的业务场景，确定所述目标对象在每个业务场景的所有属性信息；

通过所述目标对象在每个业务场景的所有属性信息，分别构建一级维度表，以及二级维度表，

其中，所述一级维度表为主表，包括主表的主键和所述二级维度表的外键；所述二级维度表为副表，包括每个业务场景对应的维度表。

2.根据权利要求1所述的方法，其特征在于，所述确定所述目标对象在每个业务场景的所有属性信息的方法包括：

获取所述目标对象所在的业务场景，基于预先设定的业务场景与用户属性信息的对应关系，枚举所述目标对象所在的业务场景中，所有的属性信息和度量信息；

其中，所述业务场景与所述用户属性信息是一一对应的，不同业务场景下，所述目标对象的属性信息和度量信息不同。

3.根据权利要求1所述的方法，其特征在于，所述通过所述目标对象在每个业务场景的所有属性信息，分别构建一级维度表，以及二级维度表的方法包括：

通过所述目标对象在每个业务场景的所有属性信息，确定所述目标对象对应的主表，所述主表包括多个字段，所述多个字段至少包括主表的主键、以及所述业务场景对应的外键，所述主表所包括的多个字段构成所述一级维度表；

通过所述目标对象所在的每个业务场景，分别构建所述每个业务场景对应的用户维度表，并将所述用户维度表关联到主表的外键字段，所述用户维度表，以及所述用户维度表关联到主表的外键字段构建所述二级维度表。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括更新所述一级维度表和二级维度表，

所述更新所述一级维度表和所述二级维度表的方法包括：

基于预先构建的数据仓库中所有的历史数据，以及所述一级维度表和所述二级维度表中最近一个维度处理时间周期的数据，

获取所述一级维度表和所述二级维度表中待更新数据；

基于所述一级维度表和所述二级维度表中最近一个维度处理时间周期的数据，将其添加至所述一级维度表和所述二级维度表中，以完成更新所述一级维度表和所述二级维度表。

5.根据权利要求1所述的方法，其特征在于，

所述业务场景包括注册、申请、审核、借款以及催收业务场景中的至少一个；

主表的主键包括user_id，业务场景对应的外键包括register_user_id、apply_user_id、audit_user_id、trade_user_id、collection_user_id。

6.一种虚拟维度表构建装置，其特征在于，所述虚拟维度表构建装置包括：

第一单元，所述第一单元用于从目标业务场景中抽取拟分析的目标对象，并获取所述目标对象的维度信息；

第二单元，所述第二单元用于基于所述目标对象的维度信息，确定所述目标对象所在的业务场景；

第三单元，所述第三单元用于根据所述目标对象的维度信息、以及所述目标对象所在的业务场景，确定所述目标对象在每个业务场景的所有属性信息；

第四单元，所述第四单元用于通过所述目标对象在每个业务场景的所有属性信息，分别构建一级维度表，以及二级维度表，

其中，所述一级维度表为主表，包括主表的主键和所述二级维度表的外键；所述二级维度表为副表，包括每个业务场景对应的维度表。

7.根据权利要求6所述的装置，其特征在于，所述第三单元还用于：

获取所述目标对象所在的业务场景，基于预先设定的业务场景与用户属性信息的对应关系，枚举所述目标对象所在的业务场景中，所有的属性信息和度量信息；

其中，所述业务场景与所述用户属性信息是一一对应的，不同业务场景下，所述目标对象的属性信息和度量信息不同。

8.根据权利要求6所述的装置，其特征在于，所述第四单元还用于：

通过所述目标对象在每个业务场景的所有属性信息，确定所述目标对象对应的主表，所述主表包括多个字段，所述多个字段至少包括主表的主键、以及所述业务场景对应的外键，所述主表所包括的多个字段构成所述一级维度表；

通过所述目标对象所在的每个业务场景，分别构建所述每个业务场景对应的用户维度表，并将所述用户维度表关联到主表的外键字段，所述用户维度表，以及所述用户维度表关联到主表的外键字段构建所述二级维度表。

9.根据权利要求6所述的装置，其特征在于，所述装置还包括第五单元，所述第五单元用于更新所述一级维度表和所述二级维度表：

基于预先构建的数据仓库中所有的历史数据，以及所述一级维度表和所述二级维度表中最近一个维度处理时间周期的数据，

获取所述一级维度表和所述二级维度表中待更新数据；

基于所述一级维度表和所述二级维度表中最近一个维度处理时间周期的数据，将其添加至所述一级维度表和所述二级维度表中，以完成更新所述一级维度表和所述二级维度表。

10.根据权利要求6所述的装置，其特征在于，

所述业务场景包括注册、申请、审核、借款以及催收业务场景中的至少一个；

主表的主键包括user_id，业务场景对应的外键包括register_user_id、apply_user_id、audit_user_id、trade_user_id、collection_user_id。

Images