数据仓库专题(23):总线矩阵的另类应用-Drill Down into a More Detailed Bus Matrix

一、前言

Many of you are already familiar with the data warehouse bus architecture and matrix given their central role in building architected data marts. The corresponding bus matrix identifies the key business processes of an organization, along with their associated dimensions. Business processes (typically corresponding to major source systems) are listed as matrix rows, while dimensions appear as matrix columns. The cells of the matrix are then marked to indicate which dimensions apply to which processes.

In a single document, the data warehouse team has a tool for planning the overall data warehouse, identifying the shared dimensions across the enterprise, coordinating the efforts of separate implementation teams, and communicating the importance of shared dimensions throughout the organization. We firmly believe drafting a bus matrix is one of the key initial tasks to be completed by every data warehouse team after soliciting the business’ requirements.

二、面临问题

While the matrix provides a high-level overview of the data warehouse presentation layer “puzzle pieces” and their ultimate linkages, it is often helpful to provide more detail as each matrix row is implemented. Multiple fact tables often result from a single business process. Perhaps there’s a need to view business results in a combination of transaction, periodic snapshot or accumulating snapshot perspectives. Alternatively, multiple fact tables are often required to represent atomic versus more summarized information or to support richer analysis in a heterogeneous product environment.

三、解决方案

We can alter the matrix’s “grain” or level of detail so that each row represents a single fact table (or cube) related to a business process. Once we’ve specified the individual fact table, we can supplement the matrix with columns to indicate the fact table’s granularity and corresponding facts (actual, calculated or implied). Rather than merely marking the dimensions that apply to each fact table, we can indicate the dimensions’ level of detail (such as brand or category, as appropriate, within the product dimension column).

 四、总结

The resulting embellished matrix provides a roadmap to the families of fact tables in your data warehouse. While many of us are naturally predisposed to dense details, we suggest you begin with the more simplistic, high-level matrix and then drill-down into the details as each business process is implemented. Finally, for those of you with an existing data warehouse, the detailed matrix is often a useful tool to document the “as is” status of a more mature warehouse environment.

时间: 2024-08-01 22:36:50

数据仓库专题(23):总线矩阵的另类应用-Drill Down into a More Detailed Bus Matrix的相关文章

数据仓库专题(22):总线架构和维度建模优势-杂项

一.总线架构 维度建模的数据仓库中,有一个概念叫Bus Architecture,中文一般翻译为“总线架构”.总线架构是Kimball的多维体系结构(MD)中的三个关键性概念之一,另两个是一致性维度(Conformed Dimension)和一致性事实(Conformed Fact). 在多维体系结构(MD) 的数据仓库架构中,主导思想是分步建立数据仓库,由数据集市组合成企业的数据仓库.但是,在建立第一个数据集市前,架构师首先要做的就是设计出在整个企业 内具有统一解释的标准化的维度和事实,即一致

数据仓库专题(4)-分布式数据仓库事实表设计思考---讨论精华

一.前言 上一篇分享博文<数据仓库专题(3)--分布式数据仓库事实表设计思考>后,陆续有各位兄弟参加大讨论,提出了各种问题,关于分布式环境下,维表和事实表设计,进行了比较深入的探讨,在此汇集整理,分享给大家.希望能有更多人参与尽力啊,共同探索分布式数据仓库数据模型的设计. 二.纪要 [活跃]北京-RTB-胖哥(1106110976) 10:21:36 分布式模式下事实表设计思考: 做大做强事实表,做小做弱维表: [冒泡]杭州-电子病历<[email protected]> 10:2

数据仓库专题(2)-Kimball维度建模四步骤

一.前言 四步过程维度建模由Kimball提出,可以做为业务梳理.数据梳理后进行多维数据模型设计的指导流程,但是不能作为数据仓库系统建设的指导流程.本文就相关流程及核心问题进行解读. 二.数据仓库建设流程 以下流程是根据业务系统.组织结构.团队结构现状设定的数据仓库系统建设流程,适合系统结构复杂,团队协作复杂,人员结构复杂的情况,并且数据仓库建设团队和业务系统建设团队不同的情况.具体流程如下图所示: 图1 数据仓库系统建设流程 三.四步维度建模 Kimball四步建模流程适合上述数据仓库系统建设

