数据库的三大范式？
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了数据库的三大范式？相关的知识，希望对你有一定的参考价值。
数据库的三大范式？我是初学者想知道三大范式详细的介绍。
1、第一范式（1NF）
所谓第一范式（1NF）是指在关系模型中，对于添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。
即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。
说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。
不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。
2、第二范式（2NF）
在1NF的基础上，非码属性必须完全依赖于候选码（在1NF基础上消除非主属性对主码的部分函数依赖）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。
例如在员工表中的身份证号码即可实现每个一员工的区分，该身份证号码即为候选键，任何一个候选键都可以被选作主键。
在找不到候选键时，可额外增加属性以实现区分，如果在员工关系中，没有对其身份证号进行存储，而姓名可能会在数据库运行的某个时间重复。
无法区分出实体时，设计辟如ID等不重复的编号以实现区分，被添加的编号或ID选作主键。（该主键的添加是在ER设计时添加，不是建库时随意添加）
第二范式（2NF）要求实体的属性完全依赖于主关键字。
所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。
为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。
3、第三范式（3NF）
在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）
第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。
简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。
那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。
如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。
简而言之，第三范式就是属性不依赖于其它非主属性，也就是在满足2NF的基础上，任何非主属性不得传递依赖于主属性。
扩展资料
设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。
满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式(3NF）就行了。
参考资料：百度百科-数据库范式
如果每列(或者每个属性)都是不可再分的最小数据单元(也称为最小的原子单元),则满足第一范式.
例如:顾客表(姓名、编号、地址、……)其中"地址"列还可以细分为国家、省、市、区等。
第二范式:在第一范式的基础上更进一层,目标是确保表中的每列都和主键相关.
如果一个关系满足第一范式,并且除了主键以外的其它列,都依赖于该主键,则满足第二范式.
例如:订单表(订单编号、产品编号、定购日期、价格、……)，"订单编号"为主键，"产品编号"和主键列没有直接的关系，即"产品编号"列不依赖于主键列，应删除该列。
第三范式:在第二范式的基础上更进一层,目标是确保每列都和主键列直接相关,而不是间接相关.
如果一个关系满足第二范式,并且除了主键以外的其它列都不依赖于主键列,则满足第三范式.
为了理解第三范式，需要根据Armstrong公里之一定义传递依赖。假设A、B和C是关系R的三个属性，如果A-〉B且B-〉C，则从这些函数依赖中，可以得出A-〉C，如上所述，依赖A-〉C是传递依赖。
例如:订单表(订单编号，定购日期，顾客编号，顾客姓名，……)，初看该表没有问题，满足第二范式，每列都和主键列"订单编号"相关，再细看你会发现"顾客姓名"和"顾客编号"相关，"顾客编号"和"订单编号"又相关，最后经过传递依赖，"顾客姓名"也和"订单编号"相关。为了满足第三范式，应去掉"顾客姓名"列，放入客户表中。本回答被提问者采纳 参考技术B 作用嘛，主要是规范数据库设计，且视你自己实现的功能而定。满足范式要求的数据库设计是结构清晰的，同时可避免数据冗余和操作异常。这并意味着不符合范式要求的设计一定是错误的，在数据库表中存在1：1或1：N关系这种较特殊的情况下，合并导致的不符合范式要求反而是合理的。
关系数据库的几种设计范式介绍
1
第一范式（1NF）
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或
者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系
。在第一范式（1NF）中表的每一行只包含一个实例的信息。例如，对于图3-2
中的员工信息表，不能将员工信息都放在一列中显示，也不能将
其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。简而言之，第一范式就是
无重复的列。
2
第二范式（2NF）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要
求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。如图3-2
员工信息
表中加上了员工编号（emp_id）列，因为每个员工的员工编号是唯一的，因此每个员工可以被唯一区分。这个唯一属性列被称为主关键字或主
键、主码。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个
属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以
存储各个实例的唯一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。
3
第三范式（3NF）
满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主
关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在图3-2的员工信息表中
列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也
应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。 参考技术C 我给你解释下，他们说的都照本宣科。
第一范式，说的是数据库要划分出多个实体，就是基础表。
第二范式，说的是实体唯一性，每一行用主键区分，所以主键不能重复，主键后面跟着的都是该实体的属性。
第三范式，说的是实体和实体之间的联系，就是关联表，他们之间用主键连起来，又叫外键关联。 参考技术D 第一范式（1NF）无重复的列
第二范式（2NF）属性完全依赖于主键
第三范式（3NF）属性不依赖于其它非主属性
数据库☞“三大范式”
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。如下表所示。
读者表
| 读者编号 | 姓名 | 性别 | 联系方式 | 专业 | 注册时间 | 读者类型名 | 最大借阅天数 | 最大借阅数量 |
|---|---|---|---|---|---|---|---|---|
| 20200101 | 白百 | 女 | 18201011129 | 语言类 | 2020/09/01 | 三类 | 10 | 3 |
| 20200202 | 赵一 | 男 | 13909890980 | 工商管理 | 2020/09/01 | 一类 | 30 | 10 |
| 20200303 | 章萌 | 女 | 15098909890 | 软件工程 | 2020/09/01 | 一类 | 30 | 10 |
1-2、第二范式
满足1NF，且每一个非主属性依赖于任何一个候选码=》此时才满足2NF。(确保表中的每列都和主键相关)
作用：消除了非主属性对于候选码的部分函数依赖。
描述：上述读者信息表中，最大借阅天数和最大借阅数量均-》依赖于读者类型；而姓名、性别、联系方式、专业、注册时间又均依赖于读者编号；此时，对于读者信息表，按照逻辑明显是读者编号作为表的主键；可以把读者类型单拉出来作为一个表，把读者类型名作为此表的主键，最大借阅天数和最大借阅数量作为非主属性。
如下所示：读者信息表
| 读者编号 | 姓名 | 性别 | 联系方式 | 专业 | 注册时间 |
|---|---|---|---|---|---|
| 20200101 | 白百 | 女 | 18201011129 | 语言类 | 2020/09/01 |
| 20200202 | 赵一 | 男 | 13909890980 | 工商管理 | 2020/09/01 |
| 20200303 | 章萌 | 女 | 15098909890 | 软件工程 | 2020/09/01 |
读者类型表
| 读者类型 | 最大借阅天数 | 最大借阅数量 |
|---|---|---|
| 一类 | 30 | 10 |
| 二类 | 20 | 5 |
| 三类 | 10 | 3 |
第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。其实就是非主属性除了依赖于主属性外（主键），不能依赖其它的属性。
1-3、第三范式
第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。(在2NF的基础上加外键)
作用：消除了非主属性对于候选码的传递函数依赖。
描述：由上述2NF中得到的新表可知，读者类型决定读者的（最大借阅天数、最大借阅数量）；此时存在读者-》读者类型-》最大借阅天数（最大节借阅数量）的传递性依赖。若想消除依赖，可以把读者类型（另一张表的主键）作为读者信息表的外键，这样就可以消除传递性依赖，又能保证读者信息表中的每一个非主属（读者类型）性直接依赖于主属性。
于是修改一下读者信息表和读者类型表：
读者信息表：
| 读者编号 | 姓名 | 性别 | 联系方式 | 专业 | 注册时间 | 读者类型 |
|---|---|---|---|---|---|---|
| 20200101 | 白百 | 女 | 18201011129 | 语言类 | 2020/09/01 | 三类 |
| 20200202 | 赵一 | 男 | 13909890980 | 工商管理 | 2020/09/01 | 一类 |
| 20200303 | 章萌 | 女 | 15098909890 | 软件工程 | 2020/09/01 | 一类 |
| 读者类型 | 最大借阅天数 | 最大借阅数量 |
|---|---|---|
| 一类 | 30 | 10 |
| 二类 | 20 | 5 |
| 三类 | 10 | 3 |
上述数据库表是符合第三范式的，消除了数据冗余、更新异常、插入异常和删除异常。
上述通过使用简单的栗子来说明如何保证满足各种范式的准则的情况下，做到将一个实例最终转换为满足3NF的数据库设计。
二、范式的作用
就像上述的栗子会导致如下问题：
- 1NF时读者信息表的读者类型、最大借阅天数、最大借阅数量，如果多个用户时，在读者信息表中，这些字段的重复率就会很高。——此时会导致数据冗余过大。
- 假如读者类型新增四类、五类、六类等等，此时，还没有学生属于本类型——此时单单插入类型的数据就会导致插入异常。
- 如果要删除读者信息，但并不代表读者类型的字段就不存在了，此时对应的读者类型数据也会被删除——删除异常。
- 如果更新读者的信息如果要更新此数据，需要保证信息的一致性，那么其它相应的表应该也需要被更新——更新异常。
综上所述，数据库范式的作用是使结构更合理，消除存储异常，使数据冗余尽量小。便于插入、删除和更新。
遵从概念单一化“一事一地”原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。
【 注】一个关系模式接着分解可以得到不同关系模式集合，也就是说分解方法不是惟一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空问，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。
其实，数据库中的设计原则不仅仅只有3NF，还有更细分的BCNF、4NF、5NF等等。然而，在常见的基础设计中，一般只考虑到3NF。如果感兴趣后面范式的设计，可以自行访问—☞六大范式——总结
以上是关于数据库的三大范式？的主要内容，如果未能解决你的问题，请参考以下文章