关系型数据库范式（数据库范式是什么）

本文目录

• 数据库范式是什么
• 创建关系型数据库有几种范式并详述各个范式之间的递进关系
• 数据库有几种范式
• 数据库的三大范式
• 如何深入理解关系型数据库的三大范式
• 什么是数据库三大范式
• 数据库设计范式有哪些

数据库范式是什么

范式是指符合某一种级别的关系模式的集合，关系数据库中的关系必须满足一定的要求，满足不同程度要求的为不同的范式。简而言之，范式是为了消除重复数据来减少冗余数据，从而让数据库内的数据更好地组织，让磁盘空间得到更有效利用的一种标准化准则。

数据库设计对数据的存储性能，以及开发人员对数据的操作都有很大的关系，所以建立科学的、规范的数据库必须满足相关的规范准则是至关重要的。设计关系数据库时，应遵从不同的规范要求设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式。各种范式呈递次规范，越高等级的范式数据库冗余越小，满足高等级范式的先决条件是先满足低等级范式。

应用数据库范式有许多优点，但是主要优点有：（（1)可以减少数据冗余，这是最重要的优点。

（2）可以消除异常，如插入异常、更新异常、删除异常等。

（3）可以让数据组织得更加和谐、合理、高效。

满足数据库设计范式规范的数据库是简洁的、结构明晰的；同时，不会发生插入（Insert）、删除（Delete）和更新（Update）操作异常。反之，不仅给数据库的编程人员带来麻烦，而且存储了大量的冗余信息。

创建关系型数据库有几种范式并详述各个范式之间的递进关系

第一范式(1NF)：每一个属性都是原子项，不可分割
INF中所述的不可分割，是指在可分割的情况下必须分割，这是在应用环境中来判断的，当属性是文档时，虽然文档有段落标记，但还是不应该分割。
第二范式：每个非主属性要完全函数依赖于候选键，或者是主键。
关键词是“完全依赖”，与“部分依赖”或“局部依赖”相对，如果候选键或主键由两个属性组成，非主属性不能只依赖与其中一个或部分属性。
比如：股票日行情表由股票代码、股票名称、日期、收盘价四个属性组成，这就违反了2NF，因为“股票名称”部分依赖于“股票代码”。
第三范式：所有非主属性对任何候选关键字都不存在传递依赖
关键词是“传递依赖”，如果非主属性通过另一个非主属性依赖主键，则是传递依赖。
比如：股票基本信息表由股票代码、股票名称、企业名称、所在地区、所在省份组成，其中“所在省份”依赖于所在地区，存在传递依赖。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
几个相关术语：
超键（super key）：在关系中能唯一标识元组的属性集称为关系模式的超键
候选键（candidate key）：不含有多余属性的超键称为候选键
主键（primary key）：用户选作元组标识的一个候选键称为主键
主属性（Prime Attribute）：候选键中的属性称为主属性
非主属性(Non-Key Attribute)：不包含在任何候选键中的属性称为非主属性。

数据库有几种范式

目前关系数据库有六种范式，即第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯−科德范式（BCNF）、第四范式（4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式依次类推。一般来说，数据库只需满足第三范式（3NF）。

第一范式（1NF）第一范式（1NF）是指在关系模型中，对域添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不是集合、数组、记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。

简而言之，第一范式（1NF）是最基本的范式，如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足第一范式（1NF）。在任何一个关系数据库中，第一范式（1NF）是对关系模式设计的基本要求，所有设计的数据模型都必须满足第一范式（1NF）。

从上面的定义描述中，可以归纳出第一范式（1NF）具有如下几个显著特点：（（1)数据库表中的字段都是单一属性。

①字段不可再分。

②同一列中不能有多个值。

（2）单一属性由基本类型构成。

①整型。

②实数。

③字符型。

④逻辑型。

⑤日期型。

⑥其他类型。

满足以上两大特征的表就是符合第一范式（1NF）的表，不满足以上任一特征的表都是不符合第一范式（1NF）的表。

