数据库规范化其实就是通过应用一些通用规则来构建关系型数据库管理系统（RDBMS）的过程，无论是通过创建新的数据库设计还是通过分解，我们都会遵循一系列所谓的“范式”，它们包括：
- 非规范化形式 (UNF)
- 第一范式 (1NF)
- 第二范式 (2NF)
- 第三范式 (3NF)
- 元素键范式 (EKNF)
- Boyce-Codd 范式 (BCNF)
- 第四范式 (4NF)
- 本质元组范式 (ETNF)
- 第五范式 (5NF)
- 域键范式 (DKNF)
- 第六范式 (6NF)
1. 非规范化形式 (UNF):
这是最简单的数据库模型，也被称为非第一范式（NF2）。UNF 模型会遭受数据冗余等问题的困扰，因此它缺乏数据库规范化所带来的效率。
示例:
学生表 (Student Table):
**StudentId Name Course **
101 Raj Mathematics
Chemistry
102 Nilesh Chemistry
103 Sanu Physics
Chemistry
在这个例子中，数据处于非规范化形式，因为这个表在课程元组中包含了多值属性。但是，非规范化形式也有其自身的优势（这也是为什么尽管它缺乏数据库规范化的某些优势，我们仍然在使用它的原因），包括：
- UNF 可以处理复杂的数据结构，
- 在 UNF 中查询更简单，
- 重构数据更容易。
利用这种易于查询的特性，像 MongoDB、Apache 等 NoSQL 数据库 具有更强的可扩展性，因此像 Google、Amazon 和 Facebook 这样的科技巨头都使用它来处理每天海量难以存储的数据。
2. 第一范式或 1NF:
只有当关系表不包含任何多值属性而仅包含单值属性时，该关系才处于第一范式。
示例:
学生表 (Student Table):
**StudentId Name Course1 course2 **
101 Raj Mathematics Chemistry
102 Nilesh Chemistry
103 Sanu Physics Chemistry
为了确保该模型符合第一范式，我们将课程元组（上一个例子中）拆分为 course1 和 course2，以便将我们的课程信息作为原子实体保存，从而确保没有一行包含超过一个课程。没有重复的行。
3. 第二范式或 2NF:
如果满足以下条件，则关系处于第二范式：
- 它处于第一范式 (1NF)
- 它不包含任何部分依赖。（它不应该有任何非主属性函数依赖于关系的候选键的任何真子集。）。
4. 第三范式或 3NF:
设 R 为关系模式，X->Y 是 R 上的任何非平凡函数依赖，当满足以下条件时，它属于 3NF：
- R 应该处于 2NF
- X 应该是候选键或超键，或者
- Y 应该是主属性
（因此，基本上如果一个已经处于 2NF 的关系不包含任何传递依赖，那么它将处于 3NF。）。
5. 元素键范式或 EKNF:
它是第三范式的改进版本，因此通常 EKNF 本身就符合第三范式。当存在多个唯一的复合键并且这些键重叠时，这会导致重叠列中的冗余。
因此，如果在 3NF 关系中，每一个非平凡的函数依赖要么涉及超键，要么涉及元素键的子键，那么它就处于 EKNF。
设 R 为关系模式，并且
- X->Y 是 R 上的任何非平凡函数依赖，如果 X 是候选键或超键，则它符合 BCNF。
- X->Y 是一个平凡的函数依赖（即，Y 是 X 的子集），
因此，BCNF 没有来自任何函数依赖的冗余，它是 3NF 的一个稍微更强的版本。
7. 第四范式或 4NF:
4NF 只不过是 BCNF 的下一个级别。虽然 2NF、3NF 和 BCNF 关注的是函数依赖，但 4NF 关注的是多值依赖。
设 R 为关系模式，F 为单值和多值依赖，如果满足以下条件，X->->Y 处于 4NF：
- X 是关系的候选键或超键，
- X 与 Y 的并集等于 R
8. ETNF (本质元组范式):
ETNF 是 Essential Tuple Normal Form（本质元组范式），它比第四范式更严格，但比第五范式宽松。我们需要 ETNF 来消除元组中的冗余。如果一个关系处于 BCNF（仅由函数依赖和连接依赖指定）并且某些键只有 o