数据库范式：1NF、2NF、3NF、BCNF

首先要明白”范式（NF）”是什么意思。按照教材中的定义，范式是“符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度”。很晦涩吧？实际上你可以把它粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。就像家里装修买建材，最环保的是E0级，其次是E1级，还有E2级等等。数据库范式也分为1NF，2NF，3NF，BCNF，4NF，5NF。一般在我们设计关系型数据库的时候，最多考虑到BCNF就够。符合高一级范式的设计，必定符合低一级范式，例如符合2NF的关系模式，必定符合1NF。

1NF的定义为：符合1NF的关系中的每个属性都不可再分。
1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。
但是仅仅符合1NF的设计，仍然会存在数据冗余过大，插入异常，删除异常，修改异常的问题

正因为仅符合1NF的数据库设计存在着这样那样的问题，我们需要提高设计标准，去掉导致上述四种问题的因素，使其符合更高一级的范式（2NF），这就是所谓的“规范化”。

第二范式（2NF）在关系理论中的严格定义我这里就不多介绍了（因为涉及到的铺垫比较多），只需要了解2NF对1NF进行了哪些改进即可。其改进是，2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。接下来对这句话中涉及到的四个概念——“函数依赖”、“码”、“非主属性”、与“部分函数依赖”进行一下解释。

函数依赖：
若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。我们可以说姓名函数依赖于学号，写作学号 → 姓名。但是反过来，因为可能出现同名的学生，所以有可能不同的两条学生记录，它们在姓名上的值相同，但对应的学号不同，所以我们不能说学号函数依赖于姓名
完全函数依赖：
在一张表中，若 X → Y，且对于 X 的任何一个真子集（假如属性组 X 包含超过一个属性的话），X ’ → Y 不成立，那么我们称 Y 对于 X 完全函数依赖，
部分函数依赖：
假如 Y 函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X

传递函数依赖：
假如 Z 函数依赖于 Y，且 Y 函数依赖于 X （严格来说还有一个X 不包含于Y，且 Y 不函数依赖于Z的前提条件），那么我们就称 Z 传递函数依赖于 X ，

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

主属性：
包含在任何一个码中的属性成为主属性。

根据2NF的定义，判断的依据实际上就是看数据表中是否存在非主属性对于码的部分函数依赖。若存在，则数据表最高只符合1NF的要求，若不存在，则符合2NF的要求。
判断的方法是：
第一步：找出数据表中所有的码。
第二步：根据第一步所得到的码，找出所有的主属性。
第三步：数据表中，除去所有的主属性，剩下的就都是非主属性了。
第四步：查看是否存在非主属性对码的部分函数依赖。
对于第一步，我们可以这么做：
查看所有每一单个属性，当它的值确定了，是否剩下的所有属性值都能确定。
查看所有包含有两个属性的属性组，当它的值确定了，是否剩下的所有属性值都能确定。
查看所有包含了三个属性，也就是所有属性的属性组，当它的值确定了，是否剩下的所有属性值都能确定。
……
看起来很麻烦是吧，但是这里有一个诀窍，就是假如A是码，那么所有包含了A的属性组，如（A，B）、（A，C）、（A，B，C）等等，都不是码了（因为作为码的要求里有一个“完全函数依赖”）。

为了让表3符合2NF的要求，我们必须消除这些部分函数依赖，只有一个办法，就是将大数据表拆分成两个或者更多个更小的数据表，在拆分的过程中，要达到更高一级范式的要求，这个过程叫做”模式分解“。模式分解的方法不是唯一的（若码只有一个属性，则不可能存在非主属性对于码的部分函数依赖，符合2NF的要求）

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

3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。也就是说，如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。

对于学生表，主码为学号，主属性为学号，非主属性为姓名、系名和系主任。因为学号 → 系名，同时系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖，所以学生表的设计，不符合3NF的要求。。为了让数据表设计达到3NF，我们必须进一步进行模式分解为以下形式：选课（学号，课名，分数）学生（学号，姓名，系名）系（系名，系主任）

