数据库三范式

认识范式

范式是关系数据库理论的基础，也是设计数据库结构过程中所要遵循的规则和指导方法。范式的种类比较多，其中最主要的有三个范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。

为什么要介绍范式？如果没有实地做过数据库设计、或者建模经验比较少，是不容易理解范式这种抽象概念的。但是随着你接触 Power BI 时间的增加、使用的表越来越多、表之间的关系越来越复杂，会逐渐体会到一个设计合理的模型结构是多么的重要。毫不夸张的说，很多时候写不出 DAX 公式不是因为公式用法没掌握，而是模型结构有问题。了解范式理论，有助于在建模过程中识别并纠正不合理的结构，防患于未然。

这也是 Power BI 和其他 BI 工具一个显著的区别，搞定可视化之前，必须先搞定模型。对于大型项目，一个设计不合理的模型，会让公式越写越复杂，越来越难以维护

不必担心，这部分内容我会写的尽可能简单，用案例帮助你理解。

第一范式（1NF）：列的原子性，保证表的每一列都是不可分割的原子项

编号	姓名	性别	所在地
0001	张三	男	广东省，深圳市
0002	李四	女	海南省，海口市

所在地这一列不符合第一范式，需要拆分为下面的结构

编号	姓名	性别	所在省	地市
0001	张三	男	广东省	深圳市
0002	李四	女	海南省	海口市

第二范式（2NF）：在 1NF 的基础上，非关键字段必须依赖唯一的主键

工牌编号	工牌姓名	饭卡编号	饭卡姓名	饭卡余额
0001	张三	A001	A1 号员工	100
0002	李四	B001	B1 号员工	80

工牌姓名依赖于工牌编号，饭卡姓名和余额依赖于饭卡编号，两个主键违反了第二范式。如果使用这种结构，删除工牌编号记录的同时也会删除饭卡信息，这是不合理的。如果一个工牌可以办理多张饭卡，表格会产生冗余数据。所以我们需要将其拆分为工牌和饭卡两张表，这样每张表都有唯一的主键。

第三范式（3NF）：在 2NF 的基础上，表中的每一列都和主键直接相关，不能存在传递依赖

用户编号	姓名	性别	城市	城市人口
0001	张三	男	深圳市	1300W
0002	李四	女	海口市	230W

城市人口依赖于城市，城市依赖于用户编号，城市人口与用户编号是传递依赖，违反了第三范式。解决方法是将城市相关信息拆分到一个单独的表。

范式设计的问题和对策

范式有效避免了模型产生数据冗余，但在实际操作过程中，我们并非一定要严格遵守三范式，虽然我们可以设计出没有冗余的模型结构。但是，没有冗余的模型未必是最好的模型，有时为了提高运行效率和开发效率，必须降低范式标准，适当保留冗余数据，达到空间换时间的目的。

什么时候不需要严格遵守范式设计：

• 性能考虑，没有任何冗余的模型会产生更多的 Join 查询。在一些实时交互的系统中，可能会拖慢报表响应。
• 成本收益，范式设计提出于 20 世纪，当时的磁盘存储成本较高，随着科技的进步，数据压缩比越来越高，存储的成本也显著降低，采用这种设计的成本收益已经不是那么明显。
• DAX 的 Auto Exists 现象，也要求适当保留冗余数据，这个问题我们会在接下来的文章中专门讨论。

随着列式数据库的流行，即使某个值在列中多次出现，新的压缩算法也不会像传统的行式数据库那样保存冗余数据，而是可以很好的将其压缩。如果考虑存储成本，我们已经不必严格遵守范式理论，但是从结构合理化的角度出发，范式理论仍然具有参考价值

既然范式设计在某些情况下可能带来问题，那么反范式设计也有其存在的必要，这就是我们常说的模型的规范化与反规范化，在优化数据模型章节，我将介绍模型的反规范化。