一文搞懂什么是“退化维度”

引言

“维度退化”是数据仓库维度建模中的概念，当你想要理解这个名词的时候，相信你一定大致了解什么是事实表、维度表了，那就直接开始吧。

正文

一、官方解释

百度百科的解释如下：

退化维度（Degenerate Dimension,DD），就是那些看起来像是事实表的一个维度关键字，但实际上并没有对应的维度表，其中，事实表的粒度就是文档本身或文档中的一个分列项。具体怎么理解呢？在传统的父子关系型数据库中，事务编号是事物标题记录的关键字，比如订单编号、发票编号，这样的纪录包含了诸如事务日期、供应商标示这样在总体上对事务有效的所有信息。但在给出的维度模型中，已经将这些令人感兴趣的标题信息抽取出来放到其它维度中去了。但这个事务编号仍然十分有用，因为它可以作为组关键字而将单个事务中处理的明细集中在一起。
尽管这个事务维度看起来是一个维度关键字，但当把事务维度所有的描述性项目进行剔出后，形成维度为空。诸如这种事务编号、固有的操作型票据编号，应该自然的放入事实表中，而不用连接到维度表。退化维度在事实表粒度表示单个事务或事务分列项目时是很常见的，因为它标示父实体的惟一标示。订单号，发票号与提货单编号等几乎总是以退化维度的形式出现在维度模型之中。同时，退化维度在事实表主关键字方面也有一定作用。比如将订单事实表主关键字可以由退化的订单编号和产品组关键字组成。

二、实例解释

是不是看了官方解释感觉好像明白了又有点迷糊，那接下来就让我拆开揉碎了解释一番。

假设我们有这样一张事实表（多事务）：服务订购订单事实表

表结构如下：

字段	字段中文名
order_id	订单ID
buyer_id	订购者ID
severice_id	服务ID（691175：商城版；690529：小程序；2085817039：旺铺卡）
severice_name	服务名称
order_type	订单类型（0:新订购，1:续订，2:升级）
crt_order_time	下单时间
pay_order_time	支付时间
pay_order_amt	支付金额（元）

从表结构可以看出，该表存储的内容是买家每下单一种服务时产生的相关信息记录。为了站在订购者的角度去分析数据（如：当月各个渠道总支付金额数），理论上可以设计一张订购者维表，存储订购者的相关属性（性别、年龄、渠道来源、电话、地区等等）。

事实表的粒度就是文档本身或文档中的一个分列项：事实表中一条记录所表达的业务细节程度被称为粒度。通常粒度可
以通过两种方式来表述：一种是维度属性组合（分列项）所表示的细节程度；一种是所表示的具体业务含义（文档本身）。

而在这张事实表中，粒度即为订单ID。

那么在上面这张事实表中，哪个字段看上去像维度关键字，却又不需要为它单独设计一张维表呢？

如果设计一张服务维表是否可行，包含字段（服务ID、服务名称、服务类型、服务上架时间、服务时长等等）？

退化维度是这样一种维度：过于简单或诸如订单ID这种量级很大的维度，不值得单独创建一个维表进行存储。

那么，订单ID和服务ID（服务维表可剔除，维度属性可放在事实表中）都可以作为退化维度

但这个事务编号仍然十分有用，因为它可以作为组关键字而将单个事务中处理的明细集中在一起：如统计各项服务的订单个数，severice_id作为组关键字，汇总该维度下的订单个数count(order_id)

至此，再看看官方解释就不难理解了

三、退化维度优点

减少事实表和维度表的关联

该技术减少维度的数量，简化维度数据仓库模式。简单的模式比复杂的更容易理解，也有更好的查询性能。

如果存在退化维，ETL的过程会变得非常容易

可以让group by 等操作变得更快

四、总结

当一个维度没有数据仓库需要的任何数据的时候就可以退化此维度，需要把退化的相关数据迁移到事实表中，然后删除退化的维度。退化维度没有对应的维表，但可以获取与之相关的事实，如上订单号对应的订购者，服务对应的订购金额等。

Kimball书中对退化维度的描述为：操作型事务控制号码，例如：订单号码，发票号码，提货单号码通常产生空的维度，经常保存为事实表中的退化维度。退化维度是没有对应维度表的维度键。