データベーススペシャリスト試験 2010年 午後1 問03

模範解答のキーワード・論点整理

• 追加すべき制約列：
  • 会員番号
  • 請求日
• 制約の種類：一意制約（UNIQUE制約）
• 制約の目的：同一会員の同一日に重複請求を防ぐ（一意性の保証）

解答になる理由

「請求登録処理を異常終了させた後、再実行したところ、請求番号を除き同じ内容の請求データ行が追加された。」

「RDBMSが請求番号に常に一意な番号を自動採番しているからであった。Fさんは、“請求”テーブルに制約を追加することによって解決しようとした。」

• 自動採番の主キー（請求番号）は重複せず、レコードは挿入される
• ビジネス的には、同一会員・同一日に同じ請求を二重に作成してはいけない

• 「同一会員（会員番号）・同一日（請求日）は一意でなければならない」
• これを実現するにはUNIQUE制約を (会員番号, 請求日) の組合せに追加

受験者が誤りやすいポイント

• 「請求番号」に対する制約追加を考える
  → すでに主キー・自動採番で一意。ここを制約しても重複防止にならない
• 他の列（明細数や入金日など）を含める
  → ビジネス要件と関係ない列は制約の目的を達成しない
• 制約目的の字数制限（15字以内）
  → 「重複登録防止」や「同一会員日に重複防止」など、簡潔に表現する

試験対策として覚えておくべきポイント

1. ビジネスルールは制約で担保
   • アプリケーションだけでなく、DB制約（主キー・一意制約・チェック制約など）で整合性を担保
2. 主キーとUNIQUE制約の違い
   • 主キーは「行の識別」
   • UNIQUE制約は「特定列の重複禁止（ビジネスルール）」
3. エラー検出タイミング
   • 制約違反はDBMSレベルで即検出→アプリの再実行ミスやバッチ重複を未然に防止
4. 字数制限の心得
   • 目的説明は15字以内など制限があるので、キーワードを押さえた短文で記述（例：一意性を保証）

キーワードと論点整理

• コアキーワード：「データ量の増加に影響されない」
• 論点：作業単位あたりのログ量を一定に保ち、スケーラビリティを確保すること

解答の理由

方法1：1作業単位の許容上限値を20%増加させる。
方法2：一定行数を削除するたびに同期点を取るように, 削除1を変更する。

受験者が誤りやすいポイント

• 「上限値を引き上げる＝問題解決」と考えがちですが、データ量が増えれば再度限界に達してしまう点を見落とさないこと。
• 「同期点を取る」の意味を「単にコミットを増やす」と誤解すると、なぜログ量抑制につながるかがわかりにくくなるため注意。

試験対策として覚えておくポイント

• 大量更新や大量削除で「1作業単位のログ量」が上限を超える問題は、小さな単位でコミット（同期点）を取ることで解決できる。
• 作業単位のログ許容量設定変更は応急的手段であり、データ増加を考慮すると抜本的な解決策にはならない。
• 問題文中の「1作業単位」「許容上限値」「同期点」の関係性を押さえておくと、類似問題での設問解答に役立つ。

1. 解答のキーワード・論点整理

… AND X.明細数 = (
    SELECT □a□
      FROM □b□ Z
     WHERE □c□
)

2. なぜこの解答になるのか

(a) 明細数を取得する集約関数

• 問題文より

  “請求” テーブルの明細数には処理日を設定し, …
  “請求明細” テーブルは,一つの請求番号に対して請求明細が平均2行存在する。
  とあり、請求 テーブルの 明細数 列は、「実際に 請求明細 テーブルにある行数」と対応させたいことが分かります。

• そのため、サブクエリでは該当請求番号の行数を取得する必要があり、
  • COUNT(*) …行数を直接カウント
  • MAX(請求明細番号) …請求明細番号は１から連番付番されるため、最大値 = 行数
    のどちらも利用可能です。

(b) 対象テーブル

• 行数を取得する対象は当然 請求明細 テーブルです。

(c) 親子テーブルの結合条件

• サブクエリの WHERE 句には、
  • Z.請求番号 = X.請求番号
  • あるいは Z.請求番号 = Y.請求番号
  • さらにバインド変数 :請求番号 を直接使う方法
    のいずれでも「同一請求番号の明細」を絞り込めれば正解となります。

