数据仓库维度建模详解：原则、结构与实践-优快云博客

本文链接：https://blog.youkuaiyun.com/HelloWowofei/article/details/132948449

数据仓库需求分析指导

简述

维度建模是一种逻辑设计技术，该技术试图采用某种直观的标准框架结构来表现数据，并且允许高性能存取。

优点：

维度建模是可预测的标准框架。允许数据库系统和最终用户查询工具在数据方面生成强大的假设条件，这些数据主要在表现和性能方面起作用。
星型连接模式的可预测框架能够忍受不可预知的用户行为变化。
具有非常好的可扩展性，以便容纳不可预知的新数据源和新的设计决策。可以很方便在不改变模型粒度情况下，增加新的分析维度和事实，不需要重载数据，也不需要为了适应新的改变而重新编码。较好的扩展性意味着以前的所有应用都可以继续运行，并不会产生不同的结果。

数据仓库总线结构

数据仓库的构建，不是一个步骤就可以建成的，也不可以将它分成孤立的片段进行建造，要使数据仓库能够长期的成功运转，很需要有一种在体系结构上可以按增量方式建造企业数据仓库的方法，当前主流的方法是：数据仓库总线结构。

1. 数据总线

总线：最初是电力行业的一个旧术语。它是一种公用结构，每个装置都与它连接，并通过它获取电力。计算机上硬件和软件也都有总线概念，正是有了总线标准，计算机的外设才能够在一起工作并且有效地共存，即使它们是在不同时间由不同厂家制作的也可以。

数据仓库总线结构提供了一种可以用于分解企业数据仓库规划任务的合理方法。在体系结构确立阶段的较短时间内，开发团队设计出一整套在企业范围内具有统一解释的标准化维度与事实。这样，数据体系结构的框架就建立起来了。然后，开发团队可以全力以赴的去实现严格依照体系结构进行迭代开发的独立数据中心。随着独立数据中心的使用，它们像积木块一样搭在了一起。一般来说，需要有足够的数据中心才可能为集成的企业数据仓库带来美好的前景。通过数据仓库环境定义标准的总线接口，独立的数据中心就可以由不同的小组在不同的时间进行实现，只要遵循这个标准，独立的数据中心就可以插入到一起并有效地共存。

多维体系结构主要包括后台（Back Room）和前台（Front Room）两部分。后台也称为数据准备区（Staging Area），是MD架构的最为核心的部件。在后台，是一致性维度的产生、保存和分发的场所。同时，代理键也在后台产生。前台是MD架构对外的接口，包括两种主要的数据集市，一种是原子数据集市，另一种是聚集数据集市。原子数据集市保存着最低粒度的细节数据，数据以星型结构来进行数据存储。聚集数据集市的粒度通常比原子数据集市要高，和原子数据集市一样，聚集数据集市也是以星型结构来进行数据存储。前台还包括像查询管理、活动监控等为了提供数据仓库的性能和质量的服务。

在多维体系结构中，所有的这些基于星型机构来建立的数据集市可以在物理上存在于一个数据库实例中，也可以分散在不同的机器上，而所有这些数据集市的集合组成的分布式的数据仓库。

如下图所示，Adventure Works Cycles的高级总线矩阵。总线矩阵的每一行代表一个业务过程，并且至少定义了一个事实表和相应的维度。通常，总线矩阵的一行会产生几个相关的事实表，由此可以从不同角度跟踪业务过程。订单业务过程可能会有行项级别的订单事务事实表和订单级别的订单快照事实表。这两种基于订单的维度模型同属于订单业务过程，这种分组称为业务过程维度模型。完全填充的企业DW/BI系统包含多个维度模型，这些模型描述了公司价值链中的所有业务过程。为总线矩阵的每一行创建业务过程维度模型，就会获得更详细的矩阵。每个维度模型都根据业务过程组合各个记录。在订单业务过程中，Order Transaction(订单事务)和Order Snapshot(订单快照)是不同的行。

图1：Adventure Works Cycles的高级总线矩阵

1. 一致性维度

一致性维度在数据仓库总线中的作用：奠基石。

一致性维度：要么是同一的，要么是具有最佳粒度性与细节性的维度在严格数学意义上的子集。

一致性维度的三种基本的交付步骤。数据整合的关键就是生成一致性维度，再通过一致性维度将来自不同数据源的事实数据合并到一起，供分析使用。通常来说，生成一致性维度有如下三个步骤：

标准化（Standardizing）

标准化的目的是使不同数据源的数据编码方式，数据格式等相同，为下一步数据匹配打下基础。

匹配（Matching and Deduplication）

数据匹配的工作有两种，一种是将不同数据源的标识同一事物的不同属性匹配到一起，是数据更完善；另一种是将不同数据源的相同数据标识成重复，为下一步的筛选打下基础。

筛选（Surviving）

数据筛选的主要目的是选定一致性维度作为主数据（Master Data），也就是最终交付的一致性维度数据。

1. 一致性事实

