数据库三范式的含义是什么

1NF即第一范式，是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。

2NF即第二范式，是指每个表必须有且仅有一个数据元素为主关键字(Primary key),其他数据元素与主关键字一一对应。

3NF即第三范式，是指表中的所有数据元素不但要能唯一地被主关键字所标识,而且它们之间还必须相互独立,不存在其他的函数关系。

扩展资料：

第二范式的规则是要求数据表里的所有非主属性都要和该数据表的主键有完全依赖关系；如果有哪些非主属性只和主键的一部份有关的话，它就不符合第二范式。如果一个数据表的主键只有单一一个字段的话，它就一定符合第二范式(前提是该数据表符合第一范式)。

如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式1NF中表的每一行只包含一个实例的信息。

参考资料来源：

百度百科——范式

百度百科——1NF

百度百科——第二范式

百度百科——第三范式

三范式：

①第一范式：数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性存在传递函数依赖关系。

②第二范式：完全依赖于主键，消除非主属性对主码的部分函数依赖。

③第三范式：每个非关键字列都独立于其他非关键字列，并依赖于关键字，第三范式指数据库中不能。

注意事项：

1、数据冗余：同一门课程由n个学生选修，"学分"重复n-1次，同一个学生选修了m门课程，姓名和年龄重复m-1次。

2、更新异常：若调整了某门课程的学分，数据表中所有行的"学分"值都需要更新，否则会出现同一门课程学分不同的情况。

3、插入异常：假设要开一门新课程，暂时没有人选修，那么由于没有"学号"关键字，"课程"与"学分"也无法记录入数据库。

4、删除异常：假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，"课程"和"学分"也被删除了，显然，这最终可能会导致插入异常。

为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。

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

在实际开发中最为常见的设计范式有三个：

首先是第一范式（1NF）。

符合1NF的关系（你可以理解为数据表。“关系”和“关系模式”的区别，类似于面向对象程序设计中”类“与”对象“的区别。”关系“是”关系模式“的一个实例，你可以把”关系”理解为一张带数据的表，而“关系模式”是这张数据表的表结构。1NF的定义为：符合1NF的关系中的每个属性都不可再分。表1所示的情况，就不符合1NF的要求。

表1

实际上，1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么 *** 作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。如果我们要在RDBMS中表现表中的数据，就得设计为表2的形式：表2

表2

但是仅仅符合1NF的设计，仍然会存在数据冗余过大，插入异常，删除异常，修改异常的问题，例如对于表3中的设计：

每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大

假如学校新建了一个系，但是暂时还没有招收任何学生（比如3月份就新建了，但要等到8月份才招生），那么是无法将系名与系主任的数据单独地添加到数据表中去的 ----—插入异常

假如将某个系中所有学生相关的记录都删除，那么所有系与系主任的数据也就随之消失了（一个系所有学生都没有了，并不表示这个系就没有了）。——删除异常

假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据。——修改异常。

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

第二范式

第二范式在第一范式的基础之上更进一层。是指2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。

函数依赖：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。

表中的函数依赖关系例如：

系名 → 系主任

学号 → 系主任

（学号，课名） → 分数

但以下函数依赖关系则不成立：

学号 → 课名

学号 → 分数

课名 → 系主任

（学号，课名） → 姓名

码:假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码。码也可以理解为主键。

第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

比如要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所示。

订单信息表

这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。

而如果把这个订单信息表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中，就非常完美了。如下所示。

订单信息表

订单项目表

商品信息表

这样设计，在很大程度上减小了数据库的冗余。如果要获取订单的商品信息，使用商品编号到商品信息表中查询即可。

因此可以总结判断的方法是：

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

第二步：根据第一步所得到的码，找出所有的主属性。

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

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

第三范式

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

则就是第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。

比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。

订单信息表

客户信息表

这样在查询订单信息的时候，就可以使用客户编号来引用客户信息表中的记录，也不必在订单信息表中多次输入客户信息的内容，减小了数据冗余。

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

数据库范式有第一范式、第二范式、第三范式、巴斯科德范式、第四范式、第五范式六种。数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。

设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

