下载文档原格式
关系型数据库三⼤范式基础概念：关键字、主关键字、候选关键字,⾮关键字如果某个字段或多个字段的值可以唯⼀地标识⼀条记录，则该字段或字段组就称为关键字。
如果⼀个关键字是⽤以标识每条记录的唯⼀性，并作为该表与其他表实现关联之⽤，则称其为主关键字（主键，primary key）或主码。
除主关键字以外的其他关键字称为候选关键字。
除关键字意外的字称为⾮关键字例如，有⼀个表字段为：id firstname lastname address phone IDcard那么id或IDcard或firstname+lastname（不存在同名的情况下）都可以说是关键字。
其中id为主关键字，IDcard和firstname+lastname为候选关键字。
数据库设计范式第⼀范式(1NF)：数据表中的字都是单⼀属性，不可再分的（原⼦性）。
单⼀属性由基本类型构成，包括整型、实数、字符型、逻辑型、⽇期型等。
在任何⼀个关系数据库中，第⼀范式（1NF）是对关系模式的基本要求，不满⾜第⼀范式（1NF）的数据库就不是关系数据库。
第⼆范式(2NF)：数据表中⾮关键字都不存在对候选关键字的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定⾮关键字段的情况），则符合第⼆范式（完全依赖于主键），也即所有⾮关键字段都完全依赖于任意⼀组候选关键字。
例：假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系： (学号, 课程名称) → (姓名, 年龄, 成绩, 学分) 这个数据库表不满⾜第⼆范式，因为存在如下决定关系： (课程名称) → (学分) (学号) → (姓名, 年龄) 即存在组合关键字中的字段决定⾮关键字的情况。
由于不符合2NF，这个选课关系表会存在如下问题： (1) 数据冗余： 同⼀门课程由n个学⽣选修，"学分"就重复n-1次；同⼀个学⽣选修了m门课程，姓名和年龄就重复了m-1次。
什么是数据库三⼤范式，它们是做什么的？设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越⾼的范式数据库冗余越⼩。
关系数据库有六种范式：第⼀范式（1NF）、第⼆范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，⼜称完美范式）。
满⾜最低要求的范式是第⼀范式（1NF）。
在第⼀范式的基础上进⼀步满⾜更多规范要求的称为第⼆范式（2NF），其余范式以次类推。
⼀般来说，数据库只需满⾜第三范式(3NF）就⾏了。
1、第⼀范式（1NF）：所谓第⼀范式（1NF）是指在关系模型中，对于添加的⼀个规范要求，所有的域都应该是原⼦性的，即数据库表的每⼀列都是不可分割的原⼦数据项，⽽不能是集合，数组，记录等⾮原⼦数据项。
即实体中的某个属性有多个值时，必须拆分为不同的属性。
在符合第⼀范式（1NF）表中的每个域值只能是实体的⼀个属性或⼀个属性的⼀部分。
简⽽⾔之，第⼀范式就是⽆重复的域。
2、第⼆范式（2NF）在1NF的基础上，⾮码属性必须完全依赖于候选码（在1NF基础上消除⾮主属性对主码的部分函数依赖）第⼆范式（2NF）是在第⼀范式（1NF）的基础上建⽴起来的，即满⾜第⼆范式（2NF）必须先满⾜第⼀范式（1NF）。
第⼆范式（2NF）要求数据库表中的每个实例或记录必须可以被唯⼀地区分。
选取⼀个能区分每个实体的属性或属性组，作为实体的唯⼀标识。
例如在员⼯表中的⾝份证号码即可实现每个⼀员⼯的区分，该⾝份证号码即为候选键，任何⼀个候选键都可以被选作主键。
在找不到候选键时，可额外增加属性以实现区分，如果在员⼯关系中，没有对其⾝份证号进⾏存储，⽽姓名可能会在数据库运⾏的某个时间重复，⽆法区分出实体时，设计辟如ID等不重复的编号以实现区分，被添加的编号或ID选作主键。
（该主键的添加是在ER设计时添加，不是建库时随意添加），第⼆范式（2NF）要求实体的属性完全依赖于主关键字。
第一范式（1NF）、第二范式（2NF）和第三范式（3NF）之间的区别是什么？构造数据库必须遵循一定的规则。
在关系数据库中，这种规则就是范式。
范式是符合某一种级别的关系模式的集合。
关系数据库中的关系必须满足一定的要求，即满足不同的范式。
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。
满足最低要求的范式是第一范式（1NF）。
在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。
一般说来，数据库只需满足第三范式（3NF）就行了。
下面我们举例介绍第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。
3.4.1 第一范式（1NF）在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。
在第一范式（1NF）中表的每一行只包含一个实例的信息。
例如，对于图3-2 中的员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。
简而言之，第一范式就是无重复的列。
3.4.2 第二范式（2NF）第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。
为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
如图3-2 员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。
数据库之闭包，范式.1 第⼀范式（1NF）⽆重复的列 所谓第⼀范式（1NF）是指数据库表的每⼀列都是不可分割的基本数据项，同⼀列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
如果出现重复的属性，就可能需要定义⼀个新的实体，新的实体由重复的属性构成，新实体与原实体之间为⼀对多关系。
在第⼀范式（1NF）中表的每⼀⾏只包含⼀个实例的信息。
简⽽⾔之，第⼀范式就是⽆重复的列。
说明：在任何⼀个关系数据库中，第⼀范式（1NF）是对关系模式的基本要求，不满⾜第⼀范式（1NF）的数据库就不是关系数据库。
1.2 第⼆范式（2NF）属性完全依赖于主键[消除部分⼦函数依赖] 第⼆范式（2NF）是在第⼀范式（1NF）的基础上建⽴起来的，即满⾜第⼆范式（2NF）必须先满⾜第⼀范式（1NF）。
第⼆范式（2NF）要求数据库表中的每个实例或⾏必须可以被唯⼀地区分。
为实现区分通常需要为表加上⼀个列，以存储各个实例的唯⼀标识。
例如员⼯信息表中加上了员⼯编号（emp_id）列，因为每个员⼯的员⼯编号是唯⼀的，因此每个员⼯可以被唯⼀区分。
这个唯⼀属性列被称为主关键字或主键、主码。
第⼆范式（2NF）要求实体的属性完全依赖于主关键字。
所谓完全依赖是指不能存在仅依赖主关键字⼀部分的属性，如果存在，那么这个属性和主关键字的这⼀部分应该分离出来形成⼀个新的实体，新实体与原实体之间是⼀对多的关系。
为实现区分通常需要为表加上⼀个列，以存储各个实例的唯⼀标识。
简⽽⾔之，第⼆范式就是属性完全依赖于主键。
1.3 第三范式（3NF）属性不依赖于其它⾮主属性[消除传递依赖] 满⾜第三范式（3NF）必须先满⾜第⼆范式（2NF）。
简⽽⾔之，第三范式（3NF）要求⼀个数据库表中不包含已在其它表中已包含的⾮主关键字信息。
例如，存在⼀个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。
那么在的员⼯信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加⼊员⼯信息表中。
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）、部门名称、部门简介等信息。
数据库第四范式
数据库第四范式（4NF）是关系数据库设计中的一种范式，它建立在第三范式（3NF）的基础上。
第三范式要求所有的非关键字列都必须和所有的超键直接依赖，但是在某些情况下，数据库设计可能会出现类似于多对多的关系，使得依赖关系的复杂度增加。
此时，第四范式就可以帮助我们通过消除多值依赖和联合依赖等复杂关系，从而减少冗余数据，提高数据库的性能和查询效率。
在第四范式中，我们可以定义一个关系模式R（A，B，C，D），其中A是关系模式的主键（也可以是超键）。
若在该关系模式中存在以下两种情况之一，则该关系模式R符合第四范式要求：
1. 对于每个非主属性B，如果它与关系的其他非主属性C存在多值依赖，那么B可以被拆分成两个关系模式，其中一个包含属性B和A，另一个包含属性C和A。
2. 对于每个非主属性B和C，如果它们之间存在联合依赖，那么B和C可以被拆分成两个关系模式，其中一个包含属性B、A和C，另一个包含属性C和A。
通过将一个大的关系模式分解成多个小的关系模式，我们可以消除重
复的数据，提高数据库的性能和查询效率。
同时，第四范式也可以保证数据库的数据一致性和完整性，减少数据冗余和异常，避免数据的不一致性和混乱。
总之，数据库第四范式是关系数据库设计中的一种重要的范式，它可以有效地提高数据库的性能和查询效率，同时也可以保证数据库的数据一致性和完整性。
然而，在实际应用中，我们需要根据具体的业务需求和数据特点来选择不同的范式和设计方案，以达到最优的数据库设计效果。
sql 规则和范式
SQL规则和范式是数据库设计和管理中非常重要的概念。
首先，让我们来谈谈SQL规则。
SQL是结构化查询语言的缩写，它是一种
用于管理关系型数据库的标准化语言。
SQL规则是指在编写SQL语
句时需要遵循的一系列规则和约定，以确保数据库操作的准确性和
一致性。
这些规则包括语法规则、数据类型规则、约束规则等。
例如，SQL语句必须按照特定的语法结构编写，数据类型必须与字段
定义一致，约束条件必须满足数据库设计的要求等。
接下来是范式的概念。
范式是用来规范化数据库设计的一组原则，旨在减少数据冗余和提高数据的一致性。
常见的范式包括第一
范式（1NF）、第二范式（2NF）、第三范式（3NF）等。
第一范式要求每个字段具有原子性，不可再分；第二范式要求每个非主键字段
完全依赖于全部主键而不是部分主键；第三范式要求每个字段都直
接依赖于主键，而不是依赖于其他非主键字段。
在SQL中，范式的应用可以提高数据库的性能和可维护性，减
少数据冗余和提高数据的完整性。
但是，过度范式化也可能导致查
询性能下降，需要在设计数据库时权衡范式化和性能之间的关系。
总的来说，SQL规则和范式是数据库设计和管理中非常重要的概念，它们能够帮助我们设计出高效、可靠的数据库结构，提高数据的一致性和完整性。
在实际应用中，需要根据具体的业务需求和性能要求来灵活运用这些原则。
数据库三范式解释-概述说明以及解释1.引言1.1 概述在数据库设计中，三范式是指关系数据库中的数据规范化的一种理论。
它是为了解决数据冗余和数据更新异常而提出的一种设计原则。
通过将数据分解成多个表，并确保每个表都符合一定的规范，可以有效地减少数据冗余，提高数据的一致性和完整性。
三范式包括第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。
每个范式都有其特定的规范要求，通过逐步满足这些要求，可以确保数据库设计得到最优化的结构。
在本文中，我们将对三范式进行详细解释，并探讨其在数据库设计中的应用和局限性。
通过本文的阅读，读者将能够更加深入地理解数据库三范式，并在实际工作中更好地运用它们。
1.2 文章结构文章结构部分主要是讲述整篇长文的结构和内容安排。
在本篇长文中，我们将首先介绍数据库三范式的概念及其重要性（引言部分），然后详细解释第一范式、第二范式和第三范式的含义和原理（正文部分），最后总结三范式的应用和局限性（结论部分）。
通过这样的结构，读者可以系统地了解数据库三范式的概念和应用，为其在实际工作中的应用提供理论支持和指导。
1.3 目的数据库三范式是设计关系型数据库的重要原则，其目的在于消除数据冗余和数据插入、更新和删除异常，使数据库结构更加规范化和高效。
本文旨在深入解释数据库三范式的概念，帮助读者了解每个范式的特点和应用场景。
通过本文的阐述，读者可以更好地应用三范式原则来设计和规划数据库结构，从而提高数据库的性能和可维护性。
同时，也可以帮助读者理解三范式在实际数据库设计中的局限性和不足之处，以便在设计数据库时做出更明智的决策。
通过对数据库三范式的深入理解，读者可以更好地应用这一原则来设计规范化的数据库结构，避免常见的数据库设计问题，提高数据的一致性和完整性，从而为企业和个人提供更加可靠和高效的数据管理和应用服务。
2.正文2.1 第一范式第一范式是关系数据库设计中的基本原则，指的是每个列都是原子性的，不可再分。
数据库范式详解在数据库设计的领域中，范式（Normal Form）是一套用于规范和优化数据库结构的准则。
理解和应用这些范式，对于构建高效、准确且易于维护的数据库至关重要。
接下来，让我们深入探讨一下数据库范式的相关知识。
数据库范式的主要目的是减少数据冗余，避免数据不一致，并提高数据库的性能和可维护性。
我们从最基础的第一范式开始逐步了解。
第一范式（1NF）要求数据库中的每一列都是不可再分的原子值。
这意味着每一列都应该只包含一种数据类型，并且不能再被分割成更小的部分。
例如，如果有一个“地址”列，它不应该同时包含城市、街道和邮编等信息，而应该将这些分别存储在不同的列中，如“城市”列、“街道”列和“邮编”列。
第二范式（2NF）在满足第一范式的基础上，要求非主键列完全依赖于主键。
换句话说，如果一个表的主键是由多个列组成的复合主键，那么非主键列必须依赖于整个主键，而不能只依赖于主键的一部分。
举个例子，假设有一个订单表，主键是“订单号”和“商品编号”，那么“订单日期”和“客户姓名”等非主键列应该依赖于整个主键，而不能只依赖于“订单号”或“商品编号”。
第三范式（3NF）进一步要求非主键列之间不能有传递依赖关系。
也就是说，如果 A 列依赖于 B 列，B 列依赖于主键，那么 A 列应该直接依赖于主键，而不是通过 B 列间接依赖于主键。
例如，在一个学生表中，如果“班级编号”决定了“班主任姓名”，而“班级编号”又依赖于主键“学生编号”，那么“班主任姓名”应该直接依赖于主键“学生编号”，而不是通过“班级编号”间接依赖。
除了以上常见的三种范式，还有更高阶的范式，如巴斯科德范式（BCNF）、第四范式（4NF）和第五范式（5NF）等，但在实际应用中，大多数情况下满足第三范式就能够满足大部分数据库设计的需求。
那么，为什么要遵循数据库范式呢？首先，减少数据冗余可以节省存储空间，提高数据更新的效率。
当相同的数据在多个地方重复存储时，一旦需要更新，就必须在多个位置进行修改，这不仅增加了工作量，还容易导致数据不一致的问题。
数据库设计三范式原则概述及解释说明1. 引言1.1 概述数据库设计是构建一个高效、可靠和易于维护的数据库系统的重要环节。
三范式原则作为数据库设计的基本准则，可以指导我们在设计关系型数据库时遵循一定的规范和理念。
三范式原则分别是第一范式（1NF）、第二范式（2NF）和第三范式（3NF），它们帮助我们消除冗余数据、提高数据存储效率和数据逻辑性，以及降低数据插入、更新和删除操作的复杂度。
1.2 文章结构本文将详细介绍数据库设计三范式原则，并对每个范式进行解释说明。
首先，我们会介绍第一范式（1NF），包括其概念和应用；然后，我们会讨论第二范式（2NF）及其在数据库设计中的应用；最后，我们会深入探讨第三范式（3NF）及其对规范化数据库的作用。
1.3 目的通过本文的撰写，旨在帮助读者充分理解数据库设计三范式原则的重要性和应用价值。
了解这些基本原则对于正确进行数据库设计至关重要，并能够避免产生滥用全能关系表所带来的问题。
我们将强调遵循三范式原则所带来的好处和影响，以及它们如何使数据库系统更加高效、可靠和易于维护。
同时，我们还会提供一些实际应用示例，以帮助读者更好地理解三范式原则的具体应用场景。
以上是文章“1. 引言”部分的详细内容解释。
2. 数据库设计三范式原则：数据库设计的三范式原则是用于规范化数据库结构的重要准则。
它们有助于确保数据在数据库中的存储和处理方式具备高效性、一致性和可靠性。
2.1 第一范式（1NF）：第一范式要求数据库中的每个数据项都应该是不可再分割的最小单位，即每个字段都应该持有一个单独的值。
如果字段包含多个值，那么这些值就应该拆分成独立字段。
例如，假设我们有一个包含学生信息的表格，其中一列是“电话号码”，如果一个学生可以有多个电话号码，那么第一范式要求将这些电话号码拆分为相应数量的单独字段，以便每个字段只存储一个电话号码。
这样可以避免冗余数据，并且方便进行数据查询和更新操作。
2.2 第二范式（2NF）：第二范式建立在第一范式的基础上进一步完善了数据库设计。
数据库设计的原则和规范在进行数据库设计时，遵循一定的原则和规范是至关重要的。
良好的数据库设计可以提高系统的性能，保证数据的完整性和一致性，并且方便后续的维护和扩展。
本文将介绍一些数据库设计的原则和规范，供读者参考。
一、遵循范式设计原则范式是数据库设计中的一个重要概念，它定义了关系型数据库中数据的组织方式。
遵循范式设计原则可以提高数据库的灵活性和规范性。
常见的范式有第一范式、第二范式和第三范式。
第一范式要求数据列是原子性的，即每个数据列都不能再分解为更小的数据单元。
这样可以确保数据的完整性和一致性。
第二范式要求数据库表中的每个非主键列都必须完全依赖于主键。
如果存在非主键列只依赖于部分主键的情况，就需要将相关的非主键列提取出来创建新的表。
第三范式要求数据库表中的每个非主键列都必须直接依赖于主键，而不能依赖于其他非主键列。
这样可以避免数据冗余和更新异常。
二、选择合适的数据类型在数据库设计中，选择合适的数据类型对保证数据的准确性和查询效率起着重要的作用。
不同的数据库管理系统提供了不同的数据类型，需要根据实际需求选择合适的数据类型。
例如，在存储整数数据时，可以选择int类型来节省存储空间和提高查询效率；而在存储小数时，可以选择float或double类型来确保精度；在存储字符串时，根据字符串的长度选择合适的varchar或char类型。
三、避免使用保留字和特殊字符在数据库设计过程中，应避免使用保留字和特殊字符作为表名、字段名或约束名。
这样可以避免在查询和更新数据时出现语法错误或歧义。
通常，数据库管理系统会提供一份保留字的列表，设计人员可以参考该列表避免使用其中的保留字。
此外，还应避免使用特殊字符，以免引起解析错误或与系统命令冲突。
四、设立适当的索引索引是提高数据库查询性能的重要手段。
在数据库设计中，应设立适当的索引来加快数据的检索速度。
一般来说，可以对主键字段和常用于查询的字段建立索引。
然而，索引也会增加数据库的存储空间和维护成本。
【数据库】--各个范式的区别⼀、定义第⼀范式：关系模式中，每个属性不可再分。
属性原⼦性第⼆范式：⾮主属性完全依赖于主属性，即消除⾮主属性对主属性的部分函数依赖关系。
第三范式：⾮主属性对主属性不存在传递函数依赖关系。
BNCF范式：在第三范式的基础上，消除主属性之间的部分函数依赖⼆、第⼀范式第⼀范式（1NF）：在关系模式R中的每⼀个具体关系r中，如果每个属性值都是不可再分的最⼩数据单位，则称R是第⼀范式的关系。
例：如职⼯号，姓名，电话号码组成⼀个表（⼀个⼈可能有多个电话号码） 规范成为1NF有三种⽅法： ⼀是重复存储职⼯号和姓名。
这样，关键字只能是电话号码。
⼆是职⼯号为关键字，电话号码分为单位电话和住宅电话两个属性 三是职⼯号为关键字，但强制每条记录只能有⼀个电话号码。
以上三个⽅法，第⼀种⽅法最不可取，按实际情况选取后两种情况。
三、第⼆范式第⼆范式（2NF）：如果关系模式R（U，F）中的所有⾮主属性都完全依赖于任意候选关键字，则称关系R 是属于第⼆范式的。
例：选课关系 sc（sid，cid，grade，credit）其中sid为学号， cid为课程号，grade为成绩，credit为学分。
由以上条件，关键字为组合关键字（sid，cid）在应⽤中使⽤以上关系模式有以下问题： a.数据冗余，假设同⼀门课由40个学⽣选修，学分就重复40次。
b.更新异常，若调整了某课程的学分，相应的元组credit值都要更新，有可能会出现同⼀门课学分不同。
c.插⼊异常，如计划开新课，由于没⼈选修，没有学号关键字，只能等有⼈选修才能把课程和学分存⼊。
d.删除异常，若学⽣已经结业，从当前数据库删除选修记录。
某些门课程新⽣尚未选修，则此门课程及学分记录⽆法保存。
原因：⾮关键字属性credit仅函数依赖于cid，也就是credit部分依赖组合关键字（sid，cid）⽽不是完全依赖。
解决⽅法：分成两个关系模式sc（sid，cid，grade），c（cid，credit）。
关系数据库中的范式
范式是关系数据库中的规范，用于定义数据库表的结构和设计。
它有以下几种类型:
1. 第一正式化范式(1NF)
定义一个关系中的每个属性都是原子性的，即不能再分解为更小的部分。
2. 第二正式化范式(2NF)
要求一个关系表中的每个非主属性都完全依赖于主键。
3. 第三正式化范式(3NF)
一个关系表中的每个非主属性都不依赖于其他非主属性, 而只依赖于主键。
4. Boyce-Codd范式(BCNF)
一个关系表中的每个函数依赖都是自包含的，即没有冗余。
5. 第四正式化范式(4NF)
要求一个关系表中的每个多值依赖都是自包含的。
6. 第五正式化范式(5NF)
一个关系表中的每个联合依赖都是自包含的，即没有多余的信息。
这些范式将数据设计成标准化形式，以减少数据冗余和不一致性，并提高了数据的存储效率和查询速度。
