第一章——数据仓库、商业智能及维度建模初步
1.1 数据获取与数据分析的区别
信息的目的：操作型记录的保存 和 分析型决策的制定
| 操作型系统 | DW/BI系统 |
|---|---|
| 保存数据，如获取订单、记录问题。 | 使用数据，如研究分析企业的运转，找原因 |
| 对其优化的目的是使其能更快的处理事务。 | 对其优化的目的是高性能地完成用户查询。 |
| 一般一次处理一个事务记录，不必维护历史数据 | 一般要搜索成千上万条事务，需要保存历史环境，精确评估在一段时间内的性能 |
1.2 数据仓库与商业智能的目标
前面两个最重要
- DW/BI系统必须成为提高决策制定能力的权威和可信的基础，是基于分析证据产生的决策
- 系统成功的标志是业务群接受此系统
- 系统要能方便地存取信息，数据要有直观性，复合用户思维过程。能在较短的时间内返回结果
- 必须以一致性的形式展现信息，数据是可信的。一致性表示系统内容的公共表示和定义在不同数据源共用，同名同意性
- 必须能够适应变化，用户需求、业务背景、数据及技术容易发生变化，能以适当方式描述变化
- 必须能够及时展现信息，需要在较短时间内转换成有用信息返回
- 必须成为保护信息财富的安全堡垒，信息数据的安全性
以出版发行工作为例说明DW/BI管理者的职责
| 主编 | 管理者 | |
|---|---|---|
| 1. 理解读者。 - 确定读者的人口统计学特征 - 发现读者希望呈现的内容 - 识别会续订杂志的最佳读者 - 发现潜在的读者 | 1. 理解业务用户 - 理解他们的工作责任、目标和任务 - 确定商业用户在制定哪些决策时需要DW/BI系统的帮助 - 识别出制定出高效率、影响的决策的最佳用户 - 发现潜在新用户 | 输入层（数据源） |
| 2. 确保杂志对读者有吸引力 - 确保内容有趣 - 布局和渲染有趣 - 高质量的写作和编辑标准，一致的展现风格 - 监控杂志中的准确性 和 广告商的要求 - 根据情况适时修改表内容，即时可用 | 2. 发布高质量、相关的、可访问的信息和分析 - 选择健壮、可操作的数据放入 - 简化用户接口和应用 - 确保数据精准、可信有一致性 - 不间断的监控数据和分析的准确性 - 适应用户变化的思维方式、需求、业务等级 | 高质量 和 一致性 |
| 3. 维持出版 - 吸引广告商，带来利益 - 定期出版 - 保持读者信任 - 投资者对杂志满意 | 3. 维护DW/BI环境 - 采用制定成功的业务决策，验证配置 - 定期更新 - 保持业务用户信任 - 保持业务用户、执行赞助商和IT管理层满意 | 维护 |
1.3 维度建模简介
维度建模主要基于以下两个同时需要满足的需求：以商业用户可理解的方式发布数据 和 提供高效的查询性能
- 简单性至关重要，确保方便理解数据，能快速、有效发现及发布结果。从简单的数据模型开始是保持设计简单性的基础
- 维度模型通常应用在关系数据库管理系统之上，但并不是必须满足第三范式（3NF）
- 数据库中强调3NF主要是为了消除冗余，有时3NF模型称为实体-关系模型。
- 实体-关系图（ER图或ERD）表示了表间的交互关系，3NF模型和维度模型都可以用ERD表示，都包含可连接的关系表。差别在规范化程度，ER模型不仅是3NF模型
- 规范化的3NF模型主要用于操作型过程，涉及到更新与插入。但是对BI来说模型太复杂，难以有效查询
维度模型包含的信息与规范化模型包含的信息相同，但是把数据以一种用户可理解的、满足查询性能要求的、灵活多变的方式进行包装
1.3.1 星型模式和OLAP多维数据库
在关系数据库管理系统中实现的维度模型称为 星型模型
在多维数据库环境中实现的维度模型称为 联机分析处理 OnLine Analytical Processing
两者有公共的逻辑设计，但是物理实现上存在差异。
OLAP部署的注意事项
-
构建于关系数据库之上的星型模型是建立OLAP多维数据库的良好物理基础
-
随着计算机硬件和软件的发展，性能优势并不明显了
-
多维数据库结构比关系数据库管理系统变化更大
-
通常能比RDBMS提供更多复杂安全选项。限制访问细节数据，提供更开放的接口
-
提供更加丰富的分析能力
-
方便地支持缓慢变化维度
-
能够方便地支持事务和周期性快照事实表，由于缓慢变化维护重写数据的问题不能处理累积快照事实表
-
支持具有层次不确定的复杂的不规则层次结构
-
能实现对下钻层次的维度关键词结构提供详细的约束
-
无法确保实现维度角色和别名，要定义不同的物理维度
1.3.2 用于度量的事实表
维度模型中的事实表存储组织机构业务过程事件的性能度量结果，尽量将同一个业务过程的底层度量结果存储在一个维度模型中，确保使用一致的数据
总结：物理世界的每一个度量事件与对应的事实表行具有一对一的关系，这思想是维度建模的基本原则。
- 事实表示某业务度量。
- 事实表中每一行对应一个度量事件。
- 每行中的数据是一个特定级别的细节数据，称为粒度。
- 最实用的事实是数值类型 和 可加类型事实
- 数值类型，通常以连续值描述
- 可加型：销售额汇总
- 半可加：账户结余，不能按照时间维度汇总
- 不可加：单位价格
- 不要试图用0表示没有发生活动来填充事实表，0会占据大量事实表变得稀疏。如果没有活动，则不要在表中插入任何行
- 按事实表的粒度划分三种：事务、周期性快照和累积快照
- 事实表一般有两个或者更多外键于维度表的主键关联，通常有包含外键集合的主键（组合间）
1.3.3 用于描述环境的维度表
维度表包含与业务过程度量事件有关的文本环境。可作为查询约束、分组、报表标识的主要来源。用来描述“睡、什么、哪里、如何、为什么”有关的事件。
-
要有明确的业务含义，将操作码这种有隐含的意思拆分，以不同的维度属性展现给用户
-
维度提供数据的入口点，提供所有DW/BI分析的最终标识和分组
-
一般来维度属性是对具体值的描述，是一个常量、某一约束和行标识的参与者
-
维度表示通常以层次关系表示，且存在冗余（为了方便使用和提高查询效率）
-
使数据规范化的方法构建的模式为雪花模型，维度表不一定满足第三范式
1.3.4 星型模型中维度与事实的连接
- 需要注意简单性和对称性
-
易于理解和查询，查询高效（先处理维度表，满足用户约束的维度表关键字与事实表通过笛卡尔积连接，只用扫描一遍事实表）
-
适用于变化，维度的地位相同，没有优先顺序
-
- 粒度最小的数据或原子数据具有最多的维度，是构建能满足用户提出任意查询的事实表的基础设计
1.4 Kimball的DW/BI架构
1.4.1 操作型源系统
- 是记录的操作型系统，获取业务事务，几乎不能控制数据的格式和内容
- 关注的事情是处理性能和可用性。
- 一般不维护历史数据，不能支持广泛的、无法预料的查询方式查询的特点
1.4.2 ETL系统
- 获取、转换、加载（Extract Transformation and Load）包含一个工作区间、实例化的数据结构以及一个
- 获取：读取并理解源数据并将需要的数据复制到ETL系统中
- 转换：清洗数据（消除拼写错误、解析为标准格式），合并不同数据源的数据，建立诊断元数据
- 加载：实际构建和加载数据到展现区域的目标维度模型中。
- 主要任务是在交付过程中划分维度和事实
- 维度表处理。代理键分配、查找代码以提供适当的描述、拆分或组合列以提供适当的数据值
- 事实表处理。加载时需要消耗大量时间
- 业界对是否将ETL系统保存的数据，在加载到展现区的维度结构，改变其物理规范化的结构存在争议。但是为ETL建立规范化结构和为展现而建立的维度模型意味着数据将被ETL两次——一次到规范化数据库，然后再到维度模型。
- 建立规范化结构支持ETL过程时可采用的，但是不能在用户查询中使用规范化结构（不能同时满足可理解性和性能这两个目标）
1.4.3 用于支持商业智能决策的展现区
可查询展现区中的数据必须是维度化的、原子（辅以增强性能的聚集）的、以业务过程为中心的。
坚持使用总线结构的企业数据仓库，数据不应该按照个别部门需要的数据来构建。
- 用于组织、存储数据，支持用户、报表制作者以及其他分析型商业智能的查询
- 数据应该以维度模型来展现，要么采用星型模式，要么OLAP多维数据库
- 展现区，必须包含详细的原子数据，提供各种细节数据，方便用户上卷解决问题
- 数据可以围绕业务过程度量事件来构建，必须使用公共的、一致性的维度建立维度结构
- 利用总线机构建立分布式DW/BI系统是成功的法宝
1.4.4 商业智能应用
- 查询是使用数据提高决策能力的关键
- BI （Business Intelligence）泛指商业用户提供利用展现区制定分析决策的能力。
1.4.5 餐厅举例描述Kimball框架
餐馆后厨 与 ETL系统
| 餐厅 | ETL系统 |
|---|---|
| 获取原始材料 | 获取各个数据源的原始数据 |
| 设计目标 - 高产出，速度要快 - 高质量，质量要好，满足要求 - 一致性，自制调味酱要做好而不是放着原材料，一人一个味 - 完整性，要整体考虑工作台面位置 - 隔离性，厨师和客人分离 | 高度关注质量、完整性、一致性。 有足够的吞吐量 能够承载从数据源获得的大量数据，并在进入的时候检查质量 监控相关环境保证ETL输出数据的完整性 能够有效地、尽量减少移动地将原始数据转换为目标模型 ETL中的活动不展示给DW用户 |
| 雇佣能熟练操作的厨师 | 明白增值度量和属性的业务规则的专业人员 |
用餐区 与 BI
| 餐厅 | BI |
|---|---|
| 食物 （质量、口味） | 展示区的数据，通过元数据、发布报表等形式给用户数据（一致性、良好的质量） |
| 装饰风格 | 按照BI使用者的口味而不是开发者的喜好 |
| 服务 （上菜速度、人员服务、餐食和用餐者需求一致） | 满足需求，快速查询 |
| 就餐的开销 | 提供服务代价 |
| 意见反馈 | 主动检查满意程度，开展对满意度的监控工作 |
1.5 其他DW/BI架构
1.5.1 独立数据集市架构
- 通常单一部门确定其针对操作型源数据的数据需求，独立地展开工作
- 但是部门不能访问由其他部门构建的数据集市，数据会有差别（不同的业务规则和标识）
- 破坏了一致性，造成大量的冗余存储，低效没有从全局考虑。但不需要考虑跨组织的数据控制和协调，成本较低
1.5.2 辐射状企业信息工厂 Inmon架构
- 辐射状企业信息工厂（Corporate Information Factory，CIF）在CIF环境下，数据从操作性数据源获取，在ETL系统中进行处理，称为数据获取。
- 从这一过程中获得的原子数据保存在满足第三范式的数据库中，分析数据库通常以部门为中心（而部署围绕业务过程来组织）， 而且包含聚集数据（不是原子级细节数据），这样的架构将原子数据固定为难查询的规范化结构，极端形式是不能实现数据仓库的功能。
- 这种规范化的、原子数据的仓库称为CIF架构下的EDW（企业数据仓库，Enterprise Data Warehouse）。然后业务用户根据数据细节程度和数据可用性要求访问EDW仓库。
- CIF提倡企业数据协调和集成，认为规范化的EDW承担。而Kimball强调具有一致性维度的企业总线的重要性。但规范化过程并未能够从技术上支持集成，仅建立能够实现多对一关系的物理表
1.5.3 混合辐射状架构与Kimball架构
- 是一种嫁接的形式，利用了CIF中处于中心地位的EDW（完全与分析和报表用户隔离），仅作为Kimball风格的展现区的数据来源，其中的数据是维度的、原子的（辅以聚集数据）、以过程为中心的，与企业数据仓库总线结构保持一致
- 如果组织已经对企业做了投入，客户也不期望更加灵活实现报表和分析，这种方式可能非常适合。
1.6 维度建模误区
-
误区：维度模型仅包含汇总数据。事实：向用户提供对细节数据的查询访问，满足不可预测的多样性的查询；汇总数据查询时能提供更好的性能
-
误区：维度模型是部门级而不是企业级的。事实：维度模型围绕业务过程组织， 多业务部门分析来自同一业务过程的相同的维度，应该获取的是同一个数据源的数据
-
误区：维度模型是不可扩展的。事实：维度模型非常易于扩展，结构灵活，能够适应变化
-
误区：维度模型仅用于预测。事实：设计应该以度量过程为中心，维度模型设计是适应变化的，以最详细的粒度表达数据
-
误区：维度模型不能被集成。事实：一致性维度作为集中的、持久的主数据建立在ETL系统中，并运行维护、跨维度模型的重用能够实现数据集成和语义的一致性。要遵守企业数据仓库总线结构
1.7 维度模型注意点
- 在听业务过程中，要关注需要的报表和控制面板的度量，而且要关注产生这报表和控制面板度量的业务过程度量是什么
- 要同时展开IT和业务管理，按照业务价值和可行性排序业务过程，组织好所有过程。
- 企业数据仓库总线矩阵为敏捷开发提供框架和主生产计划，对可用公共描述维度的标识，提供数据一致性并减少市场发布时间。采用正确的合作方法，业务及IT参与方共处，企业数据仓库总线矩阵才可以短时间内建立。增量式工作方法迭代。