戦国IT - 情報処理技術者試験の過去問対策サイト
お知らせお問い合わせ料金プラン

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

テーブルの設計及び SQL の設計に関する次の記述を読んで、設問1〜3に答えよ。

　健康食品をインターネット販売している E 社は、受注管理システムを開発することになり、Fさんがデータベースの設計を任された。 　
〔受注管理システムの要求仕様〕 1．商品 　(1) 商品は、単品商品と詰合せセット商品 (以下、セット商品という)に区分する。商品には、一意な商品番号を付与する。 　(2) セット商品には、一つの化粧箱に複数個の単品商品を詰め合わせたものと、複数種類の単品商品を詰め合わせたものがある。 単品商品は、複数種類のセット商品に含まれる。 セット商品を構成する単品商品ごとの数量 (構成数)は、決まっている。
2．注文 　(1) 顧客は、1回の注文 (以下、注文単位という)で、一つ以上の単品商品と一つ以上のセット商品を組み合わせて注文できる。 注文単位には、注文全体で一意な注文番号を付与する。 　(2) 顧客は、インターネットから商品一覧照会処理を呼び出し、商品番号、商品名、商品説明、写真、販売単価を商品一覧画面に表示させる。 表示される順番は、商品全体で重複がないように、商品企画担当者が決めた表示順に基づく。 　(3) 顧客は、表示画面から全ての購入希望の商品を検索して商品ごとの注文数を入力した後、注文処理を呼び出す。 　(4) 注文処理は、顧客が注文した商品を在庫から引き当て、注文番号、注文日 商品番号、商品名、販売単価、注文数、注文額合計及びお届け予定日の日付 ( 注文日の3日後)を確認画面に表示する。 セット商品が不足した場合、そのセット商品に必要な数の単品商品を在庫から引き当てる。 確認画面のお届け予定日には、通常のお届け予定日に単品商品を化粧箱に詰め合わせるのに必要な日数を加える。 単品商品が不足することはない。 　(5) 顧客は、注文内容を確認し、商品の送付先住所、顧客名、連絡先電話番号及び支払に必要な情報を入力し、注文を確定する。 　
〔テーブルの設計〕　 　Fさんが設計した関係 “商品” 及び “在庫” の関係スキーマを、図1に示す。
データベーススペシャリスト試験（平成26年 午後1 問3 図1）
　Fさんは、関係“商品” のテーブルの設計に当たり、次の二つの案を考えた。 　　案1 サブタイプをスーパタイプに統合し、一つの“商品” テーブルとする。 　　案2 サブタイプ別に “単品商品” テーブル及び “セット商品” テーブルとする。 　案1の“商品” テーブルの構造を図2に 案2の“単品商品” テーブル及び“セット商品” テーブルの構造を図3に示す。
データベーススペシャリスト試験（平成26年 午後1 問3 図2）
データベーススペシャリスト試験（平成26年 午後1 問3 図3）
　Fさんは、関係 “在庫” については、一つの“在庫” テーブルを設計した。 “在庫” テーブルと、その他の主なテーブルの構造を、図4に示す。図4のテーブルは、全て案12に共通とする。 また、主な列の意味を表1に示す。 　 データベーススペシャリスト試験（平成26年 午後1 問3 図4）
データベーススペシャリスト試験（平成26年 午後1 問3 表1）
　Fさんが案1の“商品” テーブルに定義した制約を表2に、案2の“単品商品”テーブル及び“セット商品” テーブルに定義した制約を表3に示す。 　受注管理システムに採用する予定の RDBMS の UNIQUE 制約は、ユニーク索引を用いて実現される。 ユニーク索引は、一つのテーブル内でキー列の一意性を保証するものであり、ユニーク索引を複数のテーブルにまたがって作成することはできない。
データベーススペシャリスト試験（平成26年 午後1 問3 表2）
データベーススペシャリスト試験（平成26年 午後1 問3 表3）
　表2に示した案1 での NOT NULL 制約は不十分なので,F さんは、図5に示すように案の“商品” テーブルに検査制約を追加した。 検査制約は、次の①〜⑥のいずれかの述語を組み合わせて指定する。 　① 社内原価 IS NOT NULL 　② 社内原価 IS NULL 　③ 化粧箱番号 IS NOT NULL 　④ 化粧箱番号 IS NULL 　⑤ 詰合せ日数 IS NOT NULL 　⑥ 詰合せ日数 IS NULL
データベーススペシャリスト試験（平成26年 午後1 問3 図5）　
〔SQL文の設計〕 　Fさんが、案1 と案2のそれぞれについて設計した主な SQL文を表4 に示す。
データベーススペシャリスト試験（平成26年 午後1 問3 表4）
〔注文トランザクションの設計〕 　Fさんは、注文トランザクションについて、次のように設計した。
(1) 注文単位を一つのトランザクションで処理し、最後に COMMIT 文を発行する。 (2) 注文に基づいて、“注文” テーブル及び “注文明細” テーブルに行を挿入する。 (3) 商品については、商品一覧画面に表示された順番に“在庫” テーブルの引当可能数を調べ、引当可能ならば注文数を減算した値で引当可能数を更新する。 (4) セット商品が在庫不足のとき、“在庫” テーブルの不足セット商品数に不足数を加算する。“セット商品構成” テーブルから、主キー順に当該セット商品を構成する単品商品の構成数を調べ、必要数を計算する。 単品商品については、“在庫” テーブルの引当可能数には必要数を減算した値で、不足セット商品用引当済数には必要数を加算した値で更新する。 (5) トランザクションの ISOLATION レベルは、READ COMMITTED とする。

