如果你正在准备日本大学院的入试笔试筆記試験尤其是情报系专攻数据库データベース和软件工程ソフトウェア工学这两科基本是绕不开的。今天这篇是这个系列的第九回正好把这两块内容放在一起做一次集中训练。比起纯刷题我更想带你搞清楚每个题背后的考点逻辑为什么出题人喜欢这么问标准答案该按什么结构写哪些地方是大多数人都会踩的坑。这个系列我之前写过八回了前面主要拆过算法、OS、网络、离散数学这些。到了第9回我特意把数据库和软件工程合成一篇是因为在实际院试里这两科经常合并出在一张卷子上题目不算难但覆盖面特别广而且特别爱考“概念的精准表达”。你如果能把这两个科目的知识点用一种“答题模板”的方式串起来那上考场会轻松很多。这篇适合两类人一是正在准备日本大学院入试、需要系统性刷题的人二是想快速复习数据库和软工核心考点、用来准备国内保研笔试或面试的人。1. 这期训练为什么把数据库和软件工程放在一起1.1 日本大学院入试常见的出题习惯先说说出题逻辑。日本的情报类研究科比如情報科学研究科、システム情報学専攻这类入试笔试一般分“専門科目”和“英語”两大类。専門科目里算法和数据库几乎是标配软件工程则不像国内有些学校那样单独画一门大课而是混杂在“情報工学基礎”这种卷子里占总分的一两成。出题人就喜欢用“短答题手写SQL名词解释小型设计题”这种组合拳。数据库题多半让你写SQL、画ER图、做范式分解偶尔考事务隔离级别。软件工程则爱考开发流程模型、UML图、结合度凝集度、设计原则这些。这两部分的共同点是题目本身不复杂但要求你用严谨的专业术语作答日本老师在採点上特别看重用语是否规范。所以这篇我会花不少篇幅帮大家整理“术语对照”和“答题模板”。1.2 本期训练的核心目标到了第9回我不想再泛泛地过知识点而是把重点放在“最容易丢分的转换题”上。具体有三个目标能快速判断一个关系模式是第几范式并正确无损分解到3NF或BCNF。能熟练地把SQL、关系代数、ER模型互相转换考场遇到哪种问法都能应对。软件工程部分能脱离死记硬背用“背景-特点-适用场景-风险”的框架答简答题。这三个目标分别对应本期的三个核心板块数据库硬核考点、软件工程答题框架、模拟题实战。最后再附上我自己的考场避坑记录希望大家看完能直接上手刷题。2. 数据库部分的硬核考点从关系代数到事务隔离2.1 关系代数与SQL的对照考场上最实用的“翻译表”很多同学一看到“请用关系代数表达……”就懵其实关系代数就是把SQL里的逻辑用运算符写出来。你只要掌握五个基本运算選択σselect、射影πproject、結合⋈natural join、和∪、差−就够应付绝大多数院试题目了。举个最常见的对应关系查询条件对应σ选列对应π多表关联对应⋈去重分组那类逻辑在关系代数里往往用不着因为在纯关系代数里集合本来就没有重复元组。SQL里的SELECT DISTINCT在关系代数里天然成立所以不要画蛇添足。考场上的快速写法顺序是先找出涉及哪些表确定连接方式再写选择条件最后写投影列。比如“查询所有选修了课程‘数据库’的学生的学号和姓名”关系代数就是π_{学号,姓名}(σ_{课程名数据库}(学生 ⋈ 选课 ⋈ 课程))SQL里则是先join再where再select逻辑完全一致。有一点要注意日本教材里关系代数的记号普遍用σ和π但有些学校也会用select、project这种英文关键字。答题前先看一眼题目用的什么符号体系跟随题目写法不要混用。我自己就吃过亏有一回把π写成了PROJECT虽然意思对了但被扣了半道题的分数。2.2 函数依赖与范式判定考场上最快的方法范式题是数据库笔试的“送分题”也是“送命题”。说它送分是因为规则明确说它送命是因为很多人在判断“第几范式”时习惯靠背诵定义一紧张就乱。我的方法分三步走。第一步先求候选键也就是找能推导出所有属性的最小属性集合。比如关系模式R(A,B,C,D,E)存在函数依赖A→B, B→C, A→D, D→E那就先看A能不能推导全A→B→CA→D→E所以A {A,B,C,D,E}候选键就是A。第二步看有没有非主属性对候选键的部分依赖有就是不到2NF第三步看有没有非主属性对候选键的传递依赖有就是不到3NF。拿上面这个例子继续推因为候选键只有A非主属性是B、C、D、E。B和D都直接由A决定不存在部分依赖所以满足2NF。但存在A→B→C这里C通过B被传递依赖所以不满足3NF。同理A→D→E也让E传递依赖于A。判断完毕这个模式属于2NF但非3NF。接下来是分解。最稳妥的无损分解思路是把每个“引起传递依赖”的依赖链拆开把B→C单独成一个表R2(B,C)把D→E单独成一个表R3(D,E)原来含候选键的部分保留R1(A,B,D)。为什么保底要留一个含候选键的表因为分解要“无损且保持依赖”没有候选键的那一组自然连接后可能产生不存在的元组也就是有损分解。这个技巧在考场上比背算法快得多亲测有效。2.3 事务与隔离级别最容易翻车的得分点事务トランザクション是另一块高频考点尤其喜欢考四个隔离级别对应哪些并发异常。先说结论再解释隔离级别脏读不可重复读幻读READ UNCOMMITTED可能可能可能READ COMMITTED不会可能可能REPEATABLE READ不会不会可能SERIALIZABLE不会不会不会记忆方法是抓关键词脏读是读到未提交的数据所以只要“已提交读”就解决不可重复读是同一行在事务内两次读取结果不同所以只要“可重复读”就解决幻读是范围查询时新插入的行冒出来只有“串行化”能彻底解决。院试里经常给一个场景问你“事务A第一次查询得到10行事务B插入1行A再次查询得到11行这属于什么异常”。答案就是幻读对应的隔离级别是REPEATABLE READ都挡不住必须用SERIALIZABLE。还要注意锁定ロック的概念特别是共享锁和排他锁的死锁デッドロック。简答题如果让你论述“如何避免死锁”标准答法是一次性锁定所有资源、按固定顺序访问资源、加锁超时机制。这三点背熟基本不会扣分。3. 软件工程部分别死记概念要会“答题模板”3.1 开发流程模型对比瀑布、螺旋、敏捷怎么答不丢分软件工程里最常考的就是“请比较瀑布模型和敏捷开发的特点”。很多人答得像百科词条堆一堆形容词日本老师看了找不到采分点。我的建议是固定用四段式结构前提条件→核心流程→优缺点→适用场景。以瀑布模型为例前提是需求明确且很少变更核心流程是“要求分析→设计→实装→测试→保守”线性推进优点是把控性强、文档完整缺点是变更成本极高。敏捷则相反需求可以渐进式明确通过スプリント冲刺迭代交付优点是响应变化快、用户参与度高缺点是文档容易不足、对团队协作要求高。如果你能把“变更成本”这个关键差异点写出来老师一眼就能看出你是真懂。还有螺旋模型スパイラルモデル它的核心是“迭代风险分析”。答题模板是每一圈都经过“目标设定→风险评价→开发验证→下一轮规划”特别适合大型高风险项目。一句话总结瀑布重计划敏捷重响应螺旋重风险。3.2 结合度与凝集度这个对比题每年都在变着花样考结合度結合度coupling和凝集度凝集度cohesion是软件工程里最经典的“一对反义词”。原则是低结合度、高凝集度就是好的模块设计。但很多人会记反方向或者把两个概念搞混。结合度从低到高依次是数据结合データ結合 印记结合スタンプ結合 控制结合制御結合 公共结合共通結合 内容结合内容結合。记忆诀窍是“数据最低、内容最高”因为数据结合只传参数最干净内容结合直接访问对方内部实现最糟糕。凝集度从高到低是功能凝集機能的凝集 顺序凝集順次的凝集 通信凝集連絡的凝集 过程凝集手順的凝集 时间凝集時間的凝集 逻辑凝集論理的凝集 偶然凝集偶然的凝集。判断题最爱这么出给出两个模块A模块调用B模块时传了一个“控制标志”让B决定做哪件事问这是什么结合答案是控制结合。能判断出“一个模块内部所有操作在逻辑上相关但在不同时间执行”是逻辑凝集这部分就稳了。我建议把这个顺序表打印出来贴墙上考前扫一眼比临时翻书有用得多。3.3 UML读图补图技巧用例图、类图、时序图的考点差异UML这块院试很少让你完整画一张大图更多是给你一张残缺的用例图或时序图让你补充某个关联或者判断描述是否正确。用例图重点看**参与者アクター和用例ユースケース**之间的关系要分清include和extendinclude是“一定会执行的基础步骤”extend是“可选扩展”。类图重点看类之间的三种关系关联、继承、依赖考试喜欢考多重度1対多、多対多怎么写。时序图则看消息的先后顺序以及生命线和激活条。补图题的答题技巧是“先读说明文字再对照图上元素”。题目通常会有一段日语说明比如“学生可以选课选课前需要登录系统登录验证失败时显示错误信息”。对应到用例图就是“登录”是“选课”的include用例而“显示错误信息”是“登录”的extend用例。把这个对应关系理清楚分数基本拿到。4. 本期模拟问题完整解法与答卷示范4.1 例题1手写SQL与关系代数互转原题设定一个简单的教务数据库学生学籍番号、氏名、学部、课程科目番号、科目名、単位、选课学籍番号、科目番号、成績。要求查询选修了科目名等于“データベース”的学生学号和姓名分别用SQL和关系代数写出。SQL写法SELECT s.学籍番号, s.氏名 FROM 学生 s JOIN 選課 t ON s.学籍番号 t.学籍番号 JOIN 課程 c ON t.科目番号 c.科目番号 WHERE c.科目名 データベース;关系代数写法π_{学籍番号, 氏名}(σ_{科目名データベース}(学生 ⋈ 選課 ⋈ 課程))这里有两个易错点。第一多表连接必须写出完整的ON条件漏一个就变成笛卡尔积结果会爆炸。第二σ里的条件只写“科目名等于数据ベース”不要顺手把连接条件也塞进去连接条件由⋈自动处理。这道题实际考试正确率不到一半很大程度就是栽在这两点上。4.2 例题2范式分解全程演示原题R(A,B,C,D,E)函数依赖集合为{A→B, B→C, A→D, D→E}。问题一求候选键。问题二判断最高满足第几范式。问题三分解为满足3NF且无损、保持依赖的关系模式。候选键的求法前面已经演示过A包含全部属性所以候选键就是A。因为A单独就能决定所有属性而非主属性B,C,D,E没有对A的部分依赖候选键只有一个属性无从部分依赖起所以至少满足2NF。再看看是否存在传递依赖A→B→C和A→D→E都存在所以不满足3NF。最高满足2NF。分解结果如下R1(A, B, D) R2(B, C) R3(D, E)验证无损性R1和R2的公共列是B在R2中B→CB是R2的键所以R1⋈R2无损再和R3连接公共列是D在R3中D→ED是R3的键所以整体无损。验证依赖保持A→B和A→D在R1中都有B→C在R2中D→E在R3中所有函数依赖都在分解结果里保留。这个分解就是标准答案。考场上有时间就写验证过程没时间至少写出分解结果老师会给大部分分。4.3 例题3软件工程简答题框架原题比较瀑布模型与敏捷开发并说明各自适用场景。我的答卷框架如下瀑布模型要求分析、设计、实装、测试、保守阶段间有明确的审查基准。优点是各阶段文档明确、进度可控缺点是需求变更的代价大因此适用于需求稳定、规格清晰的嵌入式系统和基础设施类项目。敏捷开发将开发分割为短周期的スプリント每个周期都交付可运行的增量。优点是能快速响应用户需求变化适用于需求不确定性高的Web服务和业务应用开发。风险考虑无外部因素影响开发节奏时选瀑布更稳团队协作成熟、需要频繁确认用户反馈时选敏捷更合适。第二问指出模块设计中结合度和凝集度的理想状态。答案就两句话加一个补充说明理想状态是“低结合、高凝集”。低结合意味着模块间只通过最小接口通信方便独立替换高凝集意味着模块内部的功能高度相关便于维护。补充一句优先提高凝集度、降低结合度这是模块化设计的核心准则。4.4 例题4UML补充题要点这类题没统一代码但答题套路固定。拿到用例图先数参与者、用例、关联线三个要素用题目说明文字一一对应。题干如果写“在学生选课场景中用户必须完成登录才能选课”那就在“登录”和“选课”之间画include箭头箭头从“选课”指向“登录”。如果写“管理员偶尔需要导出选课报表”那就在“导出报表”与某个基础用例之间画extend箭头。顺序图则注意消息编号从左到右、从上到下不要逆序。5. 备考工具与实战环境搭建5.1 用本地数据库验证SQL比只看答案有用十倍手写SQL最怕“自我感觉良好”写错了还不知道错在哪。我的建议是装一个本地数据库刷题的时候顺手把SQL跑一遍。SQLite是最轻量的选择一条命令就能创建单文件数据库适合快速验证查询逻辑如果想练事务和锁建议直接上PostgreSQL隔离级别的行为更标准。以PostgreSQL为例安装完成后起一个服务建三张表CREATE TABLE students ( id INT PRIMARY KEY, name TEXT, faculty TEXT ); CREATE TABLE courses ( code INT PRIMARY KEY, title TEXT, unit INT ); CREATE TABLE enrollment ( student_id INT, course_code INT, grade TEXT );然后把题目里的数据插进去每次写完SQL就实际执行一遍看结果是否符合预期。这个方法对查漏补缺特别有效你会发现JOIN漏条件时结果多了多少行也会发现GROUP BY写错时聚合值多么离谱。经历的教训比什么都深刻。5.2 日语术语对照与参考书推荐答题时用日文术语能给老师一个“这人学过”的印象。我把高频术语整理成对照表考前快速过一遍中文日本語说明范式正規形1NF、2NF、3NF、BCNF函数依赖関数従属记为 X→Y事务トランザクションACID特性隔离级别分離レベル4 levels锁ロック共有/排他耦合度結合度低いほど良い内聚度凝集度高いほど良い需求分析要求分析SRS文档用例图ユースケース図UML参考书方面数据库我推荐《データベースを学ぶ》和《定本 データベース入門》软件工程部分看《ソフトウェア工学近代科学社》或者《ソフトウェア工学の基礎》。院试近过去问永远是最重要的参考书只当字典用别沉浸式看书耽误刷题。6. 常见失分点与考场避坑实录6.1 三类最典型的低级错误先说数据库题。第一类是SQL多表连接时忘记连接条件尤其三表以上写完FROM就忘了ON。第二类是范式判断时没有求闭包就开始写结论比如只凭肉眼看到B→C就推断候选键是B结果全错。第三类是事务异常的概念混淆把“不可重复读”和“幻读”当成一回事其实前者是同一行变化后者是结果集行数变化。软件工程题的低级错误更集中简答题只写关键词不写展开说明。日本老师评卷看证据你写“ウォーターフォールは柔軟性が低い”没问题但最好补一句“ため、要件変更が発生するプロジェクトには不向き”。多写半句解释得分性质完全不同。6.2 考场时间分配与答题顺序専門科目笔试一般60到120分钟按5到6道大题计算每道大题分配10到20分钟。我的习惯是拿到卷子先花两分钟通览全卷把“会做的标记为先做”。数据库和软件工程部分通常分值不算最高但性价比高建议放在最后30分钟写。为什么因为这两科是“写多就有分”而算法题往往卡壳就浪费大量时间。先确保拿稳算法大题的分数再用余力处理数据库和软工简答是我实测最稳的策略。写到简答题时也要控制篇幅。每道简答题写8到12行就足够重点覆盖要点词不用追求长篇大论。写得太多反而会让老师找不到重点。6.3 我踩过的坑望周知说几件我亲身犯过的错都是血泪教训。第一次模拟考试时我把所有的SQL都放到题目提供的SELECT窗口里跑结果没注意到数据库用的是旧版本GROUP BY的排序行为和我本地环境不一致直接导致我以为自己写错了。后来我固定用PostgreSQL挂载同一份数据做练习才彻底排除这种干扰。还有一次考“结合度由低到高排序”我把“制御結合”排到了“スタンプ結合”前面被扣分后才知道记忆顺序错了。后来我用“数制公内”这个谐音数据、印记、控制、公共、内部才记住。最后一个心得这种训练系列最大的价值不是让你“做过”这些题而是让你形成自己的答题反射。第9回的训练量就控制在3到4道大类题加上错题复盘整个过程大约90分钟完全模拟考场的节奏。学有余力的话把自己写错的SQL和简答再默写一遍比刷新题有用得多。数据库和软件工程在院试里属于“稳定拿分项”你只要把范式分解、事务隔离、流程模型对比这些高频点吃透基本不会拖后腿。