数据库范式介绍

今天面试题目里面让罗列数据库的范式，并且简单介绍一下，但是因为学习范式过去太久，平时设计数据库虽然有这种思想，但是却没有刻意去分清概念，现在简单介绍一下。

• 范式（NF）：按照教材中的定义，范式是“符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度”。实际上可以把它粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。数据库范式也分为1NF，2NF，3NF，BCNF，4NF，5NF。

• 一般在我们设计关系型数据库的时候，最多考虑到BCNF就够。符合高一级范式的设计，必定符合低一级范式，例如符合2NF的关系模式，必定符合1NF。

• 第一范式（1NF）

  • 1NF的定义为：符合1NF的关系中的每个属性都不可再分。
    – 实际上，1NF是所有关系型数据库的最基本要求。在关系型数据库管理系统（RDBMS）中已经存在的数据表，一定是符合1NF的。
    – 仅仅符合1NF的设计，仍然会存在数据冗余过大，插入异常，删除异常，修改异常的问题

• 第二范式（2NF）

  • 2NF对1NF进行的改进是，2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。涉及到四个概念—“函数依赖”、“码”、“非主属性”、与“部分函数依赖”。
  • 函数依赖：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。
    – 也就是说，在数据表中，不存在任意两条记录，它们在X属性（或属性组）上的值相同，而在Y属性上的值不同。这也就是“函数依赖”名字的由来，类似于函数关系 y = f(x)，在x的值确定的情况下，y的值一定是确定的。
  • 完全函数依赖：在一张表中，若 X → Y，且对于 X 的任何一个真子集（假如属性组 X 包含超过一个属性的话），X ’ → Y 不成立，那么我们称 Y 对于 X 完全函数依赖，记作 X F→ Y（F在箭头的正上方）。
  • 部分函数依赖：假如 Y 函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X，记作 X P→ Y（P在箭头的正上方）。
  • 传递函数依赖：Y 不包含于 X，且 X 不函数依赖于 Y这个前提下，假如 Z 函数依赖于 Y，且 Y 函数依赖于 X ，那么我们就称 Z 传递函数依赖于 X ，记作 X T→ Z（T在箭头的正上方）。
  • 码：设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K（重点是“完全”），那么我们称 K 为候选码，简称为码。在实际中通常可以理解为：假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码。一张表中可以有超过一个码。（实际应用中为了方便，通常选择其中的一个码作为主码）。
  • 非主属性：包含在任何一个码中的属性成为主属性。
  • 判断是否是2NF：根据2NF的定义，判断的依据实际上就是看数据表中是否存在非主属性对于码的部分函数依赖。若存在，则数据表最高只符合1NF的要求，若不存在，则符合2NF的要求。判断的方法是：
    – 第一步：找出数据表中所有的码。
    – 第二步：根据第一步所得到的码，找出所有的主属性。
    – 第三步：数据表中，除去所有的主属性，剩下的就都是非主属性了。
    – 第四步：查看是否存在非主属性对码的部分函数依赖。

• 第三范式（3NF）

  • 3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。也就是说， 如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。
  • 符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。当然，在实际中，往往为了性能上或者应对扩展的需要，经常 做到2NF或者1NF，但是作为数据库设计人员，至少应该知道，3NF的要求是怎样的。

以后接着完善，借鉴自知乎