范式建模和维度建模

一、两种建模思想
对于 Inmon 和 Kimball 两种建模方式可以长篇大论叙述，但理论是很枯燥的，尤其是晦涩难懂的文字，大家读完估计也不会收获太多，所以我根据自己的理解用通俗的语言提炼出最核心的概念。
范式建模

范式建模是数仓之父 Inmon 所倡导的，“数据仓库”这个词就是这位大师所定义的，这种建模方式在范式理论上符合3NF，这里的3NF与OLTP中的3NF还是有点区别的：关系数据库中的3NF是针对具体的业务流程的实体对象关系抽象，而数据仓库的3NF是站在企业角度面向主题的抽象。
Inmon 模型从流程上看是自上而下的，自上而下指的是数据的流向，“上”即数据的上游，“下”即数据的下游，即从分散异构的数据源 -> 数据仓库 -> 数据集市。以数据源头为导向，然后一步步探索获取尽量符合预期的数据，因为数据源往往是异构的，所以会更加强调数据的清洗工作，将数据抽取为实体-关系模型，并不强调事实表和维度表的概念。
一、两种建模思想
对于 Inmon 和 Kimball 两种建模方式可以长篇大论叙述，但理论是很枯燥的，尤其是晦涩难懂的文字，大家读完估计也不会收获太多，所以我根据自己的理解用通俗的语言提炼出最核心的概念。

三、两种建模对比
两种建模方式特点

范式建模：通过上一小节的具体例子可以看出范式建模的优点：能够结合业务系统的数据模型，较方便的实现数据仓库的模型；同一份数据只存放在一个地方，没有数据冗余，保证了数据一致性；数据解耦，方便维护。但同时也带来了缺点：表的数量多；查询时关联表较多使得查询性能降低。
维度建模：模型结构简单，面向分析，为了提高查询性能可以增加数据冗余，反规范化的设计，开发周期短，能够快速迭代。缺点就是数据会大量冗余，预处理阶段开销大，后期维护麻烦；还有一个问题就是不能保证数据口径一致性，原因后面有讲解。
我们再来理解下维度建模：数据会抽取为事实-维度模型，维度就是看待问题的角度，从不同的角度看待某个问题，就会得出不同的结论，而要得到这个结论，就需要事实表中的度量，何为度量，就是事实表中数值类型的字段。
例：某公司的各个商品在全国各地市的销售情况，维度就是全国的城市和各个商品，度量就是商品的单价，从不同的维度计算销售额：如查看北京市酸奶的销售额，上海市纯牛奶的销售额，这就是不同的维度组合方式。在限定的维度条件上，计算商品单价的总和，也就是 sum 度量值，即可得到我们想要的结果。

维度建模，就是依靠维度进行建模，但是如果维度设计的不合理，会不会带来问题呢？
如果我们把省份当做一个单独维度，城市当做一个维度，计算城市的人口数量。这时省份和城市都是单独的维度，它们之间没有了关系，就会出现以下情况：
广东省 杭州市 1500
浙江省 广州市 1200
这时会出现数据口径不一致，最后导致数据结果不准确。而范式建模就不会出现这个问题，因为在范式建模中强调的就是实体-关系模型，所以省份和城市之间一定存在归属关系的，不会出现省份和城市口径不一致的问题。
所以，范式建模能保证口径的一致性，而维度建模不能！

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

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

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