扫一扫二维码
进群一起备考
查看更多当前 - 案例分析 - 数据库系统
简单
案例题
2024年5月第3题
简单
案例题
2024年5月第3题
#第二版教材
#必须掌握
在某大型大学的教务管理系统中，学校需要管理大量的教学数据。包括教师信息、学生信息、课程信息、学生选课情况等。为了提高系统的查询效率并保证数据一致性，开发团队采用了数据库规范化技术，进行了一系列的范式设计，以消除数据冗余、避免更新异常、插入异常和删除异常等问题。
-
教师信息（Teacher）
- 属性：教师ID（TID）、教师姓名（TName）、教师所在院系（Department）
- 主键：教师ID（TID）
- 函数依赖：TID → TName, Department
-
学生信息（Student）
- 属性：学生ID（SID）、学生姓名（SName）、学生出生日期（DOB）
- 主键：学生ID（SID）
- 函数依赖：SID → SName, DOB
-
课程信息（Course）
- 属性：课程ID（CID）、课程名称（CName）、学分（Credits）
- 主键：课程ID（CID）
- 函数依赖：CID → CName, Credits
-
学生选课情况（Enrollment）
- 属性：学生ID（SID）、课程ID（CID）、教工 ID（TID）
- 主键：学生ID（SID）、课程ID（CID）；学生ID（SID）、教工 ID（TID）
- 函数依赖：SID, CID → TID，SID, TID → CID，TID → CID
分值（8分）
请问这四种关系是否满足BCNF，如果不满足用什么方式满足。
参考答案
-
教师信息（Teacher）
- 属性：教师ID（TID）、教师姓名（TName）、教师所在院系（Department）
- 主键：教师ID（TID）
- 函数依赖：TID → TName, Department
这个表满足BCNF，因为左侧的属性（TID）是主键，且函数依赖是基于主键的，没有任何非主键属性依赖于其他非主键属性。
-
学生信息（Student）
- 属性：学生ID（SID）、学生姓名（SName）、学生出生日期（DOB）
- 主键：学生ID（SID）
- 函数依赖：SID → SName, DOB
同样，这个表满足BCNF，因为左侧的属性（SID）是主键。
-
课程信息（Course）
- 属性：课程ID（CID）、课程名称（CName）、学分（Credits）
- 主键：课程ID（CID）
- 函数依赖：CID → CName, Credits
这个表也满足BCNF，因为左侧的属性（CID）是主键。
-
学生选课情况（Enrollment）
- 属性：学生ID（SID）、课程ID（CID）、教师ID（TID）
- 主键：学生ID（SID）、课程ID（CID）；学生ID（SID）、教师ID（TID）
- 函数依赖：SID, CID → TID ｜ SID, TID → CID
问题点： - 虽然（SID, CID）和（SID, TID）是候选键，但存在函数依赖
TID → CID，而TID不是候选键，这意味着它违反了BCNF的规则。 - 为了满足BCNF，可以将表拆分为两个：
- Enrollment：（SID, TID）作为主键，属性为 SID 和 TID。
- Teaching：（TID）作为主键，属性为 TID 和 CID。
这样，TID → CID 变成了一个基于主键的依赖，满足BCNF。
凯恩解析
这里就要用到凯恩提到的判断方法。若一个关系为R(U)，它是满足第一范式的，当R 中不存在任何属性对候选码的传递函数依赖时，则称R 符合 BCNF，即R∈BCNF。这个书本写的很抽象。翻看别的定义也是如此。所以直接看例子理解。BCNF一定是3NF，
这个比较直观，因为直接看它的定义，包含了对3NF的定义。一个判断的简单方法是在BCNF范式中，关系模式中任何函数依赖的左侧必须是码，不能存在非码的属性。每名教师只教授一门课程，每门课程由若干名教师教授，若某一学生选定某门课程，就确定了一名教师;同样地，某名学生选修了某名教师就确定了所选课程的名称。
(教工号，学号)，(学号，课程号)可以作为主键
但是由于存在教工号→课程号。
推论判断：因为教工号不是码，所以不是BCNF范式
（如何规范化）可将授课分解为两个关系模式,即(学号，教工号)和(教工号，课程号)，它们之中不存在任何属性对候选码的部分函数依赖和传递函数依赖,所以符合 Boyce-Codd范式。