応用情報技術者 2024年 秋期 午後 問06

解答の論理構成

1. 自己参照を示す a
   【問題文】には「カテゴリの階層構造は、自己参照の関連を用いて表現する。」とあります。自己参照はエンティティ内部に折り返す矢印で示すのが一般的です。図1のカテゴリエンティティ末尾にある a はこの自己参照を表すため、曲がった矢印 「↩︎」 を補います。
2. 取引と発送の関連 b
   リレーションシップ一覧に「取引 — 発送（1対多）」とあり、矢印ではなく実線のみで 1 対多を表現しています。図1の取引エンティティ末尾の b はこの実線を示すため、凡例の 1 対 1 用ではなく水平線 「ー」 を記入します。
3. 発送エンティティの不足属性 c
   業務要件（項番5）に「S社は発送した商品の追跡番号を管理し、配送業者のWebサイトと連携することで、出品者や購入者が商品の配送状況を確認できるようにする。」と記載されています。従って発送表には追跡番号を保持する列が必要です。よって c には 「追跡番号」 を入れます。
4. 利用者とフォローの関連 d
   業務要件（項番8）は「利用者はお気に入りの利用者をフォローできる。」と述べています。リレーションシップ一覧には「利用者 → フォロー（1対多）」があり、1人の利用者が多数のフォロー行を持つ方向を矢印で示しています。したがって d には 1 対多の矢印 「→」 を入れます。

誤りやすいポイント

• 自己参照を通常の「→」で描いてしまう
  曲がった矢印で自己参照を示すと気付きにくい受験生が多いです。
• 「取引 — 発送」をどちら向きの矢印にするか迷う
  問題文は方向を特定していないため実線「ー」が正解です。
• 業務要件にだけ登場する「追跡番号」を見落とす
  列名は本文で明示されているので、そのまま「追跡番号」と書く必要があります。
• フォローのリレーション向きを逆にする
  フォロー元が 1、フォロー行が多側であることを業務要件から確認しましょう。

FAQ

解答の論理構成

• 検索画面で、利用者が「カテゴリを指定する場合、指定されたカテゴリ及びその下位にある全てのカテゴリの出品が検索の対象となる」ことが業務要件の「表1　項番2」に明記されています。
  したがって SQL では再帰的に「カテゴリ」の階層をたどる必要があります。ANSI SQL では再帰問い合わせを記述する定型句が WITH RECURSIVE なので、e に入る語句はこれになります。
• 再帰共通テーブル式（CTE）は
  ①アンカー部 ― 最初に選択された 1 行（または複数行）
  ②再帰部 ― 直前に取得した行と「上位カテゴリID」で結合して子階層を取得
  を UNION ALL で連結するのが典型形です。よって f は UNION ALL となります。
• 取得した「指定カテゴリ」CTE と「出品」表を結合して対象レコードを絞り込む必要があります。結合キーは「出品.カテゴリID」と「指定カテゴリ.カテゴリID」の等価条件なので、g には 出品.カテゴリID = 指定カテゴリ.カテゴリID が入ります。
• キーワード検索について、「キーワードは、商品名及び商品説明を部分一致で検索したい場合に指定する」（表1　項番2）とあるので、LIKE 述語とワイルドカード % を使ったパターンマッチになります。埋込み変数 :キーワード の前後に % を連結する書式が LIKE '%' || :キーワード || '%' であり、商品名・商品説明の両方で同じ式を使うため、h も同じ式になります。

誤りやすいポイント

• 再帰CTEを WITH だけで書き始め、RECURSIVE を付け忘れる。RECURSIVE を入れないと自己参照の再帰が許されません。
• 再帰部の結合で UNION を選択してしまう。重複排除付き UNION は余計な DISTINCT 処理を伴い性能低下を招きます。本問では階層を重複なく辿る前提が立っており、UNION ALL が正解です。
• 出品とカテゴリの結合条件を「上位カテゴリID」で書いてしまうミス。出品レコードが持つのは直接の「カテゴリID」です。
• LIKE :キーワード とだけ書き、ワイルドカード % を忘れる／前後のどちらか一方しか付けない誤答が多いです。