例如，图字段可再分的表所示的“电话”字段可以再拆分成“手机”与“座机”字段，不满足“字段不可再分”的要求，因此不符合第一范式（1NF）要求。

字段可再分的表

又如，图字段可再分的表所示的“姓名”字段包含“张伟”与“宋鑫”两个值，不满足“同一列中不能有多个值”的要求，因此也不符合第一范式（1NF）要求。

同一列中有多个值的表

第二范式（2NF）第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。例如，员工表中的身份证号码即可实现每个员工的区分，该身份证号码即候选键，任何一个候选键都可以被选作主键。在找不到候选键时，可额外增加属性以实现区分。如果在员工关系中没有对其身份证号码进行存储，而姓名可能会在数据库运行的某个时间重复，无法区分出实体时，设计身份证号码等不重复的编号以实现区分，被添加的编号选作主键。注意：该主键的添加是在ER设计时添加，不是在建库时随意添加。

第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖，是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分，通常需要为表加上一个列，以存储各个实例的唯一标识。

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

所谓联合主键，是指由两个或两个以上的字段共同组成数据表的主键。如图联合主键表所示，单凭“客户”字段无法确定表中唯一的记录，单凭“开户银行”字段也无法确定表中唯一的与“开户银行”一起组成数据表的联合主键。

联合主键表

从上面的定义描述中，可以归纳出第二范式（2NF）具有如下几个显著特点：（（1)数据库表满足第一范式（1NF）。

（2）数据库中每个表均有主键。

①单字段主键。

②联合主键。即不能存在单个主键字段决定非主键字段的情况。

例如，表中有A、B、C、D、E五个字段，若A与B为联合主键（A，B），如有A决定C的情况（A→C），则不符合第二范式（2NF）。

满足以上特征的表就是符合第二范式（2NF）的表，不满足以上任何一特征的表都是不符合第二范式（2NF）的表。

例如，如图所示，所有字段均不可再拆分，因而满足第一范式（1NF）的要求，但表中没有任何一个字段可以确定表中的唯一记录，即表中没有主键，因此其不满足“数据库中每张表均有主键”的要求，所以不符合第二范式（2NF）要求。

又如，如图所示，满足第一范式（1NF）的要求，并且在原来的基础上增加了“ID”字段作为表的主键，因此其符合第二范式（2NF）要求。

没有主键的数据表

增加了主键的数据表

重新分析图1−3所示的联合主键表，此表符合第一范式（1NF）“字段不可再拆分”的要求，并且有“客户”与“开户银行”两个字段作为表的联合主键（客户，开户银行），但其是否就是一个符合第二范式（2NF）的表呢？

进一步分析，就可以发现：“客户电话”字段由“客户”字段决定，“开户行地址”字段由“开户银行”字段决定；即存在如下依赖关系：客户→客户电话，开户银行→开户行地址。

（客户，开户银行）为主键字段，（客户电话，开户行地址）为非主键字段，因此，其不符合联合主键中“不能存在单个主键字段决定非主键字段”的情况，所以可以认定其并不是符合第二范式（2NF）的数据表。

例1.1判断如图所示的学生信息表是否符合第二范式（2NF）。

图所示中存在联合主键（学号，课程编号），但存在（学号→姓名）、（课程编号→课程名）的依赖关系，即存在某个主键字段决定非主键字段的情况，因此其不符合第二范式（2NF），不是第二范式（2NF）表。可考虑把此表拆成分数表（见图）、课程表（见图）和姓名表（见图），则此三个表是符合第二范式（2NF）的表。

图学生信息表

图分数表

图课程表

图姓名表

第三范式（3NF）第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。第三范式（3NF）要求一个关系中不包含已在其他关系包含的非主关键字信息。

第三范式（3NF）就是任何非主属性不依赖于其他非主属性，也就是在满足第二范式（2NF）的基础上，任何非主属性不得传递依赖于主属性。第三范式（3NF）需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。数据不能存在传递关系，即每个属性都跟主键有直接关系而不是间接关系。如属性之间含有A→B→C这样的关系，是不符合第三范式（3NF）的。

