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

模範解答

解説

解答の論理構成

1. 検索要件の整理
   【問題文】には「複数の社員が,同じ会議室に対して重複する日時を指定して予約した場合は, 最も早く実行された予約を予約成功とし, その他は予約失敗とする。」とあります。したがって“空き会議室検索”は重複予約が１件も存在しない会議室のみを抽出する処理です。
2. サブクエリの役割
   図２の SQL は外側で

   SELECT * FROM 会議室 X

   を行い，内側で相関をとる形です。「対象会議室が重複予約を持たない」ことを保証するため，外側 WHERE 句では“既存予約が存在しない”ことを表す必要があります。つまり (a) は

   NOT EXISTS

   です。
3. 重複判定条件
   重複（オーバーラップ）は次の条件で判定できます。
   • 既存予約の開始時刻 < 希望終了時刻
   • 既存予約の終了時刻 > 希望開始時刻
     いずれか一方が等号の場合，同一コマ境界での「背中合わせ」を許可できます。本問では“30分単位”で区切られており背中合わせは問題ないため，厳密に

     <

     と

     >

     を採用します。よって (b) は

     <

     ，(c) は

     >

     となります。

誤りやすいポイント

• EXISTS

  と

  NOT EXISTS

  の選択を逆にし，空いていない会議室ばかり抽出してしまう。
• オーバーラップ条件を

  <=

  ・

  >=

  で書き，前後がぴったり接する予約まで除外してしまう。

• BETWEEN :hv2 AND :hv3

  を使い，重複判定を１条件で済ませようとしても正しく表現できない。

FAQ

NOT IN

NOT EXISTS

NOT IN

<=

>=

<

>

NOT EXISTS

模範解答

解説

解答の論理構成

1. 一意制約の確認
   • 【問題文】「会議室番号、予約日、予約開始時刻で会議室予約を一意に識別する。」
     → この３列が主キー（もしくは UNIQUE 制約）であると読み取れる。
2. INSERT 処理②の動作
   • 図3②の SQL は

     INSERT INTO 会議室予約
       (会議室番号, 予約日, 予約開始時刻, 予約終了時刻, 社員番号)
     VALUES(:hv4, :hv1, :hv2, :hv3, :hv5);
     

   • 既に同じ「会議室番号，予約日，予約開始時刻」の行が存在すると，主キー一意性が破られ DB が拒否。
3. ダブルブッキング抑止との関係
   • 条件①で重複チェックをしているが，同時実行で別トランザクションが先に INSERT すると②の直前チェックをすり抜ける可能性がある。
   • その場合でも一意制約が最後の砦となり，重複キーエラーで行が挿入できず予約失敗となるためダブルブッキングは防止される。
4. 以上より，「主キー重複（重複キー）による一意制約違反」が挿入失敗の直接原因である。

誤りやすいポイント

• 「予約終了時刻」まで含めて重複チェックされると誤解しやすい。実際の主キー列に含まれない。
• ロック待ちやデッドロックが原因だと思い込むケース。あくまで制約違反が直接要因。
• SELECT①が空なら必ず INSERT 成功と決めつけ，同時実行による race condition を見落とす。

FAQ

模範解答

解説

解答の論理構成

1. 図３①の動作
   「データ参照時には共有ロックをかけ, 参照終了時に解放する」とあるため、先行・後続の①は互いの予約行を見られず、“空き”と判断し得る。
2. 主キー衝突条件
   【表１】の「会議室番号, 予約日, 予約開始時刻で会議室予約を一意に識別する」により、開始時刻が同一なら②実行時に一意制約違反となり「×②」。
3. 時間帯の重複判定
   重複確認は①で行う。②以降は主キー衝突の有無のみ。よって
   • 11時00分〜12時00分 と 11時00分〜13時00分 → 主キー衝突 → (j)×・(k)②
   • 11時00分〜12時00分 と 11時30分〜13時00分 → 主キー不衝突 → 両者登録 → (l)△
   • 11時00分〜12時00分 と 9時00分〜11時00分 → 時間帯不重複、主キー不衝突 → (n)○
   • 11時00分〜12時00分 と 8時00分〜18時00分 → 主キー不衝突だが時間帯重複 → 両者登録 → (p)△
4. 単独実行時 (表２)
   A 成功後に
   • B, C, E は①で重複検知 → ×①
   • D は終了時刻＝A開始時刻で重複と見なさず → ○
5. 以上より【模範解答】が導ける。

誤りやすいポイント

