📜  DBMS 中的范式

📅  最后修改于: 2021-09-27 14:49:51             🧑  作者: Mango

先决条件——数据库规范化和功能依赖概念。

规范化是从一个关系或一组关系中最小化冗余的过程。相关冗余可能导致插入、删除和更新异常。因此,它有助于最大限度地减少关系中的冗余。范式用于消除或减少数据库表中的冗余。

1. 第一范式 –

如果关系包含复合或多值属性,则违反第一范式;如果关系不包含任何复合或多值属性,则为第一范式。如果该关系中的每个属性都是单值属性,则该关系是第一范式。

  • 示例 1 –由于多值属性 STUD_PHONE,表 1 中的关系 STUDENT 不在 1NF 中。其分解为 1NF 如表 2 所示。

  • 示例 2 –
    ID   Name   Courses
    ------------------
    1    A      c1, c2
    2    E      c3
    3    M      C2, c3
    

    在上表中 Course 是一个多值属性,所以它不在 1NF 中。

    下表在 1NF 中,因为没有多值属性

    ID   Name   Course
    ------------------
    1    A       c1
    1    A       c2
    2    E       c3
    3    M       c2
    3    M       c3
    

2. 第二范式——

要成为第二范式,关系必须是第一范式,并且关系不能包含任何部分依赖。一个关系是2NF如果它有没有部分相关,没有非主属性(不属于任何候选关键字的一部分属性)依赖于表的任何候选键中的任何真子集。