在kimball的维度建模的数据仓库中，关于多维体系结构有三个关键性概念：总线架构（Bus Architecture），一致性维度（Conformed Dimension）和一致性事实（ConformedFact）。

在建立多个数据集市时，完成一致性维度的工作就已经完成了一致性的80%－90%的工作量。余下的工作就是建立一致性事实。

一致性事实和一致性维度有些不同，一致性维度是由专人维护在后台（Back Room），发生修改时同步复制到每个数据集市，而事实表一般不会在多个数据集市间复制。需要查询多个数据集市中的事实时，一般通过交叉探查（drill across）来实现。

为了能在多个数据集市间进行交叉探查，一致性事实主要需要保证两点。第一个是KPI的定义及计算方法要一致，第二个是事实的单位要一致性。如果业务要求或事实上就不能保持一致的话，建议不同单位的事实分开建立字段保存。

这样，一致性维度将多个数据集市结合在一起，一致性事实保证不同数据集市间的事实数据可以交叉探查，一个分布式的数据仓库就建成了。

维度模型的设计过程

设计会话中的第一项任务是为最高优先级的业务过程创建高级维度模型。高级维度模型是实体级别上的数据模型，可以直接从总线矩阵中开始建模。在其设计过程中可能还包括一些实用程序表，如查找表或用户层次结构等，但是通常这些表直到建模过程的最后阶段才会出现。这个设计过程通常需要4步。

1. 步骤1：标识业务过程

换言之，应从总线矩阵中的哪一行开始？在大多数情况下，我们已经知道设定优先级过程的结果是哪个业务过程，即总线矩阵中优先级最高的行。

1. 步骤2：声明粒度

粒度是在事实表中捕获的细节的级别。我们的目标是描述一个事实记录的含义。描述方式是："在事实表中，每个X对应一行记录"，X代表一个业务事件，确定该业务事件就是一个很好的起点。例如其答案可能是订单中的每一项对应一行记录，每个顾客呼叫对应一行记录，或者每个雇员状态变化对应一行记录。这是微妙而重要的一步。如果不清楚这个粒度，事实表就可能捕获不到原子级别的数据，从而降低灵活性。确保粒度声明不是一组维度。这就进入到下一步。粒度是一个业务事件。

1. 步骤3：选择维度

现在问自己一个问题：在所声明的粒度上，哪些对象参与了目标业务过程？答案大多直接来自于您对业务过程的理解，总线矩阵应指出其起点。列出维度的同时，也可开始列出与每个维度相关的所有属性。这有助于引用用户信息请求和源系统模型，以验证维度及其属性的选择是否正确。

1. 步骤4：选择事实

事实是所选业务过程的度量。通常有一组事实由支持该业务过程的源系统直接度量，另一组事实派生于基本事实。确保事实对应于所选的粒度。

1. 高级图形模型

在称作高级图形模型(或者简称气泡图)的可交付产品中，图形化地汇总初始设计会话。图2中的模型是根据前面章节中总线矩阵设计的Adventure Works Cycles订单业务过程的起始维度模型示例。

图2：初始Adventure Works Cycles高级订单维度模型

维度建模的10大基本原则

遵循这些原则进行维度建模可以保证数据粒度合理，模型灵活，能够适应未来的信息资源，违反这些原则你将会把用户弄糊涂，并且会遇到数据仓库障碍。

1. 原则1、载入详细的原子数据到维度结构中

维度建模应该使用最基础的原子数据进行填充，以支持不可预知的来自用户查询的过滤和分组请求，用户通常不希望每次只看到一个单一的记录，但是你无法预测用户想要掩盖哪些数据，想要显示哪些数据，如果只有汇总数据，那么你已经设定了数据的使用模式，当用户想要深入挖掘数据时他们就会遇到障碍。当然，原子数据也可以通过概要维度建模进行补充，但企业用户无法只在汇总数据上工作，他们需要原始数据回答不断变化的问题。

1. 原则2、围绕业务流程构建维度模型

业务流程是组织执行的活动，它们代表可测量的事件，如下一个订单或做一次结算，业务流程通常会捕获或生成唯一的与某个事件相关的性能指标，这些数据转换成事实后，每个业务流程都用一个原子事实表表示，除了单个流程事实表外，有时会从多个流程事实表合并成一个事实表，而且合并事实表是对单一流程事实表的一个很好的补充，并不能代替它们。

1. 原则3、确保每个事实表都有一个与之关联的日期维度表

原则2中描述的可测量事件总有一个日期戳信息，每个事实表至少都有一个外键，关联到一个日期维度表，它的粒度就是一天，使用日历属性和非标准的关于测量事件日期的特性，如财务月和公司假日指示符，有时一个事实表中有多个日期外键。

1. 原则4、确保每个事实表中的事实具有相同的粒度或同级的详细程度

在组织事实表时粒度上有三个基本原则：事务，周期快照或累加快照。无论粒度类型如何，事实表中的度量单位都必须达到相同水平的详细程度，如果事实表中的事实表现的粒度不一样，企业用户会被搞晕，BI应用程序会很脆弱，或者返回的结果根本就不对。

