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

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架构，或开发/维护规划，都要面对这一事实。

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

（更多大数据与商业智能领域干货、兼职机会请关注大圣众包平台，或添加大圣花花个人微信号（dashenghuaer)，拉你入bigdata&BI交流群330648564。)