全38問から、出題範囲の骨格が掴める14問だけを抜き出しました。まずはここだけ流して、必要なら全問へ進んでください。
全38問に進むこの14問の内容
出典: オリジナル想定問題（当サイト作成、実際の過去問ではありません）。公表されている出題範囲に基づく（最終更新 2026-09-06）
ある社員管理表は、社員番号を主キーとし、社員番号→社員名、社員番号→部門コード、部門コード→部門名という関数従属を持つ。この表に対して部門名を変更する際、同じ部門に所属する複数の社員の行をすべて更新しなければならない。この現象への対処として最も適切なものはどれか。
- ✓部門コードと部門名を別表に分離し、社員表からは部門コードで参照する形に正規化する
- B社員番号にUNIQUE制約を追加する
- C部門名列にNOT NULL制約を追加する
- D社員表全体を複製したバックアップ表を作成する
解説
部門名は部門コードに関数従属し、社員番号(主キー)に対して推移的関数従属の関係にある。これを解消するため部門表を分離するのが第3正規形化の対応であり、更新時異状(更新のたびに複数行を書き換える不整合)を防げる。
根拠シラバス「データモデリング技法」正規化(関数従属・推移的関数従属)
社員表の年齢列に、0以上150以下の範囲外の値が登録されることを防ぎたい。この目的を実現するために指定すべき制約はどれか。
- A主キー制約
- B一意性制約(UNIQUE制約)
- C外部キー制約
- ✓検査制約(CHECK制約)
解説
特定の列に許容される値の範囲や条件を列単位で強制するにはCHECK制約を用いる。主キー制約は一意性とNOT NULLを、外部キー制約は他表の値の参照整合性を保証するもので、値の範囲チェックには使えない。
根拠シラバス「データベース管理システムの特性」制約(検査制約)
トランザクションAが表Xをロックした後に表Yのロック取得待ちとなり、同時にトランザクションBが表Yをロックした後に表Xのロック取得待ちとなり、互いに相手の解放を待ち続ける状態が発生した。DBMSがこの状態を検出した際に一般的に行う対応はどれか。
- A両方のトランザクションを正常にコミットする
- ✓一方のトランザクションを選択して強制的にロールバックし、ロックを解放させる
- Cすべてのトランザクションの実行を無期限に停止する
- D表Xと表Yを自動的に1つの表に統合する
解説
これはデッドロックの状態であり、DBMSはデッドロック検出機構により関与するトランザクションの一方を犠牲者として選び強制的にロールバックしてロックを解放させ、もう一方の処理を継続させる。
根拠シラバス「データベース管理システムの特性」排他制御・デッドロック
あるB+木索引において、1,000,000行のデータに対し、索引の各ノードの分岐数(ファンアウト)が100であるとき、この索引は理論上何段(ルートからリーフまでの階層数)になるか。
- ✓3段
- B6段
- C2段
- D4段
解説
ファンアウトが100のB+木では、n段でアクセスできる行数はおよそ100のn乗である。100の3乗=1,000,000であるため、1,000,000行を格納するには理論上3段の索引で足りる計算になる。
根拠シラバス「データベース管理システムの特性」索引設計(B+木索引)
データベースの設計工程を、要件定義の後、概念設計・論理設計・物理設計の順に進める場合、「論理設計」の工程で行う作業として、直前の「概念設計」の成果物を最も適切に引き継いでいるものはどれか。
- A利用者へのヒアリングによる業務要件の洗い出し
- B格納するストレージ装置の選定とファイル配置の決定
- ✓E-R図で表現された概念データモデルを、正規化を行いながらリレーショナル表(テーブル定義)に変換する
- D索引やパーティションなど性能を考慮した物理的な格納構造の決定
解説
論理設計は、概念設計で作成したE-R図などの概念データモデルをもとに、正規化を行いながらDBMS上のテーブル定義(論理データモデル)へ変換する工程である。ストレージや索引の決定は後続の物理設計の作業である。
根拠シラバス「業務と役割」データベースの企画・要件定義・開発(概念設計・論理設計・物理設計)
関係を第1正規形から段階的に正規化する際、部分関数従属を解消する段階(第2正規形化)と、推移的関数従属を解消する段階(第3正規形化)の順序として正しいものはどれか。
- ✓部分関数従属の解消を先に行い、その後で推移的関数従属を解消する
- B推移的関数従属の解消を先に行い、その後で部分関数従属を解消する
- Cどちらを先に行っても最終的な結果の表構成は変わらないため順序は任意でよい
- D部分関数従属と推移的関数従属は同一の操作で同時にしか解消できない
解説
正規化は段階的に進めるものであり、まず複合主キーの一部にのみ従属する部分関数従属を解消して第2正規形にし、その後に非キー属性間の推移的関数従属を解消して第3正規形にするという順序が定義されている。
根拠シラバス「データモデリング技法」正規化(第1〜第3正規形)
リレーショナルデータベースにおける主キー制約とUNIQUE制約(一意性制約)の違いに関する記述のうち、適切なものはどれか。
- A主キー制約は1つの表に複数列に対して何個でも定義できるが、UNIQUE制約は1つの表に1つしか定義できない
- BUNIQUE制約は外部キーから参照できるが、主キー制約は外部キーから参照できない
- ✓主キー制約は1つの表に1つしか定義できずNULL値を許容しないが、UNIQUE制約は1つの表に複数定義でき、実装によってはNULL値を許容する
- D主キー制約とUNIQUE制約は完全に同じ機能であり、どちらを使っても違いはない
解説
主キー制約は表の中で行を一意に識別するための制約で、1つの表に1つだけ定義でき、暗黙にNOT NULLが課される。UNIQUE制約は値の重複を許さない点は共通だが、1つの表に複数定義でき、多くのDBMS実装ではNULL値の登録を許容する(NULL同士は重複とみなされない)。
根拠シラバス「データベース管理システムの特性」制約(主キー制約・一意性制約)
ある銀行システムで、口座Aから口座Bへの1万円の振替処理を行うトランザクションが、口座Aからの引き落とし処理を終えた直後、口座Bへの入金処理を行う前にシステム障害でトランザクションが中断した。再起動後のデータベースの状態として、トランザクションのACID特性のうち原子性(Atomicity)を満たすために正しい対応はどれか。
- A口座Aの引き落としだけを確定させ、口座Bへの入金は次回起動時に改めて行う
- B口座Bへの入金額を仮に計上し、口座Aの残高は変更しない
- ✓口座Aの引き落としと口座Bへの入金の両方を取り消し、振替前の状態に戻す
- D障害発生時点の状態をそのまま確定させ、管理者が手動で整合性を確認する
解説
原子性は、トランザクションに含まれる一連の処理が「すべて実行される」か「すべて実行されない」かのいずれかであることを保証する特性である。障害でトランザクションが未完了のまま中断した場合、DBMSはロールバックによって未完了の更新をすべて取り消し、振替前の状態に戻す。
根拠シラバス「期待する技術水準」データベース管理システムの特性(信頼性)・トランザクション管理(ACID特性・原子性)
DBMSがデッドロックを検出した場合の一般的な処理の流れとして、最も適切なものはどれか。
- Aすべての関係するトランザクションを即座にロールバックし、アプリケーションにエラーを返す
- Bデッドロックが解消されるまで、関係するすべてのトランザクションを一時停止し、タイムアウトを待つ
- Cデッドロックを検出した時点のログを取得し、システム管理者の手動判断でロールバック対象を決定する
- ✓デッドロックを構成するトランザクションのうち、ロールバックのコストが小さいものなど所定の基準で選んだ1つを犠牲者(victim)としてロールバックし、残りのトランザクションを続行させる
解説
デッドロックは循環待ちを解消しないと解決しないため、DBMSは待ちグラフなどでサイクルを検出し、あらかじめ定めた基準(ロールバックコストの小ささなど)で犠牲トランザクションを1つ選んでロールバックし、サイクルを断ち切る。他のトランザクションは通常継続される。
根拠シラバス「期待する技術水準」トランザクション管理・排他制御(ロック・デッドロック)
あるDBMSはWAL(Write-Ahead Logging)方式を採用している。更新トランザクションがコミットされ、クライアントにコミット完了の応答を返した直後にサーバの電源が断たれ、データファイルへの反映(フラッシュ)が完了していなかった。再起動後のDBMSの動作として適切なものはどれか。
- ✓コミット済みであることをクライアントに応答済みのため、ログに基づいてロールフォワード(redo)を行い、更新内容をデータファイルに反映する
- Bデータファイルへの反映が完了していないため、当該トランザクションの更新はすべて失われたものとして扱う
- Cコミット応答を返した時点でメモリ上のデータのみ正としてよく、ログとの整合は取らない
- Dログファイルが破損している可能性を考慮し、バックアップ取得時点まで全体をロールバックする
解説
WAL方式では、コミット時点でログがディスクに書き込まれていれば、たとえデータファイルへの反映(フラッシュ)が未完了でも、そのトランザクションはコミット済みとして扱われる。再起動時にはログを読み、コミット済みトランザクションの更新をロールフォワード(redoログの再実行)によってデータファイルに反映する。
根拠シラバス「期待する技術水準」データベース管理システムの特性(信頼性)・障害回復(WALログ・ロールフォワード)
メディア障害(ディスク破損)が発生した場合の一般的な復旧手順として、最も適切な順序はどれか。
- Aロールフォワード → バックアップからのリストア → ロールバック
- ✓バックアップからのリストア → ロールフォワード(ログによるredo) → 必要に応じてロールバック(未コミットトランザクションのundo)
- Cロールバック → バックアップからのリストア → ロールフォワード
- Dログの破棄 → バックアップからのリストア → 新規トランザクションの受付再開
解説
メディア障害では、まず最新のバックアップをリストアし、その後バックアップ取得以降のログを使ってロールフォワード(redo)を行い、コミット済みの更新を反映する。最後に、障害時点で未コミットだったトランザクションがあればロールバック(undo)して整合性を保つ。
根拠シラバス「期待する技術水準」障害回復(バックアップ・ロールフォワード・ロールバック)
ある大規模なテーブルに対する検索SQLの実行計画を確認したところ、WHERE句で絞り込み条件を指定しているにもかかわらずテーブルフルスキャンが選択されており、想定より処理時間が長くなっていた。原因調査の結果、対象列に索引は存在していたが、直近の大量データ更新後に統計情報が更新されていなかったことが判明した。このときまず行うべき対応として最も適切なものはどれか。
- ✓テーブルの統計情報を再取得(更新)し、オプティマイザが最新のデータ分布に基づいて実行計画を再評価できるようにする
- B対象列の索引を削除し、別の列に新しい索引を作成し直す
- CSQL文の結合順序をヒント句で強制的に固定し、統計情報の更新は行わない
- Dテーブル全体をトランケートし、データを入れ直す
解説
オプティマイザはテーブルの行数や列の値の分布などの統計情報を基にアクセスパス(索引を使うかフルスキャンにするか)を決定する。統計情報が古く実態と乖離していると、索引が存在していても不適切な実行計画が選ばれることがあるため、まず統計情報を更新して最新のデータ分布を反映させるのが適切な対応である。
根拠シラバス「期待する技術水準」性能設計・チューニング(オプティマイザ・統計情報・実行計画)
テーブルのパーティショニング方式である「レンジパーティショニング」と「ハッシュパーティショニング」の性質の違いを説明したものとして、適切なものはどれか。
- Aレンジパーティショニングはデータを均等に分散させることを目的とし、ハッシュパーティショニングは特定の値の範囲ごとに分割することを目的とする
- ✓レンジパーティショニングは列値の範囲(例: 日付の年月)でパーティションを分割するため特定期間のデータへのアクセスを1パーティションに限定しやすいが、ハッシュパーティショニングは値をハッシュ関数で分散するため範囲検索の絞り込みには向かない
- Cレンジパーティショニングとハッシュパーティショニングはいずれも索引を必要とせず、パーティション自体が索引の代替になる
- Dハッシュパーティショニングは日付列にのみ適用可能であり、レンジパーティショニングは数値列にのみ適用可能である
解説
レンジパーティショニングは列値の範囲(例えば年月日の期間)ごとにデータを分割するため、期間を指定した検索でアクセス対象パーティションを絞り込みやすい。一方ハッシュパーティショニングはハッシュ関数によって値を均等に分散させることを主目的とするため、データの偏り防止には向くが範囲検索の絞り込みには寄与しにくい。
根拠シラバス「期待する技術水準」性能設計・チューニング(パーティショニング)
あるシステムでは主系(プライマリ)から副系(スタンバイ)へ非同期レプリケーションでデータを転送している。主系で更新をコミットし、クライアントに応答した直後、副系への転送が完了する前に主系に障害が発生しフェールオーバーが行われた。このとき起こりうる事象として最も適切なものはどれか。
- ✓副系への転送が完了していなかった直近のコミット済み更新が、フェールオーバー後の副系には反映されておらず、データが失われる可能性がある
- B副系は主系のすべての更新を必ず保持しているため、データの欠落は発生しない
- C非同期レプリケーションでは常に主系と副系が同一トランザクション内で更新されるため、整合性は完全に保たれる
- Dフェールオーバー後は主系のデータが自動的に復元されるため、副系側の状態は無関係である
解説
非同期レプリケーションは、主系での更新確定(コミット)と副系への反映を切り離して行うため、性能面で有利な一方、主系がクライアントに応答した後で障害が起きると、副系にまだ転送されていない更新分がフェールオーバー後に失われる可能性がある。これは同期レプリケーションとの重要な違いである。
根拠シラバス「データベース技術の動向」分散データベース・レプリケーション(同期/非同期)