データベーススペシャリスト 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. 図4 の該当箇所は「AND X.明細数 = ( SELECT (a) FROM (b) Z WHERE (c) )」です。X.明細数は、その請求に含まれる請求明細の数です。返品された明細も請求明細として残っているので、明細数は返品を含む明細の数になります。この副問い合わせは、請求明細の行が明細数どおりにそろっているか（請求一括削除処理などで明細が一部だけ削除されていないか）を確認するためのものです。したがって、副問い合わせは返品の有無に関係なく、その請求の請求明細の行数を返す必要があります。
2. (b) は、明細の行をもつ「請求明細」です。
3. (c) は、対象の請求の明細だけに絞る条件です。外側では「X.請求番号 = :請求番号」「X.請求番号 = Y.請求番号」と指定しているので、副問い合わせでは次のいずれかで請求を特定できます。
   • X.請求番号=Z.請求番号
   • Y.請求番号=Z.請求番号
   • Z.請求番号=:請求番号
     返品フラグの条件は入れません。外側の「Y.返品フラグ <> 'Y'」は合計金額を計算する明細を絞る条件であり、明細数と比較する行数を絞る条件ではないからです。副問い合わせに返品フラグの条件を入れると、返品がある請求では行数が明細数より少なくなり、常に不一致になってしまいます。
4. (a) は行数を返す集約です。COUNT(*) のほか、請求明細番号が請求ごとに1から連番で付けられているので、MAX(請求明細番号) でも明細数と比較できます（解答例も両方を挙げています）。
5. 以上から空欄に入る字句は次のとおりです。

誤りやすいポイント

• 外側の「Y.返品フラグ <> 'Y'」につられて、副問い合わせにも返品フラグの条件を入れてしまう。明細数は返品を含む明細の数なので、返品があると一致しなくなります。
• (b) に「請求」を入れてしまう。数えるのは明細の行です。
• 問題文にあるトランザクション分離レベルの変更（READ UNCOMMITTED）による不整合発生の理由は「ダーティリード（未コミットデータの読取）」であり、図のオンラインICの説明等とは別概念です。オンラインICの記述を根拠にしないよう注意してください。

FAQ

解答の論理構成

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. 利用できるバックアップ等の一覧（本文から）

• 手順1で「全体オンラインIC」を取得しているが、本文にある通り「オンラインICの取得中は、ほかの利用者からのアクセスはすべての操作 (追加、参照、更新、削除)が可能であり、ICには未コミット状態のデータが含まれることがある」。つまり手順1のICは未コミットデータを含む可能性があり、それだけでは整合性（未コミットを含まない状態）を保証しないことに注意します。
• 手順2で「残すべき行を選択して抽出したファイルを作成する（作成したファイルは、1か月間保存する）」。さらに本文で「オンライントランザクションからの“請求” テーブルと “請求明細” テーブルへのアクセスを停止することにした。」とあるので、手順2の抽出はオンライントランザクションが停止された状態で行われ、抽出ファイルには未コミットデータが含まれないと考えられます。
• 手順3は「テーブルと索引を格納した全ページを空にする（削除された行と索引のログは出力されず）」であり、ログが出力されないためこの操作自体はログで復元できません。
• 手順4は「ログを出力しないオプションによって手順2のファイルをテーブルにロードする。」本文の説明では「ログを出力しないオプションを使った場合、ロード後のテーブルへのアクセスは、参照だけが可能であり、全体ICを取得すれば、すべての操作が可能になる。」とあります。したがって手順4の直後の状態は、手順2で作ったコミット済みデータがテーブルに反映され、参照は可能だが書き込みは不可、という特徴を持ちます。
• 手順5は「全体オフラインICを取得する」。オフラインICは整合性のある（未コミットを含まない）バックアップになりますが、今回は手順5のICが利用できないという条件です。

1. 各候補状態の評価（「整合性のある状態」の定義：未コミットが含まれないこと、かつオンライントランザクションを開始できること）