3. 受験者が誤りやすいポイント

1. COUNT と SUM の混同
   「明細数」を出したいだけなので SUM(請求明細番号) は不可。
2. テーブル名のケアレスミス
   サブクエリ内を 請求 テーブルにすると無限ループ的に自分自身を参照してしまう。
3. 結合条件の抜け
   WHERE Z.請求番号 = :請求番号 とだけ書くと X.明細数 との比較で X との結び付きが曖昧になるケースがある。
4. MAX(請求明細番号) の理解不足
   明細番号を連番で採番していない場合は使えない手法だが、本問では「請求明細番号には請求番号ごとに1からの連番を付与する」との記述がある点がポイント。

4. 試験対策として覚えておくべきポイント

• 集約関数の使い分け
  • COUNT(*)：レコード数
  • MAX(連番キー)：連番の場合はレコード数
• サブクエリでの親テーブルとの結合
  WHERE Z.親テーブル主キー = X.主キー を忘れずに
• 業務テーブル設計
  「明細数カラム」を持つ場合は、実データと必ず同期させるチェックロジックが必要
• SQL の可読性
  サブクエリはなるべく COUNT(*)＋結合条件でシンプルに記述するのが安定

5. 解答例まとめ

キーワード・論点の整理

解答例がなぜ正しいのか

1. 【問題文】より

   「表1 変更後の請求一括削除処理の手順」
   1 全体オンライン IC を取得する。
   2 残すべき行を選択して抽出したファイルを作成する

   手順2で何らかの障害が起こると、残すべき行を確実に取り出せず、以降の手順（テーブルのクリア→ロード）が進められなくなります。
2. モデル解答のキーワード
   • ディスク障害でIC取得済データが失われる
   • 抽出ファイルが破損して読み込み不可
   • 抽出処理自体が行を選択し忘れる（ミス）
   これらはすべて「手順2の前に取得した全体オンラインIC」があれば、直前の状態に戻して再抽出できる典型例です。

受験者が誤りやすいポイント

• オンラインICとオフラインICの混同
  オンラインICは取得中も更新が可能なため、実行中のトランザクション状況を含めてバックアップできます。オフラインICでは参照のみしか許されません。
• 「ログからの回復」との混同
  ログ＋ICで回復できるのはRDBMS標準の回復手順であり、本問では手順2の失敗に対して即時に使えるバックアップとして「全体オンラインIC」を用意する点が論点です。

試験対策として覚えておくポイント

1. ICの種類
   • 全体IC：テーブル全ページ
   • 増分IC：最後の全体IC以降に変更されたすべてのページ
   • 差分IC：最後の差分IC以降に変更されたページ
2. 取得時の影響
   • オフラインIC：参照のみ
   • オンラインIC：更新を含めた全操作可能
3. バックアップ手順の設計
   • 大量削除など復旧ポイントを確保すべき直前に全体オンラインICを取得
   • 障害発生時に最小限の作業で再試行できるようにする
4. 問題文の手順と紐づけ
   • 表1 の手順1→2の流れを理解し、2での失敗を1のICでカバーする発想を持つことが重要です。

解説のポイント整理

1. 参照だけの場合（読取を禁止する範囲）
2. すべての操作（追加・参照・更新・削除）を禁止する範囲

表1（該当部分のみ抜粋）

アクセス停止の記述

このとき, ある手順からある手順の間, オンライントランザクションからの “請求” テーブルと “請求明細” テーブルへのアクセスを停止することにした。

参照だけの場合 : 手順（ア）の開始から手順（イ）の終了まで
すべての操作の場合 : 手順（ウ）の開始から手順（エ）の終了まで

解答の根拠

1. 参照だけの場合（ア→イ＝3→4）

• 手順3「全ページを空にする」では、テーブルが空になり、データが存在しない状態です。
• 手順4「ファイルからロード」中も、まだデータ投入が完了していないため、参照すると途中状態の不整合データが返る恐れがあります。
• よって、参照だけでも一切の読取を許さない必要がある範囲は、手順3の開始から手順4の終了までです。
  → （ア）＝3、（イ）＝4

2. すべての操作の場合（ウ→エ＝2→5）

