在数据仓库领域，有两位大师，一位是数据仓库之父BillInmon，另一位是数据仓库权威专家RalphKimball。两位大师各有一本经典著作，英蒙的《数据仓库》，金博尔的《数仓工具箱》。这两本书也代表了两种不同的数据仓库构建模式，它们支撑了近二十年来数据仓库和商业智能的发展。今天就来说说这两种建模方式：——范式建模和维度建模。

本文首先简单了解两种建模方法的核心思想，然后根据一个具体的例子使用这两种建模方法进行建模，大家就一目了然了！

本文首发于微信官方账号【五分钟学会大数据】。

一、两种建模思想

:Inmon和Kimball这两种建模方法可以详细描述，但是理论很枯燥，尤其是晦涩难懂的文字。估计大家看完也不会有太大收获，所以作者根据自己的理解，用通俗的语言提炼核心概念。

范式建模

范式建模是由数据仓库之父Inmon提出的，单词& quot数据仓库& quot是由这位大师定义的。这种建模方法符合范式理论中的3NF，但这里的3NF与OLTP中的3NF有些不同：关系数据库中的3NF是针对具体业务流程的实体-对象关系的抽象，而数据仓库中的3NF是从企业角度出发的面向主题的抽象。

Inmon模型在流程上是自上而下，自上而下指的是数据的流向。"向上& quot指数据的上游，并且& quot向下& quot指的是数据的下游，即来自分散的异构数据源——数据仓库——数据集市。以数据源头为导向,然后一步一步地探索，以获得尽可能多的数据，因为数据来源往往是异构的，所以我们将更加重视数据清洗，并将数据提取到实体-关系模型中，而不是事实表和维度表的概念。

维度建模

Kimball模型是自下而上的，即从数据集市-数据仓库-去中心化的异构数据源。Kimball是一个以最终任务为导向,它根据目标将数据划分到不同的表要求中。数据将提取为事实-维度模型、数据源经ETL转化为事实表和维度表导入数据集市,并以星型模型或雪花型模型的形式建立多维数据仓库。在体系结构中，数据集市和数据仓库紧密结合，数据集市是数据仓库中一个逻辑上的主题域.

这里简单介绍一下两种建模方法的理论概念，因为无论说多少纯理论知识，大家都可能会有点困惑，所以这里举一个具体的例子来实践两种建模方法。

二、两种建模实践

通过上一节建模的两个核心思想，相信大家对这两种建模方法有了大致的了解。接下来通过具体的例子给大家一个具体的感受。

010年到1010年，大家都是网购，知道进货的流程。所以以电商购物为例，大家更容易理解。

真正的电商购物流程比较复杂，这里简化了表数和表字段。

以电商举例

对于我们的大数据平台来说，源表是指电子商务系统中后台数据库中的表，一般是OLTP类型的表：

1.源表的结构及数据

用户信息表：

城市信息表：

用户等级表：

010要对上述源表数据进行建模，需要将数据提取到实体-关系模式。根据源表的数据，我们将表分为：用户实体表、订单实体表、城市信息实体表、用户-城市信息关系表、用户-用户层级关系表等等。

用户订单表：

(注意：ETL已经过滤掉了注销的用户)

2.使用Inmon模式建模

用户实体表：

支付成功订单实体表：

010从上面我们可以发现，范式建模是将源表提取为实体表和关系表，所以范式建模是实体关系（ER）模型.数据没有冗余，符合三范式.的设计规范

城市信息实体表：

使用Kimball模式，数据需要提取为事实表和维度表.根据源表数据，我们将表拆分为：订单事实表、用户维度表、城市信息维度表、用户级别维度表。

如你所见，在Kimball的维度建模中，不需要单独维护数据关系表，因为关系已经冗余在事实表和维度表中.

订单与用户关系表：

用户与城市信息关系表：

用户与用户等级关系表：

010我们简单以图表的形式展示上述表格之间的关系：

根据上图，我们发现了什么？这不是典型的雪花模式?吗其特点是维度表可以有其他维度表。

3.使用Kimball模式建模

支付成功订单事实表：

建模方式特点

范式建模：通过上一小节的具体例子可以看出范式建模的优点：能够结合业务系统的数据模型，较方便的实现数据仓库的模型；同一份数据只存放在一个地方，没有数据冗余，保证了数据一致性；数据解耦，方便维护。但同时也带来了缺点：表的数量多；查询时关联表较多使得查询性能降低。

维度建模：模型结构简单，面向分析，为了提高查询性能可以增加数据冗余，反规范化的设计，开发周期短，能够快速迭代。缺点就是数据会大量冗余，预处理阶段开销大，后期维护麻烦；还有一个问题就是不能保证数据口径一致性，原因后面有讲解。

我们再来理解下维度建模：数据会抽取为事实-维度模型，维度就是看待问题的角度，从不同的角度看待某个问题，就会得出不同的结论，而要得到这个结论，就需要事实表中的度量，何为度量，就是事实表中数值类型的字段。

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

---

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

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

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

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

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

建模方式对比

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

特性KimballInmon开发周期短长开发难度小大维护难度大小数据要求针对具体业务站在企业角度精心设计否是缓慢变化维是否需要的人员少量专业团队数据模型维度建模，星型模型、雪花模型实体-关系模型，准三范式设计

我们知道，互联网公司的业务一般是周期比较短需求变化快，并且迭代频繁，如果精心设计Inmon实体-关系的模式似乎并不能满足快速迭代的业务需要。所以，互联网公司更多场景下趋向于使用Kimball维度-事实的设计反而可以更快地完成任务。

四、两种建模混合场景

通过以上几个小节我们已经理解了范式建模与维度建模的思想以及它们之间的异同，优缺点。那么我们能不能将两种建模方式混合使用呢，让它们发挥各自最大的优势。接下来我们一起来看下。

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

结合两种建模方式的各自规范，混合建模按照“松耦合、层次化”的基本架构原则进行实施。混合数据仓库架构方法主要包含以下关键步骤：业务需求分步构建、分层次保存数据、整合原子级的数据标准、维护一致性维度等。

---

最后

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

本文章同步自公众号【五分钟学大数据】，大数据领域原创技术号