設問1：〔テーブルの設計〕について、(1)〜(4)に答えよ。

（1）表2 中の(a)に入れる適切な字句を答えよ。また,UNIQUE 制約を定義する目的を、要求仕様に関する本文中の字句を用いて30字以内で述べよ。

模範解答

a：表示順 目的：商品全体で重複がないように商品の表示順を決めるため、商品の表示順を商品全体で一意にするため

解説

解答の論理構成

  1. 要求仕様の確認
    【問題文】「表示される順番は、商品全体で重複がないように、商品企画担当者が決めた表示順に基づく。」
    ─ 表示順が重複しないことが業務要件。
  2. UNIQUE 制約の候補列
    ・商品番号 … 主キーで既に一意
    ・表示順 … 一意性が求められている
    ・その他の列 … 重複禁止の要件なし
    ⇒ UNIQUE を付けるべき列は 表示順。
  3. 目的文の作成
    要件文のキーワード「商品全体で重複がないように」を活用し、30 字以内で
    「商品全体で重複がない表示順を保証するため」
    とまとめる。

誤りやすいポイント

  • 表示順を「ORDER BY 用」とだけ捉え、UNIQUE の必要性を見落とす。
  • 「商品名」などに UNIQUE を付けると、同一名の別商品が登録できず要件違反。
  • UNIQUE 制約はテーブル間をまたげないため、案2でも単品・セット各テーブルに個別定義が必要である点を失念しやすい。

FAQ

Q: 表示順を主キーに含めれば良いのでは？
A: 主キーは業務的に一意で変化しない列（ここでは商品番号）で構成するのが原則。表示順は変更される可能性があるため主キーには適さず、UNIQUE 制約で十分です。
Q: 案2では単品商品とセット商品で表示順が重複しそうですが？
A: UNIQUE 索引はテーブル単位なので、案2では両テーブルに同名の UNIQUE 制約を置き、アプリケーション側で重複を避ける運用にする必要があります。
Q: NOT NULL を追加すれば一意性は保証できますか？
A: いいえ。NOT NULL は NULL 禁止であり重複自体を防ぐものではありません。一意性の保証には必ず UNIQUE か PRIMARY KEY が必要です。
関連キーワード: UNIQUE制約、一意性、表示順序、主キー、インデックス

設問1：〔テーブルの設計〕について、(1)〜(4)に答えよ。

（2）表3 中のテーブルについては、UNIQUE 制約を定義し、ユニーク索引を作成しただけでは、(a)に関する要求仕様を満たせない。その理由を、本文中の字句を用いて40字以内で述べよ。

模範解答

・ユニーク索引は一つのテーブル内でキー列の一意性を保証するため ・ユニーク索引を複数のテーブルにまたがって定義することはできないため

解説