• READ COMMITTED でも「共有ロックは参照終了時に解放」という一文を見落とし、①同士が競合すると誤解する。
• 「終了時刻＝他予約の開始時刻」を重複と勘違いし、D さんを失敗だと思い込む。
• 主キーが「開始時刻」であることを忘れ、11時30分開始の C さんと11時00分開始の A さんが同時登録できる事実を見落とす。
• “ダブルブッキング発生＝△”と“予約失敗＝×”を混同し、②でエラーになるケースを△と書いてしまう。

FAQ

予約済フラグ='Y'

模範解答

解説

解答の論理構成

1. 原文の結論部

   同じ会議室に対して,予約処理の実行が重なった時に,次の二つの条件が成立する場合にダブルブッキングが発生する。
   ・(r)が重なる。
   ・(s)が異なる。

2. 「重なる」対象は何か
   • 例では 「11時00分〜12時00分」 と 「11時30分〜13時00分」 など、開始・終了の組で示される“期間”が問題となっている。
   • 先行・後続でこの期間が重なった場合にだけ表２・表３で “△（ダブルブッキング発生）” が出現。
   • よって (r) は時間の「区間」＝「時間帯」。
3. 「異なる」対象は何か
   • 図３①の SELECT 条件は

     WHERE 会議室番号 = :hv4
       AND 予約日     = :hv1
       AND 予約開始時刻 (b) :hv3
       AND 予約終了時刻 (c) :hv2
     

     すなわち “予約開始時刻” と “予約終了時刻” を比較して重複チェックをする。
   • もし両者の 予約開始時刻 が同一なら行ロック競合により後続がブロックされるが、異なれば「READ COMMITTED＋共有ロック即解放」のため互いを検知できない。
   • 後続が INSERT を実行した時点で幻読が発生し、ダブルブッキングが確定する。
   • よって (s) は「予約開始時刻」。
4. 以上より
   • (r)=時間帯
   • (s)=予約開始時刻

誤りやすいポイント

• 「同じ時間帯なら必ず開始時刻も同じ」と思い込む。30分単位なので“11:00〜12:00”と“11:30〜13:00”のように開始時刻がズレても重複します。
• READ COMMITTED だから安全と勘違いし、幻読のリスクを見落とす。
• (s) に「予約終了時刻」を入れてしまう。終了時刻が同じでも開始時刻がズレていれば SELECT で漏れるケースがある点に注意。

FAQ

模範解答

解説

解答の論理構成

1. 図５の流れを確認
   • 「① 予約処理中フラグをUPDATE文で ‘Y’ に更新する」
   • 「② コミットする」
2. RDBMS のロック仕様
   • 「データ更新時には専有ロックをかけ, トランザクション終了時に解放する」
   • 「専有ロックがかかっている間、他のトランザクションからの対象行の参照, 更新は専有ロックの解放待ちとなる」
3. コミット省略時の影響
   • ②を実行しないとトランザクションが終了しない
   • よって①で更新した“日別予約管理”の行は専有ロック状態のまま
4. 同時アクセスが集中する条件
   • 設問が示す「同じ日に,同じ会議室に対して予約が集中」すると、多数のトランザクションが同じ行を読もうとする
5. 結果
   • 先行トランザクションがコミットするまで後続はロック待ち
   • CPU・I/O が遊んでしまいスループットが低下
6. よって処理番号は「①」、原因は「多数の専有ロックの解放待ちが発生する」となる。

誤りやすいポイント

• 「図５では②がコミットだから①が原因では？」と逆に考えてしまう
  → コミットを省く条件下では①がロック保持元になる点に注意。
• READ COMMITTED だから参照はブロックされないと思い込む
  → 専有ロック中は参照も待たされる仕様が明示されている。
• “日別予約管理”を読み取り専用だと誤認
  → 実際には①で更新しているためロックが掛かる。

FAQ

模範解答

解説

解答の論理構成

1. 図５①で

   予約処理中フラグ = 'N'

   を

   'Y'

   に変えられなかった場合は、同一キーが既に処理中であることを示す。
   【問題文引用】「①で予約処理中フラグを更新できておらず…」
2. その状態で図５③の検索結果に行が存在すると、希望時間帯へ既に別予約が入っている。
   【問題文引用】「③で結果行がある場合…予約失敗として⑧に進む。」
3. したがって④では「同じ会議室・同日・重複時間帯に既存予約がある」状況を想定し、速やかに⑧へ遷移して失敗を通知する。
4. この想定を20字以内で表すと「予約対象に予約が入っている状況」となる。

