关于数据仓库:通俗易懂数仓建模Inmon范式建模与Kimball维度建模

在数据仓库畛域，有两位巨匠，一位是“数据仓库”之父 Bill Inmon，一位是数据仓库权威专家 Ralph Kimball，两位巨匠每人都有一本经典著作，Inmon 巨匠著述《数据仓库》及 Kimball 巨匠的《数仓工具箱》，两本书也代表了两种不同的数仓建设模式，这两种架构模式撑持了数据仓库以及商业智能近二十年的倒退。明天咱们就来聊下这两种建模形式——范式建模和维度建模。

本文开始先简略了解两种建模的核心思想，而后依据一个具体的例子，别离应用这两种建模形式进行建模，大家便会高深莫测！

本文首发于公众号【五分钟学大数据】

一、两种建模思维

对于 Inmon 和 Kimball 两种建模形式能够简明扼要叙述，但实践是很干燥的，尤其是艰涩难懂的文字，大家读完预计也不会播种太多，所以笔者依据本人的了解用艰深的语言提炼出最外围的概念。

范式建模

范式建模是数仓之父 Inmon 所提倡的，“数据仓库”这个词就是这位巨匠所定义的，这种建模形式在范式实践上合乎 3NF，这里的 3NF 与 OLTP 中的 3NF 还是有点区别的：关系数据库中的 3NF 是针对具体的业务流程的实体对象关系形象，而数据仓库的 3NF 是站在企业角度面向主题的形象。

Inmon 模型从流程上看是 自上而下 的，自上而下指的是数据的流向，“上”即数据的上游，“下”即数据的上游，即从扩散异构的数据源 -> 数据仓库 -> 数据集市。以数据源头为导向 ，而后一步步摸索获取尽量合乎预期的数据，因为数据源往往是异构的，所以会更加强调数据的荡涤工作，将数据抽取为 实体 - 关系 模型，并不强调事实表和维度表的概念。

维度建模

Kimball 模型从流程上看是自下而上的，即从数据集市 -> 数据仓库 -> 扩散异构的数据源。Kimball 是 以最终工作为导向 ，将数据依照指标拆分出不同的表需要，数据会抽取为 事实 - 维度 模型，数据源经 ETL 转化为事实表和维度表导入数据集市 ，以星型模型或雪花模型等形式构建维度数据仓库，架构体系中，数据集市与数据仓库是紧密结合的， 数据集市是数据仓库中一个逻辑上的主题域。

两种建模形式的实践概念就简略介绍到这，因为纯理论常识说再多，大家也可能有点蛊惑，所以上面用一个具体的例子来实际两种建模形式。

二、两种建模实际

通过上一大节两种建模核心思想，置信大家对这两种建模形式曾经有了大略的了解，接下来咱们通过具体的例子，让大家有具体的感触。

以电商举例

大家都网购过，晓得购买物品的流程，因而以电商购物为例，更易于大家的了解。

实在的电商购物的流程较简单，此处表数量和表字段做简化解决。

1. 源表的构造及数据

对于咱们大数据平台来说，源表指的电商零碎中后盾数据库中的表，这种表个别都是 OLTP 类型的表：

① 用户信息表

② 城市信息表

③ 用户等级表

④ 用户订单表

2. 应用 Inmon 模式建模

应用 Inmon 模式对以上源表数据进行建模，须要将数据抽取为 实体 - 关系 模式，依据源表的数据，咱们将表拆分为：用户实体表，订单实体表，城市信息实体表，用户与城市信息关系表，用户与用户等级关系表等多个子模块：

① 用户实体表

(注：ETL 已过滤掉登记用户)

② 领取胜利订单实体表

③ 城市信息实体表

④ 订单与用户关系表

⑤ 用户与城市信息关系表

⑥ 用户与用户等级关系表

通过以上咱们能够发现，范式建模就是将源表抽取为实体表，关系表，所以范式建模即是 实体关系（ER）模型 。数据没有冗余，合乎 三范式 设计规范。

3. 应用 Kimball 模式建模

应用 Kimball 模式，须要将数据抽取为 事实表和维度表，依据源表数据，咱们将表拆分为：订单事实表，用户维度表，城市信息维度表，用户等级维度表。

