DBMS 中的范式

DBMS 中的范式，范式是在数据库中组织数据以避免数据冗余，插入异常，更新异常和数据的过程。删除异常。让我们首先讨论异常，然后我们将用例子讨论正常形式。

DBMS 中的异常

数据库未范式时会发生三种类型的异常。这些是 – 插入，更新和删除异常。我们举一个例子来理解这一点。

示例：假设制造公司将员工详细信息存储在名为employee的表中，该表具有四个属性：emp_id用于存储员工的 id，emp_name用于存储员工的姓名，emp_address用于存储员工的地址，emp_dept用于存储部门详细信息员工的工作方式。在某些时候，表看起来像这样：

上表未范式，我们将看到当表未范式时我们面临的问题。

更新异常：在上表中，员工 Rick 有两行，因为他属于公司的两个部门。如果我们想要更新 Rick 的地址，那么我们必须在两行中更新相同的内容，否则数据将变得不一致。如果不知何故，正确的地址在一个部门更新，但在其他部门没有更新，那么根据数据库，Rick 将有两个不同的地址，这是不正确的，会导致数据不一致。

插入异常：假设一名新员工加入正在接受培训并且当前未分配到任何部门的公司，那么如果emp_dept字段不允许空值，我们将无法将数据插入表中。

删除异常：假设，如果公司关闭部门 D890 的某个时间点，那么删除具有emp_dept为 D890 的行也会删除员工 Maggie 的信息，因为她只被分配给该部门。

为了克服这些异常，我们需要范式数据。在下一节中，我们将讨论范式。

范式

以下是最常用的常规形式：

• 第一范式（1NF）
• 第二范式（2NF）
• 第三范式（3NF）
• Boyce Codd 范式（BCNF）

第一范式（1NF）

根据第一范式的规则，表的属性（列）不能包含多个值。它应该只包含原子值。

示例：假设公司想要存储其员工的姓名和联系方式。它创建一个如下所示的表：

两名员工（Jon& Lester）有两个手机号码，因此公司将它们存储在您在上表中看到的相同字段中。

该表是不在 1NF 中，因为规则说“表的每个属性必须具有原子（单个）值”，员工的emp_mobile值为Jon & Lester违反了这条规则。

为了使表符合 1NF，我们应该有这样的数据：

第二范式（2NF）

如果以下两个条件成立，则表示在 2NF 中：

• 表为 1NF（第一范式）
• 没有非主属性取决于表的任何候选键的适当子集。

不属于任何候选键的属性称为非主属性。

示例：假设学校想要存储教师的数据和他们教授的科目。他们创建了一个如下所示的表：由于教师可以​​教授多个科目，因此该表可以为同一位教师设置多行。

候选键：{teacher_id, subject}

非主属性：teacher_age

该表在 1 NF 中，因为每个属性都有原子值。但是，它不在 2NF 中，因为非主属性teacher_age仅依赖于teacher_id，它是候选键的适当子集。这违反了 2NF 的规则，因为规则说“没有非主属性依赖于表的任何候选键的正确子集”。

为了使表符合 2NF，我们可以在两个表中打破它：

teacher_details表：

teacher_subject表：

现在表符合第二范式（2NF）。

第三范式（3NF）

如果满足以下条件，则表设计为 3NF：

• 表必须是 2NF
• 应删除任何超键上非主要属性的传递函数依赖。

不属于任何候选键的属性称为非主属性。

换句话说，3NF 可以这样解释：如果表在 2NF 中，则表在 3NF 中，并且对于每个函数依赖X -> Y至少满足下列条件之一：

• X是表的超键
• Y是表的主要属性

作为候选键之一的一部分的属性称为主要属性。

示例：假设公司想要存储每个员工的完整地址，他们会创建一个名为employee_details的表，如下所示：

超键：{emp_id}，{emp_id, emp_name}，{emp_id, emp_name, emp_zip}…等

候选键：{emp_id}

非主属性：除emp_id之外的所有属性都是非主，因为它们不是任何候选键的一部分。

在这里，emp_state，emp_city和emp_district依赖于emp_zip。并且，emp_zip依赖于emp_id，这使得非主属性（emp_state，emp_city和emp_district）可传递地依赖于超键（emp_id）。这违反了 3NF 的规则。

要使此表符合 3NF，我们必须将表拆分为两个表以删除传递依赖项：

员工表：

employee_zip表：

Boyce Codd 范式（BCNF）

它是 3NF 的高级版本，这也是它被称为 3.5NF 的原因。 BCNF 比 3NF 更严格。如果表是 3NF，则表符合 BCNF，对于每个函数依赖X -> Y，X应该是表的超键。

示例：假设有一家公司，员工在多个部门工作。他们存储这样的数据：

上表中的函数依赖：

• emp_id -> emp_nationality
• emp_dept -> {dept_type，dept_no_of_emp}

候选键：{emp_id, emp_dept}

该表不在 BCNF 中，因为emp_id和emp_dept都不是键。

为了使表符合 BCNF，我们可以在三个表中打破这样的表：

emp_nationality表：

emp_dept表：

emp_dept_mapping表：

函数依赖：

• emp_id -> emp_nationality
• emp_dept -> {dept_type, dept_no_of_emp}

候选键：

• 第一个表：emp_id
• 第二个表：emp_dept
• 第三个表：{emp_id, emp_dept}

现在这是在 BCNF 中，因为在函数依赖中左侧部分是关键。