• 手順2「抽出ファイル作成」後、手順3～4によってテーブルを一度クリアし、再構築します。
• この間に追加・更新・削除などの操作を許すと、抽出データや最終ロード後の状態と食い違いが発生します。
• また、手順5「全体オフラインIC取得」は、取得中は参照のみ可の状態であり、更新系操作は行えません。
• したがって、すべての操作を禁止すべき範囲は手順2開始から手順5終了までです。
  → （ウ）＝2、（エ）＝5

模範解答

受験者が誤りやすいポイント

• 「オンラインIC」「オフラインIC」の特性（オンラインは更新可、オフラインは参照のみ可）を混同しやすい。
• 参照禁止範囲は“テーブルをクリア”から“再ロード完了”までである点を押さえる。
• すべての操作禁止範囲にオフラインIC（手順5）も含む理由は、オフラインIC取得中に更新系操作が元々できないため、実質的に禁止範囲に含める。

試験対策メモ

• 大規模データ置換バッチでは、「空ページ再利用＋ログ出力抑制ロード」という手順が典型的。
• 空ページ化～再ロード中は、テーブルが不整合状態になるため必ずアクセス禁止範囲を設定。
• オンラインIC／オフラインICの違い：
  • オンラインIC：取得中も追加・参照・更新・削除可能
  • オフラインIC：取得中は参照のみ可能、更新系操作は不可
• アクセス停止の範囲設定では、処理手順の開始・終了タイミングを正確に把握すること。

模範解答のキーワードと論点整理

• 回復対象：表１の「変更後の請求一括削除処理の手順」
• 整合性のある状態：未コミットデータを含まず，オンライントランザクションを開始できる状態
• 利用可能なバックアップ：手順1〜4で取得・作成されたもの（ただし手順5の IC は利用不可）
• 回復方法の要件：表１や本文中の用語を用いて25字以内で記述

• 核心キーワード：手順4，ロード，ファイル

なぜ「手順4の後」の状態か

1. 回復可能な状態の条件
   本文より

   「整合性のある状態とは, 未コミット状態のデータが含まれず,かつ,オンライントランザクションを開始できる状態」

2. 各手順後の状態
   • 手順1後：テーブルは削除前の状態のまま。未コミットログも混在し，回復にログ適用が必要。
   • 手順2後：抽出ファイルのみ作成。DB上のテーブルはまだ従来データ。
   • 手順3後：テーブルをまっさらに空にしただけ。データはなく，未コミットも残らず整合性はあるが，必要なデータがない。
   • 手順4後：手順2で抽出した「残すべき行」をログを出さずにテーブルにロードし，「整合性のある」かつ「最新の必要データがロードされた」状態になる。
   • 手順5後：通常のオフライン IC を取得し，さらに整合性を確保するが，本問ではこの IC が利用不可。
3. 故障発生時に利用できる最新の「整合性のある状態」は
   → 手順4の後
4. 回復方法
   • 本文より

     「ロードコマンドによって, 大量のデータを INSERT文よりも効率よくテーブルに追加できる。ログを出力しないオプションを使った場合, ロード後のテーブルへのアクセスは, 参照だけが可能であり, 全体 IC を取得すれば, すべての操作が可能になる。」

   • 今回は手順5の IC を使わないため，手順2で作成したファイルを 手順4の方法 でテーブルにロードする。

受験者が誤りやすいポイント

• 「手順3後」を選ぶ誤り
  → テーブルは空になり未コミットもないが「必要なデータがない」状態であり，「整合性を維持した最新状態」ではない。
• 「手順5後」を選ぶ誤り
  → 本問では手順5の IC が利用不可とされており，回復に使えない。
• 回復方法の表現
  → 「ロードする」だけでは不十分。「手順2のファイルをテーブルにロードする」と 手順番号と対象を明示 する必要がある。

試験対策として覚えておくべきポイント

1. バックアップ／回復の基本
   • 全体 IC，差分 IC，増分 IC の違いと回復シナリオ
   • ログを用いたリカバリ方法の組合せ
2. オフライン IC とオンライン IC の性質
   • オンライン IC には未コミットデータが含まれる可能性がある
   • オフライン IC 取得中は参照のみ許可
3. ロード処理の特徴
   • ログ出力なしオプションでは高速ロード後は参照のみ可能
   • ログ出力あり／なしで回復・運用上の制約が異なる
4. 手順変更後の回復シナリオ
   • 手順ごとのテーブル・ログ状態を正確に把握して「整合性のある最終状態」を選択できることが重要です。

