srcmini先决条件– 数据库规范化和功能依赖性概念.
正常化是最小化的过程冗余来自一个关系或一组关系。冗余可能导致插入, 删除和更新异常。因此, 它有助于最小化关系中的冗余。普通形式用于消除或减少数据库表中的冗余。
1.第一范式–
如果关系包含复合或多值属性, 则它违反第一范式, 或者如果关系不包含任何复合或多值属性, 则关系为第一范式。如果该关系中的每个属性均为单值属性.
示例1 –
由于多值属性STUD_PHONE, 表1中的关系STUDENT不在1NF中。其分解成1NF的结果如表2所示。
示例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_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 20002 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
- X是超级键。
- Y是素数属性(Y的每个元素是某些候选键的一部分)。
传递依存关系–如果A-> B和B-> C是两个FD, 则A-> C被称为传递相关性。
示例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中。
关键点 –
- BCNF没有冗余。
- 如果在BCNF中存在关系, 那么也将满足3NF。
- 如果关系的所有属性均为素属性, 则该关系始终为3NF。
- 关系数据库中的关系始终且至少为1NF形式。
- 每个二元关系(只有两个属性的关系)始终位于BCNF中。
- 如果一个关系只有一个单例候选键(即每个候选键仅包含1个属性), 则该关系始终为2NF(因为不可能存在部分功能依赖)。
- 有时选择BCNF形式可能无法保留功能依赖性。在这种情况下, 仅当不需要丢失的FD时才使用BCNF, 否则仅归一化至3NF。
- 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模拟测试中, 所有问题都已提出。强烈建议你练习它们。
- GATE CS 2012, 问题2
- GATE CS 2013, 问题54
- GATE CS 2013, 问题55
- GATE CS 2005, 问题29
- GATE CS 2002, 问题23
- GATE CS 2002, 问题50
- GATE CS 2001, 问题48
- GATE CS 1999, 问题32
- GATE IT 2005, 问题22
- GATE IT 2008, 问题60
- GATE CS 2016(Set 1), 问题31
看到关于数据库范式的测验对于前一年的所有问题。
如果发现任何不正确的地方, 或者想分享有关上述主题的更多信息, 请写评论。
评论前必须登录！
注册