5分類
① 業務要件・現状整理系
内容：システムの目的・背景・課題の把握 現行業務や問題点の整理 新システムで解決したい点の抽出 典型的な設問例（抽象化）
現行システムの問題点を挙げよ 新システム導入の目的を説明せよ 業務要件を整理せよ 根拠 各資料で冒頭に業務背景や課題が詳細に説明されており（例：在庫問題、評価制度、キャンペーンなど）、設問の前提となる読み取りが求められる。 [R5A_DB_pm06.pdf | PDF], [R7S_DB_pm06.pdf | PDF], [R7A_DB_pm06.pdf | PDF]
② データモデル（ER図）理解・設計系
内容：エンティティ・関連の理解 主キー・外部キー・関係の判断 ER図の補完・修正 典型的な設問例
エンティティ間の関係を答えよ 主キーとして適切な属性を選べ 欠けている関連を補え 根拠 すべてのPDFでERモデルが中心にあり、エンティティ（顧客、商品、社員など）と関係の設計が明示されている。 [R7A_DB_pm06.pdf | PDF], [R6A_DB_pm06.pdf | PDF], [R2A_DB_pm06.pdf | PDF]
③ リレーショナルスキーマ・正規化系
内容：ERモデルから表構造への変換 正規化・冗長性の排除 属性分離やテーブル分割 典型的な設問例 表設計として適切な構造を選べ 正規化の観点から誤りを指摘せよ 多対多関係の解決方法を答えよ 根拠 ER図から実際のDB構造へ落とし込む説明があり、単一スキーマ構成の問題点なども扱われている。 [R7S_DB_pm06.pdf | PDF]
④ SQL・データ操作系
内容：検索条件・結合・集計の記述 要件を満たすSQL文の作成 業務ロジックのクエリ化 典型的な設問例 条件に合うデータを抽出するSQLを書け 集計結果を求めるクエリを作成せよ JOIN条件を補え 根拠 複数資料で具体的なSQL例（休日一覧取得、在庫計算など）が提示されており、実際の問い合わせ処理が問われる構成。 [R7S_DB_pm06.pdf | PDF], [R2A_DB_pm06.pdf | PDF]
⑤ システム改善・非機能（性能・セキュリティ）系
内容：設計上の問題点の指摘 改善策（分離・最適化） セキュリティ・運用性の検討 典型的な設問例
現設計の問題点を指摘せよ 改善案を述べよ セキュリティリスクを説明せよ 根拠 単一DB構成のリスク（SQLインジェクションなど）や、リソース最適化・キャンペーン効果改善などの考察が含まれる。 [R7S_DB_pm06.pdf | PDF], [R7A_DB_pm06.pdf | PDF]
✅ まとめ（試験対策視点）
この問題群は毎回テーマが変わっても、本質は以下の流れで固定されています：
①業務理解
→ ②ER設計 → ③表構造 → ④SQL処理 → ⑤改善・評価
✅ 補足（得点戦略）
配点が高いのは「②③④（設計＋SQL）」 時間が足りなくなりやすいのは「④SQL」 差がつくのは「⑤改善問題（理由説明系）」 必要であれば、「各分類ごとの頻出具体設問（過去問形式）」や「解き方テンプレ」も整理できます。
解き方テンプレ
アップロードされた一連のPDF（R1A_DB_pm06.pdf～R7S_DB_pm06.pdf）は、すべて
「業務→ER→表→SQL→改善」という同一構造のため、設問ごとに“型”で解くのが最短ルートです。 [R7S_DB_pm06.pdf | PDF], [R7A_DB_pm06.pdf | PDF], [R5A_DB_pm06.pdf | PDF]
以下に、実践でそのまま使える**解き方テンプレ（答案フレーム）**を整理します。
✅ ① 業務要件・現状整理系テンプレ
🔷思考手順
① 業務の目的（何をしたいか）
② 現行の問題（何が困っているか）
③ 原因（なぜ起きているか）
④ 改善後（どうなるべきか）
🔷答案テンプレ
本システムの目的は【〇〇】である。
現行システムには【問題①】【問題②】があり、
その原因は【原因】である。
そこで【改善内容】により【効果】を実現する。
🔷ポイント
「問題→原因→対策」の流れを崩さない
“業務視点”で書く（DB用語だけにしない）
✅ ② ER図・関係性問題テンプレ
🔷思考手順
① エンティティの役割を確認
② 主キー候補を特定
③ 関係（1対多 / 多対多）を判断
④ 中間エンティティの要否を判断
🔷答案テンプレ
エンティティAとBは【関係】であり、
Aの主キー【PK_A】がBの外部キーとして設定される。
また、多対多関係であるため【中間エンティティC】を設ける。
🔷判断ルール（超重要）
明細がある → 1対多
履歴・実績 → 多対多（中間テーブル）
「複数持てる」→ 多側
✅ ③ 表設計・正規化テンプレ
🔷思考手順
① 主キーが一意か確認
② 繰返し属性がないか確認
③ 関数従属を確認
④ 分割の必要性を判断
🔷答案テンプレ
表Xには【従属関係】が存在するため、
第〇正規形を満たしていない。
よって【項目】を分離し、表Yとして独立させる。
🔷頻出パターン
名前・住所などの分離
コードと名称の分離
多値属性の別表化
✅ ④ SQL問題テンプレ（最重要）
🔷思考手順（固定フロー）
① 「何を出す？」（SELECT）
② 「どこから？」（FROM）
③ 「どうつなぐ？」（JOIN）
④ 「条件は？」（WHERE）
⑤ 「集計？」（GROUP BY）
🔷答案テンプレ（基本形）
SELECT A.項目, COUNT(*)
FROM 表A A
JOIN 表B B ON A.ID = B.ID
WHERE 条件
GROUP BY A.項目;
🔷典型パターン
主テーブル＋明細テーブルJOIN
日付条件
集計（COUNT / SUM）
🔷ミス防止チェック
JOIN条件漏れ
GROUP BY不足
WHEREとHAVINGの混同
✅ ⑤ 改善・非機能問題テンプレ
🔷思考手順
① 問題点（現状の弱点）
② 影響（何がまずい）
③ 改善策（どう直す）
④ 効果（どう良くなる）
🔷答案テンプレ
現行設計では【問題】があり、
【リスク／影響】が生じる。
これに対して【改善策】を実施することで、
【効果】を得られる。
🔷頻出テーマ
セキュリティ（SQLインジェクション等） [R7S_DB_pm06.pdf | PDF]
性能（データ増加）
分離（スキーマ・テナント）
✅ 最強まとめ（試験でそのまま使う）
① 業務：目的→問題→原因→改善
② ER：関係（1対多 or 多対多）＋中間表
③ 表：従属→正規化→分割
④ SQL：SELECT→FROM→JOIN→WHERE→GROUP
⑤ 改善：問題→影響→対策→効果
✅ さらに点を伸ばすコツ（重要）
「名詞だけ」ではなく動詞で説明
× データ重複
○ データが重複して更新不整合が発生する
ERとSQLを頭の中でつなげる
改善問題は「リスク」を必ず書く
必要なら
👉「実際の過去問でこのテンプレを当てはめた解答例（満点答案）」
も作れます。
用語集
| 第1正規化 | 繰り返し項目をなくす |
| 第2正規化 | 主キーの一部によって一意に決まる属性を別表に移す |
| 第3正規化 | 主キー以外の属性によって一意に決まる属性を別表に移す |
