matdem矩阵维度必须一致_业务分析师必须要了解的维度建模过程

业务分析，离不开维度建模，维度相当于是数据所处的环境。维度建模框架作为BI平台，是DW/BI项目成功的关键，已经得到广泛的认可。数据展现要获得成功，就必须建立在简单性的基础上，使用户能够方便地理解数据库，使软件能方便地访问数据库，维度建模就是时刻考虑如何提供简单性，坚定不移地回到业务驱动的场景，坚持以用户的可理解性和查询性能为目标，才能建立始终如一地服务于组织的分析需求的设计。

维度建模循环，是一个循序渐进的过程，如下图：

图1 - 维度建模循环

企业关键过程价值链识别

什么是关键价值链？

价值链标明了组织主要活动的自然的、逻辑的流程，通俗一点说，就是企业的主要经营活动流程，比如下图所举的零售商的例子就比较好理解了，一个企业包含了好些这样的价值链子集，这些子集的集合就构成了企业的关键过程价值链。

操作型源系统通常在价值链的每个步骤建立事务或者快照，我们要坚持让关键步骤进入系统的节点，而且是不可避开的，多数DW/BI系统的主要目标是监控关键步骤的性能结果，这样企业的关键活动都在受控中。

图2 - 零售商价值子链举例

企业的价值链弄清楚了之后，我们就可以得到具有共享维度的企业数据仓库总线图。

图3 - 具有共享维度的企业数据仓库总线

对应总线图，我们就可以得到相应的总线矩阵，这一步就是图到表的转换。矩阵的行都是组织的业务过程，矩阵的列都是企业的公共维度。

图4 - 总线矩阵

我们还能得到利益相关方矩阵，组织活动和人员都是关联的，

图5 - 利益相关方矩阵

总线矩阵选择目标业务

总线矩阵下有很多业务过程，那么我们在优先级的选择上应该将注意力集中放在两个方面，一个是容易实现，二是业务影响比较高。从以下的这个图，我们可以看到Business Plan2,Business Plan3就是我们最佳的选择，我们要把有限的资源花在最重要的事情上，这一点都是相通的。这样做还有一个好处，那就是你优先安排了领导想看的内容，而且这些内容也比较容易实现，这样不仅能避免和高层管理者产生冲突，反而较容易得到管理者的器重。

图6 - 目标业务选择

建立高层维度模型图

高层维度模型图，也叫做气泡图。我习惯用Xmind思维导图工具来做，非常方便，这一步非常有用，也一定要坚定不移的去执行，因为高层维度模型是作为内外部沟通的手段，具体体现在如下3个方面：

1. 方便设计小组内部在进入细节设计前的讨论，谋定而后动。
2. 保证每个人在被细节淹没前能够具有共同的理解，不至于在做的过程中迷失。
3. 有利于与利益相关方交流时介绍项目，项目范围及数据内容，我们不可能拿着细节的内容和管理者，业务人员及其他利益相关者进行过多的讨论，高层维度模型就是最好的一个沟通桥梁，又简练又清晰。

图7 - 高层维度模型图

我们就以上图的订单作为例子，看一下气泡图包含哪些要素：

• 气泡图图形化表示了业务过程的维度和事实表。
• 确定了事实表和与之相关的维度表的粒度。
• 粒度描述需要建模小组考虑满足业务需求需要什么以及物理数据源能够提供什么数据。
• 气泡图必须根据可用的物理数据设计。
• 总线矩阵的一行可能会用多个气泡图表示，每个气泡图对应具有特定粒度的特定事实表。
• 大多数主要的维度在确定了粒度后可以自然的获得。
• 清楚的事实表粒度声明可以精确地以图示化方法表示相关的维度。

开发详细维度模型

• 维度要解决的问题是“业务人员如何描述数据？”，常见的维度包括日期、产品、客户、员工等等。
• 事实就是对企业业务过程的台账记录，要回答的是“过程的度量是什么？”
• 详细的表设计文档包括维度表和事实表的设计
• 对模型出现的问题，我们要建立相应的问题点清单进行跟踪

图8 - 详细维度模型开发

图9 - 维度表和事实表模板

模型评审及验证

模型评审包含IT评审和业务用户评审两部分。

1. IT评审主要关注如下：

• 总线矩阵评审
• 高层模型气泡图评审
• 浏览维度和事实表工作单细节开展
• 存在问题评审

2. 业务用户评审关注点如下：

• 教育与培训
• 描述维度模型如何能够支持业务需求
• 总线矩阵评审
• 高层模型气泡图
• 评审关键维度

形成设计文档

每一个项目都得留下文档，不能“船过水无痕”，至少包括以下4个方面：

1. 项目的简短描述
2. 高层数据模型图
3. 详细的针对每个事实和维度表的维度设计工作单
4. 开放的问题点清单

这一部分是基础方法论，相当于心法部分，较为枯燥，如果能准确地把握，按照这个过程来操作，至少能保证我们不会有大的偏差，倘若我们只注重最后的结果，在过程中缺少管控，往往会出现很多问题，甚至是框架性的致命错误。