数据库三大范式通俗理解

目录

数据库范式简介

第一范式（1NF）

第二范式（2NF）

第三范式（3NF）

小结

目的原则

反范式

---

数据库范式简介

范式的简介

范式的英文名称是Normal Form，它是英国人E.F.Codd（关系数据库的老祖宗）在上个世纪70年代提出关系数据库模型后总结出来的。范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。

目前有迹可寻的共有8种范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常所用到的只是前三个范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。

数据往往种类繁多，而且每种数据之间又互相关联，因此，在设计数据库时，所需要满足的范式越多，那表的层次及结构也就越复杂，最终造成数据的处理困难。这样，还不如不满足这些范式呢。所以在使用范式的时候也要细细斟酌，是否一定要使用该范式，必须根据实际情况做出选择。一般情况下，我们使用前三个范式已经够用了，不再使用更多范式，就能完成对数据的优化，达到最优效果。

---

第一范式（1NF）

第一范式是指关系表R中的每列都是原子不可分的项。即每个属性都是最基本的数据项，不可再进行拆分。

 

所谓第一范式（1NF）是指在关系模型中，对于添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。

说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型

---

第二范式（2NF）

第二范式是指在满足第一范式的情况下，关系表R中的所有非主属性都完全依赖于R的每一个候选关键属性。即，第二范式指的是关系表有主键约束。

 

举个栗子：
假如有一个学生课程表student_course(学号, 姓名, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为只有这两个属性一起才能决定一条记录，即(学号, 课程名称) → (姓名, 成绩, 学分) ，这个关系表便不符合第二范式，因为"姓名"仅依赖于"学号"，"学分"仅依赖于"课程名"，因此，不满足第二范式条件。那么，不满足第二范式会有什么问题呢？如下：

• 数据冗余
       对于一门课程，如果有n名学生选修，则这门课程的全部信息将会重复存储n-1次，同理，一个学生选修了m门课程，则学生全部信息会重复存储m-1次，导致数据冗余存储。
• 更新问题
      如果要更新某门课程的学分，那么所有关联这门课程的记录都将更新，否则会出现数据不一致问题。
• 插入问题
      假如新增一门课程，但是尚未有学生选修，则该门课程的信息无法入库。
• 删除问题
      假如某门课程对应的记录完全被删除，则将导致这门课程的信息完全丢失。

那我们可以按照第二范式来改造上述关系表，将表分成

student(学号，姓名)，

cource(课程名称，学分)，

student_cource(学号， 课程名称， 成绩)

这样便避免了上述问题。

 

---

第三范式（3NF）

在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）。简而言之，第三范式（3NF）要求表中的非主属性都直接依赖于主键，不再依赖其他非主属性的任何一个（不存在间接传递依赖）。

举个例子：

如表emp(id，name，age，dept_id，dept_name，dept_detail)，这张表中的员工id能够决定所有非主属性。

但是我们发现dept_name，dept_detail这两个非主属性也可以由非主属性dept_id决定，而dept_id又依赖于id，因此存在间接传递依赖，不满足第三范式。

同时，可以看出，不满足第三范式的问题是存在大量的冗余数据。

解决该问题的方式很简单，只需将原关系表拆分为emp(id，name，age， dept_id)， dept(dept_id，dept_name, dept_detail)，这样不管是对于表emp还是表dept，各自的非主属性都直接依赖于主键，满足第三范式，同时也解决了数据冗余的问题。

---

小结

目的原则

规范化目的是使结构更合理，消除存储异常，使数据冗余尽量小。便于插入、删除和更新。

遵从概念单一化“一事一地”原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。

一个关系模式接着分解可以得到不同关系模式集合，也就是说分解方法不是惟一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空问，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。

 

反范式

规范化的优点是明显的，它避免了大量的数据冗余，节省了存储空间，保持了数据的一致性。

当一个库里的数据经常发生变化时，达到3NF的库可以使用户不必在超过两个以上的地方更改同一个值。那么是不是只要把所有的表都规范为3NF后，数据库的设计就是最优的呢?这可不一定。范式越高意味着表的划分更细，一个数据库中需要的表也就越多，用户不得不将原本相关联的数据分摊到多个表中。当用户同时需要这些数据时只能采用连接表的形式将数据重新合并在一起。同时把多个表联接在一起的花费是巨大的，尤其是当需要连接的两张或者多张表数据非常庞大的时候，表连接操作几乎是一个噩梦，这严重地降低了系统运行性能。