解答の論理構成

  1. 要求仕様
    「商品全体で重複がないように、商品企画担当者が決めた表示順」と明記。
  2. テーブル分割
    案2では“単品商品”と“セット商品”という２テーブルに「表示順」列を持たせ、両テーブルに UNIQUE 制約を設定。
  3. RDBMS の制限
    【問題文】引用
    「ユニーク索引は、一つのテーブル内でキー列の一意性を保証するものであり、ユニーク索引を複数のテーブルにまたがって作成することはできない。」
  4. 帰結
    異なるテーブル間の「表示順」重複は検出できず、要求仕様を満たさない。
    よってユニーク索引だけでは不足と導かれる。

誤りやすいポイント

  • 「同名列に UNIQUE を貼れば全体で一意」と誤解する。
  • ビューやトリガでの補完を忘れ、制約レベルで解決すべき場面を見落とす。
  • “商品”テーブルを単一化する案1との混同で制約範囲を誤認する。

FAQ

Q: ビューに UNIQUE を付与すれば解決できますか？
A: 一般的な RDBMS ではビューには索引や制約を直接設定できません。トリガなど別手段が必要です。
Q: 他にどんな方法で重複を防げますか？
A: １テーブルに統合（案1）、複合キーを使うCHECK制約、挿入用トリガでの検査などが考えられます。
Q: 表示順にギャップがあると問題ですか？
A: ギャップ自体は問題ありません。重複しないことだけが必須条件です。
関連キーワード: ユニーク索引、一意性制約、CHECK制約、データ整合性

設問1：〔テーブルの設計〕について、(1)〜(4)に答えよ。

（3）次の表に示すように外部キーを定義したとすれば、“セット商品構成” テーブルについては案1の場合に、“在庫” テーブルについては案2の場合に、不都合が起きるおそれがある。 項番 2,3の （ア）、（イ）に入れる不都合の内容を、項番1に倣って,35字以内で述べよ。 データベーススペシャリスト試験（平成26年 午後1 問3 設問1-3）

模範解答

ア：・単品商品番号列にセット商品番号を設定できてしまう イ：・「在庫」テーブルに行を挿入できない。 　　・異なるテーブルのキーを同じ外部キーに入力できない。 　　・単品商品番号とセット商品番号を同じ外部キーに入力できない

解説

解答の論理構成

  1. 外部キーの仕様確認
    • 【問題文】「ユニーク索引は、一つのテーブル内でキー列の一意性を保証する…ユニーク索引を複数のテーブルにまたがって作成することはできない。」
    • 外部キーも同様に “1 つの参照先テーブル” を必要とする。
  2. 項番2（ア）の検討
    • 案1では“商品”テーブルが単品とセットを同居させる。
    • したがって“セット商品構成”テーブルの「単品商品番号」列に外部キーを張ると、実際はセット商品のレコードも選択肢に入る。
    • 結果として「単品商品番号列にセット商品番号を設定できてしまう。」
  3. 項番3（イ）の検討
    • 案2では商品が「単品商品」「セット商品」の2テーブルに分割される。
    • “在庫”テーブルの「商品番号」列に外部キーを設定しようとしても、どちらか一方しか参照できない。
    • 片方を参照先にすると、もう片方の商品は登録できず「『在庫』テーブルに行を挿入できない。」事態となる。
  4. したがって（ア）（イ）は上記の内容となる。

誤りやすいポイント

  • 「複数テーブルをまたぐ外部キーを定義できる」と誤解する。SQL標準では不可。
  • 案1・案2のメリット／デメリットを逆に覚える。スーパタイプ統合は参照しやすいが属性 NULL 管理が煩雑。
  • UNIQUE 制約がテーブル単位であるため、テーブル分割後の一意性維持手段を見落とす。

FAQ

Q: 外部キーに複数の参照先を指定できる DB もあるのでは？
A: 標準 SQL では不可です。製品固有の CHECK 制約やトリガで実現する例はありますが、本試験は標準仕様が前提です。
Q: 案2で“在庫”テーブルを二つに分ければ（イ）の問題は解決しますか？
A: 技術的には可能ですが、アプリケーション変更や JOIN が複雑化するため、要件とのトレードオフを検討する必要があります。
関連キーワード: 外部キー、スーパタイプ／サブタイプ、一意性制約、リファレンシャルインテグリティ

設問1：〔テーブルの設計〕について、(1)〜(4)に答えよ。

（4）図5 中の(b)〜(e)に入れる適切な述語を、①〜⑥から一つずつ選んで答えよ。（b,cは順不同、d, eは順不同）

模範解答

b：④ c：⑤ d：② e：③

解説

