数据仓库模型建设规范1.0

数据仓库模型建设规范1.概述数据仓库不同于日常的信息系统开发,除了遵循其他系统开发的需求、分析、设计、测试等通常的软件生命周期之外，它还涉及到企业信息数据的集成,大容量数据的阶段处理和分层存储,数据仓库的模式选择等等,因此数据仓库的模型设计异常重要,这也是关系到数据仓库项目成败的关键。

物理模型就像大厦的基础架构,就是通用的业界标准,无论是一座摩天大厦也好,还是茅草房也好,在架构师的眼里,他只是一所建筑,地基—层层建筑—封顶,这样的工序一样也不能少,关系到住户的安全,房屋的建筑质量也必须得以保证,唯一的区别是建筑的材料,地基是采用钢筋水泥还是石头,墙壁采用木质还是钢筋水泥或是砖头;当然材料和建筑细节还是会有区别的,视用户给出的成本而定;还有不可忽视的一点是,数据仓库的数据从几百GB到几十TB不等,即使支撑这些数据的RDBMS无论有多么强大,仍不可避免地要考虑数据库的物理设计。

数据仓库建模的设计目标是模型的稳定性、自适应性和可扩展性。

为了做到这一点，必须坚持建模的相对独立性、业界先进性原则。

2.数聚模型架构在数聚项目实施过程，我们一般将数据仓库系统的数据划分为如下图所示几个层次。

2.1.数据架构图2.2.架构工作方法规范2.3.准备层L02.3.1.主要数据结构临时表：从数据源抽取，直接落地到临时表。

临时表总是保存这次抽取的数据，不保留历史数据。

也就是说，如果是全量抽取的话，就是源系统整个表的数据，如果是增量抽取的话，就是自从上次修改后的数据。

接口表：从临时表，经过清洗、转换到达接口表。

接口表保存历史数据，也就是说，如果是全量抽取的话，就是源系统整个表的数据，如果是增量抽取的话。

接口表里面也是源系统整个表的数据。

转换表：为了进行清洗和转换建立的中间辅助表。

2.3.2.命名规范临时表：L0_TMP_源系统_具体业务或 L0_TMP_业务主题_具体业务（对单一源）举例：L0_TMP_POS_SALESORDER接口表：L0_DCI_业务主题_具体业务表举例：L0_DCI_SALES_SALESORDER转换表：L0_MAP_具体业务表举例：L0_MAP_SALES2.3.3.开发工作●开发数据抽取接口，落地TMP区●开发数据清洗转换程序，落地DCI区，多源系统进行合并●开发数据装载程序，装载到L1层2.4.原子层L12.4.1.主要数据结构维度表：整个数据仓库一致的维度代码表：维度属性，非维度代码等。

原子事实表：根据业务主题，形成原子事实表汇总事实表：根据分析主题，业务主题形成合并或汇总的事实表。

2.4.2.命名规范维度表：DW_DIM_维度。

举例：组织维 DW_DIM_ORG 日期维 DW_DIM_DATE.代码表：DW_CODE_代码。

举例：性别 DW_CODE_GENDER原子事实表：L1_DW_FACT_分析主题_具体分析汇总事实表：L1_DM_FACT_分析主题_具体分析2.4.3.开发工作●维护聚集。

●衍生计算，二次指标计算。

2.5.应用层L22.5.1.主要数据结构宽表：根据需求，从L1层抽取成宽表，表现形式为固定报表，仪表盘等等。

立方体：根据分析主题，从L1生成OLAP立方体。

视图：根据需要，从L1，L0层产生L2层的视图。

前端应用，不仅仅可以利用L2层的数据结构，还可以利用L1层的数据结构。

对于源系统，还可以利用L0层的DCI区数据，可以做详单和明细查询。

2.5.2.命名规范宽表： L2_FACT_【应用主题】_【分析主题】_应用。

举例：L2_FACT_FIN_ZCFZB (财务->资产负债表)立方体：根据分析主题，从L1生成OLAP立方体。

视图：根据需要，从L1，L0层产生L2层的视图。

如明细单。

举例：L2_VIEW_原L1层表。

2.5.3.开发工作数据从L1层经过计算，汇总，根据前端分析需求，形成可以有效支撑前端应用查询的结构。

3.建模方法要成功地建立一个数据仓库，必须有一个合理的数据模型。

数据仓库建模在业务需求分析之后开始，是数据仓库构造的正式开始。

在创建数据仓库的数据模型时应考虑: 满足不同层次、用户的需求;兼顾查询效率与数据粒度的需求;支持用户需求变化;避免业务运营系统性能影响;提供可扩展性。

数据模型的可扩展性决定了数据仓库对新的需求的适应能力，建模既要考虑眼前的信息需求，也要考虑未来的需求。

目前两类主流的数据仓库模型分别是由Inmon提出的企业级数据仓库模型和由Kimball提出的多维模型。

Inmon提出的企业级数据仓库模型采用第三范式（3NF），先建立企业级数据仓库，再在其上开发具体的应用。

企业级数据仓库固然是我们所追求的目标，但在缺乏足够的技术力量和数据仓库建设经验的情况下，按照这种模型设计的系统建设过程长，周期长，难度大，风险大，容易失败。

这种模型的优点是信息全面、系统灵活。

由于采用了第三范式，数据存储冗余度低、数据组织结构性好、反映的业务主题能力强以及具有较好的业务扩展性等，但同时会存在大量的数据表，表之间的联系比较多，也比较复杂，跨表操作多，查询效率较低，对数据仓库系统的硬件性能要求高等问题。

另一方面，数据模式复杂，不容易理解，对于一般计算机用户来说，增加了理解数据表的困难。

Kimball提出的多维模型降低了范式化，以分析主题为基本框架来组织数据。

