目录

• 前言

• 维度表的类型

• 维度表的使用场景

• 维度表的键和属性

• 小结

前言

前面从宏观的角度，讲述了7何问题。那么从微观的角度，具体的改怎样的来建设一致性维表呢？ 本篇从表的类型和使用场景，以及建设过程中键的设置和属性的设置做一些总结。

维度表的类型

总体上讲，一般分为两类 TYPEI（不变） 和TYPEII表（变化）。  

• TYPEI

1. 维度属性值持久不变，只有新增和删除。
2. 属性能够在一定周期（比如一天）内不会变化。

• TYPEII

1. 缓慢变化维。部分维度属性可变化，但是变化的频次很低。
2. 快速变化维。部分维度属性可变化，但是变化的频次很高。

• 杂项维度

1. 大量不同的零散的维度整合在一起

使用场景

• TYPEI维表适用于大多数这种维度属性经久不变的信息描述，比如日期维度的大多数属性，门店的地址和名称等属性。一般来讲业务上的维度信息都是当天不变的，而且DW用来做数据统计分析是按照一定周期来看的，大多数情况是按天为周期。所以从数据分析的角度上来看，虽然所有维度属性不能能完全不变化，但是只要能获取到当天结束时候的维度信息的快照就可以满足业务上的数据需求。对于生命周期完全不变化的可以建成全量表，其他可以建成快照表。在不明确的情况下优先选择快照表。快照也不会占用太多的空间。
• TYPEII
  • 缓慢变化维。在有些情况下，业务上的统计周期相对比较短，就不能按照TYPEI的情况来建设表。此时如果维度变化的频次没有那么快的话，可以建成缓慢变化维度表。缓慢变化维表有几种建设方法，比较常见的一种就是采用effect_from_dt（记录有效起始时间），effect_to_date（记录有效结束时间），current_flag（当前是否有效）等字段的组合。比如营销过程中，一家门店在某几个小时采用的营销手段不同，为了获取当天所有交易的成本，如果没有现成的营销数据的话，完全可以按照交易的时间来匹配当时的营销活动，从而获取营销的成本。
  • 快速变化维。情景跟缓慢变化维差不多，唯一的问题在于维度属性变化超级频繁，甚至是秒级分钟级的变化频次，这时候如果依然采用缓慢变化维的构建方式，维表的数据量暴增的很厉害。而且大多数的维度属性没有变化，只有个别的属性变化的厉害而已，导致大量的空间存储的都是不变的信息。这种情况的结局方案是，绝大多数不变的或者变化频次很低的属性集合建成TYPEI或者缓慢变化维表， 而针对变化频次超快的属性单独建立成微型维度表。这两张表没有依赖关系，都是各自挂在事实表上的。

主键和属性

维表主键的选择有两种：自然键，代理键。自然键是具有业务含义的ID，比如身份证号，日期等等，代理键是自动生成的唯一的键。这两种改如何做出选择呢？ 如果说业务ID比较有该业务的独特性（不需要跟其他业务集成），或者具有共享性（比如公司级别的，门店ID等等），可以考虑使用自然键，特别的是日期维表直接使用日期来做主键。如果说需要不同的业务维度信息进行整合集成，这种情况比较适合生成代理键来做主键。

小结

建设维表看似比较简单，大多数情况下业务库也会直接有，但是除了需要将不同层次的维度进行冗余（星型模型），也需要在细节上把握以下维度建设的注意，毕竟维度的错误将引起所有数据的错误。

PS 最近一直在加班啊，近2周没有好好总结了，本篇维度建设重新开个头，争取抽出一些时间好好学习和总结，只有总结才能提高啊。

搭建数据仓库第08篇：逻辑建模–5–维度建模核心之一致性维度2