📌  相关文章
📜  DBMS 中的范式类型

📅  最后修改于: 2021-09-09 12:00:33             🧑  作者: Mango

数据库规范化只不过是通过应用一些一般规则来构建 RDBMS 的过程，方法是创建新的数据库设计或通过一系列所谓的规范形式进行分解，这些规范形式是：

  1. 非规范化形式或 UNF
  2. 第一范式或 1NF
  3. 第二范式或 2NF
  4. 第三范式或 3NF
  5. 基本键范式或 EKNF
  6. 博伊斯 Codd 范式或 BCNF
  7. 第四范式或 4NF
  8. 基本元组范式或 ETNF
  9. 第五范式或 5NF
  10. 域密钥范式或 DKNF
  11. 第六范式或 6NF

1. 非规范化形式或 UNF：
它是最简单的数据库模型，也称为非第一范式(NF2)。UNF 模型会遇到数据冗余等问题，因此缺乏数据库规范化的效率。

例子：
学生表： 

StudentId      Name       Course 
 
  101           Raj        Mathematics
                          Chemistry
  102          Nilesh      Chemistry
  103          Sanu        Physics
                          Chemistry

在上面的示例中，数据采用非规范化形式，因为该表包含课程元组中的多值属性。但是非规范化形式也有几个优点(这就是为什么我们仍然使用它，尽管它缺乏数据库规范化的几个优点)，它们是：

  1. UNF 可以处理复杂的数据结构，
  2. 在 UNF 中查询更简单，
  3. 重组数据更容易。

使用这种更容易查询的特性 NoSQL 数据库(如 MongoDB、Apache 等)更具可扩展性，因此谷歌、亚马逊和 Facebook 等技术巨头每天使用它来处理难以存储的大量数据。

2. 第一范式或 1NF：
仅当关系表不包含任何多值属性而仅包含单值属性时，关系才处于第一范式。

例子：
学生表： 

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 中。

6. 博伊斯 Codd 范式或 BCNF：
让 R 是一个关系模式，并且

  • X->Y如果 X 是候选键或超级键，则对 R 的任何非平凡函数依赖是 BCNF。

    或者

  • X->Y是一个平凡的函数依赖(即 X 的 Y 子集)，

因此，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，比Fourth Normal Form更严格，但比Fifth Normal Form更不严格。需要ETNF来消除元组中的冗余。关系将在 ETNF 中，关系在 BCNF(仅由 Functional 和 Join Dependencies 指定)中，并且某些键只有一个属性。 (如果每个键只有一个属性，那么 5NF 中的关系。)。这是 ETNF 关系的简单充分条件。

在 ETNF 中，每个显式连接依赖的一个组件是一个超键。

9.第五范式或5NF：
5NF 也称为 Project-Join Normal Form 或 PJ/NF。 5NF 旨在减少关系数据库中的冗余。为了避免冗余，所有表在 5NF 中被分成尽可能多的表。当该关系的候选键隐含每个非平凡连接依赖项时，表处于 5NF 中。 (不应包含任何连接依赖项并且连接应该是无损的。)。

10.域密钥范式或DKNF：
这是数据库仅包含两个约束的正常形式，它们是：

  1. 域约束，
  2. 关键约束。

域约束的函数是指定给定属性的允许值，而键约束的主要函数是指定唯一标识给定表中行的属性。
域密钥范式避免了所有非时间异常。

永远记住，无法用外键表达的关系显然违反了域键范式。

11.第六范式或6NF：
只有当一个关系不支持任何非平凡的连接依赖关系时，它才属于 6NF。任何在 6NF 中的关系也应该在 5NF 中。尽管一些作者使用术语第六范式作为 DKNF 的同义词，但 6NF 比域键范式更严格且冗余更少。

6NF 将关系变量分解为不可约分量。这对于非时间关系变量来说相对不重要，但在我们处理时间变量或其他区间数据时很重要。第六范式在许多数据仓库中使用，其利大于弊。

规范化必然涉及组织数据库的列或属性和表，以确保它们的依赖关系由数据库完整性约束正确执行