维度表设计

维度表设计

维度表表示参与到业务过程中的一个业务实体(如，商品、卖家、买家、优惠券、时间等等)，每一行数据表示的是一个业务实体的实例(如，商品维度表中的一行表示的就是一个商品)，提供了业务流程的上下文。

---

1 基础

1.1 结构

每个维度表都包含单一的主键列 。维度表的主键可以作为与之关联的任何事实表的外键，维度表行的描述环境应与事实表行完全对应 。维度表通常比较宽 ，是扁平型非规范表 ，包含大量的低粒度的文本属性 。

• 代理键&自然键
  

• 维度属性：维度所包含的表示维度的列的列，称为维度属性，一般是查询约束条件，分组和报表标签生成的基本来源。

1.2 退化维度

存储在事实表中无维度表的维度，一般除了主键外没有其他内容

---

2 维度变化处理

2.1 缓慢变化维

与事实表相比变化比较缓慢。

• 重写：直接全量导入，覆盖旧数据，保存每天所有的最新状态的数据
  优点： 易于实现且不用建立额外的维度行，效率比较高，可以查看最新数据
  缺点： 无法反映历史情况，事实表和 OLAP 多维数据库将会有重复计算的问题。

• 插入新行：使用拉链表，在维度表中增加新行 ，新行中采用 修改的属性值。要实现该方式 需要维 度主键更具有一般性 ，不能仅采用自然键或持久键 ，因为采用该方法时经常会出现多行描述同样成员的情况 。在为维度成员建 立新行时 ，将为其分配新的 主代理键，在修改发生后， 将其作为所有事实表的外键，直到后续变化产生新维度键并更新维度行 。 当变化类型 2 发生时，最少需要在维度行中增加 三个额外列 ：行有效的日期／时间戳列；行截止日期／时间戳列；当前行标识 。
  

• 增加新属性：在维度表上增加新属性以保存原来的属性值 ，新属性值重写主属性 。这种变化有时称为替换现实 。商业用户可以利用当前值或替换现实来分组或过滤事实数据 。此种缓慢变化维度技术不太 常用。
  

• …

2.2 快照维表

基于一定的周期（例如：天），保留一份全量的维表数据。此方法不按照kimball维度建模规定使用代理键作为维表的主键（对于每个表生成稳定的全局唯一的代理键难度很大，使用代理键会大大增加ETL的复杂性，对ETL任务的开发和维护成本很高）
优点：开发和维护成本低；使用方便，理解性好。
缺点：占用磁盘空间比较大，极大的浪费存储。

2.3 极限存储

情况：
历史拉链存储，本质是利用维度模型中缓慢变化维新增行的处理方式。
实现方式：
（1）新增两个时间戳字段：start_dt、end_dt（表示生命周期结束的时间，当这条记录生命周期结束时，设为无穷大）。
（2）分区字段为时间戳字段。
优点：占用磁盘空间适中,可以查看最新数据也可以查看历史数据
缺点：不易理解，使用难度大；分区数量会随着时间推移越来越多。
可以做优化：比如做视图，分月做历史拉链表。

---

3 设计过程

3.1选择实体

选择实体，也就是维度表所要描述的抽象对象。如，互联网电商在交易过程中涉及到的实体有：买家、卖家、订单、广告等等，当然还有一些在不同业务场景下衍生出来的一些业务抽象实体，如优惠券、活动、商圈等都可以作为维度实体。
实体的选择主要是结合业务流程，在需要建模的业务流程环节涉及到了哪些参与者，这些不同的参与者便是维度表描述的实体对象，维度表中的属性，就是用来区分不同实体的特性。

3.2 确定主维表

确定主维表，主要是识别出维度表的主要数据来源。通常，业务系统中也会将相同类型业务实体进行统一存储(即一张表)，亦或是在大型企业有建设业务中台会提前做同类业务实体的数据融合(如，商品中心、用户中心等)。但在没有类似业务中台可以直接获取全量维度实体数据的情况下，就需要自行确定业务实体数据的来源，并做融合。
一般情况会将常规主要业务流程中产生的业务系统数据做为主维度表，因为其一般是维度表的主要数据来源，并且数据准确、丰富。

3.3 确定辅维表

辅维表存在的目的有两方面。一方面是补全主维表在维度实体的数据(如，用户大部分是通过独立注册登录APP，还有小部分是通过微信登录、支付宝登录等等)；另一方面是为了寻找维度表所表示的业务实体的一些其他属性描述辅助表(如，商品类目表、商品属性表、用户家庭关系表等)，这些辅维表用来丰富维度表的属性描述，增强维度表的表现性，同样也能扩展维度表的分析能力。

3.4 识别维度属性

维度表的维度属性一般可以分为相对稳定的固化属性和变动频繁的动态属性

• “固化属性”通常是和维度实体关系相对紧密且较为稳定的固有属性，不依赖或很少依赖于其它的业务活动过程(如，商品维度表中的商品名称、商品品牌等)；
• “动态属性”通常是只能基于特定的事务过程或者活动关联，在维度实体的层次上汇总得到的一些统计属性(如，描述商品的近30天销量，首次上架日期等)。
  由于“固化属性”和“动态属性”的变更周期差异巨大，一般会在维度表的构建过程中结合具体的场景进行拆分，一方面是保证维度表能够高效的产出，另一方面也是为追溯历史数据提供合理的技术实现。

---

参考

• 数据仓库系列4-维度表 - 知乎 (zhihu.com)
• 维度表 - CSDN
• 一篇文章搞懂数据仓库：维度表（设计原则、设计方法）不吃西红柿丶的博客-CSDN博客_维度表怎么做
• 数据仓库维度建模——维度表设计_我爱大芬的博客-CSDN博客_维度表设计
• 关于数据仓库中变化历史数据处理方式：全量表、快照表、拉链表_我玩的很开心的博客-CSDN博客_全量表和快照表
• 事实表与维度表_宝哥大数据的博客-CSDN博客_事实表 维度表