数仓建模——Inmon与Kimball的融合建模方法论

说的小谎.

在数据仓库领域，有两位大师，一位是“数据仓库”之父 Bill Inmon，一位是数据仓库权威专家 Ralph Kimball。，Inmon的《数据仓库》及Kimball的《数仓工具箱》代表了两种不同的数仓建设模式。而这两种架构模式支撑了数据仓库以及商业智能近二十年的发展。今天我们就来聊下这两种建模方式——（1.）Inmon 的三范式（以下统称3NF）建模（2.）基于Kimball的星型和雪花型建模方式。

以BI项目中的数仓建模为例， Kimball 建模的流程为：从需求到模型，从模型到数据。从上到下的一个过程，也叫数据集市总线架构（ Data Mart Bus Architecture ）或者数据仓库总线架构 （DataWarehouse Bus Architecture。）

在大型BI项目中，数仓通常也会采用Inmon 的建模方式，从数据到模型再到需求，这样的自下往上的建设路线。也有叫集线器架构 （Huband Spoke） 或者企业信息工程架构 （CIF：CorporateInformation Factory）。

但从长期的业务实践来看，目前笔者认为最好的数仓建模方式是：数据层采用Inmon的3NF建模，业务层采用Kimball建模的架构。即混合建模方式。为什么笔者推荐混合建模？单一种建模的劣势在哪？这些架构什么样的差别？以下我们将展开讲讲。

首先 ，Inmon 3NF 建模方式是逆软件开发流程的。即：业务数据→数据仓库→分析需求，是站在企业角度面向主题的抽象。这种建模的方式主要难在：（1.）熟悉各个业务系统的底层数据表结构(2.)熟悉业务模式

其次，面向开发人员，要开发一个软件程序或业务系统，首先就需了解业务需求、画实体关系图（ER：Entity-Relationship），再到数据库表结构的设计，这个时候表结构设计就会遵守数据库设计的3NF要求。比如原子列不可再分、必须要有主键、不可传递依赖等等。

所以，业务软件系统的设计是遵守3NF数据库表设计要求的。在数据仓库层面，就相当于拉通所有数据源业务系统，在所有的业务系统层之上构建一个更大更全的3NF数据仓库。

换言之，目前企业在日常生产与管理中，应用着很多个不同的业务系统。未来想自己开发一个囊括了所有业务流程的系统，那么开发阶段第一件事情就是设计一套完整的、能够覆盖所有业务范围的新的数据库，这种数据库最后是要支撑整个软件层面，而这种数据库的设计通常情况下也一定是遵循3NF要求的。

在数据仓库层面用3NF建模就等同于软件程序设计开发中的底层数据库表设计过程，它是有比较深的软件开发思想在里面的。

所以有过软件设计开发背景的人转型BI做建模设计优势会更大一些，从软件开发的数据库设计到BI数据仓库的建模设计角色转换过程中，没有太多概念上的障碍。

但这种建模方式也有它天然的缺点，因为3NF建模本身是面向软件程序开发的。在SQL层面适合于大量的增删改动作，由于3NF减少了数据冗余，所以在查询层面上需要跨很多表查询，在可视化分析层面报表的查询性能就很低。

于是与之互补的Kimball 维度建模概念就出现了，以星型模型和雪花型模型为代表的数据模型，反3NF的建模方式，反规范化，通过减少表关联和保持大量的数据冗余来提升分析查询的效率。并且维度建模是更适合业务分析思维的，在业务分析模型的可读性上更加的直观。

所以在大型银行、金融保险等领域，可以采用数据底层是Inmon 的3NF建模架构，从业务数据层面3NF化、规范化，形成标准的业务流程性的数据。不对分析负责，对业务流程负责。基于3NF模型之上，再结合Kimball的维度建模方式，以数据集市驱动的方式面向分析端对分析负责。

Kimball建模的方法论跟Inmon建模方法论从流程上完全相反，它是遵循软件设计开发流程的，是从需求端出发，再到模型，再到数据的过程。需求是什么？就是看什么数据，怎么看指的就是维度。看什么指的就是指标。指标和维度就可以构建数据仓库的分析模型，这个分析模型指的就是星型模型或者雪花型模型。

在这个过程中，最开始的需求是大而全的数据集市。通过对数据集市的抽象与分解，层层往下剥离，抽象出通用的维度、基础事实表、衍生事实表形成不同的事实分层，例如TRANS层、DW层、DM层，再往下到数据源层的整个过程。

上面讲述的就是从Inmon建模架构，到混合架构，再到Kimball建模架构，从哪里产生以及他们之间的区别。

哪种建模方式的挑战性最大，我认为是Inmon的3NF建模。对数据的理解、对业务的理解不亚于着手一次软件程序开发的底层数据表架构设计，但是它不对分析负责，也不适用于分析模型。而Kimball架构是明确的对分析负责，再逐层往下的实现方式，离业务更近，也比较轻快灵活。但核心模型的设计对数据仓库架构的可扩展性、延展性要求和挑战很大，需要有非常丰富的架构设计经验。

我们现在看很多BI的项目从方法论上还是存在很多问题的，数据仓库的构建过程是采用Kimball的维度建模方式，但是在实际开发过程中不是从需求端走的，而是先钻到底层数据，层层往上推导，这个和Kimball的建设方向上本质就是冲突的。最后这样的架构设计下来，到真正使用的话是很难具备非常灵活的可扩展性和稳定性的。