10 分钟
数据仓库工具箱——维度建模权威指南第三版（读书笔记）
第一章 数据仓库、商业智能及维度建模初步
1.1 数据获取与数据分析的区别
信息对于系统的两个作用：
- 操作型系统保存数据（面向用户的应用开发，比如网站后台数据库，MySQL等概念）
- 不维护历史数据，仅保留最新的系统状态
- 强事务性，更快的处理事务，一次处理一个事务
- 分析型系统（DW/BI）使用数据（面向数据分析的开发，数据分析，大数据、数仓的概念）
- 维护历史数据，数据量大
- 一次处理多个事务
1.2 数仓和商业智能的目标
- 方便的存取信息
- 以一致的形式展现信息
- 能适应变化
- 即使的展现信息
- 称为保护信息菜户的安全堡垒
- 称为提高决策指定能力的权威和可行的基础
- 成功的标志是业务群体接收DW/BI系统（愿意用和相信其价值）
后两点最重要，否者所有都是白费或者有害
1.3 维度建模简介
维度建模可以满足：
- 以商业用户可以理解的方式发布数据
- 提供高效的查询性能
这源于其简单性
维度建模不要求满足3NF，3NF用于消除冗余但是不利于理解查询
1.3.1 星型模式与OLAP多维数据库
星型模型（传统数据库）和OLAP（hive）是多维建模的两种实现方式。
1.3.2 用于量度的事实表
事实表中每一行对应一个量度事件。每行中的数据是一个特定级别的细节数据，称为粒度。
维度建模的核心是事实表中的所有量度行（每个指标）必须是同一粒度
比如销售事实中的细节数据：美元销售额，事实表中数据最好是可加的，最好不要存放文本数据，文本数据应该放在维度表中
事实表是稀疏的，但是将消耗维度模型的90%甚至更多的空间。
事实表在行数上趋向于边长，在列上趋向于变短
事实表按照事务可划分为分为三类：
- 事务（最常见）
- 周期性快照
- 积累快照
一般事实表包含两个甚至更多的的外键，这些外键与维度表主键关联。
事实表的主键通常是外键组合在一起的组合主键，表示多个维度的集合
对应操作型数据库，事实表就是，操作型数据库中的关系表，比如学生选课表（仅仅多了对这个事实的数值属性比如各种成绩等）
1.3.3 用于描述环境的维度表
维度表包含与业务过程量度时间有关的文本环境，用于描述与“谁、什么、哪里、合适、如何、何时、为什么”有关的事件。
维度表通常有很多列，50~100个都很正常。
维度表趋向于包含较少的行，但是可能存在多列。
维度表由单一主键定义，用于被事实表关联参照。
维度表示查询约束（where语句）、分组（group by）、报表标识的主要来源。属性名一般为名词。可以帮助对系统的理解。尽量使用文本描述而不是代码。
区分数值属性是事实表还是维度表的方法是：
- 如果一个数值属性包含多个值并作为计算参与者的度量——事实
- 如果仅是对具体值的描述，一个常量、某个约束和行标识的参与者——维度属性
维度表不需要满足3NF，维度表通常数据量很小，因此不需要满足3NF
对应操作型数据库，维度表就是：操作型数据库中的实体，比如学生标表、课程表
1.3.4 星型模式中的维度与事实的连接
事实表存储：数值量度、多个维度外键（量度），围绕的是多个参考的维度表（环境）。
1.4 Kimball 的 DW/BI 架构
共有四个组成部分：源操作系统、ETL系统、数据展示和商业智能应用
1.4.1 源操作系统
- 行为日志
- 业务数据库
1.4.2 获取-转换-加载（ERL）系统
- 清洗数据
- 数据合并
- 复制数据
最后步骤
- 构建和加载数据到展示区域、划分维度和事实
- 拆分组合列
- 反范式化（争议、本书支持）
1.4.3 用于支持商业智能决策的展现区
- 采用维度模型来展现。
- 要包含最细粒度的数据。
- 使用公共的、一致性的维度建立维度结构
- 遵循总线结构
1.4.4 商业智能应用
查询工具、看板、可视化、推荐等
1.5 其他 DW/BI架构
1.5.1 独立数据集市架构
按部门独立建设：相当于每个部门都有自己的上面的一套
1.5.2 辐射状企业信息工厂Inmon架构
BI应用之前按照部门汇总，其他都是通用的。
详细参见：p21
1.5.3 混合辐射状架构与Kimball架构
详细参见：p22
1.6 维度建模神话
- 维度模型仅包含汇总数据（事实应该包含细节数据）
- 维度模型是部门级别而不是企业级别（事实应该是按照业务过程组织而不是部门）
- 维度模型不可扩展（实际上可以）
- 尾部模型仅能用于预测（实际上应该以度量过程为中心）
- 维度模型不能被集成
1.7 考虑使用维度模型的更多理由
- 敏捷性考虑
1.8 本章小结
- 维度建模基本概念
- Kimball DW/BI模型与其他模型比较
- 误解解释
第二章 Kimball 维度建模技术概述
2.1 基本概念
2.1.1 收集业务需求与数据展现
- 与业务代表交流发现需求
- 理解基于关键性能指标、竞争性商业问题、决策制定过程、支持分析需求
- 数据实际情况可以通过与源系统专家交流，构建高层次数据分析访问数据可行性来揭示
2.1.2 协作维度建模研讨
- 建模者与业务代表讨论协作是关键
2.1.3 4步骤维度设计过程
- 选择业务过程
- 声明粒度
- 确认维度
- 确认事实
根据此，设计组确定表名、列名、示例领域值以及业务规则。业务管理代表必须参与详细的设计活动，以确保覆盖正确的业务
2.1.4 业务过程
业务过程是组织完成的操作型活动，例如，获取订单、处理保险理赔、学生课程注册或每个月账单快照。
业务过程对应事实表。过程选择非常重要，过程定义了特定的设计目标以及对粒度、维度、事实的定义。每个业务过程对应企业数据仓库总线矩阵的一行
2.1.5 粒度
声明粒度是维度设计的重要步骤。
粒度用于确定某一事实表的行表示什么。选择维度或事实前必须声明粒度，因为每个候选维度或事实必须与定义的维度保持一致。
原子粒度是最低级别的粒度，应从原理粒度开始设计。上卷汇总粒度对性能调整非常重要，要猜测业务公共问题。
同一事实表不能混用多种粒度
2.1.6 描述环境的维度
参见第一章
2.1.7 用于量度的试试
参见第一章
2.1.8 星型模型与OLAP多维数据库
参见第一章
2.1.9 方便地扩展到维度模型
维度模型对数据关系发生变化具有灵活的适应性。可以灵活应对如下变化
- 当事实与存在的事实表粒度一致时，可以创建新列
- 通过建立新的外键列，可以将维度关联到已经存在的事实表上，前提是维度列与事实表的粒度保持一致
- 可以在维度表上通过建立心裂添加属性
- 可以使事实表的粒度更加原子化，方法是在维度表上添加属性，然后以更新的粒度重置事实表，小心保存事实表及维度表的列名
2,2 事实表技术基础
2.2.1 事实表结构
从最低粒度看，事实表行对应一个量度时间，反之亦然。因此事实表设计依赖物理活动
存储的是：
- 现实世界的操作型事件产生的量度值
- 参考维度表的外键
- 可选的退化维度键和日期时间戳
2.2.2 可加、半可加、不可加事实
- 可加：可以按照事实表中任意维度汇总
- 半可加：可以按照事实表中某些维度汇总
- 完全不可加：例如比率
2.2.3 事实表中的空值
可以存放空值量度
2.2.4 一致性事实
如果某些量度出现在不同的事实表中，应保证技术定义相同，如果不兼容，应以不同的命名告诫业务用户和BI应用
2.2.5 事务事实表
每一行对应一个空间或时间上某点（事务）的事实表，一般都包含一个与维度表关联的外键
2.2.6 周期快照事实表
每一行对应标准周期（如一天、某周）的量度事件。粒度是周期性的，不是个体事务。
2.2.7 累计快照事实表
每一行汇总了发生在过程开始和结束之间可预测步骤内的量度事件。管道或工作流过程（例如履行订单或索赔过程）
2.2.8 无事实的事实表
没有量度，仅有关系的事实表如某天参加课程的时间
2.2.9 聚集事实表或OLAP多维数据库
2.2.10 合并事实表
例如科技奖现货销售和销售预测合并为同一张事实表
2.3 维度表技术基础
2.3.1 维度表结构
每个维度表都包含单一的主键列。通常较宽，是扁平非规范表，通常作为属性查询和约束分组的定义。
2.3.2 维度代理键
一般维度表的主键是一个自增的id（维度代理建），日期维度的维度表不需要遵循代理建规则。
2.3.3 自然键、持久建和超自然键
- 自然键例子：工号
- 超自然键或持久建例子：离职员工重新入职该键不会发生变化的键
2.3.4 下钻
根据维度表的属性进行group by
2.3.5 退化维度
维度除了之间没有其他内容的情况，可以放入事实表中
2.3.6 非规范化扁平维度
非规范化有利于提高时间效率
2.3.7 多层级维度
例如日历日期维度可以按照财务周期层次从天到周进行划分，也可能存在从天到月再到年的层次。位置密集型维度可能包含多个地理层次。再次情况下，同一维度中可以存在不同的层次
2.3.8 文档属性的标识和指示器
操作码应分解为属性枚举
2.3.9 维度表中的空值属性
建议采取特殊描述字符串描述空值属性
2.3.10 日历日期维度
使用时期作为主键
2.3.11 扮演角色的维度
一个筛选条件，枚举值，当前记录的类型是啥？
2.3.12 杂项维度
类似于extra
2.3.13 雪花维度
维度表按照层次结构建，称之为雪花模式。应该避免使用雪花模式，雪花模式查询困难、效率低。应使用扁平化的非规范的维度表
2.3.14 支架维度
某个维度表引用其他维度表，称之为支架维度。应避免使用，应通过事实表关联
2.4 使用一致性维度集成
2.4.1 一致性维度
当不同维度表的属性具有相同的列名和领域内容时，称维度表具有一致性。
2.4.2 缩减维度
缩减维度是一种一致性维度，由基本维度的列与行的子集构成。
2.4.3 跨表钻取
简单的说，跨表钻取意思是每个查询的行头包含相同的一致性属性时，使用不同的查询能不针对两个或更多的事实表进行查询。
2.4.4 价值链
待阅读、待补充
2.5 处理缓慢变化属性
- 原样保留
- 重写
- 增加新行
待阅读、待补充
待阅读、待补充
第三章 零售业务
3.1 维度建模设计的4步骤
3.1.1 选择业务过程
- 业务过程一般是一个行为动词，通常表示业务执行过程中的活动。
- 业务过程通常由某个操作型系统支撑，例如账单或购买系统
- 业务过程建立或获取关键性量度
- 业务过程通常由输入激活，产生输出量度。在许多组织中，包含一系列过程，他们既是某些过程的输入又是某些过程的输出。一系列过程产生的一系列事实表
了解业务过程、业务战略并将之细化到数据和操作型系统。
业务部门不等于业务过程
3.1.2 声明粒度
粒度由获取业务过程事件的操作型系统的物理实现确定（表现为：如何确定事实表中的一行）
- 客户销售事务上的每个产品扫描到一行中
- 医生开具的票据内容采用一行表示等
3.1.3 确定维度
维度要解决的是：业务人员是如何描述来自业务过程量度事件的数据
- 谁、何时、何处、为何等环境信息
3.1.4 确定事实
通过回答：过程的量度是什么（指标）
3.2 零售业务研究
3.2.1 选择业务过程
选择 POS零售交易
3.2.2 声明粒度
选择最细的原子粒度：POS交易的单个产品
3.2.3 确定维度
描述性维度：日期、产品、门店、促销、收银员、支付方式。
3.2.4 确定事实
事实：销售数目、单价、折扣、净支付价格、扩展折扣、美元销售值。
- 计算获得事实
- 不可加事实
- 事务事实表
3.3 维度表设计细节
3.3.1 日期维度
关于每天的各种属性：key、日期、完整描述、周天、日历月、年、假日标识符等等
3.3.2 产品维度
比如产品维度，主键为sku
- 需要扁平化多对一层次（比如类别只有少量值，大量的是重复的，但是仍可以进行扁平化，不需要额外参考）
- 具有内嵌含义的列要展平
- 数字值需要判断是否要放入事实表中（比如价格）
- 对该数字进行变化分析，需要放在事实表中
- 该数字变化不大，用于分组或过滤，应放在维度表中
- 同时需要，则同时放于两种表中
- 下钻维度属性
- 合理的产品表应包含50个左右的描述属性
- 每个属性可以作为约束和构建行头指针的标识的来源，下钻就是从维度表中请求行头指针以提供更多信息（就是按照属性聚合）
3.3.3 商店维度
主要是商店的地理信息属性组成表，商店Key作为主键，商店编号作为自然键
3.3.4 促销维度
促销的属性，可以考虑更细化（按不同类型的促销放入不同的表中）
3.3.5 其他零售业维度
例如促销员维度
3.3.6 事务号码的退化维度
看起来像是事实表的一个维度关键字，但实际上并没有对应的维度表：例如POST事务号、但是可以用来分组等
3.4 实际销售模式
如何查询已有数据。按照需求进行可视化或者SQL查询(BI工具)
3.5 零售模式的扩展能力
针对各种变化如何处理
- 新的维度属性：维度表添加新列
- 新的维度：添加新的维度表、向事实表中添加新的外键列
- 新的可量度事实：向事实表中添加数据（同一粒度），创建新的事实表（不是同一粒度）
3.6 无事实的事实表
例如促销事实表，并不存在相关事实（指标）
3.7 维度与事实表键
- 维度表的唯一主键应该是代理键而不是来自操作系统的标识符（自然键）。
- 代理键又称：无意义键、整数键、非自然键、人工键、合成键（自增ID）
- 自然键：又称业务键、产品键、操作键，表示有意义的组合，比如身份证号、手机号码、各种编码，内部包含很多信息可以用来查询的，针对多维键应该拆开储存
- 日期维度智能键，一般用于分区，格式为YYYYMMDD的数字
- 事实表并不强制使用代理建（但是推荐）