能够看出，在 Kimball 的维度建模中，不须要独自保护数据关系表，因为关系曾经冗余在事实表和维度表中。

① 领取胜利订单事实表

② 用户维度表

③ 城市信息维度表

④ 用户等级维度表

咱们用图的形式将以上表之间的关系简略展现进去：

依据上图，咱们发现什么，这不就是典型的 雪花模式 嘛，其特点就是维度表能够领有其余维度表。

三、两种建模比照

两种建模形式特点

范式建模：通过上一大节的具体例子能够看出范式建模的长处：可能联合业务零碎的数据模型，较不便的实现数据仓库的模型；同一份数据只寄存在一个中央，没有数据冗余，保障了数据一致性；数据解耦，不便保护。但同时也带来了毛病：表的数量多；查问时关联表较多使得查问性能升高。

维度建模 ：模型构造简略，面向剖析，为了进步查问性能能够减少数据冗余，反规范化的设计，开发周期短，可能疾速迭代。毛病就是数据会大量冗余，预处理阶段开销大，前期保护麻烦；还有一个问题就是 不能保证数据口径一致性，起因前面有解说。

咱们再来了解下维度建模 ：数据会抽取为 事实 - 维度 模型，维度就是对待问题的角度，从不同的角度对待某个问题，就会得出不同的论断，而要失去这个论断，就须要事实表中的度量，何为度量，就是事实表中数值类型的字段。

例：某公司的各个商品在全国各地市的销售状况，维度就是全国的城市和各个商品，度量就是商品的单价，从不同的维度计算销售额：如查看北京市酸奶的销售额，上海市纯牛奶的销售额，这就是不同的维度组合形式。在限定的维度条件上，计算商品单价的总和，也就是 sum 度量值，即可失去咱们想要的后果。

维度建模，就是依附维度进行建模，然而如果维度设计的不合理，会不会带来问题呢？

如果咱们把省份当做一个独自维度，城市当做一个维度，计算城市的人口数量。这时省份和城市都是独自的维度，它们之间没有了关系，就会呈现以下状况：

广东省 杭州市 1500
浙江省 广州市 1200

这时会呈现数据口径不统一，最初导致数据后果不精确。而范式建模就不会呈现这个问题，因为在范式建模中强调的就是 实体 - 关系 模型，所以省份和城市之间肯定存在归属关系的，不会呈现省份和城市口径不统一的问题。

所以，范式建模能保障口径的一致性，而维度建模不能！

建模形式比照

通过上一节的具体的例子以及两种建模的特点，咱们比照下两种建模形式的不同：

咱们晓得，互联网公司的业务个别是周期比拟短需要变动快，并且迭代频繁，如果精心设计 Inmon 实体 - 关系的模式仿佛并不能满足疾速迭代的业务须要。所以，互联网公司更多场景下趋向于应用 Kimball 维度 - 事实的设计反而能够更快地实现工作。

四、两种建模混合场景

通过以上几个大节咱们曾经了解了范式建模与维度建模的思维以及它们之间的异同，优缺点。那么咱们能不能将两种建模形式混合应用呢，让它们施展各自最大的劣势。接下来咱们一起来看下。

范式建模必须合乎准三范式设计规范，如果应用混合建模，则源表也须要合乎范式建模的限度，即源数据须为 操作型 或事务型 零碎的数据。通过 ETL 抽取转换和加载到数据仓库的 ODS 层，ODS 层数据与源数据是保持一致的，所以 ODS 层数据也是合乎范式设计规范的，通过 ODS 的数据，利用范式建模办法，建设原子数据的数据仓库 EDW，而后基于 EDW，利用维度建模办法建设数据集市。

联合两种建模形式的各自标准，混合建模依照“松耦合、层次化”的根本架构准则进行施行。混合数据仓库架构办法次要蕴含以下关键步骤：业务需要分步构建、分档次保留数据、整合原子级的数据规范、保护一致性维度等。

最初

建模形式没有好与坏之分，只有适合与不适合之分，在理论数仓建设中，须要灵便多变，不能全依赖建模实践，也不能不依赖。适时变通，能力建设一个好的数据仓库。

可关注公众号【五分钟学大数据】，大数据畛域原创技术号