Dimensional Design 维度设计

维度模型由两部分： measurements and context, 即 测量指标和上下文。

在数据仓库模型里对应的是事实表和维度表，如果引入关系数据库，那么此时的维度模型就是星型模型。

维度设计是服务于分析型系统，而非事务型系统—— 前者是面向业务过程的评估，后者是保证服务的顺利执行。 ( evaluation vs execution )

OLTP system

Transaction(事务)要提供的接口： 增加，删除，修改，查询，而且应保证操作的原子性。

在OLTP系统，数据库表的设计要遵循一定的设计规范，比较著名的就是3NF（第三范式）。 这种规范也被称为 ER模型。

OLAP（Analytic System）

OLAP在设计和定位、实现上，和OLTP都有着较大的差异：

Measurement and Context

• 一月 各类商品的毛利是多少？
• 按教育程度分类，每类用户的账户余额平均值是多少？
• 供货商的退货率是多少？

这一系列问题与销售过程、账户管理、退款服务产生的存量数据有关。为了回答这些问题，要查询的不再是一条数据，而是一批次+多个表的数据的聚合查询结果。

对Measurement必须是结合context的， 比如当有人说销售额是1000时，这句话的信息量极少。1000到底是一个商品还是一类商品，时间描述也不清楚。 对范围的限定，即为context,上下文。

Fact and Dimensions

在维度设计中，测量对应的是事实表，上下文对应的是维度表。

要留意的是，并不是所有数值都是隶属于事实的测量。 比如说用户的年龄，可以作为维度。
事实和一个数值指标对应，往往“指标”是可以拆解或聚合的。

事实表与维度举例（销售过程）星形样例

商品维度：商品，SKU编码，商品描述，品牌与品牌编码，经理，分类与分类编码；
销售员维度：销售员，区域编码和区域名称
顾客维度：顾客ID，账单地址
时间日期：下单日期，下单月份，季，财务周期，订单年

Star Schema 星形模式

事实表为中心，向外放射（☢️）解释关联到每个方面的维度：

事实表的查询

数据仓库架构

😶 Data Warehouse Architectures

这一章介绍EDW（enterprise data warehouse)。 作者提示，不要生搬硬套文中提到的架构模块。

Inmon's Corporate Information Factory 🏭

Bill Inmon是数据仓库社区中多产的贡献者（prolific writer and contributor to the data warehousing community), 代表性著作（Corporate Information Factory, 企业信息工厂）

这个架构下， 分析型应用（包括BI工具）不直接查询。
EDW通常存储在关系数据库管理系统，Inmon提供使用3NF范式。

Kimball，维度数据仓库

Kimball的成就

1. 1990年，Kimball将之前的个人思想加以提炼，提出了star schema设计。
2. 对数据仓库Kimball给出了一套维度设计的方法论 —— 数据总线架构（bus architecture)

Kimball 维度模型和前文提到EDW最大的区别是什么？
设计是遵循维度建模，而非范式的关系建模，由一系列星型表或cubes组成。

二者，维度数仓可以直接被分析系统查询，data mart （是数据仓库中的主题区域）。