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

解答の論理構成

1. 事象の確認
   • 【問題文】「問題 A … 請求番号を除き、同じ内容の請求データ行が追加された」
   • 自動採番の「請求番号」は常に新値なので重複検知に役立たない。
2. 重複判定に使う業務項目の抽出
   • 請求登録処理は「毎月1回、バッチ処理で行う」
   • 同一会員に対して同一請求日で2行以上存在するのは業務上不正。
   • よって重複判定列は「会員番号」「請求日」。
3. 制約の種類と目的
   • 複数列の UNIQUE 制約 を追加し「一意性を保証するため」。
   • これにより再実行時は一意性違反エラーでロールバックできる。

誤りやすいポイント

• 「請求番号」は既に主キーなので追加制約対象ではない。
• 「明細数」や「入金日」を含める必要はない。請求発生タイミングの一意性は「会員番号＋請求日」で十分。
• NOT NULL など列制約と混同しがちだが、本設問は複合 UNIQUE 制約を問うもの。

FAQ

解答の論理構成

1. 原因の確認
   〈問題 B〉で失敗理由は「回復用に取得するログの量が1作業単位の許容上限値を超えた」と明示されています。
2. 方法1の特徴
   〈検討 B〉「方法1：1作業単位の許容上限値を20%増加させる」。閾値を広げるだけなので、データ量が再度増えれば同じ問題が再発します。
3. 方法2の特徴
   同じく〈検討 B〉「方法2：一定行数を削除するたびに同期点を取る」。同期点ごとにログ量が確定・クリアされるため、削除対象が増えても“1作業単位”あたりのログ量は固定化されます。
4. 比較結果
   データ量が将来増加しても方法2なら「許容上限値を超えない」＝データ量の増加に影響されないため、Fさんは方法2を選択しました。

誤りやすいポイント

• 「20%増加させる」と聞くと十分だと誤解しやすいが、年率20%以上のデータ増加とピーク1.2倍を考慮すると追いつかない。
• 同期点の目的を「途中経過保存」だけと捉え、ログ量リセット効果を見落としやすい。
• 回復ログとアーカイブログを混同し、容量問題の本質を捉え損なうケース。

FAQ

解答の論理構成

1. 【問題文】より「請求番号には、一意な連番を付与する」「請求明細番号には、請求番号ごとに1からの連番を付与する」。
2. よって同一請求番号内では

   (請求明細番号)

   の最大値がそのまま明細数と一致する。
   • 行数を直接数えるなら

     COUNT(*)

     、連番最大値を利用するなら

     MAX(請求明細番号)

     が妥当。
3. サブクエリは “請求明細” だけを対象とし、別名

   Z

   を付ける指定が (b)。
4. 親問い合わせの行とサブクエリの行を関連付ける検索条件 (c) は「請求番号 = 同一値」であることが必須。
5. 以上より

AND X.明細数 = (
  SELECT COUNT(*)
  FROM   請求明細 Z
  WHERE  X.請求番号 = Z.請求番号
)

COUNT(*)

MAX(請求明細番号)

誤りやすいポイント

• COUNT(請求明細番号)

  とすると

  NULL

  を除外するため、列が

  NOT NULL

  でない場合に誤差が出る。問題文には

  NULL

  にならない保証がないので

  COUNT(*)

  が無難。
• サブクエリに親問い合わせのエイリアスを参照し忘れ、全件集計になってしまう。
• 連番仕様を読み落として「MAX(請求明細番号) は行数と一致しない」と誤判断する。

FAQ

COUNT(*)

COUNT(請求明細番号)

COUNT(*)

COUNT(列名)

NULL

NULL

READ UNCOMMITTED

MAX(請求明細番号)

(請求番号、請求明細番号)

MAX

解答の論理構成

1. 【問題文】で、手順1は「全体オンライン IC を取得する。」と明示。
2. 手順2〜手順4では
   • 「残すべき行を選択して抽出したファイルを作成」
   • 「テーブルと索引を格納した全ページを空にする」
   • 「ログを出力しないオプションによってロード」
     と、既存ページの物理削除とノーログロードを実施。
3. これらの最中に
   • 「ディスク障害」が発生
   • 抽出「ファイルが破損」
   • 抽出条件ミスで「残すべき行を選択しなかった」
     などが起きると、テーブルを正常状態へ戻す術がなくなる。
4. そこで処理着手前に「全体 IC」を取得し、障害時は
   • 「全体IC と全体IC 取得後のすべてのログ」を使い
   • 【問題文】2.テーブルの回復 に従ってリカバリ可能。
5. 以上より、手順1の全体オンライン IC は「手順 2 の最中にディスク障害が発生した場合」などの障害に備えるために必要であると結論付く。

誤りやすいポイント

• 手順5の「全体オフライン IC」があるから十分と考え、手順1を軽視する。→手順5は処理完了後のバックアップであり進行中障害には使えない。
• 「ログを出力しないロードでもログが回復に使える」と誤解。→ノーログオプション使用時はロード自体のログが残らないため、直前ICが不可欠。
• オンラインICには「未コミットデータが含まれることがある」点を忘れて、ロールフォワードの必要性を見落とす。

FAQ

解答の論理構成

1. 手順ごとの性質を整理
   • 手順「2」：残す行を抽出するため整合性が必須。途中で更新が走ると抽出結果と実データが食い違う。
   • 手順「3」：ページを空にし「削除された行と索引のログは出力されず、空になったページは再利用される」。ここでデータは一時的に消える。
   • 手順「4」：ログを出力しないロードを行い、「ロード後のテーブルへのアクセスは、参照だけが可能であり、全体 IC を取得すれば、すべての操作が可能になる」。
   • 手順「5」：全体オフライン IC を取得し終えると更新系も許可できる。
