数据仓库建模的几个原则,让你避开“陷阱”!

转载 2016年08月30日 17:45:51

想要数据粒度的合理性、模型的灵活性得到保证,并且能够适应未来的信息资源,需要遵守维度建模的一些原则。否则,很容易会遇到数据仓库障碍,并且把用户弄糊涂。在此,大圣众包威客平台将为你提供几个数据仓库维度建模的原则,让你妥妥地避开“陷阱”。

  1.原子数据需详细

  维度建模应该使用最基础的原子数据进行填充,以支持不可预知的来自用户查询的过滤和分组请求。

  用户通常不希望每次只看到一个单一的记录,但是你无法预测用户想要掩盖或显示哪些数据。如果只有汇总数据,那么你已经设定了数据的使用模式,当用户想要深入挖掘数据时,他们就会遇到障碍。尽管原子数据通过概要维度建模补充也是一种办法,但是这样做的话,企业用户便无法只在汇总数据上工作,毕竟,他们需要原始数据回答不断变化的问题。

  2.使用代理键

  按顺序分配代理键(除了日期维度)可以获得一系列的操作优势,包括更小的事实表、索引以及性能改善。如果你正在跟踪维度属性的变化,并需要为每个变化使用一个新的维度记录,那么代理键就显得十分重要了。因为,即使你的商业用户没有初始化跟踪属性改变的设想值,使用代理也会使下游策略变化更宽松。另外,代理也允许使用多个业务键映射到一个普通的配置文件中,这有利于缓冲意想不到的业务活动。

  3.标记和过滤范围值

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

  另外,事实表的外键不应该为空,同时在维度表的属性字段中应使用“NA”或另一个默认值来替换空值,这也是明智的,可以减少用户的困惑。

  4.一致的维度,集成整个企业的数据

  企业数据仓库一致的维度(也叫做通用维度、标准或参考维度)是最基本的原则,它在ETL系统中管理一次后,在所有事实表中都可以重用。

  一致的维度,在整个维度模型中可以获得一致的描述属性,可以支持从多个业务流程中整合数据。企业数据仓库总线矩阵是最关键的架构蓝图,它展现了组织的核心业务流程和关联的维度,重用一致的维度可以缩短产品的上市时间,也消除了冗余设计和开发过程,但一致的维度需要在数据管理和治理方面有较大的投入。

  5.围绕业务流程建模

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

  6.相同的粒度或同级的详细程度

  在组织事实表时,粒度上有三个基本原则:事务、周期快照、累加快照。无论粒度类型如何,事实表中的度量单位都必须达到相同水平的详细程度;如果事实表中的事实表现的粒度不一样,企业用户容易混淆,BI应用程序也会随之变得不堪一击,从而导致返回的结果不对等低级错误的发生。

  7.一对一的关联日期维度表

  如上文所说,每个可测量事件总有一个日期戳信息,每个事实表至少需要有一个外键,能够关联到一个日期维度表,它的粒度就是一天。这个方法,利用的是日历属性和非标准的关于测量事件日期的特性,如财务月和公司假日的指示符;当然,有时一个事实表中会有多个日期外键。

  8.解决多对一关系

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

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

  9.解决多对多关系

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

  10.平衡需求和现实,提供DW/BI解决方案

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

  总的来说,数据仓库维度建模需要注意的部分挺多,在建模的过程中务必要多留心眼,细致谨慎,这才是成功之道。尤其进入大数据时代,与数据打交道的机会愈趋增多,要想成为工作中的“常胜将军”,切忌马虎。

数据库建模原则

下述十四个技巧,是许多人在大量的数据库分析与设计实践中,逐步总结出来的。对于这些经验的运用,读者不能生帮硬套,死记硬背,而要消化理解,实事求是,灵活掌握。并逐步做到:在应用中发展,在发展中应用。 ...

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

一、前言          数据仓库存储逻辑模型设计,需要遵循一定的设计原则。遵循这些原则进行维度建模可以保证数据粒度合理,模型灵活,能够适应未来的信息资源,违反这些原则你将会把用户弄糊涂,并且会遇...

Delphi7高级应用开发随书源码

  • 2003年04月30日 00:00
  • 676KB
  • 下载

数据仓库建模与ETL的实践技巧

一、Data仓库的架构   Data仓库(Data Warehouse DW)是为了便于多维分析和多角度展现而将Data按特定的模式进行存储所建立起来的关系型Datcbase,它的Data基于O...
  • a174410
  • a174410
  • 2015年03月12日 17:50
  • 317

数据仓库的模型设计 A. 数据建模方法论 数据仓库模型设计遵循“自顶向下、逐步求精”的设计原则。 模型设计分为三个阶段: 1,概念模型 对业务的范围和使用,从高度上进行抽象概括,也就是划分主题域。 一

感谢分享!http://blog.itpub.net/23659908/viewspace-1118762/ 数据仓库的模型设计 A. 数据建模方法论 数据仓库模型设计遵循“自顶向下...

数据仓库建模_抽取技巧于心得

 源系统提供增量:方案普遍要求:源表主键1.ORACLE技术:Mv 物化视图,如果提供增量,对源表有存在主键的要求。2.ORACLE技术:Cdc,提供改动记录,可提供增删改类型。3.源系统 提供 主键...

数据仓库的逻辑建模之星型模式

逻辑建模能直接反映出决策者管理者的需求, 同时对系统的物理实施有着重要的指导作用,是数据仓库实施中的重要一环, 目前较常用的包含有星型模式。 星型模式是一种多维的数据关系,它由一个事...

数据仓库建模--不同聚合方式(聚合函数示例)

使用聚合函数 本主题包含在度量值中使用聚合函数(Sum、Min、Max、Count 和 Distinct Count)的示例。 查询示例与下列示例基于相同的多维数据集单元,以...

数据仓库维度建模笔记

数据仓库工具箱—维度建模的完全指南》是数据仓库建模方面的经典著作, 1996年第一版出版被认为是数据仓库方面具有里程碑意义的事件。作者kimballl是数据仓库方面的权威,他将多年的数据仓库建模实战经...
  • A221133
  • A221133
  • 2013年09月18日 10:14
  • 1406

<数据仓库工具箱—维度建模的完全指南>读书笔记

《数据仓库工具箱—维度建模的完全指南》是数据仓库建模方面的经典著作, 1996年第一版出版被认为是数据仓库方面具有里程碑意义的事件。作者kimballl是数据仓库方面的权威,他将多年的数据仓库建模实战...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:数据仓库建模的几个原则,让你避开“陷阱”!
举报原因:
原因补充:

(最多只允许输入30个字)