当数据表不符合第三范式（3NF）时，会有大量的冗余数据，还会存在插入异常、删除异常、数据冗余度大、修改复杂等问题。

从上面的定义描述中，可以归纳出第三范式（3NF）具有如下几个显著特点：（（1)数据库表满足第二范式。

（2）数据库表的非主键字段不存在传递依赖关系（即非主键字段不能决定其他非主键字段）。例如，表中有A、B、C、D、E五个字段，若A为主键，如有C决定D的情况（C→D）则不符合第三范式（3NF）。

满足以上特征的表就是符合第三范式（3NF）的表，不满足以上任何一特征的表都是不符合第三范式（3NF）的表。

如图所示，表中有主键（工号），因而满足第二范式（2NF）的要求；但表中非主键字段间存在传递依赖关系：非主键字段“部门”决定非主键字段“部门电话”和“部门主管”（部门→部门电话，部门→部门主管），因此不符合第三范式（3NF）的要求。

图非主键字段存在传递依赖关系的表

例1.2判断图所示的学生院属信息表是否符合第三范式（3NF）。

图学生院属信息表

图中有主键（学号），则满足第二范式（2NF）的要求，但存在（所在学院→学院电话）、（所在学院→学院地点），即存在非主键字段决定其他非主键字段的情况，因此其不符合第三范式（3NF）的要求，不是第三范式（3NF）表。可考虑把此表拆成学生表（见图）和学院表（见图），则两个表是符合第三范式（3NF）的表。

图学生表

图学院表

数据库的三大范式

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）就行了。

参考资料：百度百科-数据库范式

如何深入理解关系型数据库的三大范式

