（7）缓慢变化维的处理方式
维度的属性并不是静态的，它会随着时间的流逝发生缓慢的变化。与数据增长较为快速的事实表相比，维度变化相对缓慢。在维度建模理论中，有三种处理缓慢变维的方式：
第一种处理方式： 重写维度值。说白了就是做update，采用此种方式，不保留历史数据，始终取最新数据。
第二种处理方式： 插入新的维度。采用此种方式，保留历史数据，维度值变化前的事实和过去的的维度值关联。维度值变化后的事实和当前维度值关联。
第三种处理方式： 添加维度列。采用第二种方式不能将变化前后记录的事实归一为变化前的维度或归一为变化后的维度。
（8）企业中处理缓慢变化维的最佳方案
在企业 数据仓库实践中，处理缓慢变化维的方法是采用快照方式。
数据仓库的计算周期一般是每天一次，基于此周期，处理维度变化的方式就是每天保留一份全量快照数据。比如商品维度，每天保留一份全量商品快照数据。任意一天的事实均可以获取到当天的商品信息，也可以获取到最新的商品信息，通过限定日期，采用自然键进行关联即可。
此方法既有优点，也有弊端。
优点主要有以下两点:
简单而有效， 开发和维护成本低
使用方便，理解性好。数据使用方只需要限定日期，即可获取到当天的快照数据。任意一 天的事实快照和维度快照通过维度的自然键进行关联即可。
弊端主要体现在存储的极大浪费上。比如某维度，每天的变化量占总体数据量的比例很低，在极端情况下，每天无变化，使得存储浪费很严重。此方法主要就是实现了牺牲存储获取ETL效率的优化和逻辑上的简化。但是一定 要杜绝过度使用这种方法，而且必须要有对应的数据生命周期制度，清除无用的历史数据。
对上述方案的优化：
基于第二处处理方案的基础之，上采用拉链表存储，即我们可以增加两个时间戳字段。
这个方案的缺陷：
这种存储方式对于下游使用方存在一定的理解障碍，特别是ODS数据面向的下游用户包括数据分析师、前端开发人员等，他们不怎么理解维度模型的概念，因此会存在较高的解释成本。
透明化
底层的数据还是历史拉链表，但是上层做一个视图操作或者在Hive里做一个hook， 通过分析语句的语法树，让查询透明化
select * from A where ds = 20200910
等价于
select * from A where start_dt <= 20200910 and end_dt > 20200910
（9）微型维度到底有没有用
通过将一些属性从维表中移出，放置到全新的维表中，可以解决维度的过渡增长。解决方法有两种，一种是之前讲到的垂直拆分，保持主维度的稳定性；另一种解决方式是采用微型维度。
微型维度的创建是通过将一部分不稳定的属性从主维度中移出，并将他们放置到拥有自己代理键的新表中来实现。这些属性相互之间没有之间关联，不存在自然键。
一般企业对微信维度用的比较少，原因是:
微型维度是事先用所有可能值的组合加载的，需要考虑每个属性的基数，且必须是枚举值。很多属性可能是非枚举型，比如数值类型，如VIP分数、 信用分数等；时间类型，如，上架时间、下架时间、变更时间等。
（10）特殊维度中的递归层次
递归层次指的是某维度的实例值的层次关系
维度的递归层次，按照层次是否固定分为均衡层次结构和非均衡层次结构。
比如:
均衡层次有：
类目：一级、二级、三级、四级
地区：乡镇、区县、城市、省份、国家
非均衡层次有：
公司（比如公司之间的关系，每个公司可能存在一个母公司，但可能没有固定的一级、二级等层次关系）
由于很多数据仓库系统和商业智能工具不支持递归SQL，且用户使用递归SQL的成本较高，所以在维度模型中，需要对递归层次进行处理。
方案一：层次结构扁平化，对于均衡层次结构，采用扁平化最有效
与事实表关联后，有的三级类目为空，导致根据三级类目无法统计交易结果。所以下游为了规避此问题， 如果此类目对应的三级类目为空，则取二级类目；如果二级类目为空，则取一级类目。
所以我们可以采用类目回填的方式，将类目向下虚拟。
方案二： 层次桥接表
针对层次结构扁平化所存在的问题，可以采用桥接表的方式来解决，不需要预先知道所属层级，不需要回填， .也可解决非均衡层次结构的问题。与扁平化方法相比，该方法适合解决更宽泛的分析问题，灵活性好；但复杂性高，使用成本高。
（11）多值维度的处理方式
事实表的一条记录在商品维表中有多条记录与之对应，比如买家一次购买了多种商品。
多值维度的处理方式有三种：
第一种：降低事实表的粒度， 将交易订单设置为子订单粒度，对于每个子订单，
只有一种商品与之对应。对于其中的事实，则采用分摊到子订单的方式来解决。
第二种：采用多字段。比如在房地产销售中，每次合同签订都可能存在多个买受
方的情况。如夫妻合买，对于合同签订事实表，每条记录可能对应多个买受方，而合同已经是此事实中的最细粒度，无法通过降低粒度的方式来解决，由于合同签订的买受人不会太多，所以一般采用多字段方式。
第三种：采用较为通用的桥接表。桥接表方式更加灵活、扩展性好。但逻辑复杂、开发和维护成本高。
桥接表包含和事实表关联的分组KEY，以及作为买买方维表外键的买受方ID.如果事实表的一条记录对应两个买受方，则桥接表针对这两个买受方建立两条记录，分组KEY相同。
（12）多值属性的处理方式
维表中的某个属性字段同时有多个值，称之为多值维度。它是多维度的另一种表现形式。互联网公司的电商项目中存在很多维表，如商品的SKU维表、商品属性维表、商品标签维表等。每个商品均有一到多个SKU、一到多个属性和一到多个标签，所以商品的SKU、属性、标签都是多堆垛的关系。
SPU = Standard Product Unit （标准化产 品单元），SPU是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性。通俗点讲，属性值、特性相同的商品就可以称为一个SPU。例如，iphone4就是一 一个SPU， N97也是一个SPU， 这个与商家无关，与颜色、 款式、套餐也无关。
SKU=stock keeping unit（库存量单位），SKU即库存进出计量的单位，可以是以件、 盒、托盘等为单位。在服装、鞋类商品中使用最多最普遍。例如纺织品中一个SKU通常表示: 规格、颜色、款式。
SKU是物理上不可分割的最小存货单元。在使用时要根据不同业态，不同管理模式来处理。比如一香烟是50条，一条里有十盒，一盒中有20支，这些单位就要根据不同的需要来设定SKU。
常见的多值属性处理方式有三种：
第一种处理方式是保持维度主键不变，将多值属性放在维度的一个属性字段中，通过K-V对的形式
第二种处理方式是保持维度主键不变，将多值属性放在维度的多个属性字段中。
比如卖家主营类目，由于卖家店铺中可能同时会销售男装、女装、内衣等。所以卖家主营类目可能有多个，但业务需求是计算TopN，
第三种处理方式是维度主键发 生变化，一个维度值存放多条记录。
主键是商品的ID + SKU的ID
