CN110019551B - 一种数据仓库构建方法及装置 - Google Patents

Abstract

本申请提供了一数据仓库构建方法和装置，涉及数据库技术领域。所述方法包括：提供逻辑模型；所述逻辑模型包括至少一个逻辑表的基础信息、针对所述逻辑表的属性、针对所述属性的执行逻辑、针对所述属性的关联维度；所述执行逻辑用于基于所述属性构建表时，从目标表获取所述属性需求的数据；根据所述逻辑模型构建数据仓库。本申请实现维度和执行逻辑结合的逻辑模型定义方式，ETL开发过程中不用关注如何生成物理表、也不用关注如何生成执行逻辑代码，只需要利用该逻辑模型即可构建数据仓库，因此可以节省ETL开发过程，提高效率，可维护性好。

Description

一种数据仓库构建方法及装置

技术领域

本申请涉及数据库技术领域，特别是涉及一种数据仓库构建方法及装置。

背景技术

数据仓库，英文名称为Data Warehouse，其是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它可以出于分析性报告和决策支持目的而创建，为需要进行数据分析的企业，提供指导业务流程改进、监视时间、成本、质量以及控制等。

在先技术中，数据仓库的构建有两大类方式：第一类，先定义逻辑模型，然后基于该逻辑模型生成物理表存储于数据仓库中。第二类，采用自由模式直接生成物理表存储于数据仓库中。对于第一类中，其逻辑模型可以采用 3NF(数据库构建的第三范式，第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息，且需要满足第一范式和第二范式)，还可以采用星型模型，该两种逻辑模型的维度表和事实表都是针对属性和关联维度之间的定义，在逻辑模型定义之后，还需要人工基于该逻辑模型生成相应的物理表。而第二类方式，不用逻辑模型或者很少用逻辑模型，其基于 SQL(StructuredQuery Language，结构化查询语言)其他脚本语言，直接产出物理表。

发明人在应用上述方案的过程中发现，第一类方式中，其逻辑模型和物理模型是分离的两个概念，逻辑模型仅用于指导ETL (Extract-Transform-Load，数据抽取、清洗、转换、装载)开发物理表的构建，还需要人工开发物理表，效率低，可维护性差，而第二类方式中，其由于很少不用或者很少用逻辑模型，直接用脚本语言产出物理表，可维护性差。

发明内容

鉴于上述问题，本申请实施例提供一种数据仓库构建方法，以通过包括少一个逻辑表的基础信息、针对所述逻辑表的属性、针对所述属性的执行逻辑、针对所述属性的关联维度的逻辑模型，构建数据仓库，解决在先技术中效率低、复用性、可维护性差问题。

相应的，本申请实施例还提供了一种数据仓库构建装置，用以保证上述方法的实现及应用。

为了解决上述问题，本申请实施例公开了一种数据仓库构建方法，包括：

提供逻辑模型；所述逻辑模型包括至少一个逻辑表的基础信息、针对所述逻辑表的属性、针对所述属性的执行逻辑、针对所述属性的关联维度；所述执行逻辑用于基于所述属性构建表时，从目标表获取所述属性需求的数据；

根据所述逻辑模型构建数据仓库。

相应的，本申请实施例还公开了一种数据仓库构建装置，包括：

模型提供模块，用于提供逻辑模型；所述逻辑模型包括至少一个逻辑表的基础信息、针对所述逻辑表的属性、针对所述属性的执行逻辑、针对所述属性的关联维度；所述执行逻辑用于基于所述属性构建表时，从目标表获取所述属性需求的数据；

构建模块，用于根据所述逻辑模型构建数据仓库。

相应的，本申请实施例还公开了一种装置，其特征在于，包括：

一个或多个处理器；和

其上存储有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行所述指令时，使得所述装置执行一种数据仓库构建方法。

相应的，本申请实施例还公开了一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行所述指令时，执行一种数据仓库构建方法。

本申请实施例包括以下优点：

本申请实施例通过在定义逻辑模型时，将属性的执行逻辑也进行定义，实现维度和执行逻辑结合的逻辑模型定义方式，ETL开发过程中不用关注如何生成物理表、也不用关注如何生成执行逻辑代码，只需要利用该逻辑模型即可构建数据仓库，因此可以节省ETL开发过程，提高效率。并且由于使用该逻辑模型构建仓库，无需关注物理表，那么在维护时只需要对该逻辑模型进行维护即可，不需要对物理表进行维护，可维护性好。

