原则1
载入详细的原子数据到维度结构中
维度建模应该使用最基础的原子数据进行填充，以支持不可预知的来自用户查询的过滤和分组请求，用户通常不希望每次只看到一个单一的记录，但是你无法预测 用户想要掩盖哪些数据，想要显示哪些数据，如果只有汇总数据，那么你已经设定了数据的使用模式，当用户想要深入挖掘数据时他们就会遇到障碍。当然，原子数据也可以通过概要维度建模进行补充，但企业用户无法只在汇总数据上工作，他们需要原始数据回答不断变化的问题。
原则2
围绕业务流程构建维度模型
业务流程是组织执行的活动，它们代表可测量的事件，如下一个订单或做一次结算，业务流程通常会捕获或生成唯一的与某个事件相关的性能指标，这些数据转换成事实后，每个业务流程都用一个原子事实表表示，除了单个流程事实表外，有时会从多个流程事实表合并成一个事实表，而且合并事实表是对单一流程事实表的一 个很好的补充，并不能代替它们。
原则3
确保每个事实表都有一个与之关联的日期维度表
原则2中描述的可测量事件总有一个日期戳信息，每个事实表至少都有一个外键，关联到一个日期维度表，它的粒度就是一天，使用日历属性和非标准的关于测量事件日期的特性，如财务月和公司假日指示符，有时一个事实表中有多个日期外键。
原则4
确保每个事实表中的事实具有相同的粒度或同级的详细程度
在组织事实表时粒度上有三个基本原则：事务，周期快照或累加快照。无论粒度类型如何，事实表中的度量单位都必须达到相同水平的详细程度，如果事实表中的事实表现的粒度不一样，企业用户会被搞晕，BI应用程序会很脆弱，或者返回的结果根本就不对。
原则5
解决事实表中的多对多关系
由于事实表存储的 是业务流程事件的结果，因此在它们的外键之间存在多对多(M:M)的关系，如多个仓库中的多个产品在多天销售，这些外键字段不能为空，有时一个维度可以为单个测量事件赋予多个值，如一个保健对应多个诊断，或多个客户有一个银行账号，在这些情况下，它的不合理直接解决了事实表中多值维度，这可能违反了测量事件的天然粒度，因此我们使用多对多，双键桥接表连接事实表。
原则6
解决维度表中多对一的关系
属性之间分层的、多对一(M：1)的关系通常未规范化，或者被收缩到扁平型维度表中，如果你曾经有过为事务型系统设计实体关系模型的经历，那你一定要抵抗住旧有的思维模式，要将其规范化或将M:1关系拆分成更小的子维度，维度反向规范化是维度建模中常用的词汇。在单个维度表中多对一(M:1)的关系非常常见，一对一的关系，如一个产品描述对应一个产品代码，也可以在维度表中处理，在事实表中偶尔也有多对一关系，如详细当维度表中有上百万条记录时，它推出的属性又经常发生变化。不管怎样，在事实表中要慎用M:1关系。
原则7
存储报告标记和过滤维度表中的范围值
更重要的是，编码和关联的解码及用于标记和查询过滤的描述符应该被捕获到维度表中，避免在事实表中存储神秘的编码字段或庞大的描述符字段，同样，不要只 在维度表中存储编码，假定用户不需要描述性的解码，或它们将在BI应用程序中得到解决。如果它是一个行/列标记或下拉菜单过滤器，那么它应该当作一个维度属性处理。尽管我们在原则5中已经陈述过，事实表外键不应该为空，同时在维度表的属性字段中使用“NA”或另一个默认值替换空值来避免空值也是明智的，这样可以减少用户的困惑。
原则8
确定维度表使用了代理键
按顺序分配代理键(除了日期维度)可以获得一系列的操作优势，包括更小的事实表、索引以及性能改善，如果你正在跟踪维度属性的变化，为每个变化使用一个 新的维度记录，那么确实需要代理键，即使你的商业用户没有初始化跟踪属性改变的设想值，使用代理也会使下游策略变化更宽松，代理也允许你使用多个业务键映射到一个普通的配置文件，有利于你缓冲意想不到的业务活动，如废弃产品编号的回收或收购另一家公司的编码方案。
原则9
创建一致的维度集成整个企业的数据
对于企业数据仓库一致的维度(也叫做通用维度、标准或参考维度)是最基本的原则，在ETL系统中管理一次，然后在所有事实表中都可以重用，一致的维度在 整个维度模型中可以获得一致的描述属性，可以支持从多个业务流程中整合数据，企业数据仓库总线矩阵是最关键的架构蓝图，它展现了组织的核心业务流程和关联的维度，重用一致的维度可以缩短产品的上市时间，也消除了冗余设计和开发过程，但一致的维度需要在数据管理和治理方面有较大的投入。
原则10
不断平衡需求和现实，提供用户可接受的并能够支持他们决策的DW/BI解决方案
维度建模需要不断在用户需求和数据源事实之间进行平衡，才能够提交可执行性好的设计，更重要的是，要符合业务的需要，需求和事实之间的平衡是DW/BI 从业人员必须面对的事实，无论是你集中在维度建模，还是项目策略、技术/ETL/BI架构或开发/维护规划都要面对这一事实。