部分依赖——如果候选键的真子集决定了非主属性,则称为部分依赖。

  • 示例 1 –考虑如下表 3。
    STUD_NO            COURSE_NO        COURSE_FEE
    1                     C1                  1000
    2                     C2                  1500
    1                     C4                  2000
    4                     C3                  1000
    4                     C1                  1000
    2                     C5                  2000
    

    {请注意,有许多课程的课程费用相同。 }

    这里,
    COURSE_FEE 不能单独决定 COURSE_NO 或 STUD_NO 的值;
    COURSE_FEE 和 STUD_NO 不能决定 COURSE_NO 的值;
    COURSE_FEE 和 COURSE_NO 不能决定 STUD_NO 的值;
    因此,
    COURSE_FEE 将是一个非主要属性,因为它不属于唯一的候选键 {STUD_NO, COURSE_NO} ;
    但是, COURSE_NO -> COURSE_FEE ,即 COURSE_FEE 依赖于 COURSE_NO,它是候选键的适当子集。非主属性 COURSE_FEE 依赖于候选键的一个真子集,这是一个部分依赖,所以这个关系不属于 2NF。

    要将上述关系转换为 2NF,
    我们需要将表拆分为两个表,例如:
    表 1:STUD_NO、COURSE_NO
    表 2:COURSE_NO、COURSE_FEE

    Table 1                                    Table 2
    STUD_NO            COURSE_NO          COURSE_NO                COURSE_FEE     
    1                 C1                  C1                        1000
    2                 C2                  C2                        1500
    1                 C4                  C3                        1000
    4                 C3                  C4                        2000
    4                 C1                  C5                        2000        

    2 C5

    注意: 2NF 试图减少存储在内存中的冗余数据。例如,如果有 100 名学生参加 C1 课程,我们不需要将所有 100 条记录的费用存储为 1000,而是可以将其存储在第二个表中,因为 C1 的课程费用为 1000。

  • 示例 2 –考虑以下关系 R (A, B, C, D ) 中的函数依赖
    AB -> C  [A and B together determine C]
    BC -> D  [B and C together determine D]

    在上述关系中,AB 是唯一的候选键,不存在部分依赖,即 AB 的任何真子集都不能确定任何非主属性。

    3. 第三范式——

    一个关系是第三范式,如果非素数属性没有传递依赖以及它是第二范式。
    如果在每个非平凡函数依赖项 X –> Y中至少满足以下条件之一,则关系属于 3NF

    1. X 是一个超级键。
    2. Y 是主要属性(Y 的每个元素都是某个候选键的一部分)。

    图像5

    传递依赖——如果 A->B 和 B->C 是两个 FD,那么 A->C 被称为传递依赖。

    • 示例 1 –与表 4 中给出的 STUDENT 相关,

      FD 设置:{STUD_NO -> STUD_NAME、STUD_NO -> STUD_STATE、STUD_STATE -> STUD_COUNTRY、STUD_NO -> STUD_AGE}
      候选键:{STUD_NO}

      对于表 4 中的这种关系,STUD_NO -> STUD_STATE 和 STUD_STATE -> STUD_COUNTRY 为真。所以 STUD_COUNTRY 传递依赖于 STUD_NO。它违反了第三范式。为了将其转换为第三范式,我们将关系 STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_COUNTRY_STUD_AGE) 分解为:
      学生(STUD_NO、STUD_NAME、STUD_PHONE、STUD_STATE、STUD_AGE)
      STATE_COUNTRY(州,国家)

    • 示例 2 –考虑关系 R(A, B, C, D, E)
      A -> BC,
      CD -> E,
      乙 -> 丁,
      E -> A
      上述关系中所有可能的候选键是 {A, E, CD, BC} 所有属性都在右侧所有功能依赖项都是素数。

      4. 博伊斯-科德范式 (BCNF) –

      如果 R 处于第三范式并且对于每个 FD,LHS 是超级键,则关系 R 处于 BCNF 中。一个关系在 BCNF 中,如果在每个非平凡的函数依赖 X –> Y 中,X 是一个超级键。

      • 示例 1 –找到关系 R(A,B,C,D,E) 的最高范式,其中 FD 设置为 {BC->D, AC->BE, B->E}
        Step 1. 如我们所见,(AC)+ ={A,C,B,E,D} 但它的子集都不能确定关系的所有属性,所以 AC 将是候选键。 A 或 C 不能从关系的任何其他属性派生,因此将只有 1 个候选键 {AC}。
        步骤 2. 质数属性是本示例中属于候选键 {A, C} 的那些属性,而其他属性在本示例中将是非质数 {B, D, E}。
        步骤 3. 关系 R 是第一范式,因为关系 DBMS 不允许多值或复合属性。
        关系是第二范式,因为 BC->D 是第二范式(BC 不是候选键 AC 的真子集)并且 AC->BE 是第二范式(AC 是候选键)和 B->E是第二范式(B 不是候选键 AC 的真子集)。
        该关系不是第三范式,因为在 BC->D(BC 既不是超级键,D 也不是主要属性)和 B->E(B 既不是超级键,E 也不是主要属性)中满足第三个标准,FD 的 LHS 应该是超级键,或者 RHS 应该是主要属性。
        所以关系的最高范式将是第二范式。
      • 示例 2 –例如考虑关系 R(A, B, C)
        A -> BC,
        乙->
        A 和 B 都是超级键,所以上面的关系在 BCNF 中。

      关键点 –

      1. BCNF 没有冗余。
      2. 如果一个关系在 BCNF 中,那么也满足 3NF。
      3. 如果关系的所有属性都是素属性,则该关系始终处于 3NF。
      4. 关系数据库中的关系总是并且至少是 1NF 形式。
      5. 每个二元关系(只有 2 个属性的关系)总是在 BCNF 中。
      6. 如果一个 Relation 只有单例候选键(即每个候选键只包含 1 个属性),那么 Relation 总是在 2NF 中(因为不可能有部分函数依赖)。
      7. 有时采用 BCNF 形式可能无法保留功能依赖性。在这种情况下,仅当不需要丢失的 FD 时才使用 BCNF,否则仅归一化到 3NF。
      8. 在 BCNF 之后还有更多的范式,比如 4NF 等等。但在现实世界的数据库系统中,通常不需要超越 BCNF。

      练习 1 :在以下函数依赖项下找到 R (A, B, C, D, E) 中的最高范式。

      ABC --> D
        CD --> AE 

      解决上述问题的要点
      1)从 BCNF 开始检查总是一个好主意,然后是 3 NF,依此类推。
      2)如果任何函数依赖满足范式,则无需检查下范式。例如,ABC –> D 在 BCNF 中(注意 ABC 是一个超键),因此无需检查此依赖项的低范式。

      给定关系中的候选键是 {ABC, BCD}

      BCNF: ABC -> D 在 BCNF 中。让我们检查 CD -> AE,CD 不是超级密钥,因此此依赖项不在 BCNF 中。所以,R 不在 BCNF 中。

      3NF: ABC -> D 我们不需要检查这个依赖,因为它已经满足 BCNF。让我们考虑 CD -> AE。由于 E 不是素数属性,所以该关系不属于 3NF。

      2NF:在2NF中,我们需要检查部分依赖。 CD 是候选键的适当子集,它确定 E,这是非主要属性。所以,给定的关系也不在 2 NF 中。所以,最高范式是 1 NF。

      GATE CS 角问题
      练习以下问题将帮助您测试您的知识。所有问题都在前几年的 GATE 或 GATE 模拟测试中提出。强烈建议您练习它们。

      1. GATE CS 2012,问题 2
      2. GATE CS 2013,问题 54
      3. GATE CS 2013,问题 55
      4. GATE CS 2005,问题 29
      5. GATE CS 2002,问题 23
      6. GATE CS 2002,问题 50
      7. GATE CS 2001,问题 48
      8. GATE CS 1999,问题 32
      9. GATE IT 2005,问题 22
      10. GATE IT 2008,问题 60
      11. GATE CS 2016(第 1 组),问题 31

      有关所有往年问题,请参阅数据库范式测验。