キーワード・論点整理

• 請求登録処理
  「当処理は, “請求” テーブルと“請求明細” テーブルに行を追加し, …“請求” テーブルの請求日と“会員” テーブルの最新請求日には処理日を設定し, “商品別請求” テーブルの請求額合計に請求明細行の請求額を加算する。」
• 請求取消処理
  「請求取消処理は,納品後に返品されたとき, “請求” テーブルの請求取消日に返品日を設定し, “請求明細” テーブルの返品フラグを 'N' から ‘Y'に更新する。また, “商品別請求” テーブルの請求額合計から返品対象の請求額を減算する。」

解答

• d（請求登録／請求）: C
• e（請求登録／請求明細）: C
• f（請求登録／会員）: U
• g（請求取消／請求）: U

解答の理由

1. d：請求登録処理の「“請求” テーブルに行を追加」

   当処理は, “請求” テーブルと“請求明細” テーブルに行を追加し, …

   追加(add)なので C（Create）。
2. e：請求登録処理の「“請求明細” テーブルに行を追加」

   当処理は, “請求” テーブルと“請求明細” テーブルに行を追加し, …

   こちらも追加(add)なので C（Create）。
3. f：請求登録処理の「“会員” テーブルの最新請求日に処理日を設定」

   … “‘会員’ テーブルの最新請求日には処理日を設定し, …”

   既存の行の値を変更(update)しているため U（Update）。
4. g：請求取消処理の「“請求” テーブルの請求取消日に返品日を設定」

   請求取消処理は… “‘請求’ テーブルの請求取消日に返品日を設定し, …”

   これも既存行の値を変更(update)しているため U（Update）。

受験者が誤りやすいポイント

• 追加と更新の混同
  「設定する」「加算する」の表現は一見「新しいデータを入れる」ように見えますが，あくまで既存行の属性値を変えているため Update です。
• 処理ごとの影響対象
  各処理がどのテーブルにどのように作用するか（追加・参照・更新・削除）を正確に読み取る必要があります。

試験対策：覚えておくべきポイント

• CRUD の意味
  C＝Create（挿入），R＝Read（参照），U＝Update（更新），D＝Delete（削除）
• バッチ／オンライン処理の概要から，テーブル操作の種類を正しく判別する
• 問題文の「～に行を追加／～に設定／～を削除」のキーワードで判断
• テーブルごとに同じ処理でも，操作内容が異なる場合がある点に注意すること

1. 解答の骨子──キーワードと論点整理

1. 各バッチ処理（請求登録，入金登録）がテーブルに与える「ページ変更量」のモデル化
2. 「増分IC」と「差分IC」の定義の違い
3. それぞれのバックアップを取得するタイミングにおける，変更ページの累積／差分の計算

2. 各テーブルに対する１グループ分の変更ページ率

• 「請求」は，請求登録で 25％ のINSERT，入金登録で同一行の 25％ UPDATE → 合計50％
• 「請求明細」は，INSERTのみで 25％
• 「会員」は，請求登録／入金登録それぞれで 25％ずつのUPDATE → 合計50％
• 「商品別請求」は，請求登録で 25％ のUPDATEのみ

3. 増分IC（図表中「増分IC」列）の計算

4. 差分IC（図表中「差分IC」列）の計算

5. 受験者が誤りやすいポイント

1. 「増分IC」と「差分IC」の用語混同
   • 問題文では「増分ICが全体IC以降のすべての変更」「差分ICが前回差分IC以降の変更」を定義しています。英語でDifferential／Incrementalが逆なので要注意です。
2. ページ変更率と行数変更率の混同
   • 明細テーブルは「行数が50％増」でも「ページ変更率は25％」という点。１ページあたり複数行格納を想定します。
3. 登録処理と入金処理の変更対象テーブルの違い
   • 請求明細や商品別請求は入金処理では変わらないため，変更量ゼロになります。

6. 試験対策ポイント

• バックアップ方式の違い：全体（Full），増分（Differential），差分（Incremental）の定義を正確に理解する
• 年間や月間のバッチ処理回数と，各テーブルのCRUD操作が「いつ何％のデータを変えるか」を数値モデル化する
• 行数変化率→ページ変更率への換算（ページあたり複数行格納）
• バックアップタイミングごとの「累積／差分」の計算方法