附图说明

图1是本申请一实施例提供的一种数据仓库构建方法的步骤流程图；

图2是本申请一实施例提供的另一种数据仓库构建方法的步骤流程图；

图3是本申请一实施例提供的另一种数据仓库构建方法的步骤流程图；

图4是本申请一实施例提供的一种数据仓库构建装置实施例的结构图；

图5是本申请另一实施例提供的一种装置的硬件结构示意图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

本申请在实施例中，提供了一种革新性的逻辑模型，在定义该逻辑模型时，将其中的属性和对应的执行逻辑一并定义，其定义过程比如：

1)对逻辑模型基础信息进行定义

在进行基础信息定义时，可以定义逻辑表的基本信息，比如表的名称、主键等信息。

在实际应用中逻辑模型可以包括维度逻辑表、明细逻辑表两种类型中的一种或者多种逻辑表。每种类型的逻辑表也可以有多张，每张表针对某个对象构建。

其中，维度逻辑表可以为针对对象构建的表，比如商品维度等。明细逻辑表为针对对象的操作行为构建的表，比如下单、支付等。

2)进行属性定义

对每个逻辑表，然后可以将其相关的属性进行定义。

需要说明的是，对于维度逻辑表，其属性可以是维度属性。对于明细逻辑表，其行为也具备很多属性，比如对于下单行为，其可能包括订单ID、订单类型、创建时间等，针对这些属性也进行定义。属性的名称可以基于其该属性对应的源表的名称进行定义。

3)、进行属性的执行逻辑的定义

在对属性进行定义后，可以对该属性的执行逻辑也进行定义。比如对于维度属性表的属性，定义其计算逻辑。对于明显逻辑表的属性，定义其筛选条件等。

4)、进行属性的关联维度的定义

在实际应用中属性可能会关联到其他的表，此时可以对其关联的表进行定义。

通过上述几个过程，则可以将各个逻辑表定义完毕，从而得到逻辑模型。

参照图1、其示出了本申请实施例一种数据仓库构建方法，具体可以包括：

步骤110，提供逻辑模型；所述逻辑模型包括至少一个逻辑表的基础信息、针对所述逻辑表的属性、针对所述属性的执行逻辑、针对所述属性的关联维度；所述执行逻辑用于基于所述属性构建表时，从目标表获取所述属性需求的数据；

在本申请实施例中，可以采用前述的方式定义逻辑模型，获得多个逻辑表的定义，该逻辑表包括其基础信息、属性、属性的执行逻辑、属性的关联维度。

具体而言，本申请实施例可以按照前述1)-4)的过程进行定义，从而提供上述逻辑模型。

对于上述1)，当需要针对某个对象的维度逻辑表时，可以针对该对象的名称、维度主键的进行定义。针对维度主键的定义包括名称、执行逻辑的定义。维度主键的计算逻辑的定义，可以从物理上保证维度的一致性定义，避免同一维度的重复定义，不用传统的通过人工的方式避免重复定义。

当需要针对某个对象的行为的明细逻辑表时，可以针对该行为的名称、事务进行定义。针对事务的定义包括事务主表、执行逻辑的定义。事务主表的计算逻辑的定义，可以从物理上保证维度的一致性定义，避免同一维度的重复定义，不用传统的通过人工的方式避免重复定义。

其中名称可以包括中文名称、英文名称，当然还可以包括其他语言的名称，本申请实施例不对其加以限制。

优选的，通过上述定义，提供的逻辑模型中，逻辑表的基础信息包括维度逻辑表信息，所述维度逻辑表信息包括名称和维度主键的定义信息，所述维度主键的定义信息包括名称和执行逻辑的定义信息。逻辑表的基础信息还可以包括明细逻辑表信息，所述明细逻辑表信息包括名称和事务的定义信息，所述事务的定义信息包括名称和执行逻辑的定义信息。

对于维度逻辑表，以定义第一系商品维度为例，对于上述1)其基础信息定义包括：

中文名称：第一系商品维度；

英文名称：dim_tb_item；

维度主键：中文名称为商品ID，英文名称为item_id，数据类型为BIGINT，执行逻辑为真实可执行SQL，比如：select item_id from商品表。

其中，商品表可以为从数据源同步到数据仓库的源表。

对于上述2)，可以根据相应逻辑表针对的对象或者行为的各个属性进行具体的定义。属性的定义包括名称、数据类型的定义。当然对于名称也可以包括一种或者多种语言的名称的定义。

