维度表的更新
维度表修改规律:
- 绝大部分维度表都是不变的
- 很多维度虽然会变化，但是变化的很缓慢
- 源记录产品键不会改变
- 产品描述及其他属性的改变都很缓慢
- 在源OLTP 系统中，新的值会覆盖旧的值
- 在数据仓库中，覆盖维度表的属性并不总是适当的做法
- 修改维度表的方法依赖于变化的属性，以及数据仓库必须保存什么信息
对维度表修改的类型
进入维度表中的信息，在操作系统中仍有可能发生改变，在维度设计方案时，确定数据源的变化情况在维度表中如何表示非常重要，这一想想称为缓慢变化的维度，简称缓慢变化维。
改正错误
修改原则
- 这些修改与改正源系统中的错误有关
- 这种修改在源系统中有时没有影响
- 源系统中旧数值不应保留
- 源系统中修改不需要在数据库中保存
修改方法 - 新的值覆盖维度表中旧数值
- 属性的旧数值不需要保留
- 对维度表没有其他修改
- 维度表中的键或任何其他键值均不受影响
- 这类修改是最容易实施的
保存历史数据
修改原则
- 他们通常与源系统中的修改相关
- 需要在数据仓库中保留历史数据
- 这一类修改将数据仓库的历史分区
- 对同一属性的每一个修改都要保留
修改方法 - 在维度表中增加一条新记录，该记录有修改后的数值
- 维度表中可以包含一个有效的日期字段
- 对维度表中原来数据不做修改
- 原来记录的键不受影响
- 插入新的记录，该记录有一个新的替代键
暂时的修改
几乎所有的对维度表的修改都属于前两类修改，第一类是最常见的，第二类修改保留了历史数据。
修改原则
- 它们通常与源系统的临时修改有关
- 需要利用新旧属性值跟踪历史数据
- 新旧两个值用于比较改变所带来的效果
- 它提供了向前向后追踪的能力
修改方法 - 对受影响的属性，在维度表加入旧的字段
- 将现有的字段赋值给旧的字段
- 将新的值赋值给现有的字段
- 加入一个现有的有效日期
- 记录的键不受影响
- 不需要增加新的维度表记录
- 现有的查询可以无缝转换到现有的值
- 所有使用到旧的值的查询需要做相应的修改
- 只对一次只做一个临时修改更为适用
- 如果还有后续的修改，则需要使用更复杂的技术
对所有的维度属性，选择并文档化适当地缓慢变化的响应方式，如果难以确定，选择变化类型2是最安全的。
应该认识到对缓慢变化的处理对ETL开发人员来说充满艰辛这一事实，无论是复杂性是从处理时间考虑，缓慢变化的需求对加载过程的每个部分都会造成影响，ETL开发人员可能需要面对确定是否所有变化都完全发生的挑战。
时间戳维度
当需要支持对维度值特定时间分析，与事实无关的时采用时间戳维度
时间戳维度允许三种形式的特定时间分析：
- 方便地按照时间顺序对变化的历史情况进行排序
- 快速选择影响特定日期的维度行
- 容易确定当前收到影响的维度行
- 类型2缓慢变化维度保留了属性值的历史，并允许每个事实与正确版本关联，尽管它保存了事实的历史，但却不足以提供对特定时间的分析。
- 通过事实表追踪历史的变化
- 时间戳维度用于追踪维度表自身变化的历史，而不是通过另外的事实表，维度配置额外的列用于为一行获取有效日期和截止日期。额外的列可以追踪变化的原因。
- 如果需要跟踪更细粒度的变化，则可以通过添加列来捕获记录变为生效和截止日期来完成
- 时间戳维度的构建将会给负责加载和维护维度表的开发人员增加额外的负担，当发生类型2变化时，需要识别先前行，并更新时间戳列。
- 对那些表示密切关注的实体的维度表来说，时间戳用来补充类型2变化的追踪，这将获得高效地ETL处理，当未来需要增加额外的事实表时，时间戳会极大地简化加载过程。
- 为每个维度表都构建时间戳没有必要，如果不需要开展时间点分析，就无须增加额外的工作。
- 与其他维度表一样，时间戳维度表能够链接一个事实表用来分析。
混合技术
当需求冲突，需要采用多种响应方式时，采用混合技术。
采用混合技术的原因：
- 类型1和类型2混合
- 不能应用类型3，记得属性的每个版本都不能用来区分变化前后的事实，每个值都能用来研究所有事实，但是没办法区分在单个事务繁盛时那个版本是有效的
通过提供两个不同的维度列，类型1和类型2混合设计可以处理相同来源的属性，一个被指定为类型1属性，用于按照新值对所有的事实进行分组，另一个被指定为类型2属性，用于按照历史值对所有事实进行分组。
只有在存在真实分析需求时才能实施混合变化，操作型报表可以留给操作型系统来做。
凝固属性
分析型需求偶尔需要保护其原始状态，对修改的属性，什么事情也不做。