数据仓库-维度模型
描述
Dimensional Modeling,简称DM，是一套技术和概念的集合，用于数据仓库设计
核心概念
事实
表示对业务数据的度量
通常是数字类型的，可以进行聚合和计算
维度
对观察数据的角度
一组层次关系或描述信息，用来定义事实
举例：销售金额是一个事实，而销售时间、销售的产品、购买的顾客、商店等都是销售事实的维度。
维度模型按照业务流程领域即主题域简历，例如进货、销售、库存、配送等。不同的主题域可能共享某些维度，为了提高数据操作的性能和数据一致性，需要使用一致性维度，例如几个主题域间共享维度的复制。
特点
易理解
相对于规范化的关系模型，维度模型容易理解且更直观。在维度模型中，信息按业务种类或维度进行分组，这回提高信息的可读性，也方便了对于数据含义的理解。
关系模型中，数据被分布到多个离散的实体中，对于一个简单的业务流程，可能需要很多表联合在一起才能表示。
高性能
维度模型更倾向于非规范化，因为这样可以优化查询的性能。
关系模型规范化的实质是减少数据冗余，以优化事务处理或数据更新的性能。
维度设计的整体观点是要简化和加速查询。
可扩展
由于维度模型允许数据冗余，因此当向一个维度表或事实表中添加字段时，不会像关系模型那样产生巨大的影响，带来的结果就是更容易容纳不可预料的新增数据。这种新增可以是单纯地向表中增加新的数据行而不改变表结构，也可以时在现有表上增加新的树形。
基于数据仓库的查询和应用不需要过多改变就能适应表结构的变化，老的查询和应用会继续工作而不会产生错误的结果。但是对于规范化的关系模型，由于表之间存在复杂的依赖关系，改变表结构前一定要仔细考虑
建模过程
选择业务流程
确认哪些业务处理流程是数据仓库应该覆盖的，是维度方法的基础
例如，需要了解和分析一个零售店的销售情况，那么与该零售店销售相关的所有业务流程都是需要关注的。
声明粒度
用于确定事实中表示的是什么，在选择维度和事实前必须声明粒度，因为每个候选维度或事实必须与定义的粒度保持一致。
在一个事实所对应的所有维度设计中强制实行粒度一致性是保证数据仓库应用性能和易用性的关键。
从给定的业务流程获取数据时，原始粒度是最低级别的粒度。建议从原始粒度数据开始设计，因为原始记录能够满足无法预期的用户查询。汇总后的数据粒度对优化查询性能很重要，但这样的粒度往往不能满足对细节数据的查询需求。
不同的事实可以有不同的粒度，但同一事实中不要混用多种不同的粒度。
确认维度
维度的粒度必须和第二步所声明的粒度一致
维度表是事实表的基础，也说明了事实表的数据是从哪里采集来的。典型的维度都是名词，如日期、商店、库存等。
维度表存储了某一维度的所有相关数据，例如，日期维度应该包括年、季度、月、周、日等数据
确认事实
识别数字化的度量，构成事实表的记录。
它是和系统的业务用户密切相关的，因为用户正是通过对事实表的访问获取数据仓库存储的数据。
大部分事实表的度量都是数字类型的，可累加，可计算，如成本、数量、金额等。
模型样式
星型模式
星型模型是维度模型最简单的形式，也是数据仓库以及数据集市开发中使用最广泛的形式。一个星型模式中可以有一个或多个事实表，每个事实表引用任意数量的维度表。星型模式的物理模型像一颗星星的形状，中心是一个事实表，围绕在事实表周围的维度表表示星星的放射状分支。
组成
事实表
事实表记录了特定事件的数字化的考量，一般由数字值和指向维度表的外键组成。通常会把事实表的粒度级别设计得比较低，使得事实表可以记录很原始的操作型事件，但这样做的负面影响是累加大量记录可能会更耗时
- 事务事实表
记录特定事件的事实，如销售
- 快照事实表
记录给定时间点的事实，如月底账户余额
- 累积事实表
记录给定时间点的聚合事实，如当月的总的销售金额。一般需要给事实表设计一个代理键作为每行记录的唯一标识。代理键是由系统生成的主键，它不是应用数据，没有业务含义，对用户来说是透明的。
维度表
维度表的记录数通常比事实表少，但每条记录包含有大量用于描述事实数据的属性子u但
通常给维度表设计一个单列、整型数字类型的代理键，映射业务数据中的主键。
类型
- 时间维度表
描述记录的事件所发生的时间，具有所需的最低级别的时间粒度。数据仓库是随时间变化的数据集合，需要记录数据的历史，因此每个数据仓库都需要一个时间维度表
- 地理维度表
描述位置信息的数据，如国家、省份、城市、区县、邮编等
- 产品维度表
描述产品及其属性
- 人员维度表
描述人员相关的信息，如销售人员、市场人员、开发人员等
- 范围维度表
描述分段数据的信息，如高级、中级、低级等
优点
简化查询
查询数据时，星型模式的连接逻辑比较简单，而从高度规范化的事务模型查询数据时，往往需要更多的表连接。
简化业务报表逻辑
与高度规范化的模式相比，由于查询更方便，因此星型模式简化了普通的业务报表逻辑
获得查询性能
星型模式可以提升只读报表类应用的性能
快速聚合
基于星型模型的简单查询能够提高聚合操作的性能
便于向立方体提供数据
星型模式被广泛用于高效地简历OLAP立方体，几乎所有的OLAP系统都提供ROLAP模型(关系型OLAP)，它可以直接将星型模式中的数据当作数据源，而不用单独建立立方体结构。
缺点
不能保证数据完整性
一次性的插入或更新操作可能会造成数据异常，而这种情况再规范化模型中是可以避免的。星型模式的数据装载，一般都是以高度受控的方式，用批处理或准实时过程执行的，以此来抵消数据保护方面的不足
对于分析需求不够灵活
星型模式更偏重于为特定目的建造数据视图，因此实际上很难进行全面的数据分析。星型模式不能自然地支持业务实体的多对多关系，需要在维度表和事实表之间建立额外的桥接表
雪花模式
雪花模式是一种多维模型中表的逻辑布局，其实体关系图有类似于雪花的形状，因此得名。
与星型模式相同，雪花模式也是由事实表和维度表所组成。所谓的雪花就是将星型模式中的维度表进行规范化处理。当所有的维度表完成规范化后，就形成了以事实表为中心的雪花型结构，即雪花模式。
将维度表进行规范化的具体做法是，把低基数的属性从维度表中移除并形成单独的表。基数指的是一个字段中不同值的个数，如主键列具有唯一值，所有有最高的基数，而像性别这样的列基础就很低。
在雪花模式中，一个维度被规范化成多个关联的表，而在星型模式中，每个维度由一个单一的维度表所表示。一个规范化的维度对应一组具有层次关系的维度表，而事实表作为雪花模式里的子表，存在具有层次关系的多个父表
数据规范化与存储
规范化的过程就是将维度表中重复的组分离成一个新表，以减少数据冗余的过程。正因如此，规范化不可避免地增加了表的数量。在执行查询的时候，不得不连接更多的表。但是规范化减少了存储数据的空间需求，而且提高了数据更新的效率。
组成
事实表
维度表：在星型模式的基础上对维度表做规范化
优点
规范化的维度属性节省存储空间
一些OLAP多维数据库建模工具专为雪花模型进行了优化
星型模式是雪花模式的一个特例（维度没有多个层级）
缺点
维度属性规范化增加了查询的连接操作和复杂度
向雪花模式的表中装载数据时，一定要有严格的控制和管理，避免数据的异常插入或更新。
Data Vault
定义
Data Vault是面向细节的，可追踪历史的，一组有连接关系的规范化的表的集合。这些表可以支持一个或多个业务功能。
它是一种综合了第三范式（3NF）和星型模型优点的建模方法。
设计理念是满足企业对灵活性、可扩展性、一致性和对需求的适应性要求，是一种专为企业级数据仓库量身定制的建模方式。
描述
是一种数据仓库建模方法，用来存储来自多个操作型系统的完整的历史数据。Data Vault方法需要跟踪所有数据的来源，因此其中灭个数据行都要包含数据来源和装载时间属性，用以审计和跟踪数据值所对应的源系统。
Data Vault不区分数据在业务层面的正确与错误，它保留操作型系统的所有时间的所有数据，装载数据时不做数据验证、清洗等工作，这点明显有别于其它数据仓库建模方法。
Data Vault建模方法显式地将结构信息和属性信息分离，能够还原业务环境的变化。Data Vault允许并行数据装载，不需要重新设计就可以实现扩展。
例如：业务规则应该在数据的下游实现，就是说Data Vault只按照业务数据的原样保存数据，不做任何解释、过滤、清洗、转换。即使从不同数据源来的数据是自相矛盾的，Data Vault模型不会遵照任何业务的规则，如“以系统A的地址为准”。Data Vault模型会保存两个不同版本的数据，对数据的解释将推迟到整个架构的后一个阶段(数据集市)。
组成
中心表(Hub)
用来保存一个组织内的每个实体的业务主键，业务主键唯一标识某个业务实体。
中心表和源系统表是相互独立的。当一个业务主键被用在多个系统时，它在Data Vault中也只保留一份，其他的组件都链接到这一个业务主键上。
属性
- 主键：系统生成的代理键，供内部使用
- 业务主键：唯一标识的业务单元，用于已知业务的源系统
- 装载时间：数据第一次装载到数据仓库时系统生成的时间戳
- 数据来源：定义了数据来源(例如源系统或表)
链接表(Link)
链接表是中心表之间的链接。一个链接表意味着两个或多个中心表之间有关联。
一个链接表通常是一个外键，它代表着一种业务关系。
属性
- 主键：系统生成的代理键，供内部使用
- 外键{1...N}：引用中心表的代理键
- 装载时间：数据第一次装载到数据仓库时系统生成的时间戳
- 数据来源：定义了数据来源(例如源系统或表)
附属表(Satellite)
附属表用来保存中心表和链接表的属性，包括所有的历史变化数据。一个附属表总有一个且唯一一个外键引用到中心表或链接表。
属性
- 主键：系统生成的代理键，供内部使用
- 外键：引用中心表或链接表的代理键
- 装载时间：数据第一次装载到数据仓库时系统生成的时间戳
- 失效时间：数据失效时的时间戳
- 数据来源：定义了数据来源（例如源系统或表）
- 属性{1...N}：属性自身
特点
所有数据都基于时间来存储，即使数据是低质量的，也不能在ETL过程中处理掉
依赖越少越好
和源系统越独立越好
设计上适合变化
源系统中数据的变化
在不改变模型的情况下可扩展
ETL作业可以重复执行
数据完全可追踪