比如前述第一系商品维度的逻辑表，定义其维度属性如下表一：

表一

对于上述3)，在属性定义完毕之后，可以对属性的执行逻辑进行定义。

比如上述表一的各个属性，其执行逻辑可以如表二进行定义：

表二

表二中的执行逻辑为SQL命令示例，其采用SQL语言定义了执行脚本。当然，在实际应用中，还可以采用其他语言构建执行脚本，本申请实施例不对其加以限制。

其中每个执行逻辑执行时，可以从相应的目标表获取具体数据，添加到新表的该属性列中。

优选的，该目标表可以为逻辑表和/或从数据源同步到数据仓库的物理表。

在本申请实施例中，由于定义的时候，可以定义多张逻辑表，某个属性的计算逻辑可能会到其他逻辑表去查询，此时则可以调用其他逻辑表的相关执行逻辑去获取结果。

对于上述4)，在属性定义完毕之后，可以对属性的关联维度进行定义。

比如对于上述表一的属性，可以对其的关联维度按表三进行定义：

属性名称	属性关联维度
		item_id	---
item_title	---
		item_statu<sub>s</sub>	---
item_type	---
		is_online	---
…	---
		cate_id	dim_tb_cate
seller_id	dim_tb_seller

表三

该表三中，如果属性没有属性关联维度，则其属性关联维度记录为空，比如表三中的“---”表示没有关联维度。假设dim_tb_cate，dim_tb_seller 是另外定义的两张逻辑表的表名，则说明cate_id这个属性与dim_tb_cate 表关联，seller_id这个属性与dim_tb_seller关联。

可以理解，针对所述属性的关联维度包括：针对所述属性关联的逻辑表。

下面以下单为例，对下单的逻辑表的定义过程进行描述：

1)对在购物网站的下单行为进行定义：

中文名称：下单明细逻辑表

英文名称：FCT_crt_ord

事务：事务主键为order_id，筛选条件为SQL语句。比如select order_id from交易表where下单行为and A网站。

2)对在购物网站的下单行为的属性进行定义：

比如表四：

属性名称	属性类型	属性中文名
			order_id	bigint	订单ID
order_state	string	订单状态
			order_cratetime	string	订单创建时间
order_overtime	string	订单结束时间
			…	…	…
seller_id	bigint	商品所属用户的user_Id

表四

3)对在下单行为的属性的执行逻辑进行定义，如表五：

表五

4)对在下单行为的属性的关联维度进行定义，如表六：

属性名称	属性关联维度
		order_id	---
order_state	---
		order_cratetime	---
order_overtime	---
		…	…
seller_id	dim_tb_seller

表六

当然，上述维度逻辑表和明细逻辑仅仅是一个示例，还有具体的属性等需求可以根据实际情况进行定义，本申请实施例不对其加以限制。

优选的，本申请实施例以键值对的方式对所述逻辑模型的属性的执行逻辑进行记录。

本申请实施例中对于逻辑模型中的各张逻辑表的执行逻辑，可以采用键值对key-value的方式进行记录，方便后续进行调用。比如将属性存储至key 中，该属性的执行逻辑存储至对应的value中。

当然，比如前述第一系商品维度的逻辑表，其基础信息，维度属性定义，属性的执行逻辑定义，属性的关联维度定义可以采用key-value存储。比如以最外层的key-value对，在最外层的key中记录表名，比如dim_tb_item， value里记录基础信息，然后在该value里嵌套key-value对，key里面存储属性名称，对应的value里面存储该属性的相关信息，比如属性类型、属性中文名、执行逻辑、关联维度等，本申请实施例不对其加以限制。

在实际应用中对于每张逻辑表，都可以采用组件化定义方法，即每张逻辑表的代码块与其他逻辑表相互独立，设置一个路由模块，将属性对其他逻辑表的依赖通过路由模块间接依赖。采用组件化定义得到逻辑表，其由于相互独立，可复用性更高，维护更方便。某个逻辑表需要修改，则直接对该逻辑表进行修改即可，不用对全部代码进行修改。

步骤120，根据所述逻辑模型构建数据仓库。

在本申请实施例中，由于提供了前述特性的逻辑模型，那么后续则可以根据该逻辑模型构建数据仓库。

