【大学院-筆記試験練習：数据库（データベース問題訓練） と 软件工程（ソフトウェア）（１０）】

大学院-筆記試験練習：数据库（データベース問題訓練）　と　软件工程（ソフトウェア）（１０）

• 1-前言
• 2-数据库データベース
• 【予想問題①】データ構造（B木）
• • • 【注意】
• 【予想問題②】データベース（正規化）
• 【予想問題③】アルゴリズム（計算量）
• 【予想問題④】ソフトウェア工学（概念说明）
• 3-数据库データベース-答案解析
• • [問題1（B木）：你写的「16 | | 7 28」不够](#問題1（B木）：你写的「16 | | 7 28」不够)
  • 問題2（正規化）
  • • [(1) 你答「第2正規形」✅基本正确，但要补一句理由](#(1) 你答「第2正規形」✅基本正确，但要补一句理由)
    • [(2) 你的分解 ✅正确](#(2) 你的分解 ✅正确)
    • [(3) 你这里有扣分点：主キー写错了](#(3) 你这里有扣分点：主キー写错了)
  • 問題3（計算量）
  • • [(1) O(n²log n) ✅正确](#(1) O(n²log n) ✅正确)
    • [(2) 你解释方向对，但日语表达需要改成"採点者友好"](#(2) 你解释方向对，但日语表达需要改成“採点者友好”)
  • 問題4（ソフトウェア工学）
  • • [(1) 你写的内容 ✅对，但要更"学术句式"](#(1) 你写的内容 ✅对，但要更“学术句式”)
    • [(2) テストとデバッグ ✅你答得很好，只要再"精炼"](#(2) テストとデバッグ ✅你答得很好，只要再“精炼”)
• 4-软件工程（ソフトウェア）混合
• • 【問題1】
  • • [🔥 常见陷阱](#🔥 常见陷阱)
  • 【問題2】
  • • [🔥 常见陷阱](#🔥 常见陷阱)
  • 【問題3】
  • • [🔥 常见陷阱](#🔥 常见陷阱)
  • 【問題4】
  • • [🔥 常见陷阱](#🔥 常见陷阱)
  • [📌 这套题的「真实考察点」总结（只告诉你，不写在题里）](#📌 这套题的「真实考察点」总结（只告诉你，不写在题里）)
• 5-软件工程（ソフトウェア）答案解析
• [問題１ 讲评（需求不一致的原因）](#問題１ 讲评（需求不一致的原因）)
• • 你的原答案评价
  • • [✅ 优点（非常关键）](#✅ 优点（非常关键）)
    • [❌ 会被扣分的点](#❌ 会被扣分的点)
  • [✅ 合格级最小修改版（强烈建议你背这个）](#✅ 合格级最小修改版（强烈建议你背这个）)
  • • [📊 本番得分预估](#📊 本番得分预估)
• [問題２ 讲评（原型法的目的与效果）](#問題２ 讲评（原型法的目的与效果）)
• • 你的原答案评价
  • • [✅ 优点](#✅ 优点)
    • [❌ 扣分点](#❌ 扣分点)
  • [✅ 合格级最小修改版](#✅ 合格级最小修改版)
  • • [📊 本番得分预估](#📊 本番得分预估)
• [問題３ 讲评（测试 vs 调试）](#問題３ 讲评（测试 vs 调试）)
• • 你的原答案评价
  • • [✅ 非常好](#✅ 非常好)
    • [❌ 唯一问题](#❌ 唯一问题)
  • [✅ 合格级修正版（只改 1 个字）](#✅ 合格级修正版（只改 1 个字）)
  • • [📊 本番得分预估](#📊 本番得分预估)
• [問題４ 讲评（重构）](#問題４ 讲评（重构）)
• • 你的原答案评价
  • • [✅ 优点](#✅ 优点)
    • [❌ 扣分点](#❌ 扣分点)
  • [✅ 合格级最小修改版](#✅ 合格级最小修改版)
  • • [📊 本番得分预估](#📊 本番得分预估)
• [📊 总体评价（非常重要）](#📊 总体评价（非常重要）)
• 6-总结

1-前言

为了考上大学院，做了日语版本练习，边学边看边记录

2-数据库データベース

【予想問題①】データ構造（B木）

次に示す 2 次の B 木 に対して，以下の操作を この順に 行った後の B 木を，
箱・●ポインタ形式で描け。

(1) キー値 16 のレコードを挿入する。

(2) (1) の結果に対して，キー値 28 のレコードを挿入する。

(3) (2) の結果に対して，キー値 7 のレコードを挿入する。

【注意】

• ノードの分割が発生する場合は，分割の過程が分かるように 描くこと。
• 根ノードが分割される場合も考慮せよ。

📌 出题意图

几乎必考 B木 / B+木 *

重点不是"对不对"，而是：

• 插入路径
• 分裂时中间キー是谁
• 根分裂你慌不慌

---

【予想問題②】データベース（正規化）

次の関係 R が与えられている。

R( 学生番号, 学科番号, 学科名, 成績 )

ここで，以下の関数従属が成り立つとする。

• 学生番号 → 学科番号, 成績
• 学科番号 → 学科名

(1) 上記の関係 R が 第何正規形 に属するか答えよ。

(2) R を 第3正規形 に分解せよ。

(3) 分解後の各関係について，主キー を明示せよ。

📌 出题意图

「2NF / 3NF 判断 + 分解」

常见陷阱：

• 传递函数従属
• 忘记写主キー（直接扣分）

---

【予想問題③】アルゴリズム（計算量）

次の疑似コードの 時間計算量 を求めよ。

for i = 1 to n
    for j = 1 to i
        k = 1
        while k < n
            k = k * 2

(1) 上記アルゴリズムの時間計算量を O記法 で表せ。

(2) なぜその計算量になるのかを 簡潔に説明せよ。

📌 出题意图

「for × for × while(log)」

如果你只写 O(n²logn) 不解释 → 减分

---

【予想問題④】ソフトウェア工学（概念说明）

次の問いに答えよ。

(1) ウォーターフォールモデル と アジャイル開発 の違いを，

1 つずつ利点と欠点を挙げて 説明せよ。

(2) テスト と デバッグ の違いを説明せよ。

3-数据库データベース-答案解析

問題1（B木）：你写的「16 | | 7 28」不够

你现在这一行看起来像是在写"根节点的キー"，但B木题必须用箱・●ポインタ形式画完整树，而且要体现插入后是否发生分裂。

我这里给你一个可直接写的"正解版"表达（不依赖你原题初始树，因为你没画出来我只能给你模板）：

✅ 你应该这样写（考试能得分的写法）

• 插入路径（どの葉に落ちるか）
• ノードが満杯なら分割
• 中央キーを親へ昇格
• 最后画出树

如果你把初始B木的图 发我（或你自己画的初始形），我可以把最终树用箱・●形式给你画成标准答案。

---

問題2（正規化）

(1) 你答「第2正規形」✅基本正确，但要补一句理由

你应该写成这样更像标准解答：

✅ 模板句（可直接写）

主キーが単一属性（学生番号）であり，部分関数従属が存在しないため第2正規形である。

ただし，学科番号 → 学科名 により推移的従属があるため第3正規形ではない。

(2) 你的分解 ✅正确

你写：

• 学生(学生番号, 学科番号, 成績)
• 学科(学科番号, 学科名)

✅OK

(3) 你这里有扣分点：主キー写错了

你写了「学生番号 と 学科番号」------但在你这份分解里：

• 学生表：主キー是 学生番号
• 学科表：主キー是 学科番号

✅ 正确写法：

学生の主キー：学生番号

学科の主キー：学科番号

---

問題3（計算量）

(1) O(n²log n) ✅正确

(2) 你解释方向对，但日语表达需要改成"採点者友好"

你现在这句「WHILE kよりn小さいとき...」表达不够标准。

✅ 标准写法（直接誊写）

外側の for は i=1...n で O(n)。

内側の for は j=1...i で，全体として Σ_{i=1...n} i = O(n^2)。

while ループは k を 2 倍していくため反復回数は O(log n)。

よって全体の時間計算量は O(n^2 log n) である。

---

問題4（ソフトウェア工学）

(1) 你写的内容 ✅对，但要更"学术句式"

你原句里"事件"这个词不太适合（应该是「工程」「進捗」「手順」）。

✅ 标准答案（可直接写）

ウォーターフォールモデルは工程を順序立てて進める開発手法である。

利点は，各工程の成果物が明確で管理しやすい点である。

欠点は，開発途中の要求変更に弱く，手戻りが大きくなりやすい点である。

一方，アジャイル開発は短い反復で開発とフィードバックを繰り返す。

利点は，要求変更に柔軟に対応できる点である。

欠点は，計画や見積りが難しく，品質管理が属人的になりやすい点である。

(2) テストとデバッグ ✅你答得很好，只要再"精炼"

✅ 模板句（更标准）

テストは欠陥の存在を発見する活動であり，

デバッグは発見された欠陥の原因を特定し修正する活動である。

---

4-软件工程（ソフトウェア）混合

---

【問題1】

ある業務システムの開発において，

要件定義書は作成されていたにもかかわらず，

完成後に「想定していた機能と異なる」という指摘が利用者から多数発生した。

このような問題が発生する主な原因について，
ソフトウェア工学の観点から説明せよ。

---

🔥 常见陷阱

• ❌ 只怪用户「没说清楚」
• ❌ 只怪开发者「理解能力不足」
• ❌ 写成沟通态度问题，而不是工程结构问题

---

【問題2】

開発初期において，

詳細な要件定義を完成させる前に，

試作的なシステムを作成して利用者に提示する手法が用いられることがある。

このような手法が有効とされる理由について，
目的と効果の両面から説明せよ。

---

🔥 常见陷阱

• ❌ 把「速度快」当成核心理由
• ❌ 只写"方便用户理解"，却不写工程上的作用
• ❌ 把"设计"与"需求确认"混为一谈

---

【問題3】

ソフトウェアの品質向上を目的として，

テスト工程およびデバッグ作業が行われる。

テストとデバッグの役割の違い について，

それぞれの目的を明確にして説明せよ。

---

🔥 常见陷阱

• ❌ 写成"测试是为了修 bug"
• ❌ 写成"调试是为了找 bug"
• ❌ 不区分「发现」与「修正」

---

【問題4】

長期間運用されているソフトウェアでは，

機能追加や仕様変更に伴い，

内部構造の改善が必要となる場合がある。

このような改善作業を行う際に注意すべき点について，
ソフトウェアの外部的な振る舞いとの関係に着目して説明せよ。

---

🔥 常见陷阱

• ❌ 把"改善"理解成"功能增强"
• ❌ 忘记"外部行为不变"这个隐含前提
• ❌ 写成单纯的代码美化

---

📌 这套题的「真实考察点」总结（只告诉你，不写在题里）

题号	实际考点
問1	需求工程 / 知识非对称 / 需求歧义
問2	原型法 / 需求验证 / 用户参与
問3	测试 vs 调试（目的边界）
問4	重构 / 可维护性 / 外部行为不变

---

5-软件工程（ソフトウェア）答案解析

問題１ 讲评（需求不一致的原因）

你的原答案评价

✅ 优点（非常关键）

• 抓住了 顧客と開発者の知識の非対称性（这是核心）
• 提到了 要件はあるが曖昧（命中出题点）

❌ 会被扣分的点

1. 日语不自然（助词 / 动词）
2. 因果顺序有点乱（原因 → 结果不够清晰）
3. "想定外が多い発生した"表达错误

---

✅ 合格级最小修改版（强烈建议你背这个）

顧客は業務知識を十分に持っているが，

システム開発に関する知識が十分ではない場合が多い。

一方，開発者はシステム開発の知識を持っているが，

業務内容に対する理解が不足している場合がある。

そのため，要件定義書が作成されていたにもかかわらず，

要求内容に曖昧な点が多く残り，

開発後に想定と異なる機能が発生することがある。

📊 本番得分预估

8.5 / 10（安全区）

---

問題２ 讲评（原型法的目的与效果）

你的原答案评价

✅ 优点

• 明确写了 目的 / 効果（很多人写不出来）
• 知道原型是用来确认需求的

❌ 扣分点

1. "改正"是法律用语，这里不合适
2. 句子太口语化
3. "前の要求"表达模糊

---

✅ 合格级最小修改版

目的は，開発初期の段階で顧客に要求内容を確認することである。

効果としては，開発過程における曖昧な要求を減らすことが挙げられる。

試作的なシステムを作成し提示することで，

顧客や利用者は実際の動作を通して要求内容を確認でき，

想定との差異を早期に修正することが可能となる。

📊 本番得分预估

8 / 10

---

問題３ 讲评（测试 vs 调试）

你的原答案评价

✅ 非常好

• 概念 100% 正确
• 这是标准答案级别

❌ 唯一问题

• "ですある"是语法错误

---

✅ 合格级修正版（只改 1 个字）

テストは欠陥の存在を発見する活動であり，

デバッグは発見された欠陥の原因を特定し，修正する活動である。

📊 本番得分预估

10 / 10（送分题）

---

問題４ 讲评（重构）

你的原答案评价

✅ 优点

• 知道是为了后续开发更容易
• 知道外部行为不变

❌ 扣分点

1. "再構築を整理"不自然
2. 没明确说 内部構造の改善
3. "品率"是错误词（应为 可読性 / 保守性）

---

✅ 合格级最小修改版

目的は，ソフトウェアの内部構造を整理・改善し，

その後の開発や保守を容易にすることである。

この作業では外部的な振る舞いを変更せず，

内部構造のみを改善することで，

可読性や保守性の向上を図る。

📊 本番得分预估

8 / 10

---

📊 总体评价（非常重要）

题号	预估得分
問1	8.5
問2	8
問3	10
問4	8
合计	34.5 / 40（稳合格）

---

6-总结

用日语的方式来直接训练，我认为是提示能力的好办法吧，希望从今天开始，每天坚持到考试那天，一直训练。