数据仓库工具箱-维度建模01

数据仓库、商业智能和维度建模

1.1数据获取和数据分析的区别

信息两个作用：操作型记录的保存和分析型决策的制定。操作型系统保存数据，DW/BI系统使用数据。操作型系统一般一次处理一个事务记录。所以操作型系统通常不必维护历史数据，只需修改数据以反映最新的状态。
为应对更复杂的问题，DW/BI系统一般不会一次只处理一一个事务，对此系统进行优化的目的是高性能的完成用户的查询。

1.2数据仓库和与商业智能的目标

1.DW/BI系统要能方便的存取信息
2.DW/BI系统必须以一致的形式展现信息
3.DW/BI系统必须能够适应变化
4.DW/BI系统必须能够及时展现信息
5.DW/BI系统必须成为保护信息财富的安全堡垒
6.DW/BI系统必须成为提高决策制定能力的权威和可信的基础
7.DW/BI系统成功的标志是业务群体接受DW/BI系统。

维度建模简介

维度建模是展现分析数据的首选技术，主要由于：
1.以商业用户可理解的形式发布数据
2.提供高效的查询性能
数据库中的3NF是为了消除冗余，规范化的3NF将数据划分为不同实体，每个实体构成一个关系表。实体-关系图（E-R图）表示了表间的交互关系。

星型模式与OLAP多维数据库

在关系数据库管理系统中实现的维度模型称为星型模式，因为其结构类似星型结构，在多维度、数据库环境中实现的维度模型通常称为联机分析处理（OnLine Analytical Processing）多维数据库。
当数据被加载到OLAP多维数据库时，性能聚焦或预计算汇总表通常由OLAP多维数据库引擎建立并管理以实现高性能查询。

用于度量的事实表

维度模型中的事实表存储组织机构业务过程事件的性能度量结果。事实表中的每行对应一个度量事件，每行中的数据是一个特定级别的细节数据，被称为粒度。维度建模的核心原则之一是同一事实表中的所有度量行必须具有统一粒度。最实用的事实是数值类型和可加类型事实（销售额），半可加（销售余额），不可加（平均价格）。设计者应当尽最大可能将文本数据放入维度中，以减少空间的开销。
所有事实表的粒度可以划分为三类：事务、周期性快照、累积快照。一般事实表有两个或多个外键与维度表的主键关联。

用于描述环境的维度表

维度表是事实表不可或缺的组成部分。维度表包含与业务过程度量事件有关的文本环境。与事实表相比，维度表倾向于包含比较少的行，但是可能会存在多列或文本列。每个维度表由单一主键定义，用于在与事实表链接操作的过程中实现参照完整性的基础。
维度属性可以作为查询约束、分组、报表标识得主要来源。多数情况下，数据仓库的好坏直接取决于维度属性的设置，DW/BI环境的分析能力直接取决于维度属性的质量和深度。
一个数字量到底是事实还是属性，对于设计者来说是一个两难的问题，很难做出决策，连续型数字基本可以认为属于事实，来自于一个不太大的列表的离散数字可以确认为维度属性。
维度表通常以层次关系表示，为了方便使用和提高查询性能。维度表不一定要满足第三范式，通常是非规范化的，一个维度表中往往存在多对一的关系。

星型模型中维度与事实的连接

维度模型的每个业务过程包含事实表，事实表存储事件的数值化度量，围绕事实表的是多个维度表，维度表包含事件发生时实际存在的文本环境。这种类似星状的结构通常称为星型连接。

image.png

维度模型首先要注意的是简单性和对称性，简单性对业务用户有利，便于理解和查询，表数量的减少以及使用有实际意义的业务描述使表更容易被查询，减少了错误的发生。维度模型的简单性也带来性能的好处，同时维度模型非常适用于变化。

Kimball的DW/BI架构

image.png

操作型源系统

是记录的操作型系统，用于获取业务事务，几乎不能控制这些系统中的数据格式和内容，其关注的是处理性能和可用性。可以认为源系统处于数据仓库之外。

获取-转换-加载系统

ETL系统是处于操作型源系统与DW/BI展现系统之间的区域。
获取是将数据从操作型系统导入数据仓库环境这一ETL过程的第一步，获取意味着读取并理解源数据并将需要的数据复制到ETL系统中以有利于后续的处理操作，从这点来看，数据属于数据仓库。
数据获取到ETL系统后，需要进行多种转换操作，比如清洗数据（消除拼写错误、解决领域冲突、处理错误的元素、解析为标准格式），合并来自不同数据源的数据，复制数据等。
ETL最后的步骤是实际构建和加载数据到展现区域的目标维度模型中。

用于支持商业智能决策的展现区

DW/BI展现区用于组织、存储数据、支持用户、报表制作者以及其他BI应用的查询，关于展现区的建议：
1.展现区数据应当以维度模型来展现，要么采用星型模式，要么采用OLAP多维数据库。
2.必须包含详细的原子数据。展现区中一定要包含最细粒度的数据，以便用户能够获取最准确的查询结果。由于用户需求是是不可预知的，不断变化的，因此需要提供各种细节数据，方便用户上卷下钻以解决实际问题。
展现区的数据可以围绕业务过程度量事件来构建，采用这一方法可以自然的裁剪操作型源数据系统。
必须使用公共的、一致性的维度建立维度结构。这是企业数据仓库总线结构的基础，遵守总线结构是对展现区的最后一个要求。如果没有一种可共享的、一致性的维度，维度模型将称为一种孤立的应用，无法实现交互的、隔离的烟筒型数据集合将导致企业的不兼容视图，是DW/BI系统的最大障碍。大企业的DW/BI环境中的展现区最终包含一系列维度模型，该维度模型由事实表和多个关联的维度组成。
利用总线建立分布式DW/BI系统是成功的法宝。将总线结构作为基本框架，可采用敏捷的、分散的、范围合适的、迭代的方式建立企业数据仓库。

image.png

采用这种方法的企业通常允许业务用户根据数据细节程度和数据可用性要求访问EDW仓库，然而，产生的ETL数据的发布过程包含下游的报表和分析环境以支持业务用户。虽然也采用维度结构，但结果分析数据库通常与Kimball架构的展现存在差别，分析数据库通常以部门为中心，如果部门重命名了或者做了其他类似计算，要将分析数据库与EDW原子数据联系起来将变得非常困难。

image.png

此处的EDW完全与分析和报表用户隔离，展现区数据是维度的、原子的、以过程为中心的，与企业数据仓库总线结构保持一致。
Kimball的敏捷性考虑：
1.关注发布业务价值
2.开发小组与业务相关方之间的值合作，类似敏捷小组。
3.强调与业务相关方开展面对面的沟通、反馈、优化
4.以迭代、增量方式处理开发过程。