主键、候选键、超键、范式知识强化.doc

范式相关知识强化】

一、 明确概念
范式有关的概念如下：
1、 候选键：若一个属性集能惟一标识一个元组，又不含有多余属性，那么这个属性集称为候选键。
n 注意1：候选键中有可能是一个属性，也有可能是多个属性。
例如：（学号，姓名，性别）中
Ø “学号”就可以作为一个候选键；
Ø 若班级同学不重名，“姓名”也可以作为一个候选键；
Ø “学号，姓名”不是候选键，因为“姓名”除去后，“学号”仍然可以标识一个元组，“姓名”就是一个多余属性。
再例如：（学号，课程号，成绩）中
“学号，课程号”才是候选键，两者缺一不可。
n 注意2：有可能含有多个候选键。
例如：（学号，姓名籍贯，性别）中
若班级同学均不同名，且籍贯不同，那么“学号”，“姓名”，“籍贯”就都可以唯一标识一个元组，且不含有多余属性，所以这里就有三个候选键。
2、 主键：用户选作元组标识的一个候选键。
例如（学号，姓名，籍贯，性别）例子中，“学号”，“姓名”，“籍贯”都可以唯一的标识一个元组，用户设计数据库时选择“学号”作为主键。
n 注意：主键是候选键中的一个，根据用户设计数据库时的选择不同而定。
练习：
在SQL Server数据库中，有一个学生信息表如下所示，在该表中不能作为候选键的属性集合为（ ） （选择一项）
学号 姓名 性别 年龄 系别 专业
20020612 李辉 男 20 计算机 软件开发
20060613 张明 男 18 计算机 软件开发
20060614 王小玉 女 19 物理 力学
20060615 李淑华 女 17 生物 动物学
20060616 赵静 男 21 化学 食品化学
20060617 赵静 女 20 生物 植物学
A {学号}
B {学号，姓名}
C {年龄，系别}
D {姓名，性别}
E {姓名，专业}
【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→X，A不是Y的子集，则称A传递依赖于X。
例如：
假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)
因为存在如下决定关系：
(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)
这个数据库是符合2NF的，但是不符合3NF，因为存在如下决定关系：
(学号) → (所在学院) → (学院地点, 学院电话)
即存在非主属性"学院地点"、"学院电话"对主属性"学号"的传递函数依赖。
不满足3NF。
4、第四范式
2NF和3NF的定义都假设了R只有一个候选键，但一般情况下R可能有多个候选键，并且不同的候选键之间还可能相互重叠。3NF不能处理R的一般情况（多个候选键）。BCNF扩充了3NF，可以处理R有多个候选键的情形。R只有一个候选键时BCNF等价3NF。
例如：在关系模式STJ（S，T，J）中，S表示学生，T表示教师，J表示课程。
每一教师只教一门课。每门课由若干教师教，某一学生选定某门课，就确定了一个固定的教师。某个学生选修某个教师的课就确定了所选课的名称 ： (S，J)→T，(S，T)→J，T→J
(S，J)和(S，T)都可以作为候选键 
S、T、J都是主属性（在这里要注意候选键和主属性的区别）
STJ∈3NF 
STJ不是BCNF
因为T→J，T是决定属性集，T不是候选码
再例如：
R(S#,SNAME,STATUS,CITY)设Sname唯一
S# →Sname，
S#→Status，
S# →city，
Sname →S#，
Sname →city，
Sname→Status,
S#和Sname都是候选键，也是主属性，他们并没有传递依赖，是BCNF。
判定技巧：
法一：如果关系模式R的所有不平凡的、完全的函数依赖的决定因素（左边的属性集）都是候选码，则RÎBCNF。
即→的左边都是候选键（注意不是主属性）
法二：如果一个关系模式达到了第三范式，并且它只有一个候选键，或者它的候选键都是单属性，那么就达到了BC范式。