数据仓库工具箱-笔记

一些名词，工具，原理，架构，设计模式，最佳实践等的笔记。

名词

1. 数据仓库、商业智能及维度建模初步

信息对于系统有两个作用：

一个是保存
一个是分析

OLTP-保存数据：
面向用户的应用开发，比如网站后台数据库，MySQL等概念
不维护历史数据，仅保留最新的系统状态
强事务性，更快的处理事务，一次处理一个事务
OLAP-分析数据：
面向数据分析的开发，数据分析，大数据、数仓的概念
维护历史数据，数据量大
一次处理多个事务

数仓和商业智能的目标

方便的存取信息
以一致的形式展现信息
能适应变化
即使的展现信息
称为保护信息菜户的安全堡垒
称为提高决策指定能力的权威和可行的基础
成功的标志是业务群体接收DW/BI系统（愿意用和相信其价值）

2. 维度建模简介

维度建模可以满足：

以商业用户可以理解的方式发布数据
提供高效的查询性能

2.1 星型模式与OLAP多维数据库

星型模型（传统数据库）
OLAP（hive）是多维建模的两种实现方式

2.2 用于量度的事实表

事实表中每一行对应一个量度事件。每行中的数据是一个特定级别的细节数据，称为粒度。

维度建模的核心是事实表中的所有量度行（每个指标）必须是同一粒度

比如销售事实中的细节数据：美元销售额，事实表中数据最好是可加的，最好不要存放文本数据，文本数据应该放在维度表中

事实表是稀疏的，但是将消耗维度模型的90%甚至更多的空间。

事实表在行数上趋向于边长，在列上趋向于变短

事实表按照事务可划分为分为三类：

事务（最常见）
周期性快照
积累快照

一般事实表包含两个甚至更多的的外键，这些外键与维度表主键关联。

事实表的主键通常是外键组合在一起的组合主键，表示多个维度的集合

对应操作型数据库，事实表就是，操作型数据库中的关系表，比如学生选课表（仅仅多了对这个事实的数值属性比如各种成绩等）

2.3 用于描述环境的维度表

维度表包含与业务过程量度时间有关的文本环境，用于描述与“谁、什么、哪里、合适、如何、何时、为什么”有关的事件。

维度表通常有很多列，50~100个都很正常。

维度表趋向于包含较少的行，但是可能存在多列。

维度表由单一主键定义，用于被事实表关联参照。

维度表示查询约束（where语句）、分组（group by）、报表标识的主要来源。属性名一般为名词。可以帮助对系统的理解。尽量使用文本描述而不是代码。

区分数值属性是事实表还是维度表的方法是：

如果一个数值属性包含多个值并作为计算参与者的度量——事实
如果仅是对具体值的描述，一个常量、某个约束和行标识的参与者——维度属性

维度表不需要满足3NF，维度表通常数据量很小，因此不需要满足3NF

对应操作型数据库，维度表就是：操作型数据库中的实体，比如学生标表、课程表

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

事实表存储：数值量度、多个维度外键（量度），围绕的是多个参考的维度表（环境）。

3 Kimball 的 DW/BI 架构

共有四个组成部分：源操作系统、ETL系统、数据展示和商业智能应用

3.1 源操作系统

行为日志业务数据库

3.2 获取-转换-加载（ETL）系统

清洗数据数据合并复制数据

最后步骤

构建和加载数据到展示区域、划分维度和事实

拆分组合列
反范式化（争议、本书支持）

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

采用维度模型来展现。
要包含最细粒度的数据。
使用公共的、一致性的维度建立维度结构
遵循总线结构

3.4 商业智能应用

查询工具、看板、可视化、推荐等

4 其他 DW/BI架构

4.1 独立数据集市架构

按部门独立建设：相当于每个部门都有自己的上面的一套

4.2 辐射状企业信息工厂Inmon架构

BI应用之前按照部门汇总，其他都是通用的。

4.3 维度建模神话

维度模型仅包含汇总数据（事实应该包含细节数据）
维度模型是部门级别而不是企业级别（事实应该是按照业务过程组织而不是部门）
维度模型不可扩展（实际上可以）
尾部模型仅能用于预测（实际上应该以度量过程为中心）
维度模型不能被集成

5. 考虑使用维度模型的更多理由

敏捷性考虑

6. 本章小结

维度建模基本概念
Kimball DW/BI模型与其他模型比较
误解解释