科普！数据仓库的建模——3NF模型

之前分享的一篇《如何搭建一个数据仓库》中，有提到数据仓库 的各层建模方法是不一样的。其中有朋友就问，这个 3NF 模型是个 啥？ 三范式 3NF 模型就是第三范式模型。在这里使用三范式的原因，是因为 明细数据层只做清洗和转换的工作，结构与业务库（OLTP）的一致， 而业务库基本是遵循三范式。

三范式 

3NF 模型就是第三范式模型。在这里使用三范式的原因，是因为 明细数据层只做清洗和转换的工作，结构与业务库（OLTP）的一致， 而业务库基本是遵循三范式的。

三范式指的是： 

第一范式：保证列的原子性（每一列都是不重复的，不可再拆分 的原子列）

上图中，销售下有金额和数量，咱数据库可不能做成多表头的样 子，所以只能把表头拆分。地区中含有省市县三级，不是最细的原子 粒度，所以也需要拆分。 

第二范式：保证行的原子性（每一行都有唯一的主键，其他字段 的值与主键一一对应

上图中，原表的用户 id 重复出现 2 次了，原因有 2：销售额和销 售量出现错行，需要合并；采购两个商品，这两个商品与主键“用户 id”不是一一对应的，所以需要拆出一个订单商品表。 

上图中的例子，原表描述了用户的销售，以及采购的数据，数据 颗粒度不一样，所以需要拆分。所以第二范式也通常可以理解为“每 张表只描述一件事情”

第三范式：保证表的原子性（每张表中的数据不会冗余，一旦有冗余字段，就需要拆一张表出来，用外键与主表关联

上图中的例子，业务员姓名和类型信息在用户销售表中被冗余了， 不符合第三范式，所以需要拆表。1 表的用户 id 是主键，业务员 id 是外键与 2表的业务员 id 主键关联。

数据库设计 

现在的很多开发人员，甚至是数据开发人员都不太遵守三范式了， 有些三范式规则甚至被禁用，比如外键

所有事物的发展都是有规律的，当时提出三范式，是因为我们在 进行数据库设计的时候，必须要有一个规则，用来统一所有人的思想， 保证数据库设计的通用性和可理解性。三范式就是用来约束所有设计者的。

数据库设计的过程，就是将现实世界抽象到信息系统的过程。使 用的工具就是 ER 图。 

我们把所有参与到业务流程中的对象，抽象为“实体”，每个实体 有自己的“属性”，实体与实体之间产生的动作叫“关系”，用线连接起来

还是以采购业务流为例，一共可以抽出四个实体，用户、业务员、 订单和商品。 

业务员有入职时间、业务员 id 等属性； 

用户有联系电话、所在地区等属性； 

订单有商品 id、商品时间、下单时间等属性； 

商品有商品 id、商品名称等属性

业务员维护用户，一个业务员可以维护多个用户，他俩之间的关 系就是一对多；用户采购商品，一个用户可以采购多个订单，关系是 一对多；一个订单可以下多个商品，一个商品可以被多个订单采购， 所以他俩的关系是多对多。 

根据这个方法，所有的数据库设计人员就能设计出这四张表：

这四张表遵守第一、第二、第三范式，所有的数据做到了最少的 冗余，最大的信息承载量，满足所有业务，不会对增、删、改等任何 数据操作有歧义或者带来异常。

结语 

不过现在已经进入大数据时代，上述的很多范式均已退化。以前 的存储很贵，我们必须要寸土必争。现在存储很便宜，数据量又大， 效率又要高，所以普遍采用空间换时间的方法，大量冗余数据，提升 效率。尤其是在分布式环境中，要追求数据的一致性，三范式就无法 满足。之前提到过禁用外键就是因为外键约束会导致连锁反应，那将 会是一场灾难