本申请实施例通过在定义逻辑模型时，将属性的执行逻辑也进行定义，实现维度和执行逻辑结合的逻辑模型定义方式，ETL开发过程中不用关注如何生成物理表、也不用关注如何生成执行逻辑代码，只需要利用该逻辑模型即可构建数据仓库，因此可以节省ETL开发过程，提高效率。并且由于使用该逻辑模型构建仓库，无需关注物理表，那么在维护时只需要对该逻辑模型进行维护即可，不需要对物理表进行维护，可维护性好。

参照图2、其示出了本申请实施例另一种数据仓库构建方法，具体可以包括：

步骤210，提供逻辑模型；所述逻辑模型包括至少一个逻辑表的基础信息、针对所述逻辑表的属性、针对所述属性的执行逻辑、针对所述属性的关联维度；所述执行逻辑用于基于所述属性构建表时，从目标表获取所述属性需求的数据；

本步骤参照前述实施例的描述，在此不再详述。

步骤212，将所述逻辑模型加载至数据仓库，并基于所述逻辑模型设置逻辑模型调用接口。

在本申请实施例中，对于数据仓库的构建而言，可以只将逻辑模型加载至数据仓库即可，无需关注物理表。后续查询可以直接基于该逻辑模型中的逻辑表进行查询。

当然，可以提供针对该逻辑模型的调用接口，在数据仓库中实现对逻辑表的处理接口。

该种情况下，数据仓库还未基于逻辑模型生成具体的物理表。

步骤214，当接收到查询语句时，获取所述查询语句中针对的表名以及需求的目标属性，并调用逻辑模型调用接口；

在本申请实施例中，可以对数据用户提供逻辑表的相关信息，比如逻辑表名，逻辑表的属性，逻辑的关联维度等。

可以理解，实际应用中，从数据源中同步的源表可以根据前述定义的属性的名称与源表字段的对应关系，当数据源中的原始源表的自动与定义的属性名称不一致时，根据该对应关系将原始源表的字段转换为对应的属性名称。当然也可以在定义属性的时候，就利用原始源表的字段进行定义。

然后，数据用户可以根据前述提供的相关信息，向数据库提交查询语句。该查询语句可以是SQL语句。用户可以基于逻辑表构建查询语句然后提交给数据仓库。

数据仓库接收到该查询语句后，由于数据仓库中没有相应的物理表，无法进行直接查询，此时可以获取该查询语句种的表名以及该查询语句中需求的目标属性。比如查询语句为要从dim_tb_item查询item_id中item_title为“羽绒服”的结果。

那么可以获取逻辑表的表名为dim_tb_item，目标属性为item_id， item_title，条件是item_title为“羽绒服”。

步骤216，通过所述逻辑模型调用接口，获取所述逻辑模型中对应所述表名的逻辑表，以及从所述逻辑表中获取所述目标属性的执行逻辑；

那么首先可以根据dim_tb_item找到该逻辑表的组件，从该逻辑表的key-value中找到item_id的执行逻辑为“select item_id from商品表”，找到 item_title的执行逻辑为“select title as item_title from商品表”。

步骤218，基于所述执行逻辑获取包括所述目标属性的具体数据的物理表返回。

那么执行上述“select item_id from商品表”以及“select title as item_title from商品表”，生成一张包括item_id列数据和item_title列数据的初始物理表，然后在该物理表中查询item_title为“羽绒服”的得到最终物理表返回给用户。当然，在最终物理表返回后，初始物理表可以删除，节省存储空间。

可以理解，，还可以将“select item_id from商品表”、“select title as item_title from商品表”、查询item_title为“羽绒服”的条件合并，直接到数据仓库的前述“商品表”中查询item为羽绒服的结果。

需要说明的是，实际应用中在前述获得用户的查询语句后，还可以对其进行归一化，比如合并等操作，得到完整的逻辑表查询语句，然后即可在数据仓库中执行该查询语句。

本申请实施例通过在定义逻辑模型时，将属性的执行逻辑也进行定义，实现维度和执行逻辑结合的逻辑模型定义方式，ETL开发过程中不用关注如何生成物理表、也不用关注如何生成执行逻辑代码，只需要利用该逻辑模型即可构建数据仓库，因此可以节省ETL开发过程，提高效率。并且由于使用该逻辑模型构建仓库，无需关注物理表，那么在维护时只需要对该逻辑模型进行维护即可，不需要对物理表进行维护，可维护性好。并且，对于数据仓库，不用对全部逻辑表生成物理表，节省存储空间，还可以直接基于逻辑表得到查询结果，不经过逻辑表一一对应的物理表，更简洁方便、空间占用小。