解答の論理構成

  1. 単品区分が ‘Y’（単品商品）の場合
    • 【表1】には「詰合せ日数…未定の場合、NULLが設定される」とあるが、【問題文】「確認画面のお届け予定日には…詰め合わせるのに必要な日数を加える」と記載。お届け予定日計算を確実に行うには値が必要であり NULL 非許容と判断できる。
      ⇒ (c) は「⑤ 詰合せ日数 IS NOT NULL」。
    • 単品商品は化粧箱を持たないので【表1】「化粧箱番号…セット商品に使用される化粧箱」との記述より NULL が妥当。
      ⇒ (b) は「④ 化粧箱番号 IS NULL」。
    • 社内原価については検査式の先頭に既に①「社内原価 IS NOT NULL」が配置済み。
  2. 単品区分が ‘N’（セット商品）の場合
    • セット商品自身は社内原価を保持しない（価格決定時に単品商品の社内原価を用いる）ため【表1】「社内原価…単品商品の社内原価」との説明より NULL が妥当。
      ⇒ (d) は「② 社内原価 IS NULL」。
    • セット商品には必ず化粧箱が付くので【表1】「化粧箱番号…セット商品に使用される化粧箱を一意に識別する番号。セット商品には必ず一つの化粧箱が使われ」と明示。
      ⇒ (e) は「③ 化粧箱番号 IS NOT NULL」。
  3. 以上より図5の検査制約は
    CHECK ( ( 単品区分 = ‘Y’ AND ① AND ④ AND ⑤ )
    OR ( 単品区分 = ‘N’ AND ② AND ③ ) )
    となり、(b)～(e) への適切な述語割り当ては提示のとおり。

誤りやすいポイント

  • 「詰合せ日数」をセット商品の属性と誤解し、セット商品側を NOT NULL にしてしまう。
  • 「化粧箱番号 IS NULL／NOT NULL」を単品・セットで逆に設定する。
  • 「社内原価 IS NULL／NOT NULL」を単品・セットで混同する。

FAQ

Q: 単品商品の「詰合せ日数」に NULL を許せば柔軟では？
A: お届け予定日を計算するロジックが必ず値を参照するため、NULL を許すとアプリケーション側で特例処理が必要になり整合性が落ちます。検査制約で NOT NULL を担保した方が安全です。
Q: セット商品に「社内原価」を入れておくと価格分析に便利では？
A: セット商品の価格は構成単品の「社内原価」から算出する設計方針です。重複情報を持たせると更新時に不整合が発生するため、NULL とするのが正規化の観点でも適切です。
Q: 将来サブタイプが増えたときは検査制約をどう拡張する？
A: 単品区分に新値を追加し、対応する列の NULL／NOT NULL 条件を OR 句として追加すれば良いです。検査制約は行ごとの整合性を保証するため、列追加や条件変更で柔軟に対応できます。
関連キーワード: CHECK制約、サブタイプ統合、NULL制御、データ整合性、正規化

設問2：〔SQL文の設計〕 について、(1)〜(3)に答えよ。

（1）SQL2 及び SQL3 の実行結果を SQL1 と同じにしたい。(f)、(g)に入れる適切な字句を 1 語又は2語で答えよ。 結果行の並び順は異なってよい。

模範解答

f：LEFT OUTER g：INNER

解説

解答の論理構成

  1. 基準となる “SQL1”
    【問題文】「SELECT M.商品番号、P.社内原価、P.化粧箱番号 … FROM 注文明細 M, 商品 P …」
    “商品” にはすべての商品が格納されているため、注文に存在する行は必ず取得できる。
  2. “SQL2” の要求
    • 【問題文】「SQL2 の実行結果を SQL1 と同じにしたい。」
    • 1 行の “M.商品番号” は “単品商品” か “セット商品” のどちらか 1 テーブルにしか存在しない。
    • したがって “注文明細” を起点に、両テーブルに対して「存在すれば結合、存在しなければ NULL」を返す必要がある。
    • この動作を保証する JOIN は “LEFT OUTER JOIN”。
    • 同じ動作を 2 回行うので (f) は 2 か所とも “LEFT OUTER”。
  3. “SQL3” の要求
    • 列リストを見ると、1 本目の SELECT では “化粧箱番号” を NULL、2 本目では “社内原価” を NULL に設定し、最後に “UNION ALL” で合成している。
    • したがって各 SELECT は「一致した場合のみ取得」すればよく、行の欠落は UNION 側で補完できる。
    • 通常の “INNER JOIN”（JOIN だけでも可）で十分なので (g) は “INNER”。

