(完整版)主键、候选键、超键、范式知识强化.docVIP

【范式相关知识强化】 一、明确概念 范式有关的概念如下： 1、 候选键：若一个属性集能 惟一标识 一个元组，又 不含有多余属性 ，那么这个属性集称为候选键。 注意 1：候选键中有可能是一个属性，也有可能是多个属性。 例如：（学号，姓名，性别）中 “学号”就可以作为一个候选键； 若班级同学不重名， “姓名”也可以作为一个候选键； “学号，姓名”不是候选键，因为“姓名”除去后， “学号”仍然可以标识一个元组，“姓名”就是一个多余属性。 再例如：（学号，课程号，成绩）中 “学号，课程号”才是候选键，两者缺一不可。 注意 2：有可能含有多个候选键。 例如：（学号，姓名，籍贯，性别）中 若班级同学均不同名，且籍贯不同，那么“学号” ，“姓名”，“籍贯”就都可以唯一标识一个元组，且不含有多余属性，所以这里就有三个候选键。 2、 主键：用户选作元组标识的一个候选键。 例如（学号，姓名，籍贯，性别）例子中， “学号”，“姓名”，“籍贯”都可以唯一的标识一个元组，用户设计数据库时选择“学号”作为主键。 注意：主键是 候选键中的一个 ，根据用户设计数据库时的选择不同而定。 练习： 在 SQL Server数据库中，有一个学生信息表如下所示，在该表中不能作为候选键的属性集合为（ ） （选择一项） 学号 姓名 性别 年龄 系别 专业 李辉 男 20 计算机 软件开发 张明 男 18 计算机 软件开发 王小玉 女 19 物理 力学 李淑华 女 17 生物 动物学 赵静 男 21 化学 食品化学 赵静 女 20 生物 植物学 {学号 } {学号，姓名 } {年龄，系别 } {姓名，性别 } {姓名，专业 } 【 B】有学号就够了，姓名属性是多余的不能当做候选键。 3、 主属性：包含在任一候选键中的属性称主属性。 候选键有可能不止一个，每个候选键中也有可能不止一个属性，包含在任何一个候 选键中的属性都是主属性。 例如：在关系模式 STJ（ S， T， J）中， S 表示学生， T 表示教师， J 表示课程。 每一教师只教一门课。每门课由若干教师教，某一学生选定某门课，就确定了一个 固 定 的 教 师 。 某 个 学 生 选 修 某 个 教 师 的 课 就 确 定 了 所 选 课 的 名 称 ： (S， J)→T， (S， T)→ J， T→ J (S， J)和 (S， T)都可以作为候选码 S、 T、 J都是主属性 4、非主属性：非主属性的属性。 二、范式（ 1NF、2NF、 3NF 都假定只有一个候选键） 1、 第一范式： 数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值。 例如： 对于员工信息，不能将员工信息，如姓名、性别都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。 判定技巧： 在任何一个关系数据库中， 第一范式 （ 1NF）是对关系模式的基本要求，不满足第一范式（ 1NF）的数据库就不是关系数据库。 2、 第二范式： 若关系模式 R 1NF，且每一非主属性完全函数依赖于 R 的码，则 R 2NF 在第一范式（ 1NF）的基础上建立起来的，即满足第二范式（ 2NF）必须先满足第一 范式（ 1NF）。要求实体的属性 完全依赖 于主关键字。 完全依赖 ：不能存在 仅依赖 主关键字一部分的属性 。 例如： AB→ C，只有 A 和 B 在一起才能得出 C，AB 的任何一个真子集 A 或者 B 都不 能得出 C，这样才是完全依赖，否则就是部分依赖。 再例如： R(A,B,C,D,E), {A,B}为主码，则有 A,B→ C， A,B→ D， A,B→ E 但 C、 D、 E 都不局部函数依赖于 A,B 即 A→ C、 B→ C、 A→ D、 B→ D、 A→ E、 B→ E中任何一个均不成立 判定技巧： 如果→的左边都只有一个属性，那么至少服从第二范式 。 例如： 假定选课关系表为 SelectCourse（学号，姓名，年龄，课程名称，成绩，学分） ，候 选键为组合的（学号 , 课程名称），存在如下决定关系： （学号，课程名称）→ （姓名，年龄，成绩，学分） 这个数据库表不满足第二范式，因为存在如下决定关系： （课程名称） → （学分） （学号） → （姓名 , 年龄） 即存在组合关键字中的字段决定非关键字的情况。 3、 第三范式： 关系模式 R(U,F)中，当且仅当 R属于 1NF，且 R 的每一个非主属性都不传递依赖于候选键时， R 3NF 传递依赖 ：若 X→ Y， Y→A，并且 Y→