参照图3、其示出了本申请实施例另一种数据仓库构建方法，具体可以包括：

步骤310，提供逻辑模型；所述逻辑模型包括至少一个逻辑表的基础信息、针对所述逻辑表的属性、针对所述属性的执行逻辑、针对所述属性的关联维度；所述执行逻辑用于基于所述属性构建表时，从目标表获取所述属性需求的数据；

本步骤参照前述实施例的描述，在此不再详述。

步骤312，将所述逻辑模型加载至数据仓库；

本申请实施例对定义完的逻辑模型加载至数据仓库，数据仓库则可以基于该逻辑模型进行处理。

步骤314，获取设定时间段内对各逻辑表的属性中查找热度大于预设阈值的热点属性；

本申请实施例中，针对每个对象或行为的逻辑表，比如前述第一系商品维度的逻辑表，技术人员可以将所有的属性都进行定义。但是实际应用中，可能有些属性被查询的次数很少，如果对该逻辑表的全部属性都生成物理表，可能造成物理表过宽的问题。本申请实施例则在基于逻辑表自动化生成物理表时，根据属性的查找热度，确定选择哪些去属性去生成物理表，供后续查询。

当然，在本申请实施例中基于逻辑表生成的物理表和其对于的逻辑表的表名一致。

本申请实施例则在逻辑表加载到数据仓库后，数据仓库可以获取设定时间段内对各个逻辑表中的属性的查找热度大于预设阈值的热点属性。

其中所述设定时间段可以为最近一段时间，比如最近一周、最近一月等，本申请实施例不对其加以限制。查找热度可以理解为对属性的查找次数。

比如对于前述第一系商品维度的逻辑表，假使其中的属性item_id、 item_title、item_status、item_type、seller_id最近一周的查找热度大于预设阈值，其为热点属性。而is_online、cate_id最近一周的查找热度不大于预设阈值，则不为热点属性。

该种情况由于减少了物理表中的属性，则表的宽度减少。

当然，实际应用中，还可以分析针对逻辑表的查找热度，如果查找热度也低于预设阈值，可以不生成该逻辑表对应的物理表。

步骤316，根据热点属性的执行逻辑，生成对应所述逻辑表的包括所述热点属性的具体数据的物理表。

那么可以基于逻辑表中item_id、item_title、item_status、item_type、 seller_id的执行逻辑select item_id from商品表、select title as item_title from 商品表、select item_status from商品表、select item_type from商品表、select seller_idfrom商品表，生成包括热点属性item_id、item_title、item_status、 item_type、seller_id五列数据的物理表，其物理表的表名还可以为 dim_tb_item。

优选的，还包括：

步骤A11，获取设定时间段内接收到的查询语句；

步骤A12，根据所述查询语句中针对的表名以及需求的目标属性的出现次数，更新与所述表名对应的逻辑表中各属性的查找热度。

在实际应用中，每隔一定时间周期，可以更新属性的前述查找热度。比如每隔一个周获取最新的一周的查询语句，根据该查询语句统计其对各逻辑表的属性的查询次数，然后根据查询次数更新各个属性的查找热度。

那么如前述例子，比如在下一个周期，统计item_type查找热度低于预设阈值，而cate_id查找热度高于预设阈值，则可以在获取cate_id的执行逻辑select category ascate_id from商品表，在前述物理表中增加cate_id列数据。另外，还可以删除前述物理表中低于预设阈值的item_type列数据。

步骤318，当接收到查询语句，根据所述查询语句中针对的表名以及需求的目标属性，在所述表名对应的物理表中查找所述目标属性对应的结果返回。

在本申请实施例中物理表的表名和逻辑表的表名一致，由于基于逻辑表后台自动生成了物理表，那么数据仓库在接收到查询语句后，可以直接执行该查询语句，在相应物理表中查询结果返回给用户。

比如接收到的一个查询语句要从dim_tb_item查询item_id中item_title 为“羽绒服”的结果。那么可以根据表名为dim_tb_item，目标属性为item_id， item_title，条件是item_title为“羽绒服”，直接从表名为dim_tb_item的物理表中查找结果返回给用户。

步骤320，当未查找到对应所述表名以及需求的目标属性的结果，则获取所述查询语句中针对的表名以及需求的目标属性，并调用逻辑模型调用接口；

步骤322，通过所述逻辑模型调用接口，获取所述逻辑模型中对应所述表名的逻辑表，以及从所述逻辑表中获取所述目标属性的执行逻辑；