誤りやすいポイント

  • 「どちらのテーブルか分からないときは全結合（FULL OUTER）を使う」と思い込む
    → 実際には起点テーブルが決まっており LEFT だけで足りる。
  • “SQL3” でも “LEFT OUTER JOIN” と記述してしまう
    → 分割＋UNION 方式では不要。結果が重複しパフォーマンスも低下する。
  • JOIN の順番を変えると NULL の位置が変わることを見落とす
    → 起点テーブルを意識して外部結合の向きを決定する。

FAQ

Q: “UNION” と “UNION ALL” のどちらを選べばよいですか？
A: 重複行を許容する場合は “UNION ALL” が高速です。本問では単品・セットで商品番号が重複しないため “UNION ALL” が適切です。
Q: “LEFT OUTER JOIN” を 2 回連続で書くと行が増える心配はありませんか？
A: “M.商品番号” は “単品商品” と “セット商品” のどちらか一方にしか存在しない設計なので、増殖はありません。両方に存在する可能性がある場合は注意が必要です。
Q: “JOIN” とだけ書いた場合のデフォルトは？
A: ANSI 準拠 SQL では “INNER JOIN” が暗黙の既定です。本問の (g) にも適用できます。
関連キーワード: 外部結合、内部結合、UNION ALL, NULL 補完、結合方向

設問2：〔SQL文の設計〕 について、(1)〜(3)に答えよ。

（2）SQL4 及び SQL5 は、指定した注文について、注文されたセット商品を構成する単品商品の合計数を求める SQL 文である。 SQL4 及び SQL5 の実行結果が同じになるように、(h)に入れる適切な字句を答えよ。

模範解答

h：M.注文数*M.構成数

解説

解答の論理構成

  1. 目的の確認
    【小問説明】に「注文されたセット商品を構成する単品商品の合計数を求める」とあります。
  2. 必要な情報源
    ・セット商品が何個注文されたか → 
    注文明細
    の 「注文数」（列名：
    注文数
    ）
    ・セット商品１個に単品商品が何個入っているか → 
    セット商品構成
    の 「構成数」（列名：
    構成数
    ）
  3. テーブル別の別名
    SQL4, SQL5 の FROM 句に 
    • 注文明細 M
    • セット商品構成 K

      が指定されています。従って両列は 
      M.注文数
      、
      K.構成数
      で参照します。
  4. 合計値を出すための式
    １注文行で必要な単品数 = 
    注文数
    × 
    構成数

    これを行単位で計算し 
    SUM
    で集計する設計は実務でも典型です。
  5. 以上より 
    (h)
    は 
    M.注文数 * K.構成数

誤りやすいポイント

  • P.構成数
    という列は存在しないため、
    P
    を使うとエラーになります。
  • M.注文数 + K.構成数
    と加算にしてしまうと「必要個数」ではなく「数の合計」になり要件を満たせません。
  • 両案とも結果を合わせる必要があるので、案２だけを見て別名を 
    S
    としてしまうミスに注意します。

FAQ

Q: 掛け算の列順序は 
K.構成数 * M.注文数
でも正しいですか？
A: 乗算は可換なので計算結果に差はありません。ただし読みやすさの観点で「注文数×構成数」と書くほうが意図を把握しやすいです。
Q: 
SUM
を忘れてしまうと何が起きますか？
A: 単品商品番号ごとに集計できず、行ごとに結果が返り期待する「合計数」になりません。
GROUP BY
とセットで必須です。
関連キーワード: 集約関数、列別名、ジョイン、乗算演算、グループ化

設問2：〔SQL文の設計〕 について、(1)〜(3)に答えよ。

（3）SQL4 及び SQL5 のアクセスパスは、次に示すネストループ結合である。 　① “注文明細” テーブルの主索引を用いて指定された注文番号の行を取り出し、商品番号を調べる。 　② ①で調べた商品番号ごとに、案1では“商品” テーブル、案 2 では “セット商品” テーブルの主索引を用いてアクセスする。 　③ “セット商品構成” テーブルの主索引を用いてアクセスする。 　　これらのアクセスパスでは、SQL4 の方が、“セット商品構成” テーブルの主索引をアクセスする頻度が多かった。 そのアクセス頻度を減らすために、SQL4 の WHERE 句に AND で追加すべき述語を一つ答えよ。

