3、大范式

本文主要是通过范式的实例，从而说明关系型数据库三大范式的设计思路，以及如何满足范式的规范等，最终通过例子进行理解三大范式的作用以及意义。

文章目录

• 3、大范式
• 前言
• 一、三大范式应用
• • • 1-1、第一范式
    • 1-2、第二范式
    • 1-3、第三范式
• 二、范式的作用

前言

在关系型数据库中，范式虽然只是一种设计规范，但是在数据库的设计中具有重要的作用。
再进行范式应用前，先简单介绍一些需要理解的知识：
（源自知乎用户的一篇文章：理解范式）

• 完全函数依赖

完全函数依赖在一张表中，若 X → Y，且对于 X 的任何一个真子集（假如属性组 X 包含超过一个属性的话），X ’ → Y
不成立，那么我们称 Y 对于 X 完全函数依赖，记作 X → Y。（F应该写在箭头的正上方，表示完全依赖）。

• 部分函数依赖

假如 Y 函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X，记作 X → Y，（P应该写在箭头的正上方，表示部分依赖）。

• 传递函数依赖

假如 Z 函数依赖于 Y，且 Y 函数依赖于 X ，『Y 不包含于 X，且 X 不函数依赖于 Y』这个前提），那么我们就称 Z 传递函数依赖于 X ，记作 X → Z（T应该写在箭头的正上方，表示传递函数依赖）。

• 还有主码、非主属性、外码等等常用术语的理解可以参考系数据库小结以及键（主码）小结的文章。

一、三大范式应用

1-1、第一范式

第一范式，最基本的范式。(确保每列保持原子性)

要求：数据库表中的所有字段值都是不可分解的原子值。

描述：上表的读者表中，读者类型如果仅仅只是读者类型，则属于原子。若是读者类型决定了读者借阅数量、借阅类型，此时必须把读者类型再细分下去：读者类型名、最大借阅数量、最大借阅天数。

此时满足每个属性都是不可再分的属性，满足1NF。如下表所示。

读者表

1-2、第二范式

满足1NF，且每一个非主属性依赖于任何一个候选码=》此时才满足2NF。(确保表中的每列都和主键相关)

作用：消除了非主属性对于候选码的部分函数依赖。

描述：上述读者信息表中，最大借阅天数和最大借阅数量均-》依赖于读者类型；而姓名、性别、联系方式、专业、注册时间又均依赖于读者编号；此时，对于读者信息表，按照逻辑明显是读者编号作为表的主键；可以把读者类型单拉出来作为一个表，把读者类型名作为此表的主键，最大借阅天数和最大借阅数量作为非主属性。

如下所示：读者信息表

读者类型表

第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。其实就是非主属性除了依赖于主属性外（主键），不能依赖其它的属性。

1-3、第三范式

第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。(在2NF的基础上加外键)

作用：消除了非主属性对于候选码的传递函数依赖。

描述：由上述2NF中得到的新表可知，读者类型决定读者的（最大借阅天数、最大借阅数量）；此时存在读者-》读者类型-》最大借阅天数（最大节借阅数量）的传递性依赖。若想消除依赖，可以把读者类型（另一张表的主键）作为读者信息表的外键，这样就可以消除传递性依赖，又能保证读者信息表中的每一个非主属（读者类型）性直接依赖于主属性。

于是修改一下读者信息表和读者类型表：

读者信息表：

上述数据库表是符合第三范式的，消除了数据冗余、更新异常、插入异常和删除异常。

上述通过使用简单的栗子来说明如何保证满足各种范式的准则的情况下，做到将一个实例最终转换为满足3NF的数据库设计。

二、范式的作用

就像上述的栗子会导致如下问题：

1. 1NF时读者信息表的读者类型、最大借阅天数、最大借阅数量，如果多个用户时，在读者信息表中，这些字段的重复率就会很高。——此时会导致数据冗余过大。
2. 假如读者类型新增四类、五类、六类等等，此时，还没有学生属于本类型——此时单单插入类型的数据就会导致插入异常。
3. 如果要删除读者信息，但并不代表读者类型的字段就不存在了，此时对应的读者类型数据也会被删除——删除异常。
4. 如果更新读者的信息如果要更新此数据，需要保证信息的一致性，那么其它相应的表应该也需要被更新——更新异常。

综上所述，数据库范式的作用是使结构更合理，消除存储异常，使数据冗余尽量小。便于插入、删除和更新。
遵从概念单一化“一事一地”原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。

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

其实，数据库中的设计原则不仅仅只有3NF，还有更细分的BCNF、4NF、5NF等等。然而，在常见的基础设计中，一般只考虑到3NF。如果感兴趣后面范式的设计，可以自行访问—大范式——总结

文章知识点与官方知识档案匹配，可进一步学习相关知识MySQL入门技能树SQL高级技巧CTE和递归查询31268 人正在系统学习中

来源：葡萄籽-June