1.1. 良好的数据架构必须反映出使用这些数据的组织的业务目标和业务逻辑

1.2. 数据湖1.0、NoSQL和大数据系统的兴起，使工程师们有时是为了合理的性能提升去忽略传统的数据建模

1.3. 数据在企业中的地位急剧上升，人们越来越认识到，建模对于实现数据科学需求层次金字塔中更高层次的价值至关重要

2.1. 数据模型代表了数据与现实世界的联系方式

2.2. 反映了数据需要如何结构化和标准化才能最好地反映你的组织的流程、定义、工作流和逻辑

2.3. 一些数据专家认为数据建模是乏味的，是“大企业”才会做的事情

2.4. 对数据进行建模的关键是要关注如何将模型转化为业务成果

2.4.1. 一个好的数据模型要关联到商业决策的影响

2.4.2. 一个好的数据模型包含前后一致的定义

2.5. 数据建模的思想就是从抽象的建模概念移动到具体的实现

2.6. 主要的数据模型

2.6.1. 概念模型

2.6.1.1. 包含业务逻辑和规则，描述系统的数据，如模式、表和字段（名称和类型）

2.6.1.2. 使用实体关系(Entity-Relationship，ER)图中对其进行可视化通常是有帮助的，实体关系图是一个用于可视化数据中各种实体（订单、客户、产品等）之间的关系的标准工具

2.6.2. 逻辑模型

2.6.2.1. 通过添加更多的细节来详细说明概念模型在实践中如何实现

2.6.3. 物理模型

2.6.3.1. 定义了逻辑模型如何在数据库系统中实现

2.6.3.2. 将为逻辑模型添加具体的数据库、模式和表，包括配置细节

2.7. 成功的数据建模在过程的开始阶段就引入业务利益相关者

2.7.1. 数据建模应该是一项全接触式的活动，目标是为企业提供高质量的数据，最终获得可操作的洞见和智能自动化

2.8. 数据建模的另一个重要考虑因素是数据的粒度，也就是数据的存储和查询的最小单元

2.8.1. 粒度通常位于表中的主键的层级（如客户ID、订单ID和产品ID），它通常伴随着一个日期或时间戳以提精确性

2.9. 应该努力将你的数据建模维持在尽可能低的粒度层级

2.9.1. 很容易对这个高度细化的数据集做汇总

2.9.2. 反之则不然，通常也不可能从汇总的数据还原回明细

3.1. 范式化是一种对数据库中的表和列的关系进行严格控制的数据建模实践

3.2. 范式化的目标是消除数据库中的冗余数据，并确保参照完整性