步骤324，基于所述执行逻辑获取包括所述目标属性的具体数据的物理表返回。

在本申请实施例中，由于存在某些属性不在物理表中的缘故，可能存在查找不到的情况，那么对于未查找到对应所述表名以及需求的目标属性的结果的情况，步骤320-324可以参照前述步骤214-步骤218的描述，获取结果返回给用户，在此不再详述。

如果还没查找到数据，可以返回未检索到结果给用户。

本申请实施例通过在定义逻辑模型时，将属性的执行逻辑也进行定义，实现维度和执行逻辑结合的逻辑模型定义方式，ETL开发过程中不用关注如何生成物理表、也不用关注如何生成执行逻辑代码，只需要利用该逻辑模型即可构建数据仓库，因此可以节省ETL开发过程，提高效率。并且由于使用该逻辑模型构建仓库，无需关注物理表，那么在维护时只需要对该逻辑模型进行维护即可，不需要对物理表进行维护，可维护性好。并且，对于数据仓库，不用对逻辑表的全部属性生成物理表，而是针对热点的属性生成物理表，节省存储空间；另外，还可以动态更新热点的属性以及相应的物理表，从而使数据仓库的物理表更智能。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图4，示出了本申请的一种数据仓库构建装置(例如：服务器400) 的结构图，具体可以包括如下模块：

模型提供模块410，用于提供逻辑模型；所述逻辑模型包括至少一个逻辑表的基础信息、针对所述逻辑表的属性、针对所述属性的执行逻辑、针对所述属性的关联维度；所述执行逻辑用于基于所述属性构建表时，从目标表获取所述属性需求的数据；

构建模块420，用于根据所述逻辑模型构建数据仓库。

优选的，所述基础信息包括维度逻辑表信息，所述维度逻辑表信息包括名称和维度主键的定义信息，所述维度主键的定义信息包括名称和执行逻辑的定义信息。

优选的，所述基础信息包括明细逻辑表信息，所述明细逻辑表信息包括名称和事务的定义信息，所述事务的定义信息包括名称和执行逻辑的定义信息。

优选的，所述目标表包括逻辑表和/或从数据源同步到数据仓库的物理表。

优选的，所述针对所述属性的关联维度包括：针对所述属性关联的逻辑表。

优选的，以键值对的方式对所述逻辑模型的属性的执行逻辑进行记录。

优选的，所述构建模块包括：

第一构建子模块，用于将所述逻辑模型加载至数据仓库，并基于所述逻辑模型设置逻辑模型调用接口。

优选的，还包括：

第一接口调用模块，用于当接收到查询语句时，获取所述查询语句中针对的表名以及需求的目标属性，并调用逻辑模型调用接口；

逻辑表获取模块，用于通过所述逻辑模型调用接口，获取所述逻辑模型中对应所述表名的逻辑表，以及从所述逻辑表中获取所述目标属性的执行逻辑；

第一结果返回模块，用于基于所述执行逻辑获取包括所述目标属性的具体数据的物理表返回。

优选的，所所述构建模块包括：

加载子模块，用于将所述逻辑模型加载至数据仓库；

热点属性获取模块，用于获取设定时间段内对各逻辑表的属性中查找热度大于预设阈值的热点属性；

物理表生成模块，用于根据热点属性的执行逻辑，生成对应所述逻辑表的包括所述热点属性的具体数据的物理表。

优选的，还包括：

查询语句记录模块，用于获取设定时间段内接收到的查询语句；

热点属性更新模块，用于根据所述查询语句中针对的表名以及需求的目标属性的出现次数，更新与所述表名对应的逻辑表中各属性的查找热度。

优选的，还包括：

查询模块，用于当接收到查询语句，根据所述查询语句中针对的表名以及需求的目标属性，在所述表名对应的物理表中查找所述目标属性对应的结果返回。

优选的，还包括：

第二接口调用模块，用于当未查找到对应所述表名以及需求的目标属性的结果，获取所述查询语句中针对的表名以及需求的目标属性，并调用逻辑模型调用接口；

第二逻辑表获取模块，用于通过所述逻辑模型调用接口，获取所述逻辑模型中对应所述表名的逻辑表，以及从所述逻辑表中获取所述目标属性的执行逻辑；

第二结果返回模块，用于基于所述执行逻辑获取包括所述目标属性的具体数据的物理表返回。

