在数据仓库的维度建模中，退化维度（Degenerate Dimension） 是一个重要的概念，它特指那些没有关联独立维度表、直接存在于事实表中的业务过程标识符或键。
核心特征：
它们通常直接来源于OLTP中的事务标识符，例如：
订单编号（order_id）
发票编号（invoice_number）
提货单编号（pick_ticket_number）
交易流水号（transaction_id）
无独立维度表： 这是最关键的特征！与日期、产品、客户等维度不同，退化维度没有对应的维度表来存储其描述性属性（如订单日期、客户姓名、产品描述等）。这些描述性属性通常已被建模为事实表本身的字段，或者被拆分到其他相关的维度表中。
作为事实表中一部分： 退化维度通常作为事实表的主键（或主键的一部分），用于唯一标识事实表中的一行（即一个特定的事务实例）。
退化维度与普通维度的区别：
|----------|--------------------------|-----------------------------|
| 特征 | 普通维度 (Regular Dimension) | 退化维度 (Degenerate Dimension) |
| 是否有独立维度表 | 是 | 否 |
| 存储内容 | 描述性属性、文本字段、层次结构 | 仅业务标识符本身（如订单号） |
| 作用 | 提供分析的上下文、分组、过滤、切片 | 唯一标识事务、链接回源系统、事务级分析 |
| 示例 | product, user | orderid |
为什么叫"退化"？
在OLTP中，这些标识符（如order_id）通常是主键，关联着包含丰富描述信息的表（如订单头表）。
在维度建模中，当我们把与这个订单相关的所有描述性属性（如客户、日期、产品、销售员、支付方式等）都提取出来，分别建模到各自的维度表中后，原本在源系统中的order_id表就"退化"了------只剩下一个孤零零的order_id字段本身，没有其他属性可提取（或不需要提取到单独的维度表）。这个剩余的order_id字段就变成了事实表中的一个退化维度。
至此，我们也得出了如何判断字符按是否为退化维度的方法：
检查事实表中的字段。
问："这个字段是业务事务的唯一标识符吗？（如订单号、发票号）"
问："这个标识符有对应的、包含描述性属性的维度表吗？" 如果答案是"没有"，那么它就是退化维度。
退化维度的作用与价值：
核心作用是唯一标识事实表中的每一行记录（一个特定的事务实例）。当需要从数据仓库钻取回源OLTP系统查看原始事务细节时，退化维度（如order_id）提供了关键的链接点。同时还有如下功能：
事务级分析： 支持对特定订单、发票等事务的详细分析。
事实表主键： 通常作为事实表主键或主键组成部分，保证事实记录的唯一性。
分组与过滤： 可以在查询中用于按特定订单、发票等进行分组或过滤。
举例说明
拿 销售订单 举例说明下：
事实表：fact_sales_order
字段举例：
order_id (退化维度) - 唯一订单号
order_date_key (外键 -> dim_date)
customer_key (外键 -> dim_customer)
product_key (外键 -> dim_product)
salesperson_key (外键 -> dim_salesperson)
quantity_ordered (度量)
unit_price (度量)
order_id 存在于事实表中。它没有对应的dim_order表（因为订单日期、客户、产品、销售员等信息都已被建模到各自的维度表中）。order_id 的唯一作用就是标识这个特定的订单行项目，并允许必要时通过它查询源系统的原始订单。因此，order_id 是一个典型的退化维度。
总结：
退化维度是数据仓库维度建模中处理事务标识符的一种标准方法。它代表了那些在源系统中关联着丰富描述信息，但在维度模型中因描述信息已被提取到其他维度表而"退化"只剩下标识符本身的键。它的核心价值在于唯一标识事实记录，并提供链接回源OLTP系统的桥梁。理解并正确识别退化维度对于构建高效、清晰的星型/雪花型模型至关重要。