2. 更新禁止（＝すべての操作禁止）の範囲決定
   抽出結果と実データの乖離を防ぐため、更新は手順「2」の開始から手順「5」の終了まで止める。
3. 参照も禁止する範囲決定
   ページが空になるタイミング以降はSELECT でもエラーになるため、参照停止は手順「3」開始から手順「4」終了までとする。
4. 以上より
   • （ア）＝3, （イ）＝4
   • （ウ）＝2, （エ）＝5

誤りやすいポイント

• ロード直後に「参照だけ」は許可される点を見落とし、参照停止範囲を手順「5」まで延ばしてしまう。
• 手順「2」はSELECT だけだから更新許可と早合点し、更新停止範囲を手順「3」からにしてしまう。
• オンライン／オフライン IC の違いを取り違え、手順「1」のオンライン IC 中も更新禁止と誤解する。

FAQ

解答の論理構成

1. 手順 5 の IC が失われた前提
   「全体オフライン IC を取得する。」（手順 5）が利用不能。
2. 直前状態の候補を整理
   • 手順 3：テーブル＆索引が空。ビジネスデータを含まないので不適。
   • 手順 4：手順 2 の抽出ファイルをロード済。
   • 手順 5 以降：存在しない。
3. 手順 4 が整合性を満たす理由
   • データは「残すべき行を選択して抽出したファイル」（手順 2）由来で未コミットを含まない。
   • 「ロードコマンド…ログを出力しないオプションを使った場合、ロード後のテーブルへのアクセスは、参照だけが可能」であり、読み取り系オンライントランザクションは開始できる。
   • 回復方法としては再度「手順 2 のファイルをテーブルにロードする。」だけで手順 4 の状態を再現できる。
4. 以上から回復対象は「手順番号 4 の後」、方法は「手順 2 のファイルをテーブルにロードする。」となる。

誤りやすいポイント

• 手順 5 の IC がないのにロールフォワードを試みてしまう。
• 「参照だけが可能」を整合性要件外と誤解し、手順 4 の後を排除する。
• 抽出ファイルは「1か月間保存する」と明記されている点を見落とし、利用可能なバックアップと気付かない。

FAQ

解答の論理構成

1. “請求登録処理” の処理内容を確認
   • 【問題文】
     “当処理は、“請求” テーブルと“請求明細” テーブルに行を追加し … “請求” テーブルの請求日と“会員” テーブルの最新請求日には処理日を設定”
   • 追加＝C、列値の書き換え＝U と判断
     • “請求” テーブル：行追加 → C ⇒ (d)
     • “請求明細” テーブル：行追加 → C ⇒ (e)
     • “会員” テーブル：列の更新 → U ⇒ (f)
2. “請求取消処理” の処理内容を確認
   • 【問題文】
     ““請求” テーブルの請求取消日に返品日を設定し … “請求明細” テーブルの返品フラグを 'N' から ‘Y'に更新”
   • 既存行の列更新のみなので U
     • “請求” テーブル：列更新 → U ⇒ (g)
3. 削除や読取の有無を再確認
   • “請求登録処理” で削除は行われておらず Read の必須操作も記載なし
   • “請求取消処理” でも削除・追加は発生しない
   • よって CRUD のうち必要不可欠なのは上記 C/U のみ

誤りやすいポイント

• “請求” テーブルは登録処理で列を設定するので U と誤認しやすい
  → 行自体は新規追加なので C が優先
• “請求取消処理” を D（Delete）と勘違い
  → 実際は列の書き換えのみで行は残る
• CRUD を複数回答と考えてしまう
  → 表の指示は “最も適切で欠かせないものを一つ”

FAQ

解答の論理構成

1. テーブルごとの１回当たりの変更率
   • “請求明細”
     「請求登録処理…行を追加」だけで更新や削除はなし。25%×１＝25%。
   • “請求”
     「行を追加」25% と「入金登録処理…入金日を設定」25% が同日に発生し最大50%。
   • “会員”
     最新請求日と最新入金日を更新するだけ。１回当たり 25%＋25%＝50%。
   • “商品別請求”
     売れる商品は月平均 25% ⇒ 更新対象 25%。
2. 差分 IC（前回差分以降の変更ページ）
   各回とも上記の変更率がそのまま容量比になる。
   • １回目：請求 50 → h＝50
   • ２回目：会員 50 → k＝50，商品別請求 25 → m＝25
     （“請求”と“請求明細”は既に値が与えられているため空欄）
   • ３・４回目も同様の比率なので設問対象外。
3. 増分 IC（全体 IC 以降の累積変更ページ）
   変更率を回数分累積し、選択肢に合わせて四捨五入する。
   • “請求”
     １回目 50%、２回目 100% → i＝100，４回目 200% → j＝200
   • “会員”
     １回目 50%、２回目以降は同一行の再更新で累積が伸びず 100% → l＝100
   • “商品別請求”
     毎回同じ 25% の商品コードが更新される想定なので累積は 25% のまま → n＝25，o＝25
4. 選択肢との照合
   求めた各値はいずれも 25 の倍数で、提示された８つの選択肢の中に唯一一致する。

誤りやすいポイント

• 増分 IC と差分 IC の定義を逆に覚えてしまい、累積／非累積を取り違える。
• “請求”テーブルの 50% を「25% だけ」と数え，INSERT と UPDATE を合算し忘れる。
• “会員”テーブルの累積率を 4 回で 200% と誤算し、行の再更新による重複を考慮しない。
• “商品別請求”は毎回同じ商品を更新する可能性が高い点を見落とし、累積が増えると誤判断する。

FAQ