模範解答

P：単品区分='N'

解説

解答の論理構成

  1. 【問題文】にはネストループ結合の手順が示されている。
    ① 
    注文明細
    → ②（案1の場合）
    商品
    → ③ 
    セット商品構成
    の順で主索引をたどる。
  2. セット商品構成
    は「セット商品番号」を主キーに持ち、セット商品のみが登録される構造である。
  3. ところが案1の 
    商品
    表には単品・セット両方が格納されるため、②の時点で単品行も取得してしまう。
  4. 単品行に対して③を実行しても対応行は見つからず、「主索引を探したがヒットしない」無駄アクセスが発生する。
  5. 表1の説明――
    「単品区分…区分値は、単品商品では ‘Y’、セット商品では ‘N’ が設定される。」
    これを利用し、
    WHERE
    句に 
    P.単品区分 = 'N'
    を追加すれば②で単品行を除外できる。
  6. したがってアクセス頻度低減のための追加述語は 
    P.単品区分 = 'N'
     となる。

誤りやすいポイント

  • セット商品構成
    表を「単品も含む」と誤解し、区分条件が不要と判断してしまう。
  • 案2の構造と混同し、
    単品商品
    / 
    セット商品
    個別表だから問題ないと考えてしまう。
  • 述語を 
    単品区分 <> 'Y'
    などと書き換え、原文の値 ‘N’ を改変してしまう（採点対象外になる）。

FAQ

Q: なぜ案2では同じ追加述語が不要なのですか？
A: 案2では 
注文明細
からまず 
セット商品
表（単独）へ結合しており、構造上単品商品が選択肢に入らないため区分条件を追加しなくても無駄アクセスが発生しません。
Q: 
単品区分
に索引を張らなくても効果はありますか？
A: 本問の主目的はループ対象の行数削減です。索引がなくとも行数が減れば③の回数が減るため効果があります。追加で索引を作成すれば更に効率化できますが、設問の範囲外です。
Q: 
IN
句や副問い合わせで書き換えても良いですか？
A: 可能ですが、求められているのは「AND で追加する単一述語」です。最小限で目的を達成する 
P.単品区分 = 'N'
が最適解です。
関連キーワード: ネストループ結合、主索引、検査制約、テーブル設計、チューニング

設問3：〔注文トランザクションの設計〕 について(1)、(2)に答えよ。

（1）次の TR1〜TR4 のうち、いずれか二つの組合せのトランザクションを同時に実行したとき、デッドロックが起きるおそれがある。 次の表中の （ウ）〜（カ） に、デッドロックが起きない組合せには○を、起きるおそれがある組合せには×を記入せよ。 　TR1：単品商品2個を注文する。 　TR2：単品商品1個とセット商品1個を注文する。 　TR3：セット商品 1個を注文する。 TR4 セット商品 2個を注文する。 データベーススペシャリスト試験（平成26年 午後1 問3 設問3-1）

模範解答

ウ：× エ：× オ：〇 カ：×

解説

解答の論理構成

  1. ロック対象と順序整理
    • TR1：単品商品２個を表示順でロック
    • TR2：①単品１個（表示順）→②セット１個→③セット構成単品（主キー順）
    • TR3：①セット１個→②セット構成単品（主キー順）
    • TR4：①セット１個→②セット構成単品（主キー順）→③もう１つのセット１個→④その構成単品…（主キー順）
  2. 循環待ちの有無
    • （ウ）TR1×TR2
      TR1 は単品Ａ→単品Ｂ。
      TR2 は単品Ｂ→セットＣ→構成単品Ａ。
      ＡとＢで取得順が逆転し、TR1 がＢ待ち、TR2 がＡ待ちとなり循環待ち発生。×
    • （エ）TR1×TR3
      TR1 は単品Ａ→単品Ｂ。
      TR3 はセットＣ→構成単品Ａ。
      TR1 がＡのロックを握ったままＢを取りに行き、TR3 はＣ後にＡを要求して待機。
      その後 TR1 がＢで TR3 を待つ可能性があり循環待ち。×
    • （オ）TR3×TR3
      両者とも「セットＣ→構成単品（主キー順）」で同一順序。
      同期しながら取得されるため循環待ちは起きない。○
    • （カ）TR3×TR4
      TR3：セットＣ→単品Ａ
      TR4：セットＤ→単品Ｂ→セットＣ→単品Ａ
      TR4 がＣの取得で TR3 を待機し，TR3 がＡの取得で TR4 を待機する可能性があるため循環待ち発生。×