誤りやすいポイント

• “予約処理中フラグを更新できない”だけで⑧に進むと誤解する。③の検索結果も要確認。
• 「ダブルブッキング発生時」と書くと時間帯重複が確定していないケースを含み得るため不適切。
• ④のループ条件と⑧への即時遷移を混同し、リトライの有無を取り違える。

FAQ

UPDATE … AND 予約処理中フラグ = 'N'

'Y'

模範解答

解説

解答の論理構成

1. 図５①の更新
   

   UPDATE 日別予約管理 SET 予約処理中フラグ = 'Y'

   で対象行を占有。
2. 図５②でコミット
   ここで‘Y’が確定する。
3. 図５⑤〜⑦の途中エラー想定
   【問題文】「ディスク容量不足などのエラーが発生して, 予約処理のトランザクションが中断」と記載。
4. フラグ復旧漏れ
   エラーにより図５⑥の

   UPDATE … 'N'

   が実行されず，フラグは‘Y’のまま。
5. 影響
   後続予約は図５①の

   … 予約処理中フラグ = 'N'

   条件で更新不可となり，「その日付，その会議室」を誰も予約できない。

誤りやすいポイント

• トランザクションは②で一度コミット済みなので，後続ロールバックでは‘Y’を戻せない事実を見落とす。
• “会議室予約”テーブルの行ロックを考慮し，フラグ残留問題と混同する。
• “ディスク容量不足”＝ロールバックと決め付け，実際には途中で異常終了するシナリオを誤読する。

FAQ

模範解答

解説

解答の論理構成

1. 図7①のSQLを確認
   引用：「

   GROUP BY 会議室番号 HAVING (t) = PERIODCOUNT(:hv2, :hv3)

   」
2. 比較対象の右辺
   引用：「

   PERIODCOUNT 関数は, 開始時刻と終了時刻を与えて、含まれるコマ数を求める

   」
   右辺は「必要コマ数」。
3. 左辺で求めたい値
   予約可能な空きコマを抽出する

   WHERE … 予約済フラグ = 'N'

   で得られた「空きコマ行数」をカウントする必要がある。
4. 行数を返す適切な集計関数
   SQL標準で行数を返す関数は

   COUNT(*)

   のみ。
5. よって

   (t)

   は

   COUNT(*)

   と決定。

誤りやすいポイント

• SUM(予約済フラグ)

  など列を指定する集計関数を入れると、

  HAVING

  で数値比較できても「空きコマ数」には一致しません。

• COUNT(予約開始時刻)

  としても多くの場合動作しますが、空値が混入すると行数がずれるため安全策として

  COUNT(*)

  を選ぶ必要があります。

• HAVING

  は

  WHERE

  の後に集計結果を絞り込む節です。

  WHERE

  に

  COUNT(*)

  を入れると文法エラーになります。

FAQ

MAX

MIN

MAX

MIN

COUNT(1)

COUNT(*)

COUNT(*)

HAVING

WHERE

WHERE

HAVING

模範解答

解説

解答の論理構成

1. 図７①
   

   SELECT ... 予約済フラグ = 'N' ... HAVING (t) = PERIODCOUNT(:hv2, :hv3)

   で重複がないことを確認します。SELECT 終了時点で共有ロックは解放されます（〔RDBMS のトランザクション制御〕「データ参照時には共有ロックをかけ, 参照終了時に解放する。」）。
2. 図７②
   

   UPDATE ... SET 予約済フラグ = 'Y' ... WHERE ... 予約済フラグ = 'N'

   を対象コマ数分繰り返します。もし１回でも “更新行がなかった” 場合にロールバックし予約失敗になります（図７②）。
3. 競合シナリオ
   ①が終わり共有ロックが外れた隙に、別の予約処理が同一コマを

   予約済フラグ = 'Y'

   に変更すると、②の

   WHERE ... 予約済フラグ = 'N'

   条件に合致せず更新０件になります。
4. 結論
   「①の終了後、②の終了までの間に、他の予約処理が範囲内のコマに予約を入れた」ときに更新０件 → 予約失敗となります。

誤りやすいポイント

• READ COMMITTED では共有ロックはSELECT終了後すぐ外れる点を忘れ、ロックでブロックされると誤解する。
• ②は “全部の更新が成功したか” を見るループであり、１コマでも更新０件なら即ロールバックする仕様を見落とす。

• PERIODCOUNT

  や

  PERIODNEXT

  の処理ロジックに意識が向きすぎ、ロックタイミングの問題を見逃す。

FAQ