数据库关系模式之范式详解

概念理解

术语定义：范式是符合某一种级别的关系模式的集合

通俗理解：相当于一个衡量数据库表关系模式设计优劣的一个标准，同教师的职称有初级、中级、高级、特级等等一样，范式同样分为几个级别

关系模式的冗余和异常问题

数据冗余：同一数据在系统中重复出现，在数据库管理中，数据冗余一直是影响系统性能的大问题。

操作异常：由于数据冗余，对数据库的操作会引起各种异常（修改异常，插入异常，删除异常）

范式

由于关系模式的各种问题，所以就出现了一个衡量数据库关系模式的标准也就是范式

第一范式（1NF）

定义：数据库表中的字段都是单一属性的，不可再分的（段是最小的单元不可再分）

1NF是关系模式应具备的最起码的条件

第二范式（2NF）

定义：在满足第一范式的情况下，且每个非主属性完全依赖于候选键

理解这句话的时候，我们先理解一下其中的一些名词

码（候选键）：

设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K（这个“完全”不要漏了），那么我们称 K 为候选码（候选键），简称为码。在实际中我们通常可以理解为：假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码

非主属性：包含在任何一个码中的属性成为主属性，其他的称为非主属性

第三范式（3NF）

定义：在满足第二范式的情况下，且每个非主属性都不传递对于码的函数依赖

 

实例

1、分析上表可知，上表属于第一范式（关系中的每个属性不可再分），但有许多问题，比如，数据冗余、插入异常、删除异常、修改异常等等

2、现在我们将其规范到第二范式，即 达到每个非主属性完全依赖于候选键，大致有四个步骤。

第一步：找出表中所有的码

 

方法是当找出的码值确定，其他的数据也就确定了，可知码为（学号，课名）

第二步：根据上一步找出的码，确定主属性

码为（学号，课名），所以主属性为学号和课名

第三步：根据表中，去除所有的主属性，剩下的就是非主属性了

根据主属性学号和课名，可知非主属性为姓名、系名、系主任和分数

第四步：查看是否存在非主属性对码的部分函数依赖

对于（学号，课名） → 姓名，有 学号 → 姓名，存在非主属性 姓名 对码（学号，课名）的部分函数依赖

对于（学号，课名） → 系名，有 学号 → 系名，存在非主属性 系名 对码（学号，课名）的部分函数依赖

对于（学号，课名） → 系主任，有 学号 → 系主任，存在非主属性 系主任 对码（学号，课名）的部分函数依赖

第五步：如果存在非主属性对码的部分函数依赖，将大数据表拆分成两个或者更多个更小的数据表

下图表示了模式分解以后的新的函数依赖关系

 

下图表示模式分解以后新的数据

 上述模式虽然有改进，但是仍然存在一些问题如

1、当删除学生信息时候，把系别信息也删除了

2、当插入新的系别时，由于没有学生信息，所以插入异常

所以说，仅仅符合2NF的要求，很多情况下还是不够的，而出现问题的原因，在于仍然存在非主属性系主任对于码学号的传递函数依赖。为了能进一步解决这些问题，我们还需要将符合2NF要求的数据表改进为符合3NF的要求。

对于学生表，主码为学号，主属性为学号，非主属性为姓名、系名和系主任。因为 学号 → 系名，同时 系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖，所以学生表的设计，不符合3NF的要求

为了让数据表设计达到3NF，我们必须进一步进行模式分解为以下形式：

选课（学号，课名，分数）

 学生（学号，姓名，系名）

系（系名，系主任）

来源：https://www.cnblogs.com/luxiaojun/p/8509225.html