本申请实施例通过在定义逻辑模型时，将属性的执行逻辑也进行定义，实现维度和执行逻辑结合的逻辑模型定义方式，ETL开发过程中不用关注如何生成物理表、也不用关注如何生成执行逻辑代码，只需要利用该逻辑模型即可构建数据仓库，因此可以节省ETL开发过程，提高效率。并且由于使用该逻辑模型构建仓库，无需关注物理表，那么在维护时只需要对该逻辑模型进行维护即可，不需要对物理表进行维护，可维护性好。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

图5是本申请实施例提供的一种服务器的结构示意图。参见图5，服务器500可以用于实施上述实施例中提供的数据仓库构建方法。该服务器500 可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)522(例如，一个或一个以上处理器) 和存储器532，一个或一个以上存储应用程序542或数据544的存储介质530 (例如一个或一个以上海量存储设备)。其中，存储器532和存储介质530 可以是短暂存储的或持久存储的。存储在存储介质530的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器522可以设置为与存储介质530通信，在服务器500上执行存储介质530中的一系列指令操作。

服务器500还可以包括一个或一个以上电源526，一个或一个以上有线或无线网络接口550，一个或一个以上输入输出接口558，一个或一个以上键盘556，和/或，一个或一个以上操作系统541，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。其中，中央处理器522可以在服务器500上执行以下操作的指令：

提供逻辑模型；所述逻辑模型包括至少一个逻辑表的基础信息、针对所述逻辑表的属性、针对所述属性的执行逻辑、针对所述属性的关联维度；所述执行逻辑用于基于所述属性构建表时，从目标表获取所述属性需求的数据；

根据所述逻辑模型构建数据仓库。

当然，其还可执行前述任一步骤对应的指令。

本申请实施例提供一种装置，其上存储有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行所述指令时，使得所述装置执行一种数据仓库构建方法。

本申请实施例还提供一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行所述指令时，执行一种数据仓库构建方法。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

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

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种数据仓库构建方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (26)

1.一种数据仓库构建方法，其特征在于，包括：

提供逻辑模型；所述逻辑模型包括至少一个逻辑表的基础信息、针对所述逻辑表的属性、针对所述属性的执行逻辑、针对所述属性的关联维度；所述执行逻辑用于基于所述属性构建表时，从目标表获取所述属性需求的数据；

根据所述逻辑模型构建数据仓库。

2.根据权利要求1所述的方法，其特征在于，所述基础信息包括维度逻辑表信息，所述维度逻辑表信息包括名称和维度主键的定义信息，所述维度主键的定义信息包括名称和执行逻辑的定义信息。

3.根据权利要求1所述的方法，其特征在于，所述基础信息包括明细逻辑表信息，所述明细逻辑表信息包括名称和事务的定义信息，所述事务的定义信息包括名称和执行逻辑的定义信息。

4.根据权利要求1所述的方法，其特征在于，所述目标表包括逻辑表和/或从数据源同步到数据仓库的物理表。

5.根据权利要求1所述的方法，其特征在于，所述针对所述属性的关联维度包括：针对所述属性关联的逻辑表。

6.根据权利要求1所述的方法，其特征在于，以键值对的方式对所述逻辑模型的属性的执行逻辑进行记录。

7.根据权利要求1所述的方法，其特征在于，所述根据所述逻辑模型构建数据仓库的步骤，包括：

将所述逻辑模型加载至数据仓库，并基于所述逻辑模型设置逻辑模型调用接口。

8.根据权利要求7所述的方法，其特征在于，还包括：

当接收到查询语句时，获取所述查询语句中针对的表名以及需求的目标属性，并调用逻辑模型调用接口；

通过所述逻辑模型调用接口，获取所述逻辑模型中对应所述表名的逻辑表，以及从所述逻辑表中获取所述目标属性的执行逻辑；

基于所述执行逻辑获取包括所述目标属性的具体数据的物理表返回。

9.根据权利要求1所述的方法，其特征在于，所述根据所述逻辑模型构建数据仓库的步骤，包括：

将所述逻辑模型加载至数据仓库；

获取设定时间段内对各逻辑表的属性中查找热度大于预设阈值的热点属性；

根据热点属性的执行逻辑，生成对应所述逻辑表的包括所述热点属性的具体数据的物理表。

10.根据权利要求9所述的方法，其特征在于，还包括：

获取设定时间段内接收到的查询语句；

根据所述查询语句中针对的表名以及需求的目标属性的出现次数，更新与所述表名对应的逻辑表中各属性的查找热度。

11.根据权利要求9所述的方法，其特征在于，还包括：

