2024年一篇文章搞懂数据仓库：三范式与反范式，2024年最新从零开始学数据结构和算法

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

5.1 范式化 （时间换空间）

5.2 反范式化（空间换时间）

六、OLAP和OLTP中范式设计

---

范式是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中，这种规则就是范式。

关系数据库中的关系必须满足一定的要求，即满足不同的范式。大数据生态中，各类强大的查询引擎层出不穷，相对廉价的磁盘和分布式技术，也让数据冗余变得可接受甚至更加方便。

在创建一个数据库的过程中，范化是将其转化为一些表的过程，这种方法可以使从数据库得到的结果更加明确。这样可能使数据库产生重复数据，从而导致创建多余的表。范化是在识别数据库中的数据元素、关系以及定义所需的表和各表中的项目等这些初始工作之后的一个细化的过程。

一、第一范式

---

1NF要求属性具有原子性，即列不可再分解；

表：字段1、 字段2(字段2.1、字段2.2)、字段3 …

如学生（学号，姓名，性别，出生年月日）

有些钢筋可能要问了，姓名可以拆成姓、名两列， “出生年月日” 也可以拆成年、月、日三个字段。所以就不满足第一范式了！！！这里再强调一下原子性，原子性是根据使用方便来自定义的最小单位。中国人一般姓名一起用，美国就习惯姓名分别存两字段

二、第二范式

---

2NF要求记录有惟一标识，即不存在部分依赖；

简单来说就是拆表，以人为粒度做一张明细表，以课程号为粒度做一张维度表，两表关联使用，消除了数据冗余

表：学号、课程号、姓名、学分;

这个表明显说明了两个事务:学生信息, 课程信息;由于非主键字段必须依赖主键，这里学分依赖课程号，姓名依赖与学号，所以不符合二范式。

可能会存在问题：

• 数据冗余：每条记录都含有相同信息；

• 删除异常：删除所有学生成绩，就把课程信息全删除了；

• 插入异常：学生未选课，无法记录进数据库；

• 更新异常：调整课程学分，所有行都调整。

正确做法:

学生：Student(学号, 姓名)；

课程：Course(课程号, 学分)；

选课关系：StudentCourse(学号, 课程号, 成绩)。

三、第三范式

---

3NF是对字段的**冗余性**，要求任何字段不能由其他字段派生出来，它要求字段没有冗余，即不存在传递依赖；

表: 学号, 姓名, 年龄, 学院名称, 学院电话

因为存在依赖传递: (学号) → (学生)→(所在学院) → (学院电话) 。

可能会存在问题：

• 数据冗余:有重复值；

• 更新异常：有重复的冗余信息，修改时需要同时修改多条记录，否则会出现数据不一致的情况 。

正确做法：

学生：(学号, 姓名, 年龄, 所在学院)；

学院：(学院, 电话)。

四、反范式化

---

一般说来，数据库只需满足第三范式（3NF）就行了。

没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余，达到以空间换时间的目的。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！**

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取