数据模型的演变
3NF
3NF最一开始是应用于OLTP系统中，后来Inmon采用3NF来构建企业数据仓库。
优点
- 可以很方便的扩展
- 减少数据冗余
- 与源系统结构基本保持一致，易于理解，同于也方便进行数据加载
- 可以支持实时的数据加载
缺点
- 数据查询的成本比较高，需要关联多张表
- 父子关系的处理会比较复杂；而且当父表发生变化时，所有的子表都会进行相应的处理
- 构建企业数据仓库的时间会比较长
- 为了适用于数据仓库，保留历史数据，需要在主键中增加时间，增加了处理的复杂度
Star Schema
Star Schema，是一种反范式，由事实表与多个维度表组成。Kimball的维度建模就是基于它来构建。
优点
- 面向主题，对需求方更加易懂
- 可以很方便地做多维分析
- 聚集等复杂查询性能较好
- 相比3NF，构建起来更加迅速
- 可以高效地存储历史数据
缺点
- 无法实时加载数据，而且加载处理的成本会比较高
- 由于是反范式，数据有所冗余
- 不太灵活，无法及时响应业务规则的变更
- 事实表粒度的问题
- Fact granularity
事实表的统计粒度越小，其记录条数就越多 - Fact table size
每在事实表中增加一项维度，其记录数就要再乘上新维度的条数 - Changing attributes
如果维度的属性发生了变化，则需要记录维度的历史信息，否则则会导致历史的统计信息有误
- Fact granularity
Data Vault
Data Vault是一种混合的构建方式，它不是一种adaption，而且专门解决数据仓库领域问题的一种方案。它结合了3NF与Star Schema两种方式的优点，比如：
1. 结构灵活，易于扩展，可以自由地增删
2. 可以实时加载数据
3. 可以方便地追溯历史
4. 由于不同表之间的解耦，ETL的任务可以并发执行，效率提升
5. 很方便地转换为维度模型
但是也会存在一些缺点：
1. 同样会存在大量的join，影响性能
2. Link表一直是append，导致已经过期的关系无法清理。但是其实过期的关系，反映的也是历史上曾经发生过的关联，在回溯历史的时候，同样会用到。
3. 由于将关系、属性从实体中抽取了出来，属性还会继续做拆分，那么其对象的数量是要比3NF多很多的。
4. 从源系统的表，抽象到Hub、Link等，需要资深专业数据建模人员的参与建设。
Data Vault架构
Data Vault由Hub、Link、Satellite三部分组成。
Hub
Hub对应着业务中的一个实体，但是Hub表中一般只有业务主键，不包含其他属性字段。
除了业务主键，一般还会包含以下字段：
Surrogate Key
代理主键，是可选的，可以是一个自增序列
Load Date Time Stamp
记录了这条记录第一次加载到数据仓库中的时间
Record Source
为了方便追溯，还记录了该条记录的来源
总结
源系统的数据加载到Hub表中后，Hub表的记录就不会再变动了。因为它只包含了业务主键，属性的变动不会影响到Hub表，这样源系统新增的记录就可以实时地加载到Hub表中。
Link
Link对应着业务中实体之间的关系，或者业务系统中发生的事务。它会包含以下字段：
Surrogate Key
代理主键，可选。因为一般Link表的主键是由多个Hub Key组成的复合主键，为了性能等方面的考虑，可以考虑增加代理主键。
Hub Keys
Link所关联的Hub表的主键
Load Date Time Stamp
记录关系第一次创建的时间
Record Soure
方便追溯，记录来源
总结
Link表的记录同样是只允许append，且创建后就不会变动，同样支持实时加载。和3NF不同的是，不管是1:N，还是N:N的关系都会抽取出来做为Link。如果业务规则是必须要1:N，就需要额外的特殊处理了。
Satellite
Satellite存储的是Hub或Link的上下文，或者说是描述信息。这些信息会随时间发生变动，而这些变动都应该被有效地存储起来。Satellite包含如下字段：
Satellite Primary Key
Satellite表的主键由两部分组成，因为其上下文信息经常变动，而每次变动都要被记录下来，因为主键上还要额外带上时间戳。
Hub／Link Primary key
与Hub／Link表的主键保持一致
Load Date Time Stamp
记录这一条记录是何时加载到数据仓库中的
Satellite Optional Primary Key
如果Satellite表比较特殊，比如用户由多个地址，那么地址的顺序号可以作为主键的一部分。
Record Source
方便追溯，记录来源
总结
Satellite由于需要记历史，通常会采用SCD的拉链记历史方式。但是如果某个表的属性变化频率不太一致，都放在同一个Satellite表中，就会造成存储的浪费。所以，一般会根据变化频次，相关性等原则，将属性分组，放在不同的satellite表中。
Point In Time
如果一个Hub表有多个Satellite表，不同的Satellite的更新频率不同。为了数据一致性，也就是说如果要统计某一天的指标，那么所有的Satellite表都应该能回溯到指定的那一天。这样，就需要一个Point In Time，在每一次属性发生变更时，对所有的Satellite表进行“拍照”，记录当时每个表的Load Date，以确定Satellite表的主键。
但是，如果Satellite表采取拉链记历史的方式来追溯历史，那么其实这个PIT是不需要的。PIT有个好处，就是所有的关联都是等值关联，查询的性能会比较好。