• 手順5の後：本来は最も新しい整合状態だが、手順5のICが利用不可なので選べない。
• 手順4の後：手順2で抽出されたコミット済みデータがテーブルにロードされているため未コミットデータは含まれない。また本文の説明どおりロード直後は参照が可能であるため、少なくとも参照を行うオンライントランザクションは開始できる（設問が求める「オンライントランザクションを開始できる状態」は参照トランザクションの開始を含むと解すれば条件を満たす）。手順5が取れれば書き込みも可能になるが、今回は手順5が使えないため書き込みはできない点に注意します。
• 手順3の後：ページが空になっており未コミットデータは含まれないしオンライントランザクションは開始できるが、手順4の後より時点としては古く、障害直前により近い状態ではない。
• 手順2の後（抽出ファイルのみ存在する状態）：抽出ファイル自体は整合だが、抽出を適用した実際のテーブル状態（手順4相当）よりは古い。
• 手順1の後（全体オンラインIC）：オンラインICは未コミットを含む可能性があるため整合性の条件を満たすとは限らない。

誤りやすいポイント

• 手順1の全体オンラインICは「全体」だから安全だと誤認する。本文にあるように「オンラインIC」には未コミットデータが含まれることがあるため、整合性を保証しない点を見落としやすいです。
• 手順2の抽出ファイルが自動的に未コミットを含まないと考える誤り。抽出が整合であることは「オンライントランザクションへのアクセスを停止する」という運用措置があるためであり、単に抽出を行った事実だけでは保証できません。
• 手順4の「ログを出力しないオプション」によるロード後を完全に通常の読み書き可能状態と混同する誤り。ロード直後は「参照だけが可能」であり、書き込み可能とするには全体ICの取得が必要です。
• 手順3の「ログが出力されない」操作はログで取り消したり再現したりできないため、ログのみで回復しようとする誤り。

FAQ

解答の導き方

• 根拠（問題文）：「“請求” テーブルと“請求明細”テーブルに行を追加し」
• 考え方：ここで明示されている操作は「行を追加」つまり INSERT（新規行作成）です。CRUD のうち Create を表す「C」が対応します。
• 他の選択肢の除外：参照（R）ではなく書き込み、更新（U）は既存行の変更を意味するため該当せず、削除（D）でもありません。
• 結論：(d) = C

• 根拠（問題文）：「“請求” テーブルと“請求明細”テーブルに行を追加し」
• 考え方：請求明細にも新しい明細行を追加する処理であるためCreate（C）が必須です。
• 結論：(e) = C

• 根拠（問題文）：「“請求” テーブルの請求日と“会員” テーブルの最新請求日には処理日を設定し」
• 考え方：「設定する」は既存の会員レコードの列を更新する操作を指します。新規会員の作成を記述していないためCreateではなくUpdate（U）が適切です。さらに別処理の入金登録でも「“会員” テーブルの最新入金日を設定する」とある点も更新操作であることを裏付けます。
• 結論：(f) = U

• 根拠（問題文）：「“請求” テーブルの請求取消日に返品日を設定し、“請求明細” テーブルの返品フラグを 'N' から ‘Y'に更新する」
• 考え方：請求取消は行を削除するのではなく、請求取消日や返品フラグを変更する「更新」処理です。よってUpdate（U）が適切です。
• 結論：(g) = U

誤りやすいポイント

• 「追加（行を追加）」と「更新（既存行の列を設定・変更）」の区別を見落とすと誤答しやすい。本文の「行を追加し」「〜を設定し／更新する」の語に注目すること。
• 「取消」や「返品」といった語に惑わされて即座に削除（D）と判断しがちだが、実際はフラグ設定や日付設定の更新（U）の場合がある。
• 複数テーブルが登場する処理では、どのテーブルにどの操作が行われるかを正確に紐づけないと誤答する。処理文の主語（どのテーブルに対して）を必ず確認する。
• 「必須かつ欠かせないもの」を問う設問であるため、副次的に行われうる操作（たとえばログ出力や索引の再作成など）に引きずられて主要操作を見落とさないこと。

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