前言

        范式,应该从事数据行业的您或多或少都听过,但您在数据库设计的时候是否有严格遵循呢？是否有想过不使用范式会怎么样呢？另外,在数据库中与数据仓库中对于范式的使用您是否清楚了呢？本文接下来会通过一个例子来带大家认识一下数据库中与数据仓库中的范式

1、数据库中的范式

        范式,一共有六种,分别是1NF,2NF,3NF,BCNF,4N,5NF,但是在关系型数据座中,一般考虑到3NF就够了,所以在本文也只探讨到前三种范式。

现在,有以下一份原始数据表：

原始数据表

包含的字段如图所示，下面我们根据范式一步一步来进行表的设计。很明显，我们在关系型数据库中创建的表，是不可能把原始数据表的数据入库成功的，更别说其他增删改查的操作了。所以，我们遇到的第一个难题就是入库。怎么解决呢？这时候就是第一范式出场的时候了。

1.1 第一范式

1NF：表中每个属性不可再分。按照1NF的定义，那不就是很简单吗？只要把原始数据表中的销售字段拆成产品价格和销售数量，即可符合1NF，如下图

数据表

很明显，现在把数据表入库到数据库完全不是事儿。那么在这里可以得到一个结论，但凡在关系型数据库中的表，都符合第一范式。

兄弟，别以太高兴得太早，虽然数据是入库了，却存在不少的问题：

1.1.1、冗余:价格,地址等数据重复多次

1.1.2、插入异常1：假如新增一个产品,但是没有客户购买,是没办法单独插入数据表中；                                插入异常2：假如国家新划分一个区,比如雄安新区,那么现在是没办法插入数据表的,因为新增的区不一定这么快划分群众到该区去

1.1.3、删除异常:假如一个产品A只有一位客户购买了,那么我们把该客户的所有购买记录删除了,那么产品A与产品A价格的关系就没了,可是产品A明明有呐

面对这些问题，我们可以试试用第二范式，看能不能解决！！

1.2 第二范式2NF

2NF：在1NF的基础上完全依赖主键

在这里，完全依赖指的就是，在属性x确定的情况下,就可以得到确定的结果y,类似于y=f(x)，

那么在数据表中，我们可以得到以下的依赖关系

(产品名称,产品价格)=f(产品ID)

(客户名字,地址ID,1级地址（省）,2级地址（市）,3级地址（区）)=f(客户ID)

(产品ID,客户ID,数量,实付金额,购买日期)=f(订单ID)

根据以上的依赖关系，我们可以把数据表分成产品表，客户表，订单表。

产品表 客户表 订单表

现在我们再来看看遵守了第二范式2NF,刚刚的问题有没有解决掉。

1.2.1、冗余：价格，产品名称数据不再重复多次  --有改进

1.2.2、插入异常1：假如新增一个产品,但是没有客户购买,我们可以插入产品表中 --解决

      插入异常2：假如国家新划分一个区,比如雄安新区,那么现在是没办法插入客户表的 --没解决

1.2.3、删除异常:假如一个产品A只有一位客户购买了,那么我们把该客户的所有购买记录删除了,那么产品A与产品A价格的关系还在产品表中 --解决

目前，只剩下插入异常2这一个问题了，兄弟别慌，我们还有第三范式可以用。

1.3 第三范式3NF

3NF：在2NF的基础上要直接依赖主键，不能存在传递依赖

在客户表中，客户ID和地址信息是存在传递依赖的，因为客户ID决定了地址ID，地址ID决定了1级地址（省），2级地址（市），3级地址（区），所以我们可以把地址信息单独建个表，叫地址表。

客户表 地址表

那么现在我们再来看看使用了3NF设计后，问题有没有解决或者优化。

1.3.1、地址字段不在重复出现，冗余数据更少了。

1.3.2、插入异常2：假如国家新划分一个区,比如雄安新区,可以在地址表里添加，然后在客户表插入地址ID就可以了  ---解决

2、数据仓库中的范式

        在数据仓库建模中，有范式建模与维度建模,其中范式建模与数据库中三范式建模基本一样的,所以就此略过,下面重点说说维度建模。

2.1、维度建模

        维度建模中,有两个要的概念:事实表和维度表,根据事实表与维度表直接是否直接相连,又可以分为星型模型与雪花模型，设计如下：

2.1.1、星型模型

2.1.2、雪花模型

大家有没有发现，在上面的订单事实表是符合2NF的，但是实际工作中我们会为了冗余更多的数据，满足业务的要求，通常事实表只需要符合1NF即可，如下图：

冗余的事实表

3、总结

        数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易，实时地进行增删改查的操作；反观OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果，基本不会进行删除与修改。而使用范式的好处就在于解决增删改的数据问题，这些都是传统的关系型数据库比较关注的地方，数据仓库却更着重于查询的效率，所以出现反范式的表设计。

喜欢的就点个赞吧~