之前分享的一篇《如何搭建一个数据仓库》中，有提到数据仓库的各层建模方法是不一样的。其中有朋友就问，这个3NF模型是个啥？
三范式
3NF模型就是第三范式模型。在这里使用三范式的原因，是因为明细数据层只做清洗和转换的工作，结构与业务库（OLTP）的一致，而业务库基本是遵循三范式的。
三范式指的是：
第一范式：保证列的原子性（每一列都是不重复的，不可再拆分的原子列）
上图中，销售下有金额和数量，咱数据库可不能做成多表头的样子，所以只能把表头拆分。地区中含有省市县三级，不是最细的原子粒度，所以也需要拆分。
第二范式：保证行的原子性（每一行都有唯一的主键，其他字段的值与主键一一对应）
上图中，原表的用户id重复出现2次了，原因有2：销售额和销售量出现错行，需要合并；采购两个商品，这两个商品与主键“用户id”不是一一对应的，所以需要拆出一个订单商品表。
上图中的例子，原表描述了用户的销售，以及采购的数据，数据颗粒度不一样，所以需要拆分。所以第二范式也通常可以理解为“每张表只描述一件事情”。
第三范式：保证表的原子性（每张表中的数据不会冗余，一旦有冗余字段，就需要拆一张表出来，用外键与主表关联）
上图中的例子，业务员姓名和类型信息在用户销售表中被冗余了，不符合第三范式，所以需要拆表。1表的用户id是主键，业务员id是外键与2表的业务员id主键关联。
数据库设计
现在的很多开发人员，甚至是数据开发人员都不太遵守三范式了，有些三范式规则甚至被禁用，比如外键。
所有事物的发展都是有规律的，当时提出三范式，是因为我们在进行数据库设计的时候，必须要有一个规则，用来统一所有人的思想，保证数据库设计的通用性和可理解性。三范式就是用来约束所有设计者的。
数据库设计的过程，就是将现实世界抽象到信息系统的过程。使用的工具就是ER图。
我们把所有参与到业务流程中的对象，抽象为“实体”，每个实体有自己的“属性”，实体与实体之间产生的动作叫“关系”，用线连接起来。
还是以采购业务流为例，一共可以抽出四个实体，用户、业务员、订单和商品。
业务员有入职时间、业务员id等属性；
用户有联系电话、所在地区等属性；
订单有商品id、商品时间、下单时间等属性；
商品有商品id、商品名称等属性。
业务员维护用户，一个业务员可以维护多个用户，他俩之间的关系就是一对多；用户采购商品，一个用户可以采购多个订单，关系是一对多；一个订单可以下多个商品，一个商品可以被多个订单采购，所以他俩的关系是多对多。
根据这个方法，所有的数据库设计人员就能设计出这四张表：
这四张表遵守第一、第二、第三范式，所有的数据做到了最少的冗余，最大的信息承载量，满足所有业务，不会对增、删、改等任何数据操作有歧义或者带来异常。
结语
不过现在已经进入大数据时代，上述的很多范式均已退化。以前的存储很贵，我们必须要寸土必争。现在存储很便宜，数据量又大，效率又要高，所以普遍采用空间换时间的方法，大量冗余数据，提升效率。尤其是在分布式环境中，要追求数据的一致性，三范式就无法满足。之前提到过禁用外键就是因为外键约束会导致连锁反应，那将会是一场灾难。