经典数据仓库建模方法----维度建模和关系建模

维度建模和关系建模

1、维度建模

（1）定义

维度模型是数据仓库领域另一位大师Ralph Kimball 所倡导的。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能，更直接面向业务。

典型的代表是我们比较熟知的星形模型：

星型模型由一个事实表和一组维表组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。

这也是我们在使用hive时，经常会看到一些大宽表的原因，大宽表一般都是事实表，包含了维度关联的主键和一些度量信息，而维度表则是事实表里面维度的具体信息，使用时候一般通过join来组合数据，相对来说对OLAP的分析比较方便。

2）建模方法

通常需要选择某个业务过程，然后围绕该过程建立模型，其一般采用自底向上的方法，从明确关键业务过程开始，再到明确粒度，再到明确维度，最后明确事实，非常简单易懂。

（3）优缺点

优点：技术要求不高，快速上手，敏捷迭代，快速交付；更快速完成分析需求，较好的大规模复杂查询的响应性能

缺点：维度表的冗余会较多，视野狭窄

2、关系建模

（1）定义

是数据仓库之父Inmon推崇的、从全企业的高度设计一个3NF模型的方法，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF，站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系抽象。

它更多是面向数据的整合和一致性治理，正如Inmon所希望达到的“single version of the truth”。

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。

雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。

雪花模型更加符合数据库范式，减少数据冗余，但是在分析数据的时候，操作比较复杂，需要join的表比较多所以其性能并不一定比星型模型高。

（2）建模方法

关系建模常常需要全局考虑，要对上游业务系统的进行信息调研，以做到对其业务和数据的基本了解，要做到主题划分，让模型有清晰合理的实体关系体系，以下是方法的示意：

（3）优缺点

优点：规范性较好，冗余小，数据集成和数据一致性方面得到重视，比如运营商可以参考国际电信运营业务流程规范（ETOM），有所谓的最佳实践。

缺点：需要全面了解企业业务、数据和关系；实施周期非常长，成本昂贵；对建模人员的能力要求也非常高，容易烂尾。

3、建模方法比较

一般来讲，维度模型简单直观，适合业务模式快速变化的行业，关系模型实现复杂，适合业务模式比较成熟的行业，阿里原来用关系建模，现在基本都是维度建模的方式了。

运营商以前都是关系建模，现在其实边界越来越模糊，很多大数据业务变化很快，采用维度建模也比较方便，不需要顶层设计。

属性	维度模型	关系模型
数据总量	多	少
可读性	容易	差
表个数	少	多
查询速度	快	慢
冗余度	高	低
对实时表的情况	增加宽度	字段比较少，冗余低
扩展性	差	好
实施难度	低，周期短	高，周期长
适用场景	快速变化行业、战术性投入，直接面向客户，比如淘宝	成熟行业、战略性投入、不直接面向客户，比如运营商