二、数据库范式分类
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般来说，数据库只需满足第三范式(3NF）就行了。
三、数据库三大范式剖析
3.1 第一范式（1NF）
第一范式强调每一列都是不可分割的原子数据项。
说到原子这个词，肯定有小伙伴就先到了原子性问题，其实这么想也是没有错的。那就让我带你们去剖析一下第一范式。
首先，我用Excel表格模拟数据库中的表，并在表中填入了一些数据。如下：
image-20200613164428707
当你看到这些数据的时候，是否有些数据让你感到不适？我的答案，是的。当我看到系名/系主任这一列数据的时候感觉这并不合符我们数据库的设计理念，因为它完全可以拆分为两个列的。其实每一个人的思想中的已经有了这个范式要求的概念，只是你并不知道这个概念叫做第一范式。
如果有的小伙伴说，这些数据都让感到不适，那我就在这里夸上你一句，你很聪明。但是请你跟紧我的思路，我会一步一步的将数据落实到范式中！
表1显然不遵循第一范式，那我们就把它修改一下，让其遵循第一范式的要求。
image-20200613164455095
将系名/系主任的列拆分成了两个列系名和系主任后，很明显改数据已经遵循的第一范式的要求。再来看看这张表2，聪明的你是不是第一眼又发现了问题呢？
存在的问题：

存在非常严重的数据冗余，姓名、系名、系主任
添加数据问题：当在数据表中添加一个新系和系主任时，比如：在数据表中添加高主任管理化学系。你会发现添加之后，在一个数据表中就会多出来了高主任和化学系，而这两个数据并没有对应哪个学生，显然这时不合法的数据。
删除数据问题：如果Jack同学毕业多年了，我们数据表中没有必要在留Jack相关的数据了，就会想到把Jack相关的删除掉。当你在表2的表结构中删除了Jack相关数据，你会发现整个刘主任和管理系以及会计和酒店管理都消失了，难道数据表中没有这些数据就证明这个学校没有它们吗？显然这更加离谱了！

了解了只遵循第一范式带来的麻烦，我们就需要去看一下第二范式是怎么定义的，是否能解决第一范式留下来的问题！
3.2 第二范式（2NF）
第二范式在1NF的基础上，非属性码的属性必须完全依赖于主码。（在1NF基础上消除非属性码的属性对主码的部分函数依赖）
看到第二范式的概念，现在你应该是一个不懂的状态。那让我带你了解几个概念吧，这样你就会懂了！
函数依赖（完全、部分、传递）
函数依赖： A - 》 B，如果通过A属性（或属性组）的值可以确定唯一B属性的值，则可以成为B依赖于A（- 》符号是确定关系）。例如：可以通过学号来确定姓名，可以通过学号和课程来确定该课程的分数等等

完全函数依赖： A - 》 B，如果A是一个属性组，则B属性的确定需要依赖A属性组中的所有属性值。例如：分数的确定需要依赖于学号和课程，而学号和课程可以称为一个属性组。如果有学号没有课程，我们只知道是谁的分数，而不知道是那一学科的分数。如果有课程没有学号，那我们只知道是哪一个学科的分数，而不知道是谁的分数。所以该属性组的两个值是必不可少的。这就是完全函数依赖。
部分函数依赖： A - 》 B，如果A是一个属性组，则B属性的确定需要依赖A属性组中的部分属性值。例如：如果一个属性组中有两个属性值，它们分别是学号和课程名称。那姓名的确定只依赖这个属性组中的学号，于课程名称无关。简单来说，依赖于属性组的中部分成员即可成为部分函数依赖。
传递函数依赖： A - 》 B - 》 C，传递函数依赖就是一个依赖的传递关系。通过确定A来确定B，确定了B之后，也就可以确定C，三者的依赖关系就是C依赖于B，B依赖于A。例如：我们可以通过学号来确定这位学生所在的系部，再通过系部来确定系主任是谁。而这个三者的依赖关系就是一种传递函数依赖。

候选码、主属性码与非属性码

码： 如果在一张表中，一个属性或属性组，被其他所有属性所完全函数依赖 ，则称这个属性（或属性组）为该表的候选码，简称码。然而码又分为主属性码和非属性码。例如：分数的确定没有学号和课程是不行的，所以分数完全函数依赖于课程和学号。
主属性码： 主属性码也叫主码，即在所有候选码挑选一个做主码，这里相当于是主键。例如：分数完全函数依赖于课程和学号。该码属性组中的值就有课程、学号和分数，所以我们要在三个候选码中，挑选一个做主码，那就可以挑选学号。
非属性码： 除主码属性组以外的属性，叫做非属性码。例如：在分数完全函数依赖于课程和学号时，其中学号已经让我们选为主码。那么我们就可以确定，除了学号以外的属性值，其他的属性值都是非属性码。也就是说在这个完全函数依赖关系中，课程和分数是非属性码。

当我们了解这些概念后，回过头来再看2NF的概念：在1NF的基础上，非属性码的属性必须完全依赖于主码（在1NF基础上消除非属性码的属性对主码的部分函数依赖）
我们还使用分数完全函数依赖于学号和课程这个函数依赖关系。此关系中非属性码为：课程和分数，主码为学号。梳理清楚关系后，遵循在1NF基础上，非属性码的属性必须完全依赖于主码的第二范式。就需要继续修改表结构了。遵循1NF和2NF的表结构如下：
image-20200613170300513
image-20200613170326468
正如你所看到的，我们把表2根据1NF和2NF拆分成了表3和表4。这时候你再看表3，表3中的分数就完全函数依赖于表3中的学号和课程。表4中也挑选学号做主码。虽然解决了数据冗余问题，但是仅仅这样还是不够的，上述问题中其他的两个问题并没有得到解决！
存在的问题：

数据删除问题
数据添加问题

注意： 在第二范式中存在的这两个问题，就是在第一范式中存在问题的其中两个并没有得到解决。
既然第一范式和第二范式都没有解决这两个问题，那第三范式帮你解决！
3.3 第三范式（3NF）
第三范式在2NF基础上，消除传递依赖。
说到传递依赖，那我们的数据表中还有哪些传递依赖呢？这时候你会发现表4中含有传递依赖的。表4中的传递依赖关系为：姓名 - 》 系名 - 》 系主任。该传递依赖关系为系主任传递依赖于姓名。再根据此传递依赖关系分析我们添加和删除问题就漏洞百出了。消除传递依赖的办法还是将表4进行拆分。拆分后的表结构如下：
image-20200613172237233
image-20200613172303711
当我们把表4拆分成表5和表6时，你再来分析添加和删除问题就会有不一样的结果。假设在数据表中添加高主任管理的化学系时，该数据只会添加到表6中，不会发生传递依赖而影响其他数据。那假设Jack同学毕业了，要将Jack同学的相关数据从表中删除，这时我们需要删除表6中的学号3数据和表3中的学号3数据即可，它们也没有传递依赖关系，同样不会影响到其他数据。
四、范式的表设计
在这里我详细讲解了数据库的三大范式，为什么一般我们只研究三大范式而不去延申至六大范式呢？在上面数据库范式概念的时候，我也有讲过。这里我还需要强调一下！
数据库六大范式，一级比一级要求得严格。各种范式呈递次规范，越高的范式数据库冗余越小。范式即是对数据库表设计的约束，约束越多，表设计就越复杂。表数据过于复杂，对于我们后期对数据库表的维护以及扩展、删除、备份等种种操作带来了一定的难度。所以，在实际开发中我们只需要遵循数据库前面的三大范式即可，不需要额外延申扩展。
注意： 在剖析三大范式的时候，最终版本的表结构就是表3 + 表5 + 表6。我需要在这里说明一个问题，其实这样设计表是可以的，但并不是很合理。因为我们在建表的时候是有主键和外键约束的。这三张表中，第一列的表默认为主键，其中主键为学号还可以接收，如果主键为系名那就占用的空间变大了。在表的级联查询中会损耗性能。所以，一般我们在设计表的时候，是需要主外键约束的，而其主外键基本是都是占用内容空间很小的数字。当你的表结构和需求满足主键递增时，则可以通过设置auto_increment参数来完成！
这里如果不了解MySQL主外键约束的小伙伴，可以参考此文章MySQL基础来查补缺漏知识点。
如何深入理解关系型数据库的三大范式
标签：title就是break知识点bordernear从表maxval

什么是数据库三大范式

什么是范式：简言之就是，数据库设计对数据的存储性能，还有开发人员对数据的操作都有莫大的关系。所以建立科学的，规范的的数据库是需要满足一些
规范的来优化数据数据存储方式。在关系型数据库中这些规范就可以称为范式。
什么是三大范式：
第一范式：当关系模式R的所有属性都不能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。满足第一范式是关系模式规范化的最低要
求，否则，将有很多基本操作在这样的关系模式中实现不了。
第二范式：如果关系模式R满足第一范式，并且R得所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。
第三范式：设R是一个满足第一范式条件的关系模式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选关键字，称R满足第三范式，简记为3NF。

数据库设计范式有哪些

关系数据库中的关系必须满足一定的要求，即满足不同的范式。
（推荐学习：mysql教程）
关系数据库有六种范式：
第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴德斯科范式（BCNF）、第四范式（4NF）和第五范式（5NF）。
满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以此类推。一般说来，数据库只需满足第三范式（3NF）就行了。
设计关系型数据库时，遵从不同的规范要求，设计出合理的关系型数据库。这些规范被称作范式。越高的范式数据库的冗余度就越低。
第一范式
无重复的列
数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。如果实体中的某个属性有多个值时，必须拆分为不同的属性
在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。
换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。
第二范式
属性完全依赖于主键
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
当存在多个主键的时候，才会发生不符合第二范式的情况。比如有两个主键，不能存在这样的属性，它只依赖于其中一个主键，这就是不符合第二范式。
如果存在不符合第二范式的情况，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。
第三范式
属性不能传递依赖于主属性（属性不依赖于其它非主键属性）
第三范式（3NF）是在第二范式（2NF）的基础上建立起来的，即满足第三范式（3NF）必须先满足第二范式（2NF）。
如果某一属性依赖于其他非主键属性，而其他非主键属性又依赖于主键，那么这个属性就是间接依赖于主键，这被称作传递依赖于主属性。