1. 维度建模生命周期
关键原则：关注业务需求，为用户展现维度结构数据，过程可管理，迭代开发项目
业务需求的分析通常会有一些技巧，比如 DDD 领域驱动设计等
2.事实表设计
事实的类型（可加、半可加、不可加）
1.可加事实 - 指的是该度量可以按照和事实表关联的任一维度进行
汇总。
2.半可加事实 - 指的就是该度量在某些维度下不可进行汇总，或者说汇总起
来没有意义
3.不可加事实 - 指的是该度量在所有与该事实表关联的维度下都不可进行汇
总3.多维体系结构
多维体系结构（MD）有三个关键性概念：总线架构（Bus Architecture），一致性维度（Conformed Dimension）和一致性事实（Conformed Fact）
多维体系结构
后台（数据准备区）- 是一致性维度的产生、保存和分发的场所
前台 - MD 架构对外的接口前台包括两种主要的数据集市
原子数据集市 - 保存着最低粒度的细节数据，数据以星型结构来进行数据存储
聚集数据集市 - 粒度通常比原子数据集市要高，和原子数据集市一样，聚集数据集市也是以星型结构来进行数据存储总线架构示例
一致性维度
在同一个集市内，一致性维度的意思是两个维度如果有关系，要么就是完全一样的，要么就是一个维度在数学意义上是另一个维度的子集。
建立新的数据集市时，需要在后台进行一致性维度处理，根据情况来决定是否新增和修改一致性维度，然后同步复制到各个数据集市。
一致性事实
一致性事实主要需要保证两点
第一个是 KPI 的定义及计算方法要一致
第二个是事实的单位要一致如果业务要求或事实上就不能保持一致的话，建议不同单位的事实分开建立字段保存。
4.事务事实表
事务事实表记录的事务层面的事实，保存的是最原子的数据，也称“原子事实表”。
5.周期快照事实表
周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，时间间隔如每天、每月、每年等等。
典型的例子如销售日快照表、库存日快照表等。它统计的是间隔周期内的度量统计，如历史至今、自然年至今、季度至今等等。6.累计快照事实表
累积快照事实表记录的不确定的周期的数据。累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。
7.三种事实表的区别
事务事实表中一条交易记录会每天有一条数据来记录整个交易过程；而累积
快照事实表只会有一条记录，数据会一直更新直到过程结束。
累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，
它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。
周期快照事实表记录的是重复的可预测到的时间间隔的事实，例如账户月结
余事实表，用来记录每个月末的账户结余信息。
8.维度表设计
在维度建模中，把度量称为事实，将环境称为维度。
维度属性指的就是维度的列。
维度的设计过程，就是维度属性的确定过程
以商品维度表的设计为例对维度设计的方法进行详细说明
(1)选择维度或者新建维度：在建设维度表中，要保证其在数仓中的唯一性，也就是说只允许有一个商品维表。
(2)确定维度主来源表：在此处一般指的就是 ODS 层（与业务系统表结构一样）的商品表，如 s_items_info，此表就是维度的主来源表。
(3)确定相关维表：数据仓库的设计遵循数据的高度整合原则。在确定主来源表后，还需要根据实际需求，扩展商品的相关信息如：类目、所属卖家、所属店铺等。
(4)确定维度属性：在维度主来源表+相关维表的基础字段上，创建或补充维度属性：
1.尽可能地生成新的维度属性
2.尽可能给出一些包含文字描述的属性，这些属性不应该只有编码,更应该是真正的文字。如一级类目 ID，一级类目名称。
3.某些特殊的度量（数字）有可能也能作为维度属性。如商品单价，既在观察商品价格段时可以作为维度，也可以在求平均商品价格时作为事实。（区分数值型字段是维度还是度量的方法之一，就是看字段内容枚举值的多寡，多很可能是度量；少很可能是维度，但不绝对）
4.尽量沉淀出常用、公用的字段。如商品状态，需要通过上架时间判断。维度的层次结构
维度是有层次的，也是反范式的
以商品维表举例
【商品维表】（商品 ID，商品名称，商品类目，一级类目 ID，一级类目名称，二级类目 ID，二级类目名称，三级类目 ID，三级类目名称，上架时间）
⚫ 类目层次：一级类目 》二级类目 》三级类目
⚫ 时间层次：年 》月 》季度 》周 》天维度层次结构的用途：数据钻取。
数据钻取分为上钻（维度减少）和下钻（维度增多）常见的维度层次结构有以下几个：日期，地址，类目等
在星型模型和雪花模型中维度表设计的区别：
一致性维度和交叉检查
交叉探查：将不同数据域（不同业务模块的数据）的事实数据，根据同一个维度做合并的情况就叫交叉探查
一致性维度：
Kimball 的数据仓库总线架构提供了种分解企业级数据仓库规划任务的合理方法，通过构建企业范围内一致性维度和事实来构建总线架构
维度建模要求必须有一致性维度
维度是统一设计的，每个维度表都是唯一不重复的，要做到全局通用。否则会导致数据查询的时候不一致甚至错误如何才能保证有一致性维度
共享维度 - 每个维度全局都唯一
一致性上钻 - 其中一个维度的维度属性是另一个维度的维度属性的子集，且
两个维度的公共维度属性结构和内容相同
交叉属性 - 两个维度具有部分相同的维度属性维度设计高级主题
什么维度需要整合
维度的集成的过程可以概括为：将维度相关的维度属性做到统一
1.来源系统多的情况下，表名、字段名要统一。
2.公共代码和编码值统一
3.业务含义相同的表统一：
(1)采用主从表方式（如商品维度可以拆成（商品主信息维表 + 商品扩展信息维表））
(2)统一到一张表（如果表字段重合度比较低，会出现大量空值情况）
(3)不合并（如果源表表结构实在差异太大，可以不合并。）什么维表需要拆分
当一张维度表中包含多个类别、加工逻辑十分困难、有部分维度属性可以单独处理或者不常用时，考虑将维度拆分。
关于维度表拆与分的考虑依据：当业务变化时，模型是否容易扩展；是否易用；查询效能问题
拆分方法
(1)水平拆分 — 数据层面
(2)垂直拆分 — 维度属性层面
当某些维度属性的来源表产出时间较早，而某些维度属性的产出时间较晚；或者某些维度属性的热度高、使用频繁，而某些维度属性的热度低、较少使用，都可以使用主从表垂直拆分处理缓慢变化维度属性
缓慢变化维一般采用以下几种解决方法：
1.原样保留或者重写 - 这种方式理论上都是取最新的值作为维度的最终的取
值，每个维度保留一条数据
2.增加新行 - 插人新的维度行，每当维度发生变化的时候，插入新增的一行
3.增加新属性 - 新增字段同时储存新旧值
4.快照存储 - 每一个周期定时保存一份数据，与第二点有点像，不过这里会产生很多冗余的数据，当维度里大部分行在周期内，变动频繁的时候，可以采用。
5.历史拉链存储 - 历史拉链存储是基于处理缓慢变化维的第 2 种方法来加工的，也就是：新建维度行。但不同的是，拉链存储还特地用了两个时间键（生效时间和失效时间）来替代原有的代理键。
新增维度列，这种只合适变化频率非常非常低的维度属性（毕竟频繁变化我们不可能会一直新增列来保存，特殊情况除外）