← 回首页

数据库实验二：关系、主键和一次失败的查询

这次实验的题目是建一个「学生选课」的库。听起来简单：学生一张表，课程一张表， 选课记录一张表。三个实体，两条关系，画图五分钟。

真正卡住我的是后面那个查询：找出所有选了两门以上课程的学生。

建表的时候太顺利了

学生表用学号做主键，课程表用课程号做主键，选课表用（学号, 课程号）做联合主键。 这一步没花什么力气，因为「唯一标识一行」这件事很直观。

唯一想了一下的是选课表的主键。要不要单独加一个自增 ID？最后没加—— 因为一个学生在同一门课里不该出现两次，所以（学号, 课程号）本身就已经唯一了。 再加一个 ID 只是多一列没用的东西。

Access 里建立关系的时候勾了「实施参照完整性」，两个外键都指向各自的主表。 这一步才是真正有意义的地方——它保证了选课表里不会出现不存在的学生， 也不会出现不存在的课程。

查询失败的那一次

我一开始写的是这样：

SELECT 学号, COUNT(*) FROM 选课 GROUP BY 学号 HAVING COUNT(*) >= 2

跑出来了，结果也对。但我当时想的是「选了两门以上」——严格说是大于两门， 不是大于等于。于是改成 > 2，结果少了一半。

然后我又去查题目，发现人家写的是「两门以上」。 中文里「以上」到底含不含本数，这个问题我和室友争了十分钟。最后老师说含。 所以回到 >= 2。

真正学到的东西

• 联合主键不是两个主键，是一条由两列组成的唯一约束。 写惯了单一 ID 之后，这个区别要想一下。
• 参照完整性该开就开。开的时候多一步麻烦， 不开的时候以后会多出一堆查不出来的问题。
• HAVING 和 WHERE 的区别不在语法在时机： WHERE 在分组前筛行，HAVING 在分组后筛组。 这次因为条件里用了聚合函数，只能写 HAVING。

最后那一栏差点让我把整个查询重写成子查询。 其实不需要——聚合函数的条件天然属于 HAVING。 知道这一点之后，那个查询一行就写完了。