几个让你避免“陷阱”的数据仓库原则

想要数据粒度的合理性、模型的灵活性得到保证，并且能够适应未来的信息资源，需要遵守维度建模的一些原则。否则，很容易会遇到数据仓库障碍，并且把用户弄糊涂。

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

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

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

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

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

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

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

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

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

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

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