目前关系数据库有六种范式：第一范式、第二范式、第三范式、巴斯科德范式、第四范式和第五范式。满足最低要求的范式是第一范式。在第一范式的基础上进一步满足更多规范要求的称为第二范式，其余范式以次类推。一般说来，数据库只需满足第三范式即可。

第三范式指数据库中不能存在传递函数依赖关系。

简而言之， 第三范式（ 3NF） 要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。

所以第三范式具有如下特征：

1， 每一列只有一个值

2， 每一行都能区分。

3， 每一个表都不包含其他表已经包含的非主关键字信息。

例如， 帖子表中只能出现发帖人的 id， 而不能出现发帖人的 id， 还同时出现发帖人姓名，

否则， 只要出现同一发帖人 id 的所有记录， 它们中的姓名部分都必须严格保持一致， 这就是数据冗余。

首先，你说的应该是数据库表的范式吧？

第一范式：当关系模式R的所有属性都不能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。满足第一范式是关系模式规范化的最低要

求，否则，将有很多基本 *** 作在这样的关系模式中实现不了。

第二范式：如果关系模式R满足第一范式，并且R得所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。

第三范式：设R是一个满足第一范式条件的关系模式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选关键字，称R满足第三范式，简记为3NF

具体的例子，可以看数据库设计三大范式

ps，请忽略banner上的广告，此外，这篇文章排版还是很不错的。看着舒服。

数据库 的设计范式是数据库 设计所需要满足的规范，满足这些规范的数据库 是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update） *** 作异常。反之则是乱七八糟，不仅给数据库 的编程 人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。

设计范式是不是很难懂呢？非也，大学教材上给我们一堆数学公式我们当然看不懂，也记不住。所以我们很多人就根本不按照范式来设计数据库 。

实质上，设计范式用很形象、很简洁的话语就能说清楚，道明白。本文将对范式进行通俗地说明，并以笔者曾经设计的一个简单论坛的数据库 为例来讲解怎样将这些范式应用于实际工程。

范式说明

第一范式（1NF）：数据库 表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。

例如，如下的数据库 表是符合第一范式的：

字段1 字段2 字段3 字段4

而这样的数据库 表是不符合第一范式的：

字段1 字段2 字段3 字段4 字段31字段32

很显然，在当前的任何关系数据库 管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库 ，因为这些DBMS不允许你把数据库 表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库 都是不可能的。

第二范式（2NF）：数据库 表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。

假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：

(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)

这个数据库 表不满足第二范式，因为存在如下决定关系：

(课程名称) → (学分)

(学号) → (姓名, 年龄)

即存在组合关键字中的字段决定非关键字的情况。

由于不符合2NF，这个选课关系表会存在如下问题：

(1) 数据冗余：

同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。

(2) 更新异常：

若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。

(3) 插入异常：

假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库 。

(4) 删除异常：

假设一批学生已经完成课程的选修，这些选修记录就应该从数据库 表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。

把选课关系表SelectCourse改为如下三个表：

学生：Student(学号, 姓名, 年龄)；

课程：Course(课程名称, 学分)；

选课关系：SelectCourse(学号, 课程名称, 成绩)。

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

另外，所有单关键字的数据库 表都符合第二范式，因为不可能存在组合关键字。

第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。因此，满足第三范式的数据库 表应该不存在如下依赖关系：

关键字段 → 非关键字段x → 非关键字段y

假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)，关键字为单一关键字"学号"，因为存在如下决定关系：

(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)这个数据库 是符合2NF的，但是不符合3NF，因为存在如下决定关系：

(学号) → (所在学院) → (学院地点, 学院电话)

即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。

它也会存在数据冗余、更新异常、插入异常和删除异常的情况，读者可自行分析得知。

把学生关系表分为如下两个表：

学生：(学号, 姓名, 年龄, 所在学院)；

学院：(学院, 地点, 电话)。

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

鲍依斯-科得范式（BCNF）：在第三范式的基础上，数据库 表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。

假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库 表中存在如下决定关系：

(仓库ID, 存储物品ID) →(管理员ID, 数量)

(管理员ID, 存储物品ID) → (仓库ID, 数量)

所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：

(仓库ID) → (管理员ID)