1. 原则5、解决事实表中的多对多关系

由于事实表存储的是业务流程事件的结果，因此在它们的外键之间存在多对多(M:M)的关系，如多个仓库中的多个产品在多天销售，这些外键字段不能为空，有时一个维度可以为单个测量事件赋予多个值，如一个保健对应多个诊断，或多个客户有一个银行账号，在这些情况下，它的不合理直接解决了事实表中多值维度，这可能违反了测量事件的天然粒度，因此需要使用多对多，双键桥接表连接事实表。

1. 原则6、解决维度表中多对一的关系

属性之间分层的、多对一(M：1)的关系通常未规范化，或者被收缩到扁平型维度表中，如果你曾经有过为事务型系统设计实体关系模型的经历，那你一定要抵抗住旧有的思维模式，要将其规范化或将M:1关系拆分成更小的子维度，维度反向规范化是维度建模中常用的词汇。

在单个维度表中多对一(M:1)的关系非常常见，一对一的关系，如一个产品描述对应一个产品代码，也可以在维度表中处理，在事实表中偶尔也有多对一关系，如详细当维度表中有上百万条记录时，它推出的属性又经常发生变化。不管怎样，在事实表中要慎用M:1关系。

1. 原则7、存储报告标记和过滤维度表中的范围值

更重要的是，编码和关联的解码及用于标记和查询过滤的描述符应该被捕获到维度表中，避免在事实表中存储神秘的编码字段或庞大的描述符字段，同样，不要只在维度表中存储编码，假定用户不需要描述性的解码，或它们将在BI应用程序中得到解决。如果它是一个行/列标记或下拉菜单过滤器，那么它应该当作一个维度属性处理。

尽管我们在原则5中已经陈述过，事实表外键不应该为空，同时在维度表的属性字段中使用“NA”或另一个默认值替换空值来避免空值也是明智的，这样可以减少用户的困惑。

1. 原则8、确定维度表使用了代理键

按顺序分配代理键(除了日期维度)可以获得一系列的操作优势，包括更小的事实表、索引以及性能改善，如果你正在跟踪维度属性的变化，为每个变化使用一个新的维度记录，那么确实需要代理键，即使你的商业用户没有初始化跟踪属性改变的设想值，使用代理也会使下游策略变化更宽松，代理也允许你使用多个业务键映射到一个普通的配置文件，有利于你缓冲意想不到的业务活动，如废弃产品编号的回收或收购另一家公司的编码方案。

1. 原则9、创建一致的维度集成整个企业的数据

对于企业数据仓库一致的维度(也叫做通用维度、标准或参考维度)是最基本的原则，在ETL系统中管理一次，然后在所有事实表中都可以重用，一致的维度在整个维度模型中可以获得一致的描述属性，可以支持从多个业务流程中整合数据，企业数据仓库总线矩阵是最关键的架构蓝图，它展现了组织的核心业务流程和关联的维度，重用一致的维度可以缩短产品的上市时间，也消除了冗余设计和开发过程，但一致的维度需要在数据管理和治理方面有较大的投入。

1. 原则10、不断平衡需求和现实，提供用户可接受的并能够支持他们决策的DW/BI解决方案

维度建模需要不断在用户需求和数据源事实之间进行平衡，才能够提交可执行性好的设计，更重要的是，要符合业务的需要，需求和事实之间的平衡是DW/BI从业人员必须面对的事实，无论是你集中在维度建模，还是项目策略、技术/ETL/BI架构或开发/维护规划都要面对这一事实。

推荐书籍

《数据仓库工具箱—维度建模的完全指南》是数据仓库建模方面的经典著作， 1996年第一版出版被认为是数据仓库方面具有里程碑意义的事件。作者kimballl是数据仓库方面的权威，他将多年的数据仓库建模实战经验、技巧融入本书。他提出的许多维度建模概念被广泛应用于数据仓库的设计和开发中。2002年本书出版了第二版。2015年本书出版了第三版采用新的思路和实践对上一版本进行了全面修订，给出了设计维度模型的全面指南，既适合数据仓库新手，也适合经验丰富的专业人员。

《Star Schema完全参考手册:数据仓库维度设计权威指南》全面、深入地介绍了设计原理及其理论基础。全书围绕设计概念组织并辅以详实的示例，可作为初学者逐步深入学习星型模式的参考资料，同时也为专家提供了内容丰富的参考资源。《Star Schema完全参考手册:数据仓库维度设计权威指南》首先介绍维度设计的基础知识，向读者展示如何将这些基础应用于不同的数据仓库体系结构，包括W.H.Inmon并HRalph Kimball倡导的体系结构。《Star Schema完全参考手册:数据仓库维度设计权威指南》通过介绍一系列高级技术来帮助读者解决现实世界中存在的复杂性，获得最佳性能并适应商业智能和ETL软件产品的需求。读者可以将书中的设计任务和设计产品运用于所有项目中，而无论项目采用什么方法和架构。

数据仓库模型设计人员和ETL开发工程师必须深入阅读和理解这两本书中设计方法和理念。

参考说明：