一、退化维度
1、概念
退化维度的维度表可以被剔除，从而简化维度数据仓库的模式。
当一个维度没有数据仓库需要的任何数据的时候就可以退化该维度。需要把退化维度相关数据迁移到事实表中，然后删除退化的维度。
典型的退化维度有操作型事务控制号码，例如：订单号码，发票号码，提货单号码等
2、针对订单号的退化维度
订单事实表中的每个包含明细项的行都包括作为退化维度的订单号。与操作型表头/列表或父/子数据库不同，维度模型中的订单号通常与订单表头没有关联。我们可以将订单表头中的信息分到不同的维度中，例如订单日期和客户，但是订单号没有任何维度表与它连接，所以它是一种退化维度。
然而，这种退化维度存在于事实表中也有一定的作用，比如可以用来过滤事实表和连接数据仓库与后端操作型系统。
注意：退化维度通常被保留作为操作型事务的标识符，不能将它们作为一种坚持要在事实表中使用神秘模糊代码，而不与维度表连接以获得描述性解码的接口。
二、杂项维度
1、概念
事务性商业过程中通常产生一系列混杂的，低粒度的标识和指示器。与其为每个标识或属性定义不同的维度，不如建立单独的将不同维度合并在一起的杂项维度。这些维度，通常在一个模式中标记为事务型概要维度，不需要所有属性可能值的笛卡尔积，但应该只包含实际发生在原数据中的合并值。
2、处理方式
- 忽略这些标示和指标。 要是这些标志和指标完全没有人访问和使用，或者说，这些指标和标志难以理解且不一致，可以在建模的时候删除它们。
- 保持事实表行中的标志和指标不变。
- 将每个标志和指标放入其自己的维度中。 如果外键的数量是处于合理的范围（不超过20个），则在事实表中增加不同的外键是可以接受的。但是，若外键列表已经很长，则应该避免将更多的外键加入到事实表中。
- 将标识和指标存储到订单表头维度中。 在订单事实表中，与其把订单号当做退化维度，不如视其为低粒度指标和标志作为属性的普通维度。
注意：杂项维度是对低粒度标志和指标的分组，通过建立杂项维度，将标志和指标从事实表中移出，并将它们放入到有用的多为框架中
处理这些标志和指标的适当替换方法是仔细研究它们并将它们包装为一个或多个杂项维度。杂项维度可提供地方用于基于这些标识的约束和报表，事实表与杂项维度之间还应存在一个单一的，小型的代理键。
杂项维度的建立需要考虑所有标志同时发生时最大的数据量。如果有5个标志，每个标志仅包含3个值，那么杂项维度最多只有243行。但是如果每个标志有100个值，那么该维度最多有1亿行。这时候，就需要将这些维度拆开建立多个维度了。
下图是订单标识杂项维度的示例行：