由此可见，符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。当然，在实际中，往往为了性能上或者应对扩展的需要，经常做到2NF或者1NF，但是作为数据库设计人员，至少应该知道，3NF的要求是怎样的。

BCNF范式：
在某些特殊情况下，即使关系模式符合 3NF 的要求，仍然存在着插入异常，修改异常与删除异常的问题，仍然不是 ”好“ 的设计。造成此问题的原因：存在着主属性对于码的部分函数依赖与传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。

下面各用一句话简洁地描述：
1NF
定义：所有的属性均有原子性
2NF（在满足1NF的前提上）
定义：如果依赖于主键，则需要依赖于所有主键，不能存在依赖部分主键的情况
3NF：满足2NF,非主键外的所有字段必须互不依赖，非键属性不能依赖于非键属性。
BCNF：所有属性（包括非键属性与键鼠性）不能依赖于非键属性。

数据库范式：1NF、2NF、3NF、BCNF相关推荐

数据库范式1NF 2NF 3NF BCNF
设计范式(范式,数据库设计范式,数据库的设计范式)是符合某一种级别的关系模式的集合.构造数据库必须遵循一定的规则.在关系数据库中,这种规则就是范式.关系数据库中的关系必须满足一定的要求,即满足不同的范 ...
数据库范式1NF 2NF 3NF BCNF通俗讲解
1NF(第一范式) 在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库. 所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数 ...
数据库范式1NF 2NF 3NF详细阐述
范式:关系数据库中的关系是要满足一定要求的,满足不同程度要求的不同范式.满足最低要求的叫第一范式,简称1NF ,在第一范式中满足进一步要求的为第二范式,其余以此类推.通俗来说是满足数据库关系表中的一套 ...
【转】关系型数据库的设计范式 1NF 2NF 3NF BCNF
本文转载自:https://www.cnblogs.com/langdashu/p/5924082.html 一.缘由: 要做好DBA,就要更好地理解数据库设计范式.数据库范式总结概览: 为了更好地理 ...
数据库范式 1NF, 2NF, 3NF的问题与细解
转自https://www.jianshu.com/p/94a274ef35a9 一. 关于数据冗余与异常数据库的规范化数据库规范化是一种在数据库中组织数据的技术. 规范化是消除冗余(重复)和不良 ...
数据库规范化 (1NF, 2NF, 3NF, BCNF)
先记录几个概念超键: 超键类似主键, 通过"超键", 我们可以一次性定位到某一条准确的数据上; 候选键: 候选, 即"主键"的候选; 超键是可以由多个属性来组 ...
数据库范式解析（1NF 2NF 3NF BCNF）
数据库设计范式是关系型数据库的设计准则.其目的在于通过规划设计使得数据库结构合理,尽量减少数据冗余,消除存储异常,方便数据的插入.更新和删除操作.目前常用范式包括1NF(第一范式).2NF(第二范式) ...
【数据库】范式理解：1NF,2NF,3NF,BCNF,4NF详析
数据库入门(一)范式理解:1NF,2NF,3NF,BCNF,4NF详析引言范式种类第一范式(1NF) 符合1NF的关系中的每个属性都不可再分存在问题第二范式(2NF) 在1NF基础上消除了非 ...
数据库随笔-1NF,2NF,3NF详解
数据库随笔-1NF,2NF,3NF详解基础概念通过表的更新来举例说明总结基础概念 1. 第一范式(1NF):每一列都是不可分割的原子数据项 2. 第二范式(2NF):在1NF的基础上,非码属性 ...
数据库范式（1NF 2NF 3NF BCNF）详解
数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的.结构明晰的,同时,不会发生插入(insert).删除(delete)和更新(update)操作异常.反之则是乱七八糟,不仅给 ...

数据库范式：1NF、2NF、3NF、BCNF

数据库范式：1NF、2NF、3NF、BCNF相关推荐

最新文章

热门文章