基于业务模型构建数据仓库的方法、装置及存储介质与流程

1.本技术涉及数据仓库技术领域，特别是涉及一种基于业务模型构建数据仓库的方法、装置及存储介质。


背景技术：

2.当前，越来越多的企业开始基于数据仓库建立数据模型对业务数据进行分析。现在大多数的数据仓库开发工具是以inmon数据仓库思想的三范式指导构建数据仓库的模型，而使用kimball维度建模思想指导构建数据仓库的模型是基于物理数据库使用反范式的方式建立的。
3.虽然创建出来的数据仓库模型也能够从技术角度由专业数据技术人员的进行数据分析，但是这样的模型只有技术元素，其只能反映表结构与表结构之间的关系，缺少业务含义而没有以业务视角去反映模型与实际业务之间的关系。因此业务人员基于这样的模型对数据进行分析时，不知道模型和数据来源于那个业务过程，不清楚数据的业务含义，难以对数据进行分析与追溯。
4.针对上述的现有技术中存在的数据仓库的模型只有技术元素，其只能反映表结构和表结构之间的关系，缺少业务含义，并没有与业务关联起来，因此无法从数据仓库模型中反映出业务关系的技术问题，目前尚未提出有效的解决方案。


技术实现要素：

5.本公开的实施例提供了一种基于业务模型构建数据仓库的方法、装置及存储介质，以至少解决现有技术中存在的数据仓库的模型只有技术元素其只能反映表结构和表结构之间的关系，并没有与业务关联起来，因此无法从数据仓库模型中反映出业务关系的技术问题。
6.根据本公开实施例的一个方面，提供了一种基于业务模型构建数据仓库的方法，包括：接收与预定业务相关的第一建模参数；根据第一建模参数创建业务模型单元，其中业务模型单元包括与预定业务相关的字段；构建与业务模型单元相关的物理模型，并在物理数据库中创建与物理模型对应的数据表结构；以及将业务模型单元与物理模型进行绑定，实现业务模型单元与数据表结构之间的关联，从而构建基于业务模型单元的数据仓库。
7.根据本公开实施例的另一个方面，还提供了一种存储介质，存储介质包括存储的程序，其中，在程序运行时由处理器执行以上任意一项所述的方法。
8.根据本公开实施例的另一个方面，还提供了一种基于业务模型构建数据仓库的装置，包括：数据接收模块，用于接收与预定业务相关的第一建模参数；单元创建模块，用于根据第一建模参数创建业务模型单元，其中业务模型单元包括与预定业务相关的字段；物理模型构建模块，用于构建与业务模型单元相关的物理模型，并在物理数据库中创建与物理模型对应的数据表结构；以及模型绑定模块，用于将业务模型单元与物理模型进行绑定，实现业务模型单元与数据表结构之间的关联，从而构建基于业务模型单元的数据仓库。
9.根据本公开实施例的另一个方面，还提供了一种基于业务模型构建数据仓库的装置，包括：处理器；以及存储器，与处理器连接，用于为处理器提供处理以下处理步骤的指令：接收与预定业务相关的第一建模参数；根据第一建模参数创建业务模型单元，其中业务模型单元包括与预定业务相关的字段；构建与业务模型单元相关的物理模型，并在物理数据库中创建与物理模型对应的数据表结构；以及将业务模型单元与物理模型进行绑定，实现业务模型单元与数据表结构之间的关联，从而构建基于业务模型单元的数据仓库。
10.在本公开实施例中，系统首先接收与预定业务相关的建模参数，然后根据建模参数创建包括与预定业务相关字段的业务模型单元，然后系统根据业务模型单元创建物理模型，最终将业务模型单元与物理模型进行绑定，构建与预定业务相关的数据仓库。从而与现有技术在物理数据库基础上使用反范式构建维度数据仓库相比，本方案可以从业务角度出发，构建业务模型，而不必受到物理数据库中的数据表的限制。即，根据本方案，可以先根据实际的业务构建业务模型单元，然后基于建立的业务模型单元(可以由系统自动或技术人员手动)构建与预定业务相关的物理模型，然后用户(业务或技术人员)就可以根据创建的业务模型对预定业务相关的数据进行分析和追溯。从而数据仓库的建模过程可以不必受到物理数据库中的数据表的限制，数据分析不再受限于技术人员。
11.由于本实施例的建模过程不是基于物理数据库采用自下而上的方法建立，而是根据业务建立业务模型单元，再根据业务模型单元由系统自动或技术人员手动建立物理模型，并由系统根据物理模型自动构建物理数据库的表结构及表关系，因此通过业务模型单元与业务的关联，实现了通过模型可以知道数据来源于那个业务过程的技术效果。进而解决了现有技术中存在的数据仓库的模型只有技术元素其只有表结构和表关系，并没有与业务关联起来，缺少业务含义，无法从模型中反映出业务关系的技术问题。另处现有技术中的数据仓库模型只提供由技术人员操作的技术窗口，而业务模型提供了业务人员与技术人员共同操作的业务操作窗口，能让业务人员与技术人员对数据达成一致共识，屏蔽了底层的技术细节。
附图说明
12.此处所说明的附图用来提供对本公开的进一步理解，构成本技术的一部分，本公开的示意性实施例及其说明用于解释本公开，并不构成对本公开的不当限定。在附图中：
13.图1是用于实现根据本公开实施例1所述的方法的计算设备的硬件结构框图；
14.图2是根据本公开实施例1所述的系统的工作原理架构设计图；
15.图3是根据本公开实施例1的第一个方面所述的基于业务模型构建数据仓库的方法的流程示意图；
16.图4a是根据本公开实施例1所述的参数输入界面的示意图；
17.图4b是根据本公开实施例1所述的业务模型单元的基础信息界面的示意图；
18.图4c是根据本公开实施例1所述的业务模型单元的字段信息界面的示意图；
19.图4d是根据本公开实施例1所述的部分业务模型单元的列表的示意图；
20.图4e是根据本公开实施例1所述的业务模型单元关联结构的示意图；
21.图5a是根据本公开实施例1所述的事实模型单元的列表的示意图；
22.图5b是根据本公开实施例1所述的事实模型单元的基本信息的示意图；
23.图5c是根据本公开实施例1所述的事实模型单元描述与预定业务相关联的事实的字段的示意图；
24.图5d是根据本公开实施例1所述的自动绑定业务模型与物理模型的示意图；
25.图5e是根据本公开实施例1所述的手动绑定业务模型与物理模型的示意图；
26.图5f是根据本公开实施例1所述的维度模型单元和事实模型单元关联的示意图；
27.图6a是根据本公开实施例1所述的订单和商品的多值层次维度的关联示意图；
28.图6b是根据本公开实施例1所述的树形结构关联的示意图；
29.图6c是根据本公开实施例1所述枚举实体的示意图；
30.图7a是根据本公开实施例1所述的订单物理模型的表信息的示意图；
31.图7b是根据本公开实施例1所述的订单物理模型的表结构的示意图；
32.图7c是根据本公开实施例1所述的物理模型的er关系示意图；
33.图7d是根据本公开实施例1所述的物理模型的质量规则示意图；
34.图7e是根据本公开实施例1所述的物理模型的映射关系示意图；
35.图7f是根据本公开实施例1所述的物理模型的版本信息示意图；
36.图8是根据本公开实施例2所述的基于业务模型构建数据仓库构建的装置的示意图；以及
37.图9是根据本公开实施例3所述的基于业务模型构建数据仓库构建的装置的示意图。
具体实施方式
38.为了使本技术领域的人员更好地理解本公开的技术方案，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本公开一部分的实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本公开保护的范围。
39.需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
40.实施例1
41.根据本实施例，提供了一种基于业务模型构建数据仓库的方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
42.本实施例所提供的方法实施例可以在服务器或者类似的计算设备中执行。图1示出了一种用于实现基于业务模型构建数据仓库的方法的计算设备的硬件结构框图。如图1
所示，计算设备可以包括一个或多个处理器(处理器可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)、用于存储数据的存储器、以及用于通信功能的传输装置。除此以外，还可以包括：显示器、输入/输出接口(i/o接口)、通用串行总线(usb)端口(可以作为i/o接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算设备还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。
43.应当注意到的是上述一个或多个处理器和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到计算设备中的其他元件中的任意一个内。如本公开实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。
44.存储器可用于存储应用软件的软件程序以及模块，如本公开实施例中的基于业务模型构建数据仓库的方法对应的程序指令/数据存储装置，处理器通过运行存储在存储器内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的基于业务模型构建数据仓库的方法。存储器可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器可进一步包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至计算设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
45.传输装置用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算设备的通信供应商提供的无线网络。在一个实例中，传输装置包括一个网络适配器(network interface controller，nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置可以为射频(radio frequency，rf)模块，其用于通过无线方式与互联网进行通讯。
46.显示器可以例如触摸屏式的液晶显示器(lcd)，该液晶显示器可使得用户能够与计算设备的用户界面进行交互。
47.此处需要说明的是，在一些可选实施例中，上述图1所示的计算设备可以包括硬件元件(包括电路)、软件元件(包括存储在计算机可读介质上的计算机代码)、或硬件元件和软件元件两者的结合。应当指出的是，图1仅为特定具体实例的一个实例，并且旨在示出可存在于上述计算设备中的部件的类型。
48.此外，图2还示出了实施本实施例所述的基于业务模型构建数据仓库的数据建模管理系统的工作原理架构设计图。参考图2所示，该系统从上到下分为三层，分别是接入层、服务层和存储层。
49.接入层是用户的入口，用户通过入口访问系统功能。它包管理入口、web服务器和odbc服务器。其中管理入口是管理员以及建模工程师等人员管理模型的操作入口；web服务器通过web的方式曝露模型信息，通过web服务接口或界面可以查询模型的元数据和数据；3.odbc服务器通过tcp的连接进行sql协议通信方式提供查询服务，用户使用odbc驱动或支持odbc的sql客户端就可以连接odbc服务器进行操作。
50.服务层是系统业务逻辑的实现，负责接收接入层的操作请求，根据请求进行相关
业务处理并作出响应，包括模型管理模块和执行管理器模块。
51.模型管理模块用于对模型的建立、维护、查询和跟踪等进行管理。其中模型的信息也可以说是元数据，它包括业务模型单元与物理模型。其中业务模型是从业务角度建模，包括业务过程管理、维度实体管理以及事实模型管理等。物理模型是从技术角度建模，包括表结构与表关系管理、约束与质量管理以及映射关系管理等。其中系统会根据业务模型自动建立物理模型，也可以手动建立物理模型，然后在业务模型的绑定物理模型功能中进行绑定，设置业务模型与物理模型的绑定关系。
52.执行管理管理器模块主要有以下核心功能：1.根据物理模型与采用的物理数据仓库构造相关sql语句，然后在物理数据仓库执行sql语句创建物理结构。2.接收来自web服务器与odbc服务器的sql请求，然后解释sql语句，并根据所采用的物理数据仓库和查询到的元数据信息进行sql转换，转换成物理数据仓库能执行sql语句，然后发到物理数据仓库执行，并处理物理数据仓库返回的结果，然后再返回给web服务与odbc服务。
53.存储层是负责存储数据，包括应用数据库与数据仓库。其中，应用数据库主要存储模型数据(元数据)和系统相关的数据；数据仓库存储业务系统抽取过来的操作型数据、数据仓库的数据、主题数据等。
54.此外图2中所示的数据建模管理系统适用于图1中所示的硬件结构图。
55.在上述运行环境下，根据本实施例的第一个方面，提供了一种基于业务模型构建数据仓库的方法，该方法例如可以由图2所示数据建模管理系统实现。图3示出了该方法的流程示意图，参考图3所示，该方法包括：
56.s302：接收与预定业务相关的第一建模参数；
57.s304：根据第一建模参数创建业务模型单元，其中业务模型单元包括与预定业务相关的字段；
58.s306：构建与业务模型单元相关的物理模型，并在物理数据库中创建与物理模型对应的数据表结构；以及
59.s308：将业务模型单元与物理模型进行绑定，实现业务模型单元与数据表结构之间的关联，从而构建基于业务模型单元的数据仓库。
60.正如背景技术中所述的，现有技术中基于数据仓库创建出来的模型虽然也能够基于数据仓库中的数据进行分析，但是这样创建出来的模型只能技术元素其只能反映表结构与表结构之间的关系，而没有以业务视角去反映模型与实际业务之间的关系。因此业务人员基于此模型对数据进行分析时，不知道模型和数据来源于那个业务过程，缺少业务含义，难以理解数据，不利于对数据进行分析与追溯。
61.针对背景技术中存在的技术问题，本实施例技术方案在步骤s302中，数据建模管理系统首先接收与预定业务相关的第一建模参数。其中，第一建模参数为用户输入的与预定业务相关的参数。参考图4a所示，用户可以通过接入层的管理入口提供的可视化界面进行输入。第一建模参数例如可以包括用于创建与预定业务的相关业务模型单元的基础信息，例如：名称、编码、类别、数据域以及描述等，还可以包括与预定业务相关的业务模型单元的结构信息(例如：具体业务的字段名称、字段值)。在一个具体实例中，预定业务可以是订单业务，与订单业务相关的第一建模参数可以包括与订单业务相关的业务模型单元的基本信息。业务模型单元例如可以是与以下环节相关的业务模型单元：商家、组团、订单状态、
卖家、商品信息以及日期等。
62.以用户输入的用于创建与订单业务相关的“下单日期”业务模型单元的基本信息为例，图4b中示出了用户输入的“下单日期”业务模型单元的基本信息(即界面上所示的“实体信息”)，该基本信息包括与业务模型单元相关的以下信息：名称：“下单日期”；类别：“普通层次”；编码：“ordertime”；创建时间：“2019-10-30”；作用域：“交易域”；对业务模型单元的描述；以及更新时间：“2019-10-30”。
63.此外，参考图4c所示，用户可以进一步通过可视化的界面输入与“下单日期”业务模型单元相关的字段信息作为部分第一建模参数，包括：“代理键”、“年”、“月”和“日”等。此外，参考图4c所示，对于每一个字段，还可以限定属性。例如，属性可以包括：维度编码date_id(year、month、day)、维度名称(年、月、日)、数据类型(string、var)、约束(主键约束、外键约束)以及相关描述等。
64.从而通过以上方式，系统可以接收用户输入的第一建模参数，用于创建相关的业务模型单元。
65.进一步地，在步骤s304中，系统的模型管理模块根据第一建模参数创建业务模型单元，其中业务模型单元包括与预定业务相关的字段。即，系统根据用户输入的第一建模参数创建业务模型单元。图4d示例性的示出了创建完成的部分业务模型单元的列表的示意图，参考图4d所示，创建的业务模型单元包括商家、组团、订单状态以及下单日期等业务模型单元，并且每个业务模型单元包括与预定业务相关的字段。
66.进一步地，在步骤s306中，系统的模型管理模块构建与业务模型单元相关的物理模型，并在物理数据库中创建与物理模型对应的数据表结构。其中，可以根据该业务模型单元，由系统自动或技术人员手动创建与预定业务相关的物理模型。
67.最终，在步骤s308中，系统将业务模型单元与物理模型进行绑定，实现业务模型单元与数据表结构之间的关联，从而构建基于业务模型单元的数据仓库。即，将物理数据模型的字段与业务模型单元的字段进行对应绑定，例如：与“下单日期”业务模型单元的字段(年、月、日)对应的物理模型的字段也可以包括年、月、日等字段。从而，系统可以根据业务模型单元与物理模型的绑定关系，将业务模型单元与物理模型对应的数据表结构关联，从而将业务模型单元和物理数据库中的数据表结构关联起来。
68.从而通过这种方式，数据建模管理系统首先接收与预定业务相关的建模参数，然后根据建模参数创建包括与预定业务相关字段的业务模型单元，然后根据业务模型单元创建物理模型，最终将业务模型单元与物理模型进行绑定，构建与预定业务相关的数据仓库。从而与现有技术在物理数据库基础上使用反范式构建维度数据仓库相比，本方案可以从业务角度出发，构建业务模型，而不必受到物理数据库中的数据表的限制。即，根据本方案，可以先根据实际的业务构建业务模型单元，然后基于建立的业务模型单元(可以由系统自动或技术人员手动)构建与预定业务相关的物理模型，然后用户(业务或技术人员)就可以根据创建的业务模型对预定业务相关的数据进行分析和追溯。从而数据仓库的建模过程可以不必受到物理数据库中的数据表的限制，数据分析不再受限于技术人员。
69.由于本实施例的建模过程不是基于物理数据库采用自下而上的方法建立，而是根据业务建立业务模型单元，再根据业务模型单元由系统自动或技术人员手动建立物理模型，因此通过业务模型单元与业务的关联，实现了通过模型可以知道数据来源于那个业务
过程的技术效果。进而解决了现有技术中存在的数据仓库的模型只有技术元素，其只有表结构和表关系，并没有与业务关联起来，缺少业务含义，无法从模型中反映出业务关系的技术问题。另外现有技术中的数据仓库模型只提供由技术人员操作的技术窗口，而业务模型提供了业务人员与技术人员共同操作的业务操作窗口，能让业务人员与技术人员对数据达成一致共识，屏蔽了底层的技术细节。
70.可选地，还包括：基于业务模型单元，构建与预定业务相关的业务逻辑模型。
71.具体地，数据建模管理系统还可以基于业务模型单元，构建与预定业务相关的业务逻辑模型。在一个具体实例中，系统例如通过接收用户的输入的建模参数，建立”会员”维度实体与”会员类型”维度实体的业务逻辑模型，或建立“订单”事实模型与“商家”维度实体、“组团”维度实体、“订单状态”维度实体、“组织”维度实体以及“会员”维度实体等的的业务逻辑模型。业务逻辑模型包括维度实体之间的关系逻辑模型与事实和维度实体间的关系逻辑模型，将业务模型单元之间进行关联，构建可以反映出业务逻辑关系的业务逻辑模型。从而通过这种方式，用户可以从自己的业务出发，构建与自己的业务相关的业务逻辑模型，因此可以使得所建立的模型能够充分反映与业务的关联。
72.可选地，根据第一建模参数，创建业务模型单元的操作，包括：根据第一建模参数，创建与预定业务相关的维度模型单元，其中维度模型单元包括描述用于对预定业务进行分析的维度的字段；以及根据第一建模参数，创建与预定业务相关的事实模型单元，其中事实模型单元包括描述与预定业务相关联的事实的字段。
73.具体地，参考图2所示，业务模型单元例如可以包括维度模型单元(即图2中所示的维度实体)和事实模型单元(即图2中所示的事实模型)，其中维度模型单元包括描述用于对预定业务进行分析的维度的字段，事实模型单元包括描述与预定业务相关联的事实的字段。在根据第一建模参数，创建业务模型单元的操作中，系统可以根据第一建模参数，创建与预定业务相关的维度模型单元。例如：参考图4d所示的维度模型单元(界面中的“维度实体”)包括商家、组团、订单状态以及下单日期维度等维度模型单元。例如下单日期维度单元可以描述订单业务中的时间维度，下单日期维度单元可以包括的字段为年、月以及日，从而可以从下单日期这个维度对订单业务的数据进行分析。再例如，商家维度单元可以包括“商家id”字段，从而可以从商家这个维度对订单业务的数据进行分析。
74.此外，系统还可以创建与预定业务相关的事实模型单元，通过事实模型单元可以描述预定业务相关联的事实。图5a示出了事实模型单元的列表的示意图，包括采购单、订单、考勤、配送等事实模型单元，并且图5b示例性的示出了“订单”事实模型单元的基本信息，参考图5b所示，“订单”事实模型单元包括以下基本信息：名称：订单；类别：事务型；编码：order；创建时间：2019-10-30；作用域：交易域；对订单事实模型的描述；以及更新时间：2019-10-30。
75.此外，图5c还示例性的示出了“订单”事实模型单元描述与预定业务相关联的事实的字段的示意图，参考图5c所示，“订单”事实模型单元的字段包括：商品数量、订单金额、优惠金额等。
76.正如背景技术中所述的，现有的kimball维度建模思想是在物理数据库的基础上利用反范式的方式自下而上建立的。其中根据kimball的建模思想，需要在物理数据库的基础上创建用于描述与预定业务相关的事实的事实表，并且创建用于从不同维度对预定业务
进行分析的维度表。通过将事实表与维度表进行关联，实现维度建模。例如，可以通过将事实表与维度表关联，建立星型模型或雪花模型等不同形式的数据模型。
77.但是这仍然是一种自下而上构建数据模型的方案，因此仍然存在背景技术中所提到的数据仓库的模型只有技术元素其只有表结构和表关系，并没有与业务关联起来，缺少业务含义，无法从模型中反映出业务关系的技术问题。并且，所建立的模型没有区分维度或事实，没有业务元素，不利于数据的分析和溯源。
78.通过本实施例的这种方式，在创建业务模型的过程中通过自上而下的方式，首先构建维度模型单元以及事实模型单元，然后基于构建的维度模型单元和事实模型单元，由系统自动或技术人员手动构建物理模型，并自动在物理数据库上建立表结构及表关系，因此可以将业务模型与业务关联起来，并且通过维度模型单元和事实模型单元反映出业务关系。此外，通过本实施例的技术方案，还可以从开始构建业务模型单元的时候就将维度和事实进行区分，因此可以更加灵活的创建业务模型。
79.需要补充说明的是，事实模型单元是把业务活动中的每一个活动抽象成一个事实模型，通过事实模型来信息化业务活动、业务事件。事实模型记录了业务活动信息，参与的实体，以及衡量这个活动的度量，包括：
80.1.事实信息：名称、编码、类型、数据域、描述等(如图5b所示，可以通过可视化界面输入事实模型单元的基本信息)；
81.2.事实的结构包括维度属性和度量属性：维度属性与实体的属性一样；度量属性由名称、编码、数据类型，度量类型、约束、描述等组成；
82.3.事实模型表示由哪些实体参与到这个活动中，通常以事实表为中心连接周围实体的星形或雪花结构表示，可以通过可视图形化的方式设置这种星型结构的关联关系，只要拖入不同类型的维度实体，系统自动根据维度实体的类型按不同的连接(桥接)方式连接到事实表上。
83.可选地，构建与业务模型单元对应的物理模型，包括：响应于创建业务模型单元的操作，构建与业务模型单元对应的物理模型；或者响应于接收的创建物理模型的指令，构建与业务模型单元对应的物理模型。
84.具体地，在构建与业务模型单元对应的物理模型的操作中，系统可以响应于创建业务模型单元的操作，构建与业务模型单元对应的物理模型，即：系统响应创建业务模型单元的操作，自动构建与业务模型单元对应的物理模型，例如：业务模型单元构建完成之后系统自动构建物理模型。此外，系统还可以响应于接收的创建物理模型的指令，构建与业务模型单元对应的物理模型。例如：系统可以接收用户的创建物理模型的指令，由用户根据实际的业务需求手动在系统中构建与业务模型单元对应的物理模型。即，由系统自动或技术人员手动构建与预定业务相关的物理模型。
85.此外，图5d和5e示例性地示出了将业务模型与物理模型的字段之间进行绑定的界面的示意图。从而，通过该界面，可以将物理数据库中的数据结构与业务模型的字段进行关联。
86.参考图5d所示，右侧为业务模型单元的字段，左侧为物理模型的字段。如果物理模型是由系统自动生成的，则物理模型与业务模型的绑定关系已由系统自动建立，通过5d可以直接看到物理模型与业务模型的绑定明细；如果物理模型是由技术人员手建立的，则用
户可以编辑绑定关系，参考图5e所示，用户在左侧物理模型对应个各选择控件中选择与右侧业务模型的字段对应物理字段进行绑定。从而通过这种方式，系统可以借助于适用于物理数据库(即图2中示出的数据仓库中的数据库)的物理模型单元，将创建的业务模型单元(例如，维度模型单元和/或事实模型单元)与物理数据库中的数据结构进行关联。
87.可选地，在物理数据库中创建与物理模型对应的数据表结构，包括：在物理数据库中创建与维度模型单元相关的物理模型对应的维度表；以及在物理数据库中创建与事实模型单元相关的物理模型对应的事实表。
88.具体地，在物理数据库中创建与物理模型对应的数据表结构的操作中，系统在物理数据库中创建与维度模型单元相关的物理模型对应的维度表，例如：根据“下单日期”维度模型单元的物理模型，创建“下单日期”维度表。此外，系统还在物理数据库中创建与事实模型单元相关的物理模型对应的事实表，例如：根据“订单”事实模型单元的物理模型，创建“订单”事实表。
89.可选地，基于业务模型单元，构建与预定业务相关的业务逻辑模型，包括：接收用于构建业务逻辑模型的第二建模参数；根据第二建模参数，将维度模型单元与事实模型单元进行关联，构建业务逻辑模型。
90.具体地，在基于业务模型单元，构建与预定业务相关的业务逻辑模型的操作中，系统首先接收用于构建业务逻辑模型的第二建模参数，其中第二建模参数用于指示将业务模型单元之间进行逻辑关联。然后，系统根据第二建模参数，将维度模型单元与事实模型单元进行关联，构建业务逻辑模型。例如，参考上面图4e所示，用户可以通过可视化的界面，将“商家”维度模型单元、“组团信息”维度模型单元、“订单状态”维度模型单元、“组织信息”维度模型单元以及“会员信息”维度模型单元等与订单事实模型单元进行关联，从而产生反映维度模型单元与订单事实模型单元的关联关系的第二建模参数。然后系统可以根据该第二建模参数构建业务逻辑模型。
91.此外，参考图5f所示，例如用户可以通过可视化的界面，将“会员”维度模型单元和“商品信息”维度模型单元与“订单”事实模型单元相关联，从而产生反映维度模型单元与订单事实模型单元的关联关系的第二建模参数。然后系统根据第二建模参数，将维度模型单元以及事实模型单元进行关联，从而构建业务逻辑模型。从而，通过这种方式，系统可以将维度模型单元与事实模型单元进行关联，从而使得业务模型与实际业务有更好地关联。
92.此外，系统还可以根据第二建模参数，将多个维度模型单元与事实模型单元进行关联，即：将一个事实模型单元关联多个维度模型单元。例如：参考图4e所示，用户可以通过可视化的界面，将订单事实模型单元与商家维度模型单元和组团维度模型单元、订单状态维度模型单元进行关联，从而产生反映订单事实模型单元与商家维度模型单元、组团维度模型单元、订单状态维度模型单元之间的关联关系的第二建模参数。从而，系统可以根据第二建模参数将多个维度模型单元与一个事实模型单元进行关联。
93.可选地，维度模型单元为多个维度模型单元，并且方法还包括：根据以下至少一项关联规则，将多个维度模型单元进行关联：根据多个维度模型单元的一对多关联关系，采用外键建立维度模型单元之间的关联；根据多个维度模型单元的多对多关联关系，采用桥接表建立维度模型单元之间的关联；根据多个维度模型单元的层次关联关系，采用树形桥接表建立维度模型单元之间的关联。
94.具体地，维度模型单元为多个维度模型单元，在维度模型单元之间是一对多的关系的情况下，例如：商家维度模型单元与商家等级维度模型单元之间是一对多的情况，系统可以通过外键关联设置维度模型单元之间的关联关系。在维度模型单元之间是多对多关系(多值层次维度)的情况下，系统可以通过预先设置的桥接表把两个维度模型单元进行关联，图6a示出了商家维度模型单元和组团维度模型单元的多值层次维度的关联示意图，通过桥接表进行关联。维多模型单元还可以是父子的层级关系，在明确父子层次或不规则的父子层次情况下，可以通过树形结构组织维度模型单元的层次关系，参考图6b所示，这种关系可以通过一个由父、子、路径等字段的桥接表来描述父子层次的关系。从而，可以反映出维度之间的层次关系。
95.此外，例如维度模型单元还包括角色维度模型单元，角色维度是一个实体在不同的场景下扮演不同的角色，如地区实体：在下单的场景扮演的是收货地址角色；在注册的场景下扮演的是联系地址；日期角色维度模型单元，日期角色实体是一个特殊的角色实体，它几乎在所有场景都用到所以系统自动生成这个实体，在场景使用时候只要明确角色就行了；枚举维度模型单元，参考图6c所示，可以通过键值对表示的实体，并且预先知道可以一一枚举实体的值。
96.参考图2所示，由于数据仓库的物理库可以选用不同类型的数据库，例如hive、druid或者kylin等。因此，对于不同类型的物理数据库，图2中所示的模型管理模块可以创建不同类型的物理模型，从而适用于不同类型的物理数据库。
97.从而通过这种方式，业务人员可以通过创建业务模型单元以及物理模型，进而通过业务模型的实现与业务需求的数据分析。
98.并且正如背景技术中所述，由于现有技术中所创建的模型都是与特定的物理数据库绑定在一起的，因此一旦创建就不能迁移到其他物理数据库。但是本实施例的方法由于提供了与业务模型单元对应的物理模型，因此在将业务模型迁移至新的物理数据库时，只需要选定所用的物理数据库，然后系统自动根据业务模型创建新的物理模型，并在物理数据库中建立表结构与表关系，从而建立了业务模型到新的物理数据库中的数据结构的关联。因此提高了模型的可迁移性。
99.此外，图7a示例性地示出了订单物理模型的表信息示意图，参考图7a所示，物理模型由以下信息(基本信息和物理信息)组成，其中基本信息包括：表名称：“订单”；表编码：“order”；所在分层：“ods”；数据域：“交易域”；数据来源：“order_info”；创建时间：“2019-10-20”；更新时间：“2019-10-20”；描述：“对模型的描述”。物理信息包括：存储引擎：“hive”；存储格式：“orc”；是否分区：“是”；是否外表：“否”。通过表信息可以清楚地了解物理模型的相关信息。
100.图7b示例性地示出了物理模型的表结构的示意图，参考图7b所示，表结构由多个字段组成，每个字段包括编码、名称、数据类型、约束、更新时间、操作等。以订单物理模型的表结构为例，字段名称包括订单类型、订单时间、订单金额，分别对应的字段编码为order_type、order_time、order_amount。
101.图7c示例性地示出了物理模型的er关系示意图，er关系表示表与表之间的关联关系、通过可视化拖拉的方式快速设置表的关系。参考图7c所示，可以反映出出“订单”事实模型单元与“退货”维度模型单元以及“会员”维度模型单元之间的er关系。
102.图7d示例性地示出了物理模型的质量规则示意图，质量规则是根据数据标准建立的数据质量规范配置相应的监控策略，当出现违返数据质量规范问题时候系统根据监控策略采取相应的响应措施。参考图7d所示，配置不同的数据约束规范出现异常的情况下的处理方式，以及异常的预警级别。
103.图7e示例性地示出了当前物理表的数据来源的转换映射的示意图，参考图7e所示，右侧标识“目标”为当前物理表和左侧的“来源”为数据的源表，其映射关系组成了单向的数据流。
104.图7f示例性地示出了物理模型的版本信息示意图，版本信息是事实模型单元的变更通过不同版本保存起来以便跟踪追查。
105.此外，参考图1所示，根据本实施例的第二个方面，提供了一种存储介质。所述存储介质包括存储的程序，其中，在所述程序运行时由处理器执行以上任意一项所述的方法。
106.从而根据本实施例，系统首先接收与预定业务相关的第一建模参数，然后根据第一建模参数创建包括与预定业务相关的字段的业务模型单元，最终根据业务模型单元，由系统自动或技术人员自动构建与预定业务相关的物理模型，然后再由系统自动根据物理模型创建物理数据库的数据结构。与现有技术在物理数据库上使用反范式构建维度模型的数据仓库是从技术视角构建维度数据仓库相比，本方案可以从业务角度出发，构建业务模型，通过业务模型单元与业务进行关联的目的，实现了通过模型可以知道数据来源于那个业务过程的技术效果。此外，还增加了业务元素，以及对数据的维度和事实进行明确区分，确定维度的层次。进而解决了现有技术中存在的数据仓库的模型只有技术元素其只有表结构和表关系，并没有与业务关联起来，无法反映出业务关系的技术问题。
107.此外，从业务角度去构建数据仓库，还具有以下优点：1.以系统化、可视化的方式快速实践kimball的维度建模思想；2.从业务角度建模，不用关注物理层面的技术，让人更加专注业务的实践；3.根据业务模型(逻辑模型)自动生成相应物理模型，提高建仓的效率；4.通过版本管理来追踪模型的历史变化。
108.需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。
109.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
110.实施例2
111.图8示出了根据本实施例所述的基于业务模型构建数据仓库的装置800，该装置800与根据实施例1的第一个方面所述的方法相对应。参考图8所示，该装置800包括：数据接收模块810，用于接收与预定业务相关的第一建模参数；单元创建模块820，用于根据第一建
模参数创建业务模型单元，其中业务模型单元包括与预定业务相关的字段；物理模型构建模块830，用于构建与业务模型单元相关的物理模型，并在物理数据库中创建与物理模型对应的数据表结构；以及模型绑定模块840，用于将业务模型单元与物理模型进行绑定，实现业务模型单元与数据表结构之间的关联，从而构建基于业务模型单元的数据仓库。
112.可选地，装置800还包括：逻辑模型构建模块，用于基于业务模型单元，构建与预定业务相关的业务逻辑模型。
113.可选地，单元创建模块820，包括：第一创建子模块，用于根据第一建模参数，创建与预定业务相关的维度模型单元，其中维度模型单元包括描述用于对预定业务进行分析的维度的字段；以及第二创建子模块，用于根据第一建模参数，创建与预定业务相关的事实模型单元，其中事实模型单元包括描述与预定业务相关联的事实的字段。
114.可选地，物理模型构建模块830，包括：第一响应子模块，用于响应于创建业务模型单元的操作，构建与业务模型单元对应的物理模型；或者第二响应子模块，用于响应于接收的创建物理模型的指令，构建与业务模型单元对应的物理模型。
115.可选地，物理模型构建模块830，还包括：维度表创建子模块，用于在物理数据库中创建与维度模型单元相关的物理模型对应的维度表；以及事实表创建子模块，用于在物理数据库中创建与事实模型单元相关的物理模型对应的事实表。
116.可选地，逻辑模型构建模块，包括：数据接收子模块，用于接收用于构建业务逻辑模型的第二建模参数；逻辑模型构建子模块，用于根据第二建模参数，将维度模型单元与事实模型单元进行关联，构建业务逻辑模型。
117.可选地，维度模型单元为多个维度模型单元，并且装置还包括：关联模块，用于根据以下至少一项关联规则，将多个维度模型单元进行关联：根据多个维度模型单元的一对多关联关系，采用外键建立维度模型单元之间的关联；根据多个维度模型单元的多对多关联关系，采用桥接表建立维度模型单元之间的关联；根据多个维度模型单元的层次关联关系，采用树形桥接表建立维度模型单元之间的关联。
118.从而根据本实施例，通过装置800可以首先接收与预定业务相关的建模参数，然后根据建模参数创建包括与预定业务相关字段的业务模型单元，然后根据业务模型单元创建物理模型，最终将业务模型单元与物理模型进行绑定，构建与预定业务相关的数据仓库。从而与现有技术在物理数据库基础上使用反范式构建维度数据仓库相比，本方案可以从业务角度出发，构建业务模型，而不必受到物理数据库中的数据表的限制。即，根据本方案，可以先根据实际的业务构建业务模型单元，然后基于建立的业务模型单元(可以由系统自动或技术人员手动)构建与预定业务相关的物理模型，然后用户(业务或技术人员)就可以根据创建的业务模型对预定业务相关的数据进行分析和追溯。从而数据仓库的建模过程可以不必受到物理数据库中的数据表的限制，数据分析不再受限于技术人员。
119.由于本实施例的建模过程不是基于物理数据库采用自下而上的方法建立，而是根据业务建立业务模型单元，再根据业务模型单元由系统自动或技术人员手动建立物理模型，因此通过业务模型单元与业务的关联，实现了通过模型可以知道数据来源于那个业务过程的技术效果。进而解决了现有技术中存在的数据仓库的模型只有技术元素其只有表结构和表关系，并没有与业务关联起来，缺少业务含义，无法从模型中反映出业务关系的技术问题。
120.实施例3
121.图9示出了根据本实施例所述的基于业务模型构建数据仓库的装置900，该装置900与根据实施例1的第一个方面所述的方法相对应。参考图9所示，该装置900包括：处理器910；以及存储器920，与处理器910连接，用于为处理器910提供处理以下处理步骤的指令：接收与预定业务相关的第一建模参数；根据第一建模参数创建业务模型单元，其中业务模型单元包括与预定业务相关的字段；构建与业务模型单元相关的物理模型，并在物理数据库中创建与物理模型对应的数据表结构；以及将业务模型单元与物理模型进行绑定，实现业务模型单元与数据表结构之间的关联，从而构建基于业务模型单元的数据仓库。
122.可选地，存储器920还用于为处理器910提供处理以下处理步骤的指令：基于业务模型单元，构建与预定业务相关的业务逻辑模型。
123.可选地，根据第一建模参数，创建业务模型单元的操作，包括：根据第一建模参数，创建与预定业务相关的维度模型单元，其中维度模型单元包括描述用于对预定业务进行分析的维度的字段；以及根据第一建模参数，创建与预定业务相关的事实模型单元，其中事实模型单元包括描述与预定业务相关联的事实的字段。
124.可选地，构建与业务模型单元对应的物理模型，包括：响应于创建业务模型单元的操作，构建与业务模型单元对应的物理模型；或者响应于接收的创建物理模型的指令，构建与业务模型单元对应的物理模型。
125.可选地，在物理数据库中创建与物理模型对应的数据表结构，包括：在物理数据库中创建与维度模型单元相关的物理模型对应的维度表；以及在物理数据库中创建与事实模型单元相关的物理模型对应的事实表。
126.可选地，基于业务模型单元，构建与预定业务相关的业务逻辑模型，包括：接收用于构建业务逻辑模型的第二建模参数；根据第二建模参数，将维度模型单元与事实模型单元进行关联，构建业务逻辑模型。
127.可选地，维度模型单元为多个维度模型单元，并且方法还包括：根据以下至少一项关联规则，将多个维度模型单元进行关联：根据多个维度模型单元的一对多关联关系，采用外键建立维度模型单元之间的关联；根据多个维度模型单元的多对多关联关系，采用桥接表建立维度模型单元之间的关联；根据多个维度模型单元的层次关联关系，采用树形桥接表建立维度模型单元之间的关联。
128.从而根据本实施例，通过装置900可以首先接收与预定业务相关的建模参数，然后根据建模参数创建包括与预定业务相关字段的业务模型单元，然后根据业务模型单元创建物理模型，最终将业务模型单元与物理模型进行绑定，构建与预定业务相关的数据仓库。从而与现有技术在物理数据库基础上使用反范式构建维度数据仓库相比，本方案可以从业务角度出发，构建业务模型，而不必受到物理数据库中的数据表的限制。即，根据本方案，可以先根据实际的业务构建业务模型单元，然后基于建立的业务模型单元(可以由系统自动或技术人员手动)构建与预定业务相关的物理模型，然后用户(业务或技术人员)就可以根据创建的业务模型对预定业务相关的数据进行分析和追溯。从而数据仓库的建模过程可以不必受到物理数据库中的数据表的限制，数据分析不再受限于技术人员。
129.由于本实施例的建模过程不是基于物理数据库采用自下而上的方法建立，而是根据业务建立业务模型单元，再根据业务模型单元由系统自动或技术人员手动建立物理模
型，因此通过业务模型单元与业务的关联，实现了通过模型可以知道数据来源于那个业务过程的技术效果。进而解决了现有技术中存在的数据仓库的模型只有技术元素其只有表结构和表关系，并没有与业务关联起来，缺少业务含义，无法从模型中反映出业务关系的技术问题。
130.上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
131.在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
132.在本技术所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
133.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
134.另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
135.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
136.以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。