收集业务需求与数据实现
开始维度建模工作前，需要理解业务需求，作为基础的源数据的实际情况。通过与业务代表交流发现需求，理解他们的基于关键性能指标、竞争性商业问题、决策制定过程、支持分析需求的目标。同时，数据实际情况通过与源系统专家交流，构建高层次数据分析访问数据可行性来揭示。
协作维度建模研讨
维度模型由主题专家与企业数据管理代表合作设计而成。维度模型不能由不懂业务以及业务需求的人来设计，协作是成功的关键。
维度设计过程
维度模型设计主要涉及4个主要的决策：
1.选择业务过程；
2.声明粒度；
3.确认维度；
4.确认事实。
维度建模设计需要考虑业务需求以及协作建模阶段涉及的底层数据源。按照业务过程、粒度、维度、事实声明的流程，来确定表名和列名、示例领域值以及业务规则。而业务数据管理代表必须参与详细的设计活动，以确保涵盖正确的业务。
业务过程
业务过程是组织完成的操作型活动，（如，获得订单、处理保险索赔、学生课程注册或每个月每个账单的快照等）。业务过程事件是建立或获取性能度量，并转换为事实表中的事实。每一个业务过程是对应企业数据仓库总线矩阵的一行。
粒度
声明粒度是维度设计的重要步骤。粒度用于确定某一事实表中的行表示什么。粒度声明是设计必须履行合同。在选择维度或事实前必须声明粒度，因为每个候选维度或事实必须与定义的粒度保持一致。所有维度设计中强制实行一致性是保证BI应用性能和易用性的关键。在获取数据时，原子粒度是最低级别的粒度。原子粒度数据能够承受无法预期的用户查询。针对不同的事实表粒度，要建立不同的物理表，在同一事实表中不要混用多种不同的粒度。
描述环境的维度
维度提供围绕某一业务过程实际所涉及的“谁、什么、何处、”等背景。维度表包含BI应用所需要的用于过滤及分类事实的描述性属性。当与给定事实表行关联时，任何情况下都应使维度保持单一值。
维度表包含确保DW/BI系统能够被用作业务分析的入口和描述性标识。主要的工作都放在数据管理与维度表的开发方面，因为它们是用户BI经验的驱动者。
用于度量的事实
事实涉及来自业务过程事件的度量，基本上都是以数量值表示。一个事实表行与按照事实表粒度描述的度量事件之间存在一对一关系，因此事实表对应一个物理可观察的事件。所有事实只允许与声明的粒度保持一致。
星型模式与OLAP多维数据库
星型模式是部署在关系数据库管理系统（RDBMS）之上的多维结构。主要包含事实表，以及通过主键/外键关系与之关联的维度表。联机分析处理（OLAP）多维数据库是实现在多维数据库之上的多维结构，它与关系型星型模式内容等价，或者说来源于关系型星型模式。OLAP多维数据库包含维度属性和事实表，它能够使用比SQL语言具有更强的分析能力的语言访问（如，XMLA和MDX等）。OLAP多维数据库在基本技术的列表中，它通常是部署维度DW/BI系统的最后步骤，或作为一种基于多个原子关系型星型模式的聚集结构。
方便地扩展到维度模型
维度模型对数据关系发生变化具有灵活的适应性。当发生如下列举的变化时，不需要改变现存的BI查询（应用），查询结果不会发生任何改变。
1.当事实与存在的事实表粒度一致时，可以创建新列。
2.通过建立新的外键列，当维度列与事实表粒度保持一致，可以将维度关联到已经存在的事实表上。
3.可以在维度表上通过建立新列添加属性。
4.在维度表上增加属性，以更细的粒度重置事实表，小心保存事实表及维度表的列名，这样可以使事实表的粒度更原子化。
事实表技术基础
事实表结构
发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。从最低的粒度级别来看，事实表行对应一个度量事件，反之亦然。事实表的设计完全依赖于物理活动，不受可能产生的最终报表的影响。事实表包含外键，用于关联与之相关的维度，也包含可选的退化维度键和日期/时间戳。查询请求的主要目标是基于事实表开展计算和聚集操作。
可加、半可加、不可加事实
事实表中的数字度量可划分为三类。完全可加是最灵活、最有用的事实，可加性度量可以按照与事实表关联的任意维度汇总。半可加度量可以对某些维度汇总，但不能对所有维度汇总（如：差额，除了时间维度外，可以跨所有维度进行加法操作）。完全不可加有一些度量（如：比率）。对于非可加事实，尽可能存储非可加度量的完全可加分量，并在计算出结果事实前，将这些分量汇总到最终的结果集合中。最终计算通常发生在BI层或OLAP多维度数据库层。
事实表中的空值
事实表中可以存在空值度量。所有聚集函数（SUM、COUNT、MIN、MAX、AVG）均可以针对空值事实计算。但是事实表的外键不能存在空值，否则会导致违反参照完整性的情况发生。
一致性事实
不同的事实表定义是一致的，则这些一致性事实应该具有相同的命名，如果它们不兼容，则应该有不同的命名用于告诫业务用户和BI应用。
事务事实表
事务事实表的一行对应空间或时间上某点的度量事件。原子事务粒度事实表是维度化及可表达的事实表，这类维度确保对事务数据的最大化分片和分块。事务事实表可以是稠密的，也可以是稀疏的。事务事实表包含一个维度表关联的外键，可能包含时间戳和退化的维度键。度量数字事实必须与事务粒度保持一致。
周期快照事实表
周期快照事实表中每行汇总了发生在某一标准周期（如：某周，某一天等）多个度量事件。粒度是周期性的，而不是个体的事务。周期快照事实表通常包含许多事实。这些事实表其外的密度是均匀的，因为即使周期内没有活动发生，也会在事实表中为每个事实插入包含0或空值的行。
累积快照事实表
累积快照事实表的行汇总了发生在过程开始和结束之间可预测步骤内的度量事件。通常在事实表中针对过程中的关键步骤都包含日期外键。累积快照事实表中的一行，对应某一具体的订单，当订单产生时会插入一行。对累积快照事实表行的一致性修改在三种类型事实表中具有特性，除了日期外键与每个关键过程步骤关联外，累积快照事实表包含其他维度退化和可选退化维度的外键。通常包含数字化的与粒度保持一致的，符合里程碑完成计数的滞后性度量。
无事实的事实表
多数度量事件获取得结果是数字化的，但存在某些事件仅仅记录一系列某一时刻发生的多维度实体。利用无事实的事实表也可以分析发生了什么。这类查询包含两个部分：包含所有可能事件的无事实覆盖表，包含实际发生的事件的活动表。当活动从覆盖表中减除时，其结果是尚未发生的事件。
聚集事实表或OLAP多维数据库
聚集事实表是对原子粒度事实表数据进行简单的数字化上卷操作，目的是为了提高查询性能。可以同时被BI层使用。聚集事实表包含外键以缩小一致性维度，聚集事实的构建是通过对来自多个原子事实表的度量的汇总而获得。OLAP多维数据库可以被商业用户直接访问。
合并事实表
通常将来自多个过程的，以相同粒度表示的事实合并为一个单一的合并事实表，能够带来方便。合并事实表会增加ETL处理过程的负担，但降低了BI应用的分析代价。合并事实表特别适合经常需要共同分析的多过程度量。
维度表技术基础
维度表结构
维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，维度表行的描述环境应与事实表行完全对应。维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性。维度表属性是查询及BI应用的约束和分组定义的主要目标。报表的描述性标识通常是维度表属性领域值。
维度代理键
维度表中会包含一个列，表示唯一主键。该主键不是操作型系统的自然键，需要跟踪变化，若采用自然键，将需要多个维度行表示。DW/BI系统需要声明对所有维度的主键的控制，当无法采用单一的自然键或附加日期的自然键，可以为每个维度建立无语义的整型主键。这种维度代理键是按顺序分配的简单整数，以值1开始。当需要新键时，键值自动加1。
自然键、持久键和超自然键
由操作型系统建立的自然键受业务规则影响，无法被DW/BI系统控制。如，员工辞职，然后重新工作，则员工号码（自然键）可能发生变化。数据仓库希望为该员工创建单一键，需要建立新的的持久键以确保在此情况下，员工号码保持持久性不会发生变化。该键有时被称为持久性超自然键。最好的持久键其格式应该独立于原始业务过程，并以整数1开始进行分配。多个多个代理键与某一雇员关联时，若描述发生变化时，持久键不会发生变化。