3.3. 是在数据库中实践“不要重复自己”(Don't Repeat Yourself，DRY)的原则

3.4. 由关系数据库的先驱Edgar Codd在20世纪70年代初首次提出的

3.5. 四个主要目标

3.5.1. 把关系集合从不合适的插入、更新和删除依赖中解放出来

3.5.2. 当新的数据类型被引入时，尽可能减少关系集合的重组，从而增加应用程序的寿命

3.5.3. 使得关系模型对用户来说更有信息价值

3.5.4. 使得关系集合对于查询统计是中立的，这些统计可能会随着时间的推移而改变

3.6. 范式是有顺序的，每个范式都包含了之前范式的条件

3.6.1. 无范式

3.6.1.1. 没有范式化

3.6.1.2. 允许嵌套和冗余的数据

3.6.2. 第一范式(First Normal Form, 1NF)

3.6.2.1. 每一列都是唯一的，有一个单一的值

3.6.2.2. 该表有一个唯一主键

3.6.2.2.1. 唯一主键是一个单一的字段或多个字段的组合，它唯一地确定了表中的行

3.6.2.2.2. 每个键值最多出现一次，否则一个值会映射到表中的多条记录

3.6.3. 第二范式(Second Normal Form, 2NF)

3.6.3.1. 满足第一范式的要求，并移除部分依赖

3.6.3.1.1. 部分依赖是指完全由唯一主键（复合键）中的一个子集决定的非键列

3.6.3.1.2. 部分依赖只有在主键是复合键时才会出现

3.6.3.1.3. 当复合键中的一个字段子集可以用来确定表中的一个非键列时，就会出现部分依赖

3.6.4. 第三范式(Third Normal Form, 3NF)

3.6.4.1. 满足第二范式的要求，再加上每个表只包含与其主键相关的字段，并且没有传递依赖

3.6.4.2. 当一个非键字段依赖于另一个非键字段时，就会出现传递依赖

3.7. 尽管去范式化看起来像是一种反模式，但它在许多存储半结构化数据的OLAP系统中很常见

4.1. 星型模式

4.1.1. 在数据集市中对数据进行建模的另一个流行方式是星型模式，理论上任何访问方便简单的数据模型也都是满足要求的

4.1.2. 代表了企业的数据模型

4.1.3. 与高度范式化的数据建模方法不同，星型模式是被必要维度包围的事实表

4.1.3.1. 使得星型模式需要比其他数据模型更少的连接操作，从而加快了查询性能

4.1.4. 星型模式的另一个优点是它可以更容易被业务用户理解和使用

4.2. Inmon

4.2.1. 数据仓库之父Bill Inmon在1989年提出了他的数据建模方法

4.2.2. 在数据仓库之前，分析往往直接发生在源系统内部，其明显的副作用是长时查询造成了生产环境事务数据库的性能问题

4.2.3. 数据仓库的目标是将源系统与分析系统分离

4.2.4. 数据仓库的四个关键部分

4.2.4.1. 面向主题的

4.2.4.1.1. 数据仓库专注于一个特定的主题域

4.2.4.2. 集成的

4.2.4.2.1. 来自不同数据源的数据会被整合并范式化

4.2.4.3. 非易失的

4.2.4.3.1. 数据存储在数据仓库后保持不变

4.2.4.4. 反映历史变化的

4.2.4.4.1. 不同的时间范围的数据都可以被查询到

4.2.5. 在Inmon数据仓库，整个组织的数据都被整合到一个细粒度、高度范式化的并且注重ETL的实体关系模型中

4.2.6. 数据从优先级最高的业务领域开始被逐步引入

4.3. Kimball模型

4.3.1. 由Ralph Kimball在20世纪90年代初创建，这种数据建模方法不太注重范式化，在某些情况下还接受去范式化

4.3.2. Kimball方法有效地使数据集市成为数据仓库本身

4.3.2.1. 这也会使迭代和建模的速度比Inmon更快，但代价是潜在的更松散的数据集成、数据冗余和重复

4.3.3. 数据被建模为两种类型的表：事实和维度

4.3.3.1. 事实表

4.3.3.1.1. 可以把事实表看作一个数字表

4.3.3.1.2. 星型模式中的第一种表是事实表，它包含了事实的、定量的和与事件相关的数据

4.3.3.1.3. 事实表中的数据是不可改变的，因为事实与事件有关

4.3.3.1.3.1. 事实表只能做追加而不会被更新

4.3.3.1.4. 事实表通常又窄又长，意味着它们没有很多列，但有很多代表事件的行

4.3.3.1.5. 事实表应该是尽可能细粒度的

4.3.3.2. 维度表B

4.3.3.2.1. 维度表则是引用事实的定性数据

4.3.3.2.2. 维度表以一种叫作星型模式的关系围绕着一个事实表

4.3.3.2.3. 维度表为存储在事实表中的事件提供参考数据、属性和关系上下文

4.3.3.2.4. 维度表比事实表小（形状相反），通常是宽而短

4.3.3.2.5. 缓慢变化维度表(Slowly Changing Dimension，SCD)

4.3.3.2.5.1. 第一类

4.3.3.2.5.1.1. 覆盖现有的维度记录

4.3.3.2.5.1.2. 很简单的但是这意味着你无法访问被删除的历史维度记录

4.3.3.2.5.1.3. 是大多数数据仓库的默认行为

>   4.3.3.2.5.2. 第二类

4.3.3.2.5.2.1. 保留完整的历史维度记录

4.3.3.2.5.2.2. 是我们在实践中最常看到的一种

>   4.3.3.2.5.3. 第三类

4.3.3.2.5.3.1. 第三类缓慢变化维度与第二类相似，但是在第三类中不是创建一个新行，而是创建一个新的字段

4.3.4. Kimball方法允许冗余数据的存在，但是要避免复制相同的维度表，以避免业务定义和数据完整性的漂移

4.3.5. 只适合于批处理数据而不适合于流处理数据

4.4. Data Vault模型

4.4.1. Kimball和Inmon专注于数据仓库中的业务逻辑结构，而Data Vault则提供了一种不同的数据建模方法

4.4.2. 由Dan Linstedt在20世纪90年代创建的Data Vault方法将源系统数据的结构与属性分离

4.4.3. Data Vault不是用事实、维度或高度范式化的表来表示业务逻辑，而是简单地将数据从源系统直接加载到少数几个特制的表中，只需插入即可

4.4.4. 目标是使数据尽可能地与业务保持一致，甚至在业务数据的演进过程中

4.4.5. 三种主要类型的表组成：中心表、链接表和卫星表

4.4.5.1. 中心表存储业务主键

4.4.5.1.1. 查询通常涉及通过业务主键进行搜索

4.4.5.2. 链接表维护业务主键之间的关系

4.4.5.2.1. 跟踪中心表之间的业务主键的关系

4.4.5.2.2. 最好以最细的粒度来连接中心表

4.4.5.3. 卫星表表示业务主键的属性和上下文

4.4.5.3.1. 卫星表中唯一需要的字段是一个由父级中心表的业务键组成的主键和一个加载日期

4.4.5.3.2. 一个卫星表可以包含多个有意义的属性

4.4.6. 用户将查询中心表，它将链接到一个包含查询的相关属性的卫星表

4.5. 去范式化的宽表

4.5.1. 云计算的普及意味着存储是非常便宜的

4.5.1.1. 存储数据的成本已经低到不值得花时间去寻找最省空间的方式

4.5.2. 嵌套数据（JSON和类似的）的流行意味着模式在源和分析系统中是灵活的

4.5.3. 宽表就像它听起来那样，是一个常在列式数据库中创建的、高度去范式化的、包含许多字段的集合

4.5.3.1. 一个宽表有可能有成千上万个列，而关系数据库中的表通常少于100列

4.5.3.2. 宽表一般是通过模式演化产生的，工程师随着时间的推移逐渐增加字段

4.5.4. 对宽表的分析查询往往比对需要许多连接的高度范式化的数据运行得快

4.5.5. 宽表包含了你在一个更严格的建模方法中加入的所有数据，且事实和维度在同一张表

5.1. 由于流数据的无界性和连续性，将Kimball这样的批处理技术转化为流范式是很困难的，甚至是不可能的

5.2. 存在两种主要类型的流：事件流和变更数据捕获

5.3. 建议预测源数据的变化，并保持一个灵活的模式