维度建模是DW/BI系统的核心，他是ETL系统的目标、数据库的结构、支持用户查询和制作报表的模型。建模要实现3个主要设计目标，分别是：能尽可能简洁的向用户展示需要的信息；能尽快返回查询结果给用户；能提供相关信息，以便精确的跟踪潜在的业务过程。
维度建模能使任何事情尽可能简单，但绝不是简化。在数据仓库和商业智能中，维度模型是给用户显示信息的首选结构，其比典型的原系统规范化模型更便于用户理解。维度建模中表更少，信息分组为对用户有意义的、一致的业务类别。这些类别称为维度，有助于用户浏览模型，因为可以忽略与特定分析无关的全部类别。但是尽可能简洁并不意味着模型一定简单。模型必须反映业务，而业务通常都比较复杂，如果简化的过多，一般来说只表示了聚合数据，模型就会丢失对理解业务非常重要的信息。无论如何进行数据建模，数据内容在的复杂性都使大多数人最终愿意通过结构化报表和分析应用程序来访问DW和BI系统。
维度建模能提供更好的查询性能，因为在创建维度时采用了反规范化的方法，通过预先连接各种层次结构和查询表，优化程序考虑的连接路径较少，创建的中间临时表更少。
为了精确跟踪潜在的业务过程，需要采用各种设计模式，以创建出精确捕获和跟踪业务模型。维度模型由一个或者多个中心事实表和与其相关的维度构成。事实表位于中心，而维度环绕在其周围，类似于星型结构，因此又把维度模型成为星型模型。
一、维度建模概念
1、事实表
事实表是维度模型的基本表，存放有大量的业务性能度量值。应力图将从一个业务处理过程得到的度量值数据存放在单个数据中心。由于度量值数据压倒性的成为任何数据中心的最大部分，因此应该避免在企业范围内的不同地方存储其拷贝。用术语“事实”代表一个业务度量值。例如：商品销售记录每个商店每种产品的销售数量和销售额。在各维度值（日期、产品和商店）的交叉点就可以得到一个度量值。维度值的列表给出了一个事实表的粒度定义，并确定出度量值的取值范围是什么。
事实表的设计中要解决几个重要问题：
- 粒度（记录事实的细节级）：事实表中包含信息的详细程度称为粒度。强烈建议以原始来源中可能的最小细节级别构建事实表--通常称为原子级别。原子事实表提供了完整的灵活性，数据可以累积到现在或将来任何维度需要的任何聚合级别。每个事实表必须只有一种粒度。例如，如果在同一事实表中包含每月预测项和单独的销售订单项，就很容易引起混淆并产生危险。
- 相加性：事实的可加性是至关重要的，因为数据仓库应用几乎从不仅仅只检索事实表的单行数据。相反，往往一次性带回数百、数千乃至数百万行的事实，并且处理这么多行的最有用的事就是将它们加起来。但是有些事实是半加性质的，而另外一些是非加性质的。半加性事实仅仅沿某些维度相加，而非加性事实根本就不能相加。对于非加性事实，如果希望对其进行总结就不得不使用计数或平均数，或者降为一次一行的打印出全部事实行。对这长达数十亿行的事实表来说，将是一个迟缓而乏味的工作。
- 文本度量值：度量事实在理论上可以是文本形式的，文本度量可以是某种事物的描述。但是设计者应该尽量将文本度量转换成维度，原因在于维度能够与其他文本维度属性更有效关联起来，并且消耗少的多的空间。不能将冗余的文本信息存放在事实表内。除非文本对于事实表的每行来说都是唯一的，负责他应该归属到维度表中。真正的文本事实在数据仓库中很少出现，因为文本事实具有像自由文本内容那样不可预见性，这几乎是不可能进行分析的。
- 键选择：多维数据建模中的键选择是一个难题。它包含性能和易于管理之间的权衡（trade-off）。键选择主要适用于维度。您为维度所选择的键必须是事实的外键。维度键有两种选择：您可以分配一个任意键，或者使用操作系统中的标识符。任意键通常只是一个序列号，当需要一个新键时，就分配下一个可用的号码。【为了使用操作系统中的标识符惟一地表示维度，您有时需要使用一个复合键。复合键就是由多个列组成的键。任意键是一列，通常比操作派生的键要小。因此，任意键通常可以更快地执行连接。】【键选择中的最后一个因素就是它对事实表的影响。在创建事实时，必须将每个维度的键分配给它。如果维度将带有时间戳的操作派生的键用于历史数据，那么在创建事实时，就没有附加工作。连接将自动发生。对于任意键或任意历史标识符，在创建事实时，就必须将一个键分配给事实。】【分配键的方式有两种。一种就是维护操作和数据仓库的键的转换表。另一种就是存储操作键，并且在必要时，存储时间戳作为维度上的属性数据。】【那么，选择就在任意键的更好性能和操作键的更易维护之间进行。性能提高多少和维护增加多少的问题就必须在您自己的组织中进行评估了。】【无论做出什么选择，都必须在元数据中用文档记录生成它们的过程。该信息对于管理和维护数据仓库的技术人员来说是必要的。如果您所使用的工具没有隐藏连接处理，那么用户可能也需要理解这一点。】
2、维度表
维度表包含有业务的文字描述。在一个设计合理的维度模型中，维度表有许多列或者属性，这些属性给出对维度表的行所进行的描述。维度表倾向于将列数做的特别大，每个维度用单一的主关键字进行定义，主关键字是确保同与之相连的任何事实表之间存在应用完整性的基础。
维度属性是查询约束条件、成组与报表标签生成的基本来源。例如，一个用户要按照“星期”和“商标”来查看销售额，那么“星期”与“商标”就必须是可用的维度属性。数据仓库的能力直接与维度属性的质量和深度成正比。在提供详细的业务用语属性方面所化的时间越多，数据仓库就越好。在属性列值的给定方面所花的时间越多，数据仓库就越好。在保证属性列值的质量方面所花的时间越多，数据仓库就越好。
最好的属性是文本的和离散的。属性应该是真正的文字而不应是一些编码简写符号。例如：对于产品来说，典型的属性应该包括一个短描述、一个长描述、一个商标名、一个分类名、包装类型、尺寸以及大量其他产品特征等方面的内容。
维度表时常描述业务中的层次关系。例如：产品划分为商标、然后是分类。产品维度的每行都存放有与产品有关的商标和分类。但是存放层次描述信息显得很冗余， 不过也是基于容易使用和查询性能方面的考虑才这样做的。不要受仅仅存储商标编码并为其建立一个单独的商标查询表的固有想法所限制，这种形式可以称为雪花。维度表一般是很不规范的，通常也非常小。既然维度表一般都很小，通过规范化或者雪花来提高存储效率的做法也起不了大作用，所以实际应用中，几乎总是用维度表的空间来换取简明性和可访问性。
3、事实与维度的融合
由数字型度量值组成的事实表连接到一组填满描述属性的维度表上。这个星型特征结构通常被叫做星型连接方案。关于维度方案，应该注意第一件事就是其简明性与对称性。简明性是指用户可以很容易的理解和浏览数据；简明性也提升了性能上的好处，仓库在处理时首先对维度表进行过滤处理，然后用满足用户约束条件的维度表关键字的笛卡尔乘积一次性处理全部的事实表。
维度表模型能够很自然的进行扩展以适应变化的需求。维度模型的可预订框架能够经受住无法预见的用户行为变化所带来的考验。每个维度都是平等的，所有维度都是进入事实表的对等入口。每个逻辑模型不存在内置的关于某种期望的查询形式方面的偏向，不存在这个月要问的业务问题相对于下个月来说具有优化方面的考虑。没有谁希望，如果业务用户采用新的方式进行业务分析，就要调整设计方案这样的事情发生。维度模型的事实与维度表如下：
在设计过程中，最佳粒度或者原子数据具有最佳的维度。被聚合起来的原子数据是最有表现力的数据。原子数据应该成为每个事实表设计的基础。从而经受住业务用户无法预见的查询所引起的特别攻击。对于维度模型来说，完全可以向方案中加入新的维度，只要其值对于每个现有的事实行存在唯一性定义就行。同样，可以向事实表加入新的不曾预料到的事实，只要其详细程度与现有事实表处在一致的水平面上就可以了。可以用新的不曾预料到的属性补充先前存在的维度表，也可以从某个前向时间点的角度在一个更低的粒度层面上对现存维度进行分解。在每种情况下，可以简单的在表中加入新的数据行或者对现在表进行适当的修改。
认识事实与维度表之间互补性的另外一种方式是在所形成的报表中了解他们。如上图，维度属性提供了生成报表标签的内容，而事实表则提供了报表的数字型取值。
最后就像已经强调的那样，展示环节的数据应该是维度形式的。不过，维度模型与规范化模型之间存在着一种自然的关系。理解这种关系的关键在于认识到，单个规范化ER图通常分解为多个维度方案。为机构建立的大型规范化模型可以将电话销售、订购单、装货发票、顾客付款、产品利润等内容全部放在一个图中。在某种程度上讲，规范化ER图对自身就是一种伤害，原因在于他将许多从来就不会出现在单个数据集中的多个业务处理放在了单张绘制图中。可见，规范化模型看起来很复杂，是不足为奇的。
如果有一张已经存在的规范化ER图，将它转换为一组维度模型的第一步是，将ER图分成一些分散的业务处理过程，然后分别单独建模。第二步是选出ER图中那些含有数字型与可加性非关键字事实的多对多关系，并将他们标记为事实表。最后一步是，将剩下的所有表复合成具有直接连接到事实表的单连关键字的平面表，这些表就成为维度表。
二、维度建模的设计过程
维度建模具有一定顺序，分别是：①业务处理②粒度③维度④事实。
1、选取业务处理
业务处理过程是机构中进行的一般都是有源系统提供支持的自然业务活动。听取用户的意见是选取业务处理过程的效率最高的方式。在选取业务阶段，数据模型设计者需要有全局和发展的视角，应该理解整体业务流程的基础上，从全局角度选取业务处理。
要记住的重要一点是，这里谈到的业务处理并不是指业务部门或者职能。通过将注意力集中放在业务处理过程方面，就能在机构范围内更加经济的提交一致的数据。如果建立的维度模型是同部门捆绑在一起的，就无法避免出现具有不同标记与术语的数据拷贝的可能性。多重数据流向单独的维度模型，会使用户在应付不一致性的问题方面显得很脆弱。确保一致性的最佳办法是对数据进行一次性的发布。单一的发布过程还能减少ETL的开发量，以及后续数据管理和磁盘存储方面的负担。
2、定义粒度
粒度定义意味着对各事实表行，实际代表的内容给出明确的说明。粒度传递了同事实表度量值相联系的细节所达到的程度方面的信息。他给出了后面这个问题的答案“如何描述事实表的单个行？”
粒度定义是不容轻视的至关重要的步骤。在定义粒度时应优先考虑为业务处理获取最有原子性的信息而开发维度模型。原子性数据是所收集的最详细的信息，这样的数据不能再做更进一步的细分。通过在最低层面上装配数据，大多原子粒度在具有多个前段的应用场合显示出其价值所在。原子型数据是高度维结构化的。事实度量值越细微并具有原子性，就越能够确切的知道更多的事情，所有那些确切知道的事情都转换为维度。在这点上，原子型数据可以说是维度方法的一个极佳匹配。
原子型数据可为分析方面提供最大程度的灵活性，因为他可以接受任何可能形式的约束，并可以以任何可能的形式出现。维度模型细节性数据是稳如泰山的，并随时准备接受业务用户的特殊攻击。
当然，可以总是给业务处理定义较高层面的粒度，这种粒度表示最具有原子性的数据的聚集。不过，只要选取较高层面的粒度，就意味着将自己限制到更少或者细节性可能更小的维度上了。具有较少粒度性的模型容易直接遭到深入到细节内容的不可预见的用户请求的攻击。聚集概要性数据作为调整的一种手段起着非常重要的作用，但他绝不能作为用户存取最底层面细节内容的替代品。遗憾的是，有些权威人士在这方面一直含糊不清，他们宣称维度模型只适合于总结性数据，并批判那些认为维度建模方法可以满足预测业务需求的看法。这样的误解会随着细节性的原子型数据在维度模型中的出现而慢慢的消失。
3、选定维度
维度所引出的问题是：“业务人员将如何描述从业务处理过程得到的数据？”。应该用一组在每个度量上下文中取单一值而代表了所有可能情况的丰富描述，将事实表装扮起来。如果对粒度方面的内容很清楚，那么维度的确定一般是非常容易的。通过维度的选定，可以列出那些使每个维度表丰满起来的离散的文本属性。常见的例子包括：日期、产品、客户、账户和机构等。
4、确定事实
他是设计过程的第四步也是最后一步，在于仔细确定那些事实要在事实表中出现。事实的确定可以通过回答“要对什么内容进行评测”这个问题来进行。业务用户在这些业务处理性能度量值的分析方面有浓厚的兴趣。设计中所有供选取的信息必须满足在第2步中定义的粒度要求。明显属于不同粒度的事实必须放在单独的事实表中。通常可以从以下三个角度来建立事实表：
- 针对某个特定的行为动作，建立一个以行为活动最小单元为粒度的事实表。最小活动单元的定义，依赖于分析业务需求。比如用户的一次网页点击行为、一次网站登录行为，一次电话通话记录。这种事实表，主要用于从多个维度统计，行为的发生情况，主要用于业务分布情况，绩效考核比较等方面的数据分析。
- 针对某个实体对象在当前时间上的状况。我们通过对这个实体对象在不同阶段存储他的快照，比如用户的余额、用户拥有的产品数等。通过这种可以统计实体在不同生命周期中的关键数量指标。
- 针对业务活动中的重要分析和跟踪对象，统计在整个企业不同业务活动中的发生情况。比如会员，可以执行或参与多个特定的行为活动。这种事实表是以上两种事实表的一个总计和归纳。它主要用于针对我们业务中的活动对象进行跟踪和考察。
三、数据仓库总线结果
业务与IT机构一般都对不同的业务处理过程的集成很感兴趣。低级别业务分析师在这方面的愿望可能并不是很迫切，单那些处于较高管理阶层的人员非常清楚，在跨业务的范围内进行数据的查看对于提高评估性能是很必要的。众多的数据仓库项目将注意力放在从终端到终端的视角，更好的理解顾客关系的管理需求方面了。如下图，在某大型国有银行中，业务价值的产品运营中，包含许多相关的业务处理，如营销支持、产品运营、风险管控、财务绩效等诸多业务管理。
如果针对这些业务处理分别进行维度建模、建立独立数据集市，数据集市之间没有共享公共维度，那么就会出现问题，数据集市就会变成独立的集市，不能组合成数据仓库，而一致性维度的提出正是为了解决这个问题。如下图给出了这种维度共享情形的逻辑表示形式。
共享公共的维度对于设计可以进行集成的数据集市来说，具有绝对的决定性作用。这样做使得来自不同处理的性能度量值可以被组合到单个报表中去。具体的实现过程是，使用多通路的SQL单独查询各个集市，然后基于共同的维度属性对查询结果施加外连接。这个通常称作交叉探查（Drill Across）的连接，在维度属性具有一致性的情况下是很直接的。
将一组分布在各处的有关业务处理成一个综合的数据仓库来说，总线结构师最基本的要素。
1、数据仓库总线结构
很显然，想一个步骤就建成企业数据仓库太令人望而生畏。然而，将它分成独立的片段进行建造又会挫败一致性这个压倒一切的目标。要使数据仓库能够长期的成功运转，很需要有一种在体系结构上可以按照增量方式建造企业数据仓库的方法。这里提倡使用的一种方法就是数据仓库总线结构。
通过为数据仓库环境定义标准的总线接口，独立的数据集市就可以由不同的小组在不同的时间进行实现。只要遵循这个标准，独立的数据集市就可以插入到一起并有效的共存。所有业务处理将创建一个维度模型系列，这些模型共享一组综合的具有一致性的共用维度。如下图
数据仓库总线结构提供了一种可以用于分解企业数据仓库规划任务的合理方法。在体系结构确立阶段的较短时间内，开发团队设计出一整套在企业范围内具有统一解释的标准化维度和事实。这样，数据体系结构的框架就建立起来了。然后，开发团队可以全力以赴实现严格依照体系结构进行迭代开发的独立数据集市。随着独立数据集市的投入使用，他们就像积木块一样搭在一起。在某种意义上讲，需要存在足够的数据集市才可能为集成的企业数据仓库带来美好的前景。
总线结构使数据仓库管理人员获取两个方面的优势。一方面，他们有了指导总体设计的体系框架，并且将问题分成了可以根据具体时限加以实施的以字节计量的数据集市块。另一方面，各数据集市开发团队遵照体系指南，可以相对独立的异步开展工作。
2、一致性维度
在了解总线结构的重要性以后，现在可以进一步开发发挥数据总线奠基石作用的一致性维度。一致性维度要么是统一的，要么是具有最佳粒度性与细节性的维度在严格数学意义上的子集。例如：如果建立月维度，月维度的各种描述必须与日维度中的完全一致，最常用的做法是在日维度上建立视图生成月维度。这样月维度就可以是日期维度的子集，在后续钻取操作时可以保持一致。
一致的维度具有一致的关键字、一致的属性列名字、一致的属性定义以及一致的属性值。如果属性标签的记录不同或者包含不同的值，维度表就不是一致的。如果客户或者产品维度是按照非一致的方式进行配置的，那么，要么分散的数据集市不能在一起使用，要么更为严重的是，视图将他们用在一起将产生无效的结果。
一致的维度以几种不同的样式出现。在最基本的层次上，一致的维度意味着与同他们相连接的每种可能的事实表具有完全相同的内容。连接到产品服务签约的事实上的日期维度与连接到产品服务账户余额事实上的日期维度表是统一的。实际上，一致的维度在数据库范围内可能就是相同的物理表。不过，基于对配有多种数据库平台的数据仓库技术环境的典型复杂性的考虑，维度更有可能同时在每个数据集市都存在拷贝。在其中任何一种情况下，两个数据集市的日期维度都将具有相同的行、相同的关键字值、相同的属性标签、相同的属性定义与相同的属性值等。同样，也存在一致的数据内容、数据解释与用户展示。
3、一致性事实
通常，像利润、经济资本、产品覆盖度、客户满意度以及其他关键性指标（KPI）需要在企业级共享的度量指标，都是必须保持一致性的事实。一般的说，事实表数据并不在各个数据集市之间明确的进行拷贝。不过，如果事实确实存在于多个位置，那么支撑这些事实的定义与方程都必须是相同的，假如将他们当做同种事物看待的话，如果这些事实具有相同地 标记，那么需要在相同维度环境下对他们进行定义，同时使其在各个数据集市之间具有相同的度量单位。必须在数据命名实践中接受规范的约束，如果不可能做到使事实完全一致，那么应该对不同的解释给出不同的名称。这样可以减少计算中使用不兼容的事实的可能性。