数据仓库、商业智能初步，常用维度建模架构对比。
业务管理的问题
信息系统存在的目的是解决业务的问题，对于数据仓库 Data WareHouse 和商业智能 Business Intelligence 来说，下面这些问题已经存在了几十年了：
- 收集了很多数据却无法访问
- 需要对数据做切片、切块
- 分析师、业务人员需要方便的获取数据
- 怎么展示最重要的事情
- 花费大量时间在研究数字的正确性，而不是业务决策
- 希望使用信息做更多基于事实的决策
这些问题对应了数据仓库与商业智能的目标，解决这些业务问题，信息系统必须做到：
- 方便的存取信息
- 一致性的形式展示信息
- 能够适应变化
- 及时的展示信息
- 保护信息财富
- 成为提高决策制定能力的权威
- 业务群体的认可
作为一个 DW/BI 管理者，你的责任则更具体：
- 理解业务用户
- 对业务用户发布高质量、相关的、可访问的信息和分析
- 维护 DW/BI 环境
维度建模
爱因斯坦曾说: 凡事应该尽量简单，直到不能再简单为止。
维度建模是展示分析数据的首选技术，它的优势在于能以商业用户可理解的方式发布数据并提供了高效的查询性能。它最初是用来简化数据库的，在维度建模中最开始使用的数据模型通常越简单越好，复杂的开始会导致最终的模型也很复杂。
维度模型通常建立在关系型数据库上，但这不意味着维度模型必须满足关系型数据库的要求，比如第三范式（3NF）。
3NF 是为了减少数据冗余，它会将数据划分成不同的实体，每个实体构成一个关系表。
但 3NF 不适用于 BI，主要是其模式太复杂，3NF 主要应用在操作性过程中，而不是 BI 查询，维度建模可以解决模式过分复杂的问题。
维度建模在不同的数据库系统中有不同的叫法：
- 关系数据库 -> 星型模式
- 多维数据库 -> 联机分析处理
事实表与维度表
在维度建模中，存在两类表：
- 事实表（数量，销售额，需注意可加性和不可加性，比如账户结余不可加）
- 维度表（谁、什么、哪里、何时、如何、为什么）
事实表中一条记录所表达的业务细节程度被称为粒度。通常粒度可以通过两种方式来表述：一种是维度属性组合所表示的细节程度；一种是所表示的具体业务含义。
事实表的粒度有三类：事务周期快照累快照，个。 事实表通常只有很少的列和很多行，是一种“瘦高”型的表。事实表定义为以下三种类型之一：
- 事务事实表:记录有关特定事件的事实（例如，销售事件，保存在原子的粒度，也称为原子事实表）
- 周期快照事实表记录给定时间点的事实（例如，月末的帐户详细信息）
- 累积快照事实表记录了给定时间点的汇总事实（例如，某产品的当月迄今总销售额）
作为度量业务过程的事实，一般为整型或浮点型的十进制数值，有可加性、半可加性和不可加性三种类型。可加性事实是指可以按照与事实表关联的任意维度进行汇总。半可加性事实只能按照特定维度汇总，不能对所有维度汇总，比如库存可以按照地点和商品进行汇总，而按时间维度把一年中每个月的库存累加起来则毫无意义。还有一种度量完全不具备可加性，比如比率型事实。对于不可加性事实可分解为可加的组件来实现聚集。
一般事实表具有两个或更多外键与维度表关联，比如事实表中的产品键始终与产品维度中的特定产品键匹配。如果事实表中所有键与维度表中的都匹配，则满足了 参照完整性, 可以通过维度表使用连接操作访问事实表。
事实表通常包含外键集合的主键，具有组合键的表即事实表，事实表通常具有多对多的关系。
维度是维度建模的基础和灵魂。在维度建模中，将度量称为事实，将环境描述为维度，维度是用于分析事实所需要的多样环境。
维度表通常有很多列、属性，维度表倾向于包含少量的行，一般用维度表来作为查询的约束、分组。
多数情况下，数据仓库的好坏直接取决于维度属性的设置，也决定了 DW/BI 的分析能力，强大的维度属性等于健壮的分片、分块分析能力。
对维度表的设计重点关注简单性和可访问性，可以不满足第三范式。
Kimball 的 DW/BI 架构
操作型源系统
该系统面对很多用户，并发事务很多。多是插入、更新操作。对数据的插入，更新性能要求更高，因此数据多是规范化的，规范化是指冗余度比较少。
ETL 系统
处理操作型源系统与DW/BI 之间，该系统对数据的处理分为三个部分：
- 获取 Extract，从操作型系统导入到 DW/BI
- 转换 Transformation，清洗，合并，复制等
- 加载 Load，构建和加载数据到
展现区域的目标维度模型
展现区域用于组织、存储，用户也可以在这里制作报表，查询，这是用户主要关注的区域，关于展现区，该书作者有两点建议：
- 数据应该以维度模型来展现（星型或OLAP多维数据库）
- 必须包含到最详细的原子数据级别
BI 应用
这是最后一个主要的部件，BI 突出的是支持商业决策的能力，它可以很简单，也可以很复杂。
其他 DW/BI 架构
第一种是独立数据集市，特点是以部门为架构组织，只考虑本部门的需要与业务规则，但不同部门之间的数据访问与标准各异，很多数值无法匹配。
这种架构代表了一种 DW/BI 架构，但其实属于没有结构，容易造成混乱。虽然可以低成本实现快速开发，但会存在分析数据冗余的问题，不是长远之计。
第二种是辐射状企业信息工厂(Corporate Information Factory) Inmon 架构，它的数据从操作型数据库获取，经过 ETL 会保存在满足第三范式的数据库中，称为 EDW (Enterprise Data Warehouse).
EDW 中的数据都是规范化的，原子级别的，相当于有一个中间过程协调与集成数据，缺点是它的下游数据组织形式以部门为单位，且包含的是聚集数据，非原子级别的数据，而对业务用户暴露原子级别的数据是有必要的，聚集数据比原子数据提供了更好的性能，但不能取代细节数据。
最后还有一种混合了 CIF 与 Kimball 模式的架构，有人说这是最好的架构因为混合了前面的两种架构，但是这也意味着更多的开销与时间，无论是开发还是运行期间，因为数据需要更多次的移动，细节数据冗余存储。
如果你已经建立了第三范式的 EDW，但无法让用户更灵活的实现报表与分析，可以采用这种模式。
维度建模的误解
维度模型被广泛使用，但也还存在很多误解，如：
- 它仅包含汇总数据
- 它是部门级的，不是企业级的
- 它不可扩展
- 它仅用于预测
- 它不能被集成
实际上，维度模型可以存储大量历史数据，按照业务过程组织即可满足企业级的要求，事实表非常容易扩展，数据库提供商也在不断优化维度模型的可扩展性和性能。
维度模型对业务的适应性也很强，业务需求可能是经常变化的，但维度模型具有对称性，只要以最细粒度级别构建事实表，加上维度结构非常灵活，可以很好的满足业务需要。
细节就是上帝。—— 建筑师 Mies van der Rohe