以维模型开发分析主题，这样能够快速实施，迅速获得投资回报，在取得实际效果的基础上，再逐渐增加应用主题，循序渐进，积累经验，逐步建成企业级数据仓库。

这也可以说是采用总线型结构先建立数据集市，使所有的数据集市具有统一的维定义和一致的业务事实，这种方法融合了自下而上和自上而下两种设计方法的思想。

这种模型的优点是查询速度快，做报表也快;缺点是由于存在大量的预处理，其建模过程相对来说就比较慢。

当业务问题发生变化，原来的维不能满足要求时，需要增加新的维。

由于事实表的主码由所有维表的主码组成，所以这种维的变动将是非常复杂、非常耗时的。

而且信息不够全面、系统欠灵活、数据冗余多。

本规范我们主要针对维度建模的方法来阐述规范。

3.1.维度建模多维数据建模以直观的方式组织数据，并支持高性能的数据访问。

每一个多维数据模型由多个多维数据模式表示，每一个多维数据模式都是由一个事实表和一组维表组成的。

多维模型最常见的是星形模式。

在星形模式中，事实表居中，多个维表呈辐射状分布于其四周，并与事实表连接。

位于星形中心的实体是指标实体，是用户最关心的基本实体和查询活动的中心，为数据仓库的查询活动提供定量数据。

每个指标实体代表一系列相关事实，完成一项指定的功能。

位于星形图星角上的实体是维度实体，其作用是限制用户的查询结果，将数据过滤使得从指标实体查询返回较少的行，从而缩小访问范围。

每个维表有自己的属性，维表和事实表通过关键字相关联。

使用星形模式主要有两方面的原因:提高查询的效率。

采用星形模式设计的数据仓库的优点是由于数据的组织已经过预处理，主要数据都在庞大的事实表中,所以只要扫描事实表就可以进行查询，而不必把多个庞大的表联接起来，查询访问效率较高。

同时由于维表一般都很小,甚至可以放在高速缓存中,与事实表作连接时其速度较快;便于用户理解。

对于非计算机专业的用户而言，星形模式比较直观，通过分析星形模式，很容易组合出各种查询。

3.2.建模步骤第一步：选取建模的业务过程设计过程的第一步是确定要建模的业务过程或者度量事件。

业务过程是在业务需求收集过程明确下来。

在很多的生产活动中，存在着很多价值链，这些价值链就是有一系列的业务过程来组成的。

比如在供应链管理中。

存在着下面的业务过程：原材料购买原材料交货原材料库存材料账单生产制造将产品运到仓库制成品库存客户订单为客户送货货品计价付款退货第二步：定义模型的粒度业务过程被确定下来后，就建模师就必须声明事实表的粒度。

清楚地定义事实表的行到底代表什么在提出业务过程维度模型的过程至关重要。

如果没有在事实表的粒度上达成一致，那么设计过程就不可能成功地向前推进。

第三步：选定维度一旦事实表的粒度已经稳固地确定下来，对维的选择就相当简单了。

也正是在此时，就可以开始考虑外键的问题了。

一般来说，粒度本身就能够确定一个基本或者最小的维度集合，设计过程就是在此基础上添加其他维。

这些维在已经声明的事实表粒度都有一个唯一对应的值。

第四步：确定事实四步设计过程的最后一步是仔细选择适用于业务过程的事实和指标。

事实可以从度量事件中采用物理手段捕捉，或者也可以从这些度量中导出。

对于事实表粒度来说，每个事实都是必须设计存在的，不要将那些明确声明的粒度不相匹配的其他时间段的事实或者其他细节层次的事实混杂进来。

4.维度表设计维度表包含内容：1)代理键：整型，不可重复，唯一标识每一条记录，不包含任何商业信息。

（必选）2)代理键有效开始时间和结束时间。

（必选）3)当前有效标志。

（必选）4)主键：传统意义的业务键，包含相应的商业信息，如员工编号。

（必选）5)名称：数据分析时显示的内容，如员工名称等；（必选）6)排序键：自定义序列。

（可选）7)自定义汇总：利用自定义表达式进行特定的数据运算。

可选）8)父键：父子维度中用来标识主键的上级。

（可选）9)一元运算符：在父子维度中用来定义上下级的汇总关系。

（可选）(详细)10)属性：属性包含有关维度的信息。

例如，Customer 维度可以包含 Name、PhoneNumber、Gender、City、State 等属性。

属性通过属性层次结构显示出来。

维度中的属性层次结构同时包含可选的 (All) 级别和该属性的非重复成员。

例如，Customer 维度可以包含具有两个级别的 Name 属性层次结构：(All) 级别以及为每个姓名包含一个成员的级别。

父子层次结构的处理方式有所不同。

属性不一定要具有属性层次结构。

如果未创建属性层次结构，多维数据集的空间将与属性无关。

例如，通常不会为 Phone Number 属性创建属性层次结构，因为通常不会按电话号码导航维度。

如果没有为属性创建属性层次结构，则该属性可用作成员属性，但不能用作用户层次结构中的级别。

属性可以通过前端展示软件进行展现。

（可选）11)属性层次结构：属性层次结构完全定义多维数据集的空间。

多维数据集是由多维数据集的属性层次结构的交集产生的多维空间。

（可选）4.1.时间维度时间维度是必不可少的一个维度，可以参考如下的模板：4.2.层级维度层级维度也是我们模型设计最常遇见的维度，比如组织结构，区域，产品树，行业结构等等。

在设计时，可以采用如下模板：针对数据存储时，采用自关联的结构：针对数据展现时，将自关联的结构展开，以列存储层次：根据需要可以把组织层级具体化。

4.3.缓慢变化维缓慢变化维定义数据会发生缓慢变化的维度就叫”缓慢变化维”。