数据仓库专题(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-10-02 12:25:34

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

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

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

数据仓库专题(7)-维度建模10大基本原则

一.前言       特别声明:本文整理自互联网.        遵循这些原则进行维度建模可以保证数据粒度合理,模型灵活,能够适应未来的信息资源,违反这些原则你将会把用户弄糊涂,并且会遇到数据仓库障碍. 二.正文 原则1.载入详细的原子数据到维度结构中 维度建模应该使用最基础的原子数据进行填充,以支持不可预知的来自用户查询的过滤和分组请求,用户通常不希望每次只看到一个单一的记录,但是你无法预测 用户想要掩盖哪些数据,想要显示哪些数据,如果只有汇总数据,那么你已经设定了数据的使用模式,当用户想要深

数据仓库专题(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

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

一.前言 陆续有各位兄弟参加大讨论,提出了各种问题,关于分布式环境下,维表和事实表设计,进行了比较深入的探讨,在此汇集整理,分享给大家.希望能有更多人参与尽力啊,共同探索分布式数据仓库数据模型的设计. 二.纪要 [活跃]北京-RTB-胖哥(1106110976) 10:21:36  分布式模式下事实表设计思考: 做大做强事实表,做小做弱维表: [冒泡]杭州-电子病历<ruanjizhou@qq.com> 10:23:31  能举例子说明吗? 您这句话,我似懂非懂,但是确实在临床上又有非常多的问

数据仓库专题(10)-文本事实和杂项维度

一.杂项维度 在维度建模的数据仓库中,有一种维度叫Junk Dimension,中文一般翻译为"杂项维度".杂项维度是由操作系统中的指示符或者标志字段组合而成,一般不在一致性维度之列. 在操作系统中,我们定义好各种维度后,通常还会剩下一些在小范围内取离散值的指示符或者标志字段.例如:支付类型字段,包括现金和信用卡两种类型,在源系统中它们可能是维护在类型表中,也可能直接保存在交易表中. 一张事实表中可能会存在好几个类似的字段,如果作为事实存放在事实表中,会导致事实表占用空间过大:如果单独

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

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

数据仓库专题(9)-缓慢变化维处理技术

一.案例描述 在一个零售业数据仓库中,事实表保存着各销售人员的销售记录,某天一个销售人员从北京分公司调到上海分公司了,那么如何来保存这个变化呢?也就是说销售人员维度要怎么恰当的处理这一变化. 先来回答一个问题,为什么要处理,或保存这一变化?如果我们要统计北京地区或上海地区的总销售情况的时候,这个销售人员的销售记录应该算在北京还是算在上海?当然是调离前的算在北京,调离后的算在上海,但是如标记这个销售人员所属区域?这里就需要处理一下这个维度的数据,即我们缓慢变化维需要做的事情. 二.解决方案 2.1

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

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