(管理员ID) → (仓库ID)

即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。它会出现如下异常情况：

(1) 删除异常：

当仓库被清空后，所有"存储物品ID"和"数量"信息被删除的同时，"仓库ID"和"管理员ID"信息也被删除了。

(2) 插入异常：

当仓库没有存储任何物品时，无法给仓库分配管理员。

(3) 更新异常：

如果仓库换了管理员，则表中所有行的管理员ID都要修改。

把仓库管理关系表分解为二个关系表：

仓库管理：StorehouseManage(仓库ID, 管理员ID)；

仓库：Storehouse(仓库ID, 存储物品ID, 数量)。

这样的数据库 表是符合BCNF范式的，消除了删除异常、插入异常和更新异常。

范式应用

我们来逐步搞定一个论坛的数据库 ，有如下信息：

（1） 用户：用户名，email，主页，电话，联系地址

（2） 帖子：发帖标题，发帖内容，回复标题，回复内容

第一次我们将数据库 设计为仅仅存在表：

用户名 email 主页电话联系地址发帖标题发帖内容回复标题回复内容

这个数据库 表符合第一范式，但是没有任何一组候选关键字能决定数据库 表的整行，唯一的关键字段用户名也不能完全决定整个元组。我们需要增加"发帖ID"、"回复ID"字段，即将表修改为：

用户名email主页电话联系地址发帖ID发帖标题发帖内容回复ID回复标题回复内容

这样数据表中的关键字(用户名，发帖ID，回复ID)能决定整行：

(用户名,发帖ID,回复ID) → (email,主页,电话,联系地址,发帖标题,发帖内容,回复标题,回复内容)

但是，这样的设计不符合第二范式，因为存在如下决定关系：

(用户名) → (email,主页,电话,联系地址)

(发帖ID) → (发帖标题,发帖内容)

(回复ID) → (回复标题,回复内容)

即非关键字段部分函数依赖于候选关键字段，很明显，这个设计会导致大量的数据冗余和 *** 作异常。

我们将数据库 表分解为（带下划线的为关键字）：

（1） 用户信息：用户名，email，主页，电话，联系地址

（2） 帖子信息：发帖ID，标题，内容

（3） 回复信息：回复ID，标题，内容

（4） 发贴：用户名，发帖ID

（5） 回复：发帖ID，回复ID

这样的设计是满足第1、2、3范式和BCNF范式要求的，但是这样的设计是不是最好的呢？

不一定。

观察可知，第4项"发帖"中的"用户名"和"发帖ID"之间是1：N的关系，因此我们可以把"发帖"合并到第2项的"帖子信息"中；第5项"回复"中的"发帖ID"和"回复ID"之间也是1：N的关系，因此我们可以把"回复"合并到第3项的"回复信息"中。这样可以一定量地减少数据冗余，新的设计为：（1） 用户信息：用户名，email，主页，电话，联系地址

（2） 帖子信息：用户名，发帖ID，标题，内容

（3） 回复信息：发帖ID，回复ID，标题，内容

数据库 表1显然满足所有范式的要求；

数据库 表2中存在非关键字段"标题"、"内容"对关键字段"发帖ID"的部分函数依赖，即不满足第二范式的要求，但是这一设计并不会导致数据冗余和 *** 作异常；

数据库 表3中也存在非关键字段"标题"、"内容"对关键字段"回复ID"的部分函数依赖，也不满足第二范式的要求，但是与数据库 表2相似，这一设计也不会导致数据冗余和 *** 作异常。

由此可以看出，并不一定要强行满足范式的要求，对于1：N关系，当1的一边合并到N的那边后，N的那边就不再满足第二范式了，但是这种设计反而比较好！

对于M：N的关系，不能将M一边或N一边合并到另一边去，这样会导致不符合范式要求，同时导致 *** 作异常和数据冗余。

对于1：1的关系，我们可以将左边的1或者右边的1合并到另一边去，设计导致不符合范式要求，但是并不会导致 *** 作异常和数据冗余。

以上就是关于数据库三范式的含义是什么全部的内容，包括:数据库三范式的含义是什么、三范式指的是什么呢、关于数据库三大设计范式浅析等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！