数据仓库专题(21):Kimball总线矩阵说明-官方版

一.前言 Over the years, I have found that a matrix depiction of the data warehouse plan is a pretty good planning tool once you have gathered the business requirements and performed a full data audit. This matrix approach has been exceptionally effectiv

数据仓库专题(5)-如何构建主题域模型原则之站在巨人的肩上(一)IBM-FSDM主题域模型划分

一.前言 如何构建主题域模型原则是构建企业级数据仓库重要的议题,最好的路径就是参照成熟的体系.IBM金融数据模型数据存储模型FSDM,是金融行业应用极为广泛的数据模型,可以作为我们构建企业级数据仓库主题域模型划分的重要依据.本文就IBM FSDM主题域模型进行初步的介绍. 二.模型结构 三.标准定义 关系人 IP 银行的业务开展过程中的相关各方,个人.机构.柜员.. 合约 AR 参与者之间达成的 合约.合同.协议等 条件 CD 描述银行的业务正常开展,所需要的前提条件.资格标准和要求 产品 PD

数据仓库专题(3)-分布式数据仓库事实表设计思考

一.前言 最近在设计数据仓库的数据逻辑模型,考虑到海量数据存储在分布式数据仓库中的技术架构模式,需要针对传统的面相关系型数据仓库的数据存储模型进行技术改造.设计出一套真正适合分布式数据仓库的数据存储模型. 二.事实表设计基础 事实表记录发生在现实世界中的操作型事件,其所产生的可度数值.事实表的设计完全依赖于物理活动,不受可能产生的最终报表的影响.事实表中,除数字度量外,事实表总是包含外键,用于关联与之相关的维度,也可以包含退化的维度键和日期/时间戳. 三.传统模式 以FS-LDM数据存储模型Ev

数据仓库专题(1)-数据仓库生命周期模型

一.前言 工作内容的变更,导致重新回到数据仓库模型的架构和设计,于是花点时间比较系统的回顾数据仓库建模和系统建设的知识体系,记录下来,作为笔记吧. 二.模型 无论数据仓库技术如何变化,从RDBMS到NoSQL,从传统技术到大数据,其实只是实现技术手段的变化,数据仓库建设生命周期的模式从来都不曾真正颠覆性改变过.向前辈致敬.下图是The Kimball Lifecycle diagram中文版本: 三.未完待续 后续考虑根据项目的实施,分环节,从实践角度,记录分享点滴,算是我的工作笔记吧. 另外项

数据仓库专题(6)-数据仓库、主题域、主题概念与定义

一.数据仓库 关于数据仓库概念的标准定义业内认可度比较高的,是由数据仓库之父比尔·恩门(Bill Inmon)在1991年出版的"Building the Data Warehouse"(<建立数据仓库>)一书中所提出: 中文定义:数据仓库是一个面向主题的.集成的.相对稳定的.反映历史变化的数据集合,用于支持管理决策. 英文定义:A data warehouse is a subject-oriented, integrated, nonvolatile, and time

数据仓库专题(16)-分布式数据仓库实践指南-目录篇

前言: 准备系统化整理一套分布式数据仓库建模实践指南,先把目录列出来吧,算是给自己设计一个目标吧. 第一部分 基础篇 第一章 数据仓库概念与定义 1.1 数据管理体系 1.2 数据仓库概念 1.3 数据仓库职责 第二章 数据仓库体系结构 2.1 Inmon CIF 2.2 Kimball 2.3 对于与分析 第三章 维度建模基础 3.1 kimball四步建模法 3.2 维度设计 3.3 事实表设计 第二部分 实践篇 第一章 路线图 第二章 业务分析-深浅有度 第三章 数据分析-区别对待 第四章