FAQ

解答の論理構成

1. 問題文は、インデックス設定方針について「①B-treeインデックスの特性を踏まえて、特定の値を指定したときに行数を表全体の5%以下に絞り込める列だけにインデックスを設定する」と述べています。
   これは B-tree が
   ・検索対象行を“少数”に絞れる列ほど効果が高い
   ・探索コストが木の高さに比例し $O(\log n)$ になる
   という一般的な特性を示しています。
2. 解答群を B-tree の事実と照合します。
   ア：NOT 条件はインデックスを使いづらい。AND 条件の組合せは選択率が下がり利用されやすい。○
   イ：列に関数・型変換を掛けると索引キーが一致せずフルスキャンになることが多い。×
   ウ：値の分布に偏りが無い（＝高い選択性が保たれる）と、どの値を検索しても行数が平均的になり性能が安定。○
   エ：カーディナリティが低い列は選択率が悪く、インデックスを使っても行取得コストが下がらない。×
   オ：B-tree は高さ $h\approx {\log }_{m}n$（m は分岐数）なので検索計算量は $O(\log n)$。○
   カ：挿入も分割が起きても高さに比例し $O(\log n)$ が一般的。×
   キ：B-tree は範囲走査にも強い。×
3. よって、正しい三つは
   ア・ウ・オ。

誤りやすいポイント

• 「カーディナリティが低い列でもインデックス＝高速化」と思い込み、解答群「エ」を選択しやすい。
• B-tree が範囲検索に弱いと誤解し「キ」を選ぶケース。実際は木構造が連続キーを順次たどれるため範囲走査にも適する。
• 挿入計算量を線形 $O(n)$ と誤認し「カ」を選択するミス。ページ分割は発生しても高々木の高さ分で済む。

FAQ

解答の論理構成

1. インデックス設定の方針確認
   問題文より
   • “①B-treeインデックスの特性を踏まえて、特定の値を指定したときに行数を表全体の5%以下に絞り込める列だけにインデックスを設定する”
     つまり
     (a) 検索条件や結合条件に現れる列
     (b) カーディナリティが中〜高（≒選択度が高い）
     が対象になる。
2. 図2のSQL文で検索・結合に使われる列
   • 出品表：
     “出品.出品価格 BETWEEN :下限価格 AND :上限価格”
     “出品.商品状態 = :商品状態”
     “出品.出品状況 = :出品状況”
     “ON … 出品.カテゴリID …”
   • カテゴリ表：
     “WHERE B.上位カテゴリID = C.カテゴリID”
     （“カテゴリID”は主キーなのでインデックス済）
3. 各列のカーディナリティと適否判定
   【表2 出品表】
   • “出品価格” … カーディナリティ “高” → 5%以下に絞り込める可能性大 → ○
   • “カテゴリID” … カーディナリティ “中” → 結合列で絞込効果も期待 → ○
   • “商品状態”“出品状況” … カーディナリティ “低” → 5%以下になりにくい → ×
   【表3 カテゴリ表】
   • “上位カテゴリID” … カーディナリティ “中” かつ再帰CTE内の検索キー → ○
   • “カテゴリID” は主キーで既にインデックス自動付与 → 対象外（追加不要）
4. 以上より高速化に寄与する列
   出品表：カテゴリID, 出品価格
   カテゴリ表：上位カテゴリID

誤りやすいポイント

• 「主キーは自動でインデックス化される」記述を見落とし、カテゴリIDに重複してインデックスを定義してしまう。
• “カーディナリティ 低” でも WHERE 句に出てくるからと安易にインデックスを貼る（B-tree では逆効果になり得る）。
• “全文検索エンジンを用いる”と明示された“商品名”“商品説明”に B-tree インデックスを重ねてしまう。
• BETWEEN 句に対して範囲検索だから B-tree は不要だと誤解する（実際は範囲条件でも有効）。

FAQ