数据仓库工具箱读书笔记01 基础

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

信息(或者说是数据)一般有两个目的:

1. 记录操作(操作型系统)
2. 指定决策(DW/BI系统)

操作性系统一般一次只处理一个事务(获取订单 记录问题等), 如果要优化方向在于让其更快的处理事务, 因此不必维护历史数据, 只需要修改数据来反映最新的状态即可

DW/BI系统会处理成千上万的事务(本周新订单与过去一周进行比较, 并寻找新客户原因), 如果要优化方向在于让其高性能完成用户的查询, 因此需要维护历史数据

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

1. 存取信息方便
   内容必须易于理解, 不光是让开发理解, 也要让业务理解.
   支持以各种方式分隔和合并数据, 以进行分析.
   访问数据的BI工具要简单.
   较短时间将查询结果返回(不满足后两点你会被吐槽死)

2. 一致性
   数据可信(数据清洗一定要确保数据质量)
   同名同意(名字一样则含义一样)

3. 适应变化
   需求会变, 业务会变, 数据更会变. 对这些变化进行调整时不应该影响已有的数据和应用
   如果必须去修改DW, 也应该对用户透明

4. 及时性
   对时效有一些要求,数据要及时发布出来

5. 安全性
   数据比较敏感, 必须控制访问权限

6. 权威性
   DW系统最重要的输出就是基于对数据的分析而产生的决策

7. 业务群体接受
   要让业务群体接受并积极使用它

1.3 维度建模简介

为什么维度建模是分析数据的首选技术呢?

• 数据业务用户可理解
• 高效的查询性能

什么是3NF, 使用3NF目的是什么?
3NF(三范式)主要的目的是 消除冗余, 将数据划分成不同的实体, 每个实体一张表

请比较下维度模型和3NF?
其实维度模型和3NF模型所包含的信息都是一样子的, 他们的主要区别就是规范化的程度不一样

1.3.1 星型模型和OLAP多维数据库

什么是星型模型, 及OLAP?
在关系数据库管理系统实现的维度模型成为星型模型, 而在多维数据库环境实现的维度模型称为联机分析处理(OLAP)

关系型数据库管理系统 和 多维数据库系统 是什么意思?
关系型数据库是二维表, 多维数据库可以存储两个以上的数据维

1.3.2 用于度量的事实表

事实表存储什么内容?
存储业务过程所产生的度量结果 (销售过程产生的销售额)

同一业务过程产生了多个度量, 怎么存储?
销售过程产生了销售额 销售数量等多个度量, 他们应当存储在同一个维度模型中

业务产生的度量的数据量巨大, 分开存储好不好?
不行, 应当建立单一的集中式数据仓库让多个组织访问, 来确保他们使用的数据是一致的

请解释下粒度?
事实表中的一行就对应了业务过程产生的一个度量. 这一行数据是一个特定级别的细节数据, 称为粒度

举例 : 销售事实表中的一行代表了什么呢?
假设小阳同学去商店买了两瓶酸奶,一个面包 付款之后拿到了一张小票…
因为后期可能要以商品为维度进行数据分析,所以存储结果如下:

日期维度键	商品维度键	销售额	销售数量
1	1	10	2
1	2	3	1

事实表中的事实可分成哪几类?
可加: 销售额, 可从所有维度加和
半可加: 余额, 不能按照时间维度进行加和
不可加: 单价, 所有维度不可加和

数值类型: 存储的事实是数值, 可进一步划分 可加 半可加 不可加
文本类型: 理论上可行, 但是一般会把文本放到维度上以减少空间开销. 除非对事实表的每行文本都市唯一的

事实表的粒度可分成哪几类?
事务 周期性快照 累计快照

1.3.3 用于描述环境的维度表

维度表是做什么的?
用于描述业务过程产生的度量的环境, 一般描述 谁 什么时间 什么地点 做什么 如何做 为什么要做

维度表存储什么内容?
首先声明维度表中的内容一般用于做 查询约束 分组 报表标识等. 那么维度表的内容应该是真是的词汇, 而不是令人迷惑的缩写.

上面不是说维度表不要存一些标识符(操作码), 而是将它们解码成真实的词汇嘛, 那如果我的标识符有业务含义, 我需要用到它去和后台的操作环境进行交互, 这个怎么办?
将标识符存成一列, 然后加一列对这列标识符进行友好的文本描述

我的标识符设计规则是前两列代表区域, 三四列代表类别, 这样的该怎么存储?
拆分成多列, 方便用户进行查询

如何判断一个数值数据是事实还是维度?
包含多个值 且 是计算的参与者 -> 事实
具体指的描述 且 是常量 约束 标识的参与者 -> 维度
连续值数字基本上可以认为是事实, 来自于一个不太大列表的离散数字基本上可以认为是维度

1.3.4 星型模式中维度于事实的连接

1.4 Kimball的DW/BI架构

由四部分组成: 操作型源系统 ETL系统 数据展现 商业智能应用

1.4.1 操作型源系统

处理业务所产生的事务的系统 (销售业务会产生很多的事务, 比如生成订单, 查询商品库存等)

1.4.2 获取-转换-加载(ETL)系统

获取是将数据从操作型源系统导入数据仓库环境, 意味着读取并理解源数据并将需要的数据复制到ETL系统中

转换: 数据清洗(消除拼写错误 解析标准格式等) 合并来自不同数据源的数据等. 反正目的就是将数据标准化不要乱七八糟的. 另外这里可以记录元数据来改进数据质量

加载: 将转换好的数据加载到展现区的维度模型中(这里为什么是维度模型, 规范化结构行吗? 不行, 规范化结构难以满足可理解性和性能两个目标)

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

存储数据. 支持用户 报表制作者 或者其他BI用用的查询. 展现区必须是维度化的（规范化难以满足简单性和性能）、原子的（存储细节数据）、以业务过程为中心的（不能按照个别部门需要的数据构建）、使用总线结构（公共一致性维度）的数据仓库

1.4.4 商业智能应用

利用展现区为商业用户提供分析决策的能力(很显然, 查询的性能很重要)

1.4.5 以餐厅举例描述下Kimball架构

① 高效: 餐厅人满为患, 我们要尽快把菜做出来, 提前把菜洗好, 或者提前炒好菜不要现炒

② 一致性: 同一份菜味道要一样, 我们把调味酱提前放进菜里, 而不是让顾客自己放

③ 完整性: 不希望顾客中毒或者串味, 所以素菜工作台和肉类工作台要分开

④ 质量: 菜肴要达到一定的标准才能上桌, 否则重做

1.5 其他DW/BI架构

1.5.1 独立数据集市架构