DB試験まで残り1ヶ月で行うべき過去問を纏めました！一緒に頑張っていきましょう！！
○✔︎R04午後1問2；トリガの問題（優先度；★★★★☆）
出題要旨
| 設問 | テーマ | 技術要素 | 問われた理解の焦点 | キーワード・要点 |
|---|
| 設問2 | トリガー（制御内部）の動作タイミング | BEFORE／AFTERトリガー | 更新操作の前後での処理の違いを理解できているか。BEFOREではNEWの変更が可能、AFTERでは他テーブル更新が可能。 | – BEFORE：データ補正（例：NULL→現在日付）- AFTER：履歴登録（例：更新前行を履歴テーブルへ）- OLD／NEWの使い分け |
| 設問3 | レプリケーション（制御間）の処理方式 | 同期／非同期レプリケーション | 性能と整合性のトレードオフを理解できているか。どちらを選択すべきかを業務特性から判断できるか。 | – 同期：複製先の書き込み完了を待つ→確実だが遅い- 非同期：待たない→高速だが整合性リスクあり- 見積システムでは非同期が適する |
ポイント
トリガーの比較（BEFORE／AFTER）
| 項目 | BEFOREトリガー | AFTERトリガー |
|---|
| 実行タイミング | 変更操作前に実行 | 変更操作後に実行 |
| 対象行の扱い | 更新対象の行（NEW）を書き換え可能 | 変更後の行をもとに他テーブル操作が可能 |
| 主な目的 | データ整形・値の補正（例：NULLなら現在日付を設定） | 履歴登録・ログ記録など副作用的処理 |
| 使用例 | 「適用開始日がNULLなら現在日付に更新」など | 「更新前の行を履歴テーブルに挿入」など |
| 特徴 | ・NEWを変更可能・コミット前に実行されるため高速・同一テーブル内での値補正向き | ・他テーブルへのINSERT/UPDATEが可能・コミット後処理的な使い方・トランザクション整合性確保が重要 |
| 試験での狙い | 値の整合性維持・自動補完 | 履歴管理・データ追跡の理解 |
| 注意点 | ・AFTERではNEWを変更できない・目的に応じた使い分けが重要 | ・BEFOREでは他テーブルを操作できない |
同期型と非同期型の比較（まとめ）
| 特性 | 同期型レプリケーション | 非同期型レプリケーション |
| コミット処理 | 複製先でのログのディスク出力完了を待つ | 複製先へのログの到達を待たずにコミット |
| 応答速度 | ログ出力分遅延する | 最速で完了する |
| データ一貫性 | 高い（RPO: 0） | 低い（ログの未到達による不一致の可能性あり） |
| システム影響 | 複製先の負荷が直接影響し、遅延が発生しやすい | 複製先の負荷が影響しにくい（応答速度の最小化） |
理解確認問題
① トリガー（BEFORE／AFTER）の理解確認
- タイミング
- Q1: BEFOREトリガーは更新操作の前／後のどちらに実行されますか？
- Q2: AFTERトリガーは更新操作の前／後のどちらに実行されますか？
- 操作対象
- Q3: BEFOREトリガーで変更可能なのはOLD／NEWのどちらですか？
- Q4: AFTERトリガーで変更可能なのはOLD／NEWのどちらですか？
- Q5: 他テーブルへのINSERTやUPDATEはBEFORE／AFTERのどちらで可能ですか？
- 目的・用途
- Q6: NULL値を現在日付に補正する処理はBEFORE／AFTERトリガーが適切ですか？
- Q7: 更新前の行を履歴テーブルに挿入する処理はBEFORE／AFTERトリガーが適切ですか？
② レプリケーション（同期／非同期）の理解確認
- タイミングと待機
- Q8: 同期型レプリケーションでは、複製先でのログ書き込み完了を待つ／待たない？
- Q9: 非同期型レプリケーションでは、複製先でのログ書き込み完了を待つ／待たない？
- メリット・デメリット
- Q10: 同期型のメリットは？デメリットは？
- Q11: 非同期型のメリットは？デメリットは？
- 業務適用の判断
- Q12: 見積もりシステムのような高速応答が必要な業務では、同期型／非同期型どちらが向いていますか？
- Q13: データの整合性を絶対に確保したい場合は、同期型／非同期型どちらが向いていますか？
○✔︎H30午後1問2；参照制約の問題（優先度；★★★☆☆）
＜出題要旨＞【設問1】SQL【設問2(1)】参照制約【設問2(2)】トリガー【設問3】参照制約
ポイント
外部キー制約のポイント
| 操作対象 | 操作内容 | 主な制約チェック | 挙動（エラー or 正常） | 備考 |
|---|
| 参照先（親） | 追加（INSERT） | 特に参照制約なし（他から参照される側） | 常に正常終了 | 子テーブルから参照される可能性があるキーを追加 |
| 参照先（親） | 削除（DELETE） | 子テーブルに対応する外部キーが存在するか | – 子に該当行がある → 制約違反（RESTRICT／NO ACTION）- CASCADE → 子も削除- SET NULL → 子の外部キーがNULLになる | 「ON DELETE」の指定で挙動が変化する |
| 参照元（子） | 追加（INSERT） | 外部キーの値が参照先に存在するか、またはNULLか | – 存在 or NULL → 正常- 存在しない → 制約違反 | もっとも典型的な参照整合性チェック |
| 参照元（子） | 削除（DELETE） | 特に制約なし（外部キーを削除するだけ） | 常に正常終了 | 親には影響しない（片方向の制約） |
更新順序の違いによる不具合
| 手順の原則 | 動作の安全性 | 理由（CASCADE設定時） |
| 新規 → 更新 → 削除 | 安全 | 更新（異動）を先に行うことで、後の削除操作から従業員データを切り離し、連鎖削除を防ぐ。 |
| 削除 → 更新 → 新規 | 不安全 | 削除を先に行うとCASCADEで行全体が消滅し、その後の更新操作が不可 |
参照制約における挙動モード（NO ACTION／CASCADE）と検査契機モード（即時／猶予）
| 組み合わせ | 挙動（データの反映） | 制約検査のタイミング | 主な特徴 |
|---|
| NO ACTION × 即時モード | 反映しない | 各SQL実行後に即検査 | 最も厳格。整合性維持は強いが柔軟性は低い |
| NO ACTION × 猶予モード | 反映しない | トランザクション終了時に検査 | トランザクション内で一時的な不整合を許容 |
| CASCADE × 即時モード | 自動反映する | 各SQL実行後に即検査 | 更新・削除が即時に連鎖反映 |
| CASCADE × 猶予モード | 自動反映する | トランザクション終了時に検査 | 大量更新・バッチ処理向き |
○✔︎H19午後1問3；セキュリティと監査の問題（優先度；★★★☆☆）
・アクセス制御、ロール、監査などのデータベースセキュリティ
・データベース管理エンジニアに必要なデータベースセキュリティに関する技術及び知識実装能力
【設問1】ビューを使用したアクセス制御
【設問2】ロールとSQL
【設問3】監査証拠
ポイント
ビューによる行レベルのアクセス制御
| ポイント | 解説 |
| ビューの役割 | 実テーブルの特定の行（レコード）や列のみを表示する仮想的なテーブルとして機能します。 |
| セキュリティ | 標準SQLでは行単位のアクセス制御ができないため、ビューを用いて「自分のデータのみ」を抽出するようフィルタリング（WHERE句）を設定します。 |
| 権限付与 | 従業員には実テーブルへのアクセス権限は与えず、フィルタリング済みのビューにのみアクセス権を付与することで、行レベルのセキュリティを実現します。 |
USER関数の活用
| ポイント | 解説 |
| USER関数の機能 | 現在データベースにログインしているユーザーID（またはユーザー名）を自動的に返します。 |
| 効率性 | 従業員一人ひとり（例：E001, E002, …）のIDを固定したビューを人数分作る代わりに、WHERE 社員ID = USERという条件を設定した単一のビューを作成できます。 |
| 結論 | 従業員ごとにビューを作成する必要がなくなり、管理の手間が大幅に削減されるため効率的です。 |
ロールによる権限管理
| 項目 | 説明/SQLコマンドの構成 | 試験でのポイント（なぜ使うのか） |
| 定義 | 複数のアクセス権限（SELECT, UPDATEなど）を束ねた論理的な役割。 | 権限設定をユーザーごとではなく役割ごとに行うことで、管理の手間を大幅に削減できる。 |
| ① ロールの作成 | CREATE ROLE ロール名; | 権限のまとまりである**「役割」を定義**する最初のステップ。 |
| ② ロールへの権限付与 | GRANT 権限 ON オブジェクト名 TO ロール名; | ロールが持つべき権限を確定させる。ユーザーではなくロールに付与するのが特徴。 |
| ③ ユーザーへのロール付与 | GRANT ロール名 TO ユーザー名; | ユーザーにその役割を与える（ユーザーがロールの権限を使えるようになる）。 |
| 権限の変更 | REVOKE（削除）と**GRANT（付与）のセット**が必要。 | SQLには権限を移動・コピーする単一の構文はない。人事異動などで権限者が変わる際は、必ず「旧ユーザーからREVOKE → 新ユーザーにGRANT」の2操作が必要。 |
| 最大のメリット | 管理負荷の軽減、セキュリティポリシーの一貫性。 | 組織変更や異動があっても、ユーザーへのロール付与/剥奪のみで済み、テーブルごとの権限設定（GRANT）を変更する必要がない。 |
権限変更時の操作
| ポイント | 解説 |
| 権限の移動/コピー | SQLには「権限を他のユーザーへそのまま移す」ための専用構文はありません。 |
| 必要な操作 | ユーザーID “B110” から “B130” へ「営業部長ロール」を異動させる場合、次の2ステップが必要です。 |
| ① 削除（剥奪） | 旧ユーザーからロールを削除：REVOKE 営業部長ロール FROM B110; |
| ② 追加（付与） | 新ユーザーにロールを付与：GRANT 営業部長ロール TO B130; |
| 結論 | ユーザID”B110″から営業部長ロールのアクセス権限を削除し、ユーザID”B130″に営業部長ロールのアクセス権限付与を行う必要があります。 |
監査証跡調査：試験の核となる考え方
| SQL操作 | 問われる事象 | ログに残る情報（特定できること） | ログに残らない情報（特定できない理由） | 試験の解答ポイント |
| SELECT | 情報漏洩の調査 | ✅ 誰がアクセスしたか（ユーザーID）、✅ どのテーブルにアクセスしたか。 | ❌ SELECT文のWHERE句の内容（どのデータを見たか）。❌ 抽出された具体的なデータ値。 | 「漏洩したデータの中身（一覧）」までは特定できない。 |
| UPDATE | データ改竄の調査 | ✅ 誰が更新操作をしたか（ユーザーID）、✅ どのテーブルを更新したか。 | ❌ UPDATE文のSET句の内容（変更した値）。❌ 変更前後の具体的なデータ値。 | 「更新内容が正当か改竄か」を判断したり、「改竄された中身」を特定したりはできない。 |
| GRANT/REVOKE | 権限変更の調査 | ✅ 誰が権限を付与/剥奪したか、✅ どの権限に対して操作したか。 | | 権限管理の操作履歴は明確に特定可能。 |
| 権限エラー | 権限のない操作試行 | ✅ 操作の結果がエラーであること（SQLSTATE）、✅ エラーを試みたユーザーID。 | | 権限外の操作を試みたユーザーは、エラーログによって特定可能。 |
| 全体的な限界 | セキュリティ監査 | 操作の履歴（誰がいつ何を）と試行/失敗の記録。 | データの中身（参照値、更新前後の値）やSQL文の具体的な条件。 | 監査証跡は操作者の特定には役立つが、データの中身の検証にはトリガなどの別機能が必要。 |
○✔︎H23午後1問3；【性能・索引の問題】（優先度；★★★★★）
出題要旨
・性能測定の目的にあったSQL文の設計能力
・アクセス経路による性能を見極める能力
・性能測定結果から適切に分析できる能力
ポイント
🔸 SQL処理時間の構成要素まとめ
| 区分 | 内容 | 主な処理 | 具体例（秒） |
|---|
| ① CPU処理時間 | SQLの演算処理に要する時間 | ・演算・条件評価・データバッファ上の処理 | SQL1A：2,010SQL2A：10 |
| ├①A：データ入力処理のCPU時間 | データページを順次バッファへ読み込む | 全データページの読み込み | 10 |
| └①B：データ出力処理のCPU時間 | バッファからプログラム内へデータ移動 | 結果行生成・取得 | 2,000 |
| ② データ入出力処理時間 | ディスクI/Oに要する時間 | ・データの読み込み（入力）・データの書き込み（出力） | SQL2A：1,000 |
| ├②A：データ入力処理時間 | ディスク→バッファ（読み込み） | 表全体の読み込み | 1,000 |
| └②B：データ出力処理時間 | バッファ→ディスク（書き込み） | 結果行の外部出力 | 0 |
| SQL処理時間 | RDBMSで計測される総処理時間 | MAX（①CPU処理時間，②データ入出力処理時間） | SQL1A：2,010SQL2A：1,000 |
🔸 同期処理と非同期処理の違い
| 項目 | 同期処理 | 非同期処理 |
|---|
| 処理の流れ | CPU処理 → I/O処理を順番に実行 | CPU処理とI/O処理を並行実行 |
| SQL処理時間の算出 | 加算（CPU＋I/O） | **最大値（MAX）**を採用 |
| メリット | 処理の順序が明確で制御しやすい | 高速化（CPUとI/Oが重ならない時間を削減） |
| デメリット | I/O待ちの間、CPUが遊ぶ | 処理の同期が複雑になる |
| H23設問の対象 | ― | ✅ 非同期処理 |
SQL処理時間
| 覚えるべき式 | 内容 |
|---|
| SQL処理時間＝MAX（CPU処理時間，データ入出力処理時間） | 非同期処理の場合 |
| SQL処理時間＝CPU処理時間＋データ入出力処理時間 | 同期処理の場合（参考） |
データバッファ vs ログバッファ
| 項目 | データバッファ（Data Buffer） | ログバッファ（Log Buffer） |
| 1. 役割 | データI/Oの高速化。ディスク上のデータページを一時的にメモリに格納し、アクセス速度を向上させる。 | トランザクションの永続化を保証。更新情報（REDO/UNDOログ）をディスクに書き込む前に一時的にメモリに溜める。 |
| 2. 格納内容 | テーブルデータ、索引データなどのデータページ。 | トランザクションログ（データの変更内容やCOMMIT/ROLLBACKの情報）。 |
| 3. この問題での関わり | SQL1A/2Aの表探索により、ディスクからデータページがここに読み込まれる。設問 g や h の計算の起点となる。 | SELECT文では、通常、関わらない（更新がないためログの書き込みは発生しない）。UPDATE/INSERT/DELETEで重要となる。 |
| 4. まとめ（一言） | 「データ」の高速な読み書き用メモリ | 「更新履歴」の一時保管用メモリ |
RDBMSの処理フロー
| 処理ステップ | 処理内容 | 変更あり（INSERT / UPDATE / DELETE） | 変更なし（SELECTなど） |
|---|
| ① SQL実行 | SQL文を解析し、実行計画を作成して処理開始 | 構文解析・最適化を行い実行 | 同左 |
| ② データバッファ処理 | テーブル・インデックスページをメモリ上（データバッファ）に読み込む | 読み込み後、対象データを更新または追加 | 読み込みのみ（変更なし） |
| ③ ログバッファ処理 | 変更内容を一時的に保存（ログバッファ） | 更新内容をログに記録し、コミット時にディスクへ同期書き込み | 処理なし |
| ④ コミット / ロールバック | トランザクションの確定または取消 | コミット時にログをディスクに出力、データを永続化 | コミット不要（読み取りのみ） |
| ⑤ 結果表示 | 実行結果をクライアントへ返す | 更新結果または完了メッセージを返す | 検索結果を返す |
バッファヒット率の「高い・低い」がシステムに与える影響
| バッファヒット率 | 状態 | システムへの影響 |
| 高い（理想：90%以上） | 多くのデータがメモリ上に存在している。 | ✅ レスポンスタイムの向上：データアクセスが高速化し、SQLの処理時間が短縮される。 ✅ CPU負荷の低減：ディスクI/O処理やデータ転送処理が減るため、CPUの負荷が下がる。 |
| 低い（問題：80%以下） | 頻繁にディスクへのアクセスが発生している。 | ❌ パフォーマンスの劣化：ディスクI/Oがボトルネックとなり、SQLの実行が遅延する。 ❌ ディスクI/O待ちの増加：システム全体の待ち時間が増え、同時実行性が低下する。 |
✔︎R03午後1問2；【SQLの処理時間の問題】（優先度；★★★★★）
・処理時間の見積もり
・バッファプールのチューニング
・区分表の設計
・ロギングの性能に関する考慮点
【設問1】参照処理の処理時間の見積もり
【設問2】区分化に関する設問
【設問3】ログに関する設問
○✔︎H29午後1問2；【トランザクション制御（同時実行制御・デッドロック）の問題】（優先度；★★★★☆）
ポイント
トランザクションのISOLATIONレベル
| ISOLATIONレベル | 操作種別 | ロックの種類 | ロック取得のタイミング | ロック解放のタイミング | 特徴・補足 |
|---|
| READ UNCOMMITTED | 参照 | なし（ノーロック） | － | － | 他トランザクションの未コミットデータも読める（ダーティリード発生） |
| 更新 | 専有ロック（Xロック） | UPDATE実行時 | トランザクション終了時（COMMIT/ROLLBACK時） | 他トランザクションの更新・参照をブロックする |
| READ COMMITTED | 参照 | 共有ロック（Sロック） | SELECT実行時 | SELECT終了時（文単位で解放） | ノンリピータブルリードが発生（再読で値が変わる） |
| 更新 | 専有ロック（Xロック） | UPDATE実行時 | トランザクション終了時 | 1文ずつ更新結果を確定していく。性能と整合性のバランス型 |
| REPEATABLE READ | 参照 | 共有ロック（Sロック） | SELECT実行時 | トランザクション終了時 | 同じ行を再読しても値が変わらない（ノンリピータブルリード防止） |
| 更新 | 専有ロック（Xロック） | UPDATE実行時 | トランザクション終了時 | 他トランザクションの更新を完全に排他 |
| SERIALIZABLE | 参照 | 範囲ロック（共有＋範囲） | SELECT実行時 | トランザクション終了時 | ファントムリードも防止。最も厳密だが遅い |
| 更新 | 専有ロック（Xロック）＋範囲ロック | UPDATE実行時 | トランザクション終了時 | 完全直列化を保証 |
ロックの種類と粒度
| 分類 | 種類 | 内容 |
|---|
| ロック種別 | 共有ロック（Sロック） | SELECT時など。読取り可・更新不可。他のSロックと共存可 |
| 専有ロック（Xロック） | UPDATE/DELETE時など。完全排他。他ロックと共存不可 |
| 粒度 | テーブルロック | テーブル全体に対するロック。並列性が低い |
| 行ロック | 特定の行に対するロック。並列性が高いが制御が複雑 |
デッドロックになる全パターン
1. ロックの競合に基づくパターン（最も典型的）
| パターン | 概要 | 隔離レベル | 例（T1とT2のトランザクション） |
| ① 資源獲得順序の逆転 | 異なるトランザクションが複数の資源（データ行、ページ、テーブルなど）を異なる順序でロックし合うパターン。専有ロック（Xロック）同士の排他関係で発生することが多いです。 | 全レベル (特にRead Committed以上) | T1: 行Aをロック → 行Bを要求 (T2待ち) T2: 行Bをロック → 行Aを要求 (T1待ち) |
| ② SロックとXロックの循環待ち | 異なるトランザクションが同一の資源に対し、Sロックを保持したまま、Xロックへの昇格（または要求）を同時に試みるパターン。Sロックの保持期間が長い隔離レベルで発生しやすいです。 | REPEATABLE READ | T1: 行AにSロック保持 → Xロック要求 (T2のSロック待ち) T2: 行AにSロック保持 → Xロック要求 (T1のSロック待ち) |
2. ロック粒度とデータ範囲に基づくパターン
| パターン | 概要 | ロック対象 | 例（T1とT2のトランザクション） |
| ③ 複数テーブル/データ範囲の順序逆転 | 複数のテーブルや異なるデータ範囲を対象とするトランザクション間で、テーブルごと、またはキー値の範囲ごとの処理順序が逆転する場合。 | テーブル、ページ、インデックスキー範囲 | T1: テーブルAを更新 → テーブルBを更新 T2: テーブルBを更新 → テーブルAを更新 |
| ④ 粒度の異なるロックの競合 | 単一行/単一ページをロックするトランザクションと、テーブル全体またはインデックス範囲をロックするトランザクションが競合するパターン。 | 行ロックとテーブルロック | T1: テーブル全体に意図的Xロック → 行ロック要求 (T2待ち) T2: 単一行にXロック → テーブルXロック要求 (T1待ち) |
| ⑤ インデックスキー範囲ロックの競合 | ファントムリードを防ぐためにかけられるキー範囲ロックが、他のトランザクションによる行の挿入/削除と競合するパターン。 | キー範囲 (GAP Lock) | T1: 範囲ロックを保持（特定の範囲への挿入を禁止） T2: その範囲に行を挿入 → ロック待ち |
3. その他（アプリケーション起因）のパターン
| パターン | 概要 | 特徴 |
| ⑥ アプリケーションによるロックの明示制御 | データベースの自動ロックではなく、SELECT FOR UPDATEなどの明示的なロックが異なる順序で行われることで発生。 | SQLレベルでのロック順序制御の誤り |
| ⑦ 複数の接続プール/プロセス間でのリソース競合 | データベース外のリソース（ファイル、メッセージキューなど）も含め、トランザクションが複数の外部システムのリソースを異なる順序で確保し合うパターン。 | データベース外の排他制御も絡む |
デッドロック発生パターンと対策
| № | 発生パターン | 主な原因 | 有効な対策 | 備考 |
|---|
| ① | 同一テーブル内で異なる順序で行ロック | トランザクションごとに更新順序が異なる（例：T1→A,B、T2→B,A） | – 更新順序を統一する（主キー順など）- 更新対象を1行ずつコミット- ロック範囲を明示的に指定 | 最も典型的なデッドロック原因。IPA午後問でも頻出。 |
| ② | 共有ロック→専有ロック昇格競合 | SELECTでSロック保持後にUPDATEするトランザクションが複数同時実行 | – SELECT後すぐUPDATEせず、更新対象を先に特定する- SELECT FOR UPDATEを使用して最初から排他ロックを取得- アクセス順序を統一 | REPEATABLE READで特に起こりやすい。 |
| ③ | 複数テーブルを異なる順序で更新 | トランザクション間でテーブル更新の順序が不一致 | – すべての処理でテーブル更新順序を統一（例：常にA→Bの順）- トランザクション粒度を小さくする | システム設計で防ぐのが基本。 |
| ④ | 親子・構成要素の多重更新 | 親（セット）と子（単品）をまたいで更新順序が不一致 | – 主キー順・構成順を統一- 親→子または子→親の更新順序を固定- ロック設計を見直す | 今回のTR3・TR4のようなケース。 |
| ⑤ | インデックス／範囲ロック競合 | 範囲条件（WHERE < など）でNext-Key Lockが重複 | – インデックス設計を見直す- 検索条件を限定してロック範囲を最小化- 必要ならISOLATION LEVELを下げる | InnoDBなどでよく発生。 |
| ⑥ | 外部キー制約の親子同時更新 | 親テーブル更新時、子テーブルが外部キー参照で同じ行をロック | – 更新順序を統一（親→子）- 外部キーの遅延チェック（DEFERRED制約）を利用- 外部キー制約をアプリで制御 | 複雑なリレーションで発生。 |
| ⑦ | サブクエリによる遅延ロック | UPDATE文中の副問い合わせが内部的に別順序で評価 | – サブクエリを分離して一時テーブルに格納- 更新前に必要データをすべて取得 | 内部的な実行順序が読みにくいため注意。 |
| ⑧ | トリガーやカスケード更新による再帰ロック | トリガーや外部キーで同一テーブルを再更新 | – トリガー処理の再帰呼び出しを避ける- 更新対象を明示的に分離 | アプリ側で制御するのが安全。 |
デッドロック回避原則
| 原則 | 内容 |
|---|
| ① 更新順序の統一 | すべてのトランザクションで、テーブル・行のアクセス順序を統一する。 |
| ② トランザクションの短縮 | ロック保持時間を短くする（コミットを早める、細分化する）。 |
| ③ ロック範囲の明示化 | 必要な範囲だけ SELECT ... FOR UPDATE で明示ロックする。 |
| ④ 再試行制御（リトライ） | デッドロック発生を検出したら、トランザクションを自動的に再実行する。 |
| ⑤ ロック競合を避ける設計 | 同一データを複数トランザクションが同時更新しないよう設計段階で分離。 |
△✔︎H31午後1問1；決定表の問題（優先度；★☆☆☆☆）
設問2が決定表の問題。業務について記載のある箇所を読んで整理していく。
設問3の関係の追加の方がやりごたえがあり、かなり悩んだ。
内容としては、関係スキーマの設計変更（属性の追加・削除／関係の追加）です。
×H26午後1問1；関係代数の問題（優先度；★☆☆☆☆）
○✔︎H26午後1問3；各種制約の問題（優先度；★★★★☆）
＜出題要旨＞【設問1(1)(2)】UNIQUE制約【設問1(3)】外部キー【設問1(4)】検査制約【設問2】SQL【設問3】デッドロック
ポイント
デッドロックについては、【H29午後1問2】で要点をまとめた。
UNIQUE制約とは
| 項目 | 内容 |
|---|
| 概要 | 特定の列（または列の組み合わせ）の値が**一意（重複不可）**であることを保証する制約。 |
| 目的 | 重複データを防ぎ、整合性・検索性能を維持する。 |
| 特徴 | – NULLは複数行に許可される（DBMSによる）- 複数列の組合せ（複合UNIQUE）も設定可能 |
| 使用例 | 社員番号、メールアドレス、会員IDなどを一意に保つ場合 |
| 注意点 | – 主キー（PRIMARY KEY）も内部的にはUNIQUE制約を持つ。- UNIQUEとPRIMARY KEYの違いは「NULL許可」と「1テーブル1つ制限」。 |
| 例文（SQL） | ALTER TABLE users ADD CONSTRAINT uq_email UNIQUE (email); |
外部キー設定条件
| 項目 | 内容 |
|---|
| 概要 | 外部キー（FOREIGN KEY）は、他テーブルの主キーまたは一意キーを参照し、参照整合性を保証する。 |
| 設定条件 | ✅ 以下すべてを満たす必要あり：1️⃣ 参照先の列が 主キーまたはUNIQUE制約付き列 である。2️⃣ 参照元・参照先の データ型・桁数が一致 している。3️⃣ 両方のテーブルが 同じDBスキーマ上 に存在。 |
| 参照整合性制約の動作 | – ON DELETE CASCADE：親削除時に子も削除- ON DELETE SET NULL：親削除時に子をNULL化- ON UPDATE CASCADE：親の変更に追従 |
| 目的 | 論理的に関連するデータの整合性を保持（孤児レコードの防止）。 |
| 注意点 | – 外部キー制約により、削除・更新が遅くなる場合あり。- パフォーマンス重視の場面では一時的に外すこともある。 |
| 例文（SQL） | ALTER TABLE orders ADD CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users(id); |
サブタイプをテーブルとして実装する時の考慮すべき点
「単品商品」と「セット商品」のように、共通の属性を持ちながら一部の属性や振る舞いが異なる関係をスーパータイプ/サブタイプ（または汎化/特化）と呼びます。これをリレーショナルデータベースで実装する際には、主に以下の3つのパターンがあり、それぞれ考慮点があります。
| 実装パターン | 特徴 | 考慮すべき点（今回の問題に絡む点） |
| 案1: 1つのテーブルにまとめる (スーパータイプ方式) | 全属性を1つのテーブルに定義し、区別用のフラグ（例: 商品区分）を持つ。 | 外部キーの不都合: 外部参照時、単品とセットの区別がつかず、不適切な参照（設問1（3）ア）が起こりやすい。 |
| 案2: サブタイプごとにテーブルを分ける (サブタイプ方式) | 単品商品、セット商品のテーブルに分け、共通属性を持つスーパータイプテーブルは作らない。 | 外部キーの不都合: 外部参照（例: 在庫）はどちらのテーブルを参照すべきか確定できず、通常の外部キー設定（設問1（3）イ）ができない。 |
| 案3: スーパータイプとサブタイプに分ける | 商品（共通属性）と単品商品、セット商品（固有属性）のテーブルに分ける。 | 複数のテーブルをJOINする必要があり、参照は複雑になるが、外部キーによる参照整合性は保ちやすい。 |
○✔︎H28午後1問2；バックアップの問題（優先度；★★★★☆）
・バックアップ、回復を実行する際には、対象を見極め、業務への影響を理解・整理し、その結果を適切にバックアップ・回復計画に反映させることが求められる。
・データベースのバックアップ・回復機能についての理解
・システムの環境条件、運用状況に応じた適切なバックアップ・回復手順の設計能力
ポイント
🔹バックアップ方式の要点整理
| 種類 | 内容 | 特徴 | 適するケース |
|---|
| 全体バックアップ | 全データを毎回保存 | 最も単純だが時間・容量が大 | 変更頻度が少ないテーブル |
| 差分バックアップ | 最後の全体バックアップ以降の変更ページすべて | 時間・容量が日々増加 | 変更が局所的な場合 |
| 増分バックアップ | 前回のバックアップ以降の変更ページのみ | 毎日のバック容量が小さい | 追加が多い場合（変更範囲が広がりにくい） |
業務特性に応じたバックアップ計画（設問1・2）
| 項目 | ポイントとなる知識/技能 |
| バックアップタイミング | データ更新の特性（オンライン処理かバッチ処理か）と参照の整合性を理解し、**RPO（目標復旧時点）**を考慮してバックアップ時刻（T1～T5）を決定する。 |
| バックアップの種類 | テーブルごとのデータ変化特性（更新頻度、追加頻度）に基づき、「差分」と「増分」のどちらが容量と時間の面で最適か判断する。特に「在庫」と「出荷」のケースは、更新と追加の特性を理解する良い訓練となる。 |
| 「差分」と「増分」の比較 | 差分は復旧時間が短い（フル＋最新差分）が、取得容量と時間が日を追うごとに増大する。増分は取得容量と時間が安定するが、復旧時に全増分を適用するため復旧時間が長くなる。 |
障害発生時のパッチ処理と回復手順（設問2・3）
| 項目 | ポイントとなる知識/技能 |
| パッチ処理の判断 | 論理障害が発生したテーブルに対し、並行して実行中のパッチプログラムが参照または更新しているかをデータフロー（図1）と仕様（表1）から確認する。影響があれば再実行、なければ継続とする。 |
| 復旧時の再実行判断 | あるテーブルの論理障害（データ不正）を回復（復元）した場合、その不正なデータを参照して処理を進めたパッチプログラムは、正しい結果を得るために必ず再実行が必要となる。 |
| 影響連鎖の把握 | 図1のデータフローから、障害発生元のテーブルを参照するプログラムだけでなく、その不正な結果を参照して後続の処理を行った連鎖的なパッチプログラム（例：「在庫」→「需要予測」→「発注対象データ作成」）もすべて再実行が必要となることを把握する。 |
| 再実行の不要な理由 | 影響のないパッチプログラムについて、「なぜ再実行が不要か」を論理的に説明する。解答の要点は「障害の影響を受けたテーブル（とそれを反映したテーブル）を参照していないから」となる。 |
×H24午後1問3；データウェアハウスの問題（優先度；★☆☆☆☆）
△✔︎H16午後1問4；性能と索引設計の問題（優先度；★★★☆☆）
DB過去問（H16問4）の出題要旨まとめ
| 設問 | 要旨 | 補足（より詳細な論点） |
| 設問1 | クラスタ索引と非クラスタ索引の物理的なデータ格納方法の違いによるデータページの物理入出力数と処理時間の問題 | ランダムアクセス（非クラスタ）は行数ベース、順次アクセス（クラスタ・フルスキャン）はページ数ベースでI/O回数を計算し、さらにアクセス方式が1ページあたりのI/O時間に与える影響を問う。 |
| 設問2 | 連結索引の設計（列順序）の違いと索引リーフページの入出力回数との関係の問題 | 索引キー全体で絞り込みが効く場合、索引リーフページへのアクセスは順次アクセスとして機能し、索引リーフページ総数に複合絞り込み率を乗じてI/O回数を求める（キーの順序自体よりも絞り込み率の積が重要）。 |
| 設問3 | クラスタ索引における索引キーの設計の違いによる検索性能のトレードオフに関する問題 | 検索処理の最適化（ORDER BY句のソート回避）と、更新処理のオーバーヘッド抑制（更新頻度の低い静的な列の採用）という、クラスタ索引キー選定の2大要件を問う。 |
💡 クラスタ索引設計のための3つの最重要確認ポイント（設問3）
クラスタ索引はテーブルの物理的なデータ配置を決定するため、そのキー選定はデータベースの検索性能と更新処理性能（維持管理コスト）に最も大きな影響を与えます。
| 確認ポイント | 目的とする効果 | 索引キー選定の具体例 |
|---|
| 1. 索引キーは「静的」な列か？ | 更新コストの最小化：索引キーの更新による重い物理的なデータ移動（再編成）と、他の索引の連鎖的な更新を回避する。 | 〇 地域コード、性別、登録日など（変更されない、または稀にしか変更されない列） |
| 2. ORDER BY句の列が含まれているか？ | 検索性能の極大化：SQLのORDER BY句と索引キー順を一致させ、重いソート処理（ディスクソート）を不要にする。 | ORDER BY句の列（この問題では地域コード）を、複合索引のキーに含める。 |
| 3. テーブルの並び順（クラスタ索引）を利用しているか？ | ランダムアクセスの回避：クラスタ索引により、データを順次アクセス（シーケンシャル）で読み込めるようにし、I/O時間を大幅に短縮する。 | 索引を使用しない全件走査（Full Scan）や、範囲検索の性能を向上させる。 |
◻︎H25午後1問1；データベースの基礎理論の問題（優先度；★★★☆☆）
H16午後1問1；ボイスコッド正規形・第4正規形の問題（優先度；★☆☆☆☆）
コメント