信息总是用作两个目的：操作型记录的保存和分析型记录的制定。
简单来说，操作型系统保存数据，DW/BI系统使用数据。
对于操作型系统，其用户确保组织能正常运转，对其的优化目的是使其能够更快的处理事务。
对于DW/BI系统，其用户研究分析企业运转，并对其性能进行评估，对其进行优化的目的是高性能地完成用户的查询。
一.维度建模
维度模型通常应用于关系数据库管理系统上，但不要求其必须满足第三范式（3NF）。
规范化的3NF模型主要应用于操作型过程中，因为对事务的更新与插入只涉及数据库的单一位置。但是对于BI查询来说，规范化模型太复杂，难以满足对数据的高性能检索需求。维度建模就是用来解决模式过分复杂的问题的。
1.星型模式与OLAP多维数据库
关系型数据库中实现的维度模型称为星型模式。
多维数据库环境中实现的维度模型为OLAP。
OLAP数据库建立并管理了性能聚集和预计算汇总表，采用这些优化方法，OLAP可以实现高性能查询。
星型模型有两个关键部件：用于度量的事实表，用于描述环境的维度表。
2.用于度量的事实表
事实表示某个业务度量，比如产品的销售数量，或销售额等。
事实表中的每行对应一个度量事件，每行中的数据是一个特定级别的细节数据，称为粒度。例如，销售事务中用一行来表示每个卖出的产品。
物理世界中的每一个度量事件与对应的事实表行具有一对一的关系，这一思想是维度建模的基本原则，其他工作都是以此为基础的。
最常用的事实是数值类型和可加类型事实。
事实通常以连续值描述，这样可以用来区分是事实还是维度属性。
不要在事实表中存储冗余的文本信息，应将其放入维度表中。
事实表的粒度可以分为三类：事务、周期性快照和累积快照。
事实表通常具有两个或更多外键与维度表的主键相连。
事实表通常有包含外键集合的主键。
通常几个维度一起唯一标识每个事务表行。
3.用于描述环境的维度表
维度表包含与业务度量事件有关的文本环境，“谁、什么、哪里、何时”等信息。
与事实表比较，维度表包含较少的行，且由单一主键定义，用于与事实表实现连接操作。
维度属性可作为查询约束、分组、报表标识的主要来源。因此，在DW/BI系统中起着至关重要的作用。
多数情况下，数仓的好坏直接依赖于维度属性的设置，良好的维度属性带来的回报是健壮的分片-分块分析能力。
4.星型模型中维度与事实的连接
维度模型表示每个业务过程包含事实表，以及围绕着事实表的多个维度表，这包含事件发生时实际存在的文本环境。
粒度最小的数据或原子数据具有最多的维度，尚未聚集的原子数据是最具有可表达性的数据。
在一个报表应用中，维度属性支持报表过滤和标识，事实表支持报表中的数字值。
二.Kimball的标准DW/BI架构
DW/BI分为4个不同的组成部分：操作型源系统、ETL系统、数据展现和商业智能应用。
1.ETL系统
建立规范化结构支持ETL过程是可以采用的方法。然而，这不是最终目标，不能在用户查询中使用规范化结构，因为其难以同时满足可理解性和性能两个目标。
2.展现区
DW/BI系统的展现区中的数据必须是维度化的、原子的、以业务过程为中心的。坚持使用总线结构的企业数仓，数据不应按照个别部门需要的数据来构建。
三.其他DW/BI架构
1.独立数据集市架构
采用这种架构，分析型数据以部门为基础来部署，不需要考虑企业级别的信息共享和集成。
2.辐射状企业信息工厂Inmon架构
Corporate Information Factory，CIF。
在这种架构下，数据从操作性数据源获取，在ETL系统中进行处理，称为数据获取。从这一过程中获得的原子数据保存在满足第三范式的数据库中，这种规范化的、原子数据的仓库称为CIF架构下的EDW（企业数据仓库，Enterprise Data Warehouse）。
然后业务用户根据数据细节程度和数据可用性要求访问EDW仓库。
四.维度建模的误区
误区1：维度模型仅包含汇总数据
我们不可能预测用户提出的所有问题，所以必须向业务用户提供最细粒度的数据。
