数据仓库建模便是数据的组织和存储方法，举个例子，数据仓库的建模就类似于家庭物品收纳问题，我们会按照物品的特性以及自身的喜好将物品进行一个有条不紊的整理收纳，使我们清晰地知道物品归放的位置，便于日后查找利用，也能无形地让大脑标记物品位置，形成归类统一意识，逐渐成为一种好习气。
数据建模也是如此，它强调从业务出发，将数据有序组织和存储起来，只有做到这样，数据才可以高效率、高质量、高性能、低成本地利用，才可以更好地支持企业决策，赋能企业业务，提升企业综合实力。
二、数据仓库建模常用模型浅析1. ER模型（实体关系模型）
数据仓库之父Bill Inmon提出的建模方法是从全企业的高度，用实体关系（Entity Relationship，ER）模型来描述企业业务，并用规范化的办法表示出来，在范式理论上符合3NF。
1）什么是实体关系模型
实体关系模型由美籍华裔打算机科学家陈品山发明，用观点数据模型的描述所利用的数据或模式图，实体关系模型将繁芜的数据抽象为两个观点——实体和关系。实体表示一个工具，例如商店、员工这两个工具，关系是指两个实体之间的关系，例如员工和商店的从属关系。工具与工具的关系可以分为1-1，1-n,n-n这三种类型，举例解释：
1-1：一个商店只能有一个店长，一个店长只能在一个商店中任职，则商店和店长便是1对1的关系。1-n：一个商店有很多雇员，雇员只属于这个商店。则商店和雇员便是1对多的关系。n-n:商店里有很多商品，商品也可以在多个商店售卖，则商店和商品便是多对多的关系。2）范式理论是什么？
范式是表构造设计标准的级别，是关系的约束条件的规范，关系型数据库的范式一共有六种，分别是第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF）。遵照的范式级别越高，数据冗余性就越低。
由于数据仓库ER建模遵照3范式标准，本文就只针对付前3个范式进行讲解，其他的范式不再赘述， 感兴趣的读者可以自己查询下干系资料。
数据库规范化便是利用一系列范式设计数据库（常日是关系型数据库）的过程，其目的是减少数据冗余，增强数据的同等性，必须要把稳的一点是范式存在前置依赖，如要利用第三范式，设计数据库时必须依赖于利用前两个范式的之后，才可以按照第三范式的连续设计数据库表。详细设计时要根据业务实际流程，一样平常遵照第三范式即可。
第一范式：强调列的原子性，哀求每列属性不可分割。
上图数据列中商品这一列的数据不是原子数据，它可以连续分割成商品数量和商品名称，按照第一范式进行调度后，如下图所示：
第二范式：在1范式的根本上,哀求属性必须依赖于主键，不能存在部分函数依赖。
函数依赖：某个属性集x决定另一个属性集y时，称另一属性集y依赖于该属性集x。如学号和姓名，通过学号可以找到姓名，那么就说姓名依赖于学号。
完备函数依赖：通过xy能得到z，但是单独通过x或者通过y得不到z，那么就称z完备依赖于xy。如：学号，课程和成绩。可以通过学号和课程得到成绩，但是单独通过课程和学号得不到课程，就说成绩完备依赖于课程和学号。
部分函数依赖：通过xy能得到z，通过x得到z或者通过y也可以得到z，那么就说z部分依赖于xy，如学号、姓名和性别，通过学号和姓名可以找到性别，也可以通过学号单独找到性别，就说性别部分依赖于学号和姓名。
通报函数依赖：通过x能得到y，通过y得到z，那么就说z通报依赖于x，如通过学号得到班级名称，在通过班级名称找到班主任，就可以说班主任通报依赖于学号。
如上图所示：表中的主键如果是（学号、课程）的话，通过（学号、课程）可以找到成绩，分数是完备依赖于（学号、课程）但是姓名可以单独通过学号找到，姓名不完备依赖于找到（学号、课程），故不符合第二范式。调度后如下所示：
第三范式：肃清依赖通报，任何非主属性不依赖与其他非主属性。
如图所示：上边这张表中，如果想要找到辅导，通过学号找到班级，通过班级找到辅导员，存在很明显的函数依赖，故不符合第三范式哀求，调度后如图所示：
以上便是关于三范式的干系讲解，那么按照Bill Inmon提出的数仓建模思想，用ER模型进行建模，首先以京东商城订单流程为例子，全体交易环节中包含下单，取消订单、支付，拆单、退款，发货、收货、退换货、评价等，下图为京东商城订单截图。
那么我们以订单业务为例，采取ER模型遵照3范式建模，按照这种办法将数据进行规范化处理，则可以构建出下图所示的数仓模型，值得把稳的是下图只是将一部分交易流程进行了绘制，订单风控、订单退货退款、订单评价等还没有绘制到模型中。
从图中我们可以看出按照这样的办法进行数据建模，虽然减少了数据冗余性，担保了数据的同等性，但是如果要查询一个干系的指标或者事实可能须要关联十几张表，在数据量小，有索引的情形下可能还好些，如果数据量十分惊人，数以亿计，那查询的速率可能十分缓慢，乃至可能会造成宕机，显而易见这种模型不太适宜直接应用于业务剖析和打算场景。
2. 维度模型
维度模型是Ralph Kimball 在90年代提出的数仓建模理论，并在于1996年发布的《The Data Warehouse Toolkit》一书中详细先容了维度建模理论知识。
维度建模之以是能受到广泛的关注和认可，一方面是由于它从企业决策剖析作为出发点，为数据剖析做事，它的初衷是旨在，利用户更快的完成数据剖析，以及更好地实现大规模繁芜的查询操作。其余一方面，得益于技能的发展，根本存储硬件的本钱逐年降落，同时硬件的打算性能也大幅度提升，才使得维度建模能够走上历史舞台，得到海内外企业和用户的认同。
维度模型将企业的业务通过两个方面进行数据建模，即事实表和维度表。事实常日指企业详细的业务过程，如登录、注册、加购、下单等等，须要把稳的是建模时常日会选择最细粒度的业务过程数据作为事实表，如订单事实表会选订单明细表作为根本事实表，而上边简述的ER模型则选订单主表作为根本，维度常日指业务过程发生时所处的环境，如何人、何地、何时、何种东西，何种方法做了哪些事情。
详细细节该当联系业务过程，通过5W2H的方法进行剖析，绘制出详细的总线矩阵。按照维度建模理论，我们将上述订单过程进行了一个初步建模，中间的为事实表，周边的为维度表，须要把稳的是，本次建模的内容和上边ER模型讲解保持了同等，以是也没有涵盖所有的维度，如图所示：
从上图中可以看出，维度建模数据构造相对ER模型来说，更为清晰简洁，查询时连表操作相对较少，可以及时相应大量且繁芜的查询操作，提升业务剖析速率，快速支持业务决策。但是数据存在大量冗余，须要花费大量存储空间。
本文由 @菜鸟数据之旅 原创发布于大家都是产品经理，未经作者容许，禁止转载
题图来自Unsplash，基于CC0协议
该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。