誤りやすいポイント

  • 「READ COMMITTED なのでロックはすぐ解放される」と誤解し、更新系ステートメントでロックが保持され続ける事実を見落とす。
  • セット商品の構成単品も同じ “在庫” 行をロックする点を忘れ、単品のみ／セットのみで安全と思い込む。
  • ロック順序を“商品表示順”と“主キー順”で分けることを見逃し、同じ順序と誤認する。

FAQ

Q: 主キー順と表示順がたまたま同じ場合でもデッドロックは発生しませんか？
A: 同一順序であれば循環待ちが起きないため、デッドロックは発生しません。本設問では「商品全体で重複がないように、商品企画担当者が決めた表示順」と「主キー順」が必ずしも一致しない前提で判定します。
Q: READ COMMITTED でなく SERIALIZABLE にしたら解決しますか？
A: SERIALIZABLE は一貫性を高めますが、ロック保持期間はむしろ長くなり、順序が逆転していればデッドロックの危険は残ります。根本的にはロック取得順序の統一が必要です。
Q: 在庫テーブルを行ではなく商品番号範囲でロックしたら？
A: 範囲ロックは衝突範囲を広げるためデッドロック確率が上がります。行ロック＋統一順序の方が実運用に適します。
関連キーワード: デッドロック、行ロック、ロック順序、READ COMMITTED, トランザクション

設問3：〔注文トランザクションの設計〕 について(1)、(2)に答えよ。

（2）(1)で起きるおそれがあるとしたデッドロックを防ぐためには、一つのトランザクションの中で“在庫” テーブルの行をどの列の順番で更新すればよいか。 列名を答えよ。

模範解答

商品番号

解説

解答の論理構成

  1. トランザクション仕様
    「(3) 商品については、商品一覧画面に表示された順番に…更新する」「(5) ISOLATION レベルは,READ COMMITTED」とある。
    → 更新時点で行ロックを取得する。
  2. デッドロックの発生パターン
    • 取引Ａ：表示順が〔200→300〕
    • 取引Ｂ：表示順が〔300→200〕
      Ａが商品番号 200 をロック→Ｂが 300 をロック→Ａが 300 待ち→Ｂが 200 待ち で循環待ち。
  3. 防止策
    全トランザクションで同一順序でロック取得すれば循環は起きない。主キー「商品番号」は「PRIMARY KEY」として表２・表３に定義され、全商品で一意。
  4. よって更新は「商品番号」の順で行う。

誤りやすいポイント

  • 「表示順」が指定されているのでそれを使うと思い込む。表示順は顧客操作や商品追加で変化し、統一順にならない。
  • 行ロックよりテーブルロックを想定し、「ロックは一つだからデッドロックしない」と誤解。READ COMMITTED では行単位ロックが基本。
  • 注文明細番号や登録順を使うと、一部商品だけを更新する別トランザクションとの間で順序不一致が起き得る。

FAQ

Q: 表示順を昇順にそろえてもデッドロックは防げますか？
A: 顧客ごとに表示される商品が異なるため、同じ昇順にしても最初に取得する行が違う商品になる場合があります。全トランザクションが必ず保持する列で順序を合わせる必要があり、主キー「商品番号」が最適です。
Q: READ COMMITTED でなく SERIALIZABLE にすれば解決しますか？
A: SERIALIZABLE でもロックは行単位で取得され、取得順が異なればデッドロックは発生します。順序統一は不可欠です。
Q: トランザクション全体を商品種別（単品／セット）で分けても良いですか？
A: 種別ごとにロックを分けても、同じ種別内の複数行を異順序で取得するケースが残るので根本解決にはなりません。
関連キーワード: デッドロック、行ロック、主キー、ロック順序、READ COMMITTED
戦国ITクイズ機能

\ せっかくなら /

データベーススペシャリストを
クイズ形式で学習しませんか？

クイズ画面へ遷移する→

すぐに利用可能！

©︎2025 情報処理技術者試験対策アプリ

このサイトについてプライバシーポリシー利用規約特商法表記開発者について