DBMS中的范式详细指南

先决条件– 数据库规范化和功能依赖性概念.
正常化是最小化的过程冗余来自一个关系或一组关系。冗余可能导致插入, 删除和更新异常。因此, 它有助于最小化关系中的冗余。普通形式用于消除或减少数据库表中的冗余。
1.第一范式–
如果关系包含复合或多值属性, 则它违反第一范式, 或者如果关系不包含任何复合或多值属性, 则关系为第一范式。如果该关系中的每个属性均为单值属性.
示例1 –
由于多值属性STUD_PHONE, 表1中的关系STUDENT不在1NF中。其分解成1NF的结果如表2所示。

DBMS中的范式详细指南

文章图片
示例2 – ID名称课程— — — — — — 1 A c1, c2 2 E c3 3 M C2, c3在上表中Course是一个多值属性, 因此它是不在1NF中。下表位于1NF中, 因为没有多值属性ID名称课程— — — — — — 1 A c1 1 A c2 2 E c3 3 M c2 3 M c3
2.第二范式–
要采用第二范式, 关系必须采用第一范式, 并且关系不得包含任何部分依存关系。关系在2NF中, 如果具有没有部分依赖即, 没有任何非主要属性(不属于任何候选键的属性)都依赖于表中任何候选键的任何适当子集。
部分依赖–如果候选键的正确子集确定非素数属性, 则称为部分依赖。
示例1 –
考虑如下表3。
STUD_NOCOURSE_NOCOURSE_FEE 1C11000 2C21500 1C42000 4C31000 4C11000 2C52000

{请注意, 有许多课程费用相同。 }
这里,
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 1Table 2 STUD_NOCOURSE_NOCOURSE_NOCOURSE_FEE 1C1C11000 2C2C21500 1C4C31000 4C3C42000 4C1C52000

2 C5
注意:2NF尝试减少冗余数据存储在内存中。例如, 如果有100名参加C1课程的学生, 我们不需要为所有100条记录将其Fee存储为1000, 而是一旦我们可以将其存储在第二张表中, 因为C1的课程费用为1000。
示例2 –考虑关系R(A, B, C, D)中的以下函数依赖性AB-> C++[A和B共同确定C] BC-> D [B和C共同确定D]在上述关系中, AB为唯一的候选键, 并且没有部分依赖性, 即AB的任何适当子集都不能确定任何非素数属性。
3.第三范式–
关系存在第三范式(如果存在)
没有传递依赖
非主要属性, 以及第二个标准格式。
如果是, 则关系为3NF
至少满足以下条件之一
在每个非平凡函数中, 依赖项X –> Y
  1. X是超级键。
  2. Y是素数属性(Y的每个元素是某些候选键的一部分)。
DBMS中的范式详细指南

文章图片
传递依存关系–如果A-> B和B-> C是两个FD, 则A-> C被称为传递相关性。
【DBMS中的范式详细指南】示例1 –
对于表4中给出的学生,
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为true。因此, 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(STATE, COUNTRY)
示例2 –
考虑关系R(A, B, C, D, E)
A-> BC,
CD-> E,
B-> D,
E-> A
上述关系中所有可能的候选键为{A, E, CD, BC}所有属性在所有功能依赖项的右侧, 都是素数。
4. Boyce-Codd范式(BCNF)–
如果R为第三范式且对于每个FD, LHS是超级键, 则关系R在BCNF中。如果在每个非平凡的函数依赖项X –> Y中, BCNF中都有一个关系, 则X是超键。
  • 示例1 –找出FD设置为{BC-> D, AC-> BE, B-> E}的关系R(A, B, C, D, E)的最高范式
    步骤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,
    B->
    A和B都是超级密钥, 因此以上关系在BCNF中。
关键点 –
  1. BCNF没有冗余。
  2. 如果在BCNF中存在关系, 那么也将满足3NF。
  3. 如果关系的所有属性均为素属性, 则该关系始终为3NF。
  4. 关系数据库中的关系始终且至少为1NF形式。
  5. 每个二元关系(只有两个属性的关系)始终位于BCNF中。
  6. 如果一个关系只有一个单例候选键(即每个候选键仅包含1个属性), 则该关系始终为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 Corner问题
练习以下问题将帮助你测试知识。在前几年的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(Set 1), 问题31
看到关于数据库范式的测验对于前一年的所有问题。
如果发现任何不正确的地方, 或者想分享有关上述主题的更多信息, 请写评论。

    推荐阅读