当接收到查询语句，根据所述查询语句中针对的表名以及需求的目标属性，在所述表名对应的物理表中查找所述目标属性对应的结果返回。

12.根据权利要求11所述的方法，其特征在于，还包括：

当未查找到对应所述表名以及需求的目标属性的结果，则获取所述查询语句中针对的表名以及需求的目标属性，并调用逻辑模型调用接口；

通过所述逻辑模型调用接口，获取所述逻辑模型中对应所述表名的逻辑表，以及从所述逻辑表中获取所述目标属性的执行逻辑；

基于所述执行逻辑获取包括所述目标属性的具体数据的物理表返回。

13.一种数据仓库构建装置，其特征在于，包括：

模型提供模块，用于提供逻辑模型；所述逻辑模型包括至少一个逻辑表的基础信息、针对所述逻辑表的属性、针对所述属性的执行逻辑、针对所述属性的关联维度；所述执行逻辑用于基于所述属性构建表时，从目标表获取所述属性需求的数据；

构建模块，用于根据所述逻辑模型构建数据仓库。

14.根据权利要求13所述的装置，其特征在于，所述基础信息包括维度逻辑表信息，所述维度逻辑表信息包括名称和维度主键的定义信息，所述维度主键的定义信息包括名称和执行逻辑的定义信息。

15.根据权利要求13所述的装置，其特征在于，所述基础信息包括明细逻辑表信息，所述明细逻辑表信息包括名称和事务的定义信息，所述事务的定义信息包括名称和执行逻辑的定义信息。

16.根据权利要求13所述的装置，其特征在于，所述目标表包括逻辑表和/或从数据源同步到数据仓库的物理表。

17.根据权利要求13所述的装置，其特征在于，所述针对所述属性的关联维度包括：针对所述属性关联的逻辑表。

18.根据权利要求13所述的装置，其特征在于，以键值对的方式对所述逻辑模型的属性的执行逻辑进行记录。

19.根据权利要求13所述的装置，其特征在于，所述构建模块包括：

第一构建子模块，用于将所述逻辑模型加载至数据仓库，并基于所述逻辑模型设置逻辑模型调用接口。

20.根据权利要求19所述的装置，其特征在于，还包括：

第一接口调用模块，用于当接收到查询语句时，获取所述查询语句中针对的表名以及需求的目标属性，并调用逻辑模型调用接口；

第一逻辑表获取模块，用于通过所述逻辑模型调用接口，获取所述逻辑模型中对应所述表名的逻辑表，以及从所述逻辑表中获取所述目标属性的执行逻辑；

第一结果返回模块，用于基于所述执行逻辑获取包括所述目标属性的具体数据的物理表返回。

21.根据权利要求13所述的装置，其特征在于，所述构建模块包括：

加载子模块，用于将所述逻辑模型加载至数据仓库；

热点属性获取模块，用于获取设定时间段内对各逻辑表的属性中查找热度大于预设阈值的热点属性；

物理表生成模块，用于根据热点属性的执行逻辑，生成对应所述逻辑表的包括所述热点属性的具体数据的物理表。

22.根据权利要求21所述的装置，其特征在于，还包括：

查询语句记录模块，用于获取设定时间段内接收到的查询语句；

热点属性更新模块，用于根据所述查询语句中针对的表名以及需求的目标属性的出现次数，更新与所述表名对应的逻辑表中各属性的查找热度。

23.根据权利要求21所述的装置，其特征在于，还包括：

查询模块，用于当接收到查询语句，根据所述查询语句中针对的表名以及需求的目标属性，在所述表名对应的物理表中查找所述目标属性对应的结果返回。

24.根据权利要求23所述的装置，其特征在于，还包括：

第二接口调用模块，用于当未查找到对应所述表名以及需求的目标属性的结果，获取所述查询语句中针对的表名以及需求的目标属性，并调用逻辑模型调用接口；

第二逻辑表获取模块，用于通过所述逻辑模型调用接口，获取所述逻辑模型中对应所述表名的逻辑表，以及从所述逻辑表中获取所述目标属性的执行逻辑；

第二结果返回模块，用于基于所述执行逻辑获取包括所述目标属性的具体数据的物理表返回。

25.一种装置，其特征在于，包括：

一个或多个处理器；和

其上存储有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行所述指令时，使得所述装置执行如权利要求1-12任一项的方法。

26.一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行所述指令时，执行如权利要求1-12任一项的方法。

Images