応用情報技術者 2013年 春期 午後 問06

解答の論理構成

1. 発言と発言キーワードの関連
   • 【問題文】のエンティティ概要では「発言キーワード」について「一つの発言に対して一つ以上のキーワードが関連付けられる。」と明記されています。
   • これは“1 つの発言(親) ➡ 複数の発言キーワード(子)”という 1 対多の関係であり、リレーション一覧にも「発言 → 発言キーワード（1対多）a」とあります。
   • よって a には凡例で 1 対多を表す「→」をそのまま記入するのが妥当です。
2. サポートとサポート分類の関連
   • リレーション一覧には「サポート分類 → サポート（1対多）」とあり、サポート側に外部キーが入ることが示唆されています。
   • また、サポートエンティティの属性一覧には「b」という空欄が準備されており、ここにサポート分類を指す列を設ける必要があります。
   • サポート分類の主キーは【問題文】E-R 図中の属性「サポート分類ID」であるため、サポート側の外部キー名も同一の「サポート分類ID」となります。
   • 凡例では外部キーは点線下線で表すため、記述は「サポート分類ID」を点線下線付きで示せば完成です。

誤りやすいポイント

• 「発言」と「発言キーワード」の多重度を逆に捉え、矢印を←にしてしまう。概要文の「一つの発言に対して一つ以上のキーワード」を読み落とさないよう注意が必要です。
• 外部キー名を“分類ID”や“分類コード”などと省略し、本来の「サポート分類ID」と一致しない名前で書いてしまう。主キーと外部キーは完全一致が原則です。
• 凡例に従った記号・下線の形式を忘れる。特に試験では図表の記号ミスも減点対象になります。

FAQ

解答の論理構成

1. 【問題文】には次の要件があります。
   • 「掲示板上の発言に対してキーワード表だけに存在するキーワードの重みは 0 として集計する。」
   • 「発言キーワードの重みを、掲示板上の社員以外の顧客による発言のうち、そのキーワードを含む発言数と定義する。」
   • 「社員番号属性には、社員の発言の場合は社員番号が入り、社員以外の顧客による発言の場合はNULLが入る。」
2. 0 も含めて全キーワードを取得するためには、キーワード表を基準に結合し、対応する発言数がなかった場合でも行が残る必要があります。これを満たすのが LEFT OUTER JOIN です。
3. 「社員以外の顧客による発言」を抽出するには、社員の場合にのみ値が入る列が NULL であることを条件にします。したがって 発言.社員番号 IS NULL が最も直接的かつ可読性の高い式となります。
4. 以上より、
   • c には LEFT OUTER JOIN
   • d には 発言.社員番号 IS NULL
     を挿入するのが適切です。

誤りやすいポイント

• INNER JOIN を選択すると、キーワード表に存在するが掲示板では一度も使用されていないキーワードが欠落し、「重みは 0 として集計する」という要件を満たせません。
• NULL 判定を = NULL で書くと一致判定ができず、結果に社員の発言が混入します。IS NULL を忘れずに使います。
• LEFT OUTER JOIN を RIGHT OUTER JOIN と誤記すると、基準表が逆になり意図した結果が得られません。

FAQ

解答の論理構成

1. 抽出対象の確認
   【問題文】に「掲示板に書き込まれた否定的な発言を、含まれるキーワードの重みの総和が大きいものから順にリストアップする」とあります。
   否定的かどうかは表1の「発言」エンティティ説明にある「否定的フラグ属性には、否定的な発言内容の場合は‘1’が、そうでない場合は‘0’が入る」で判定します。
   したがって WHERE 句 e には
   sql 発言.否定的フラグ = '1'
   を記述し、否定的な発言のみを対象にします。
2. 並べ替え条件の決定
   同じく【問題文】に「含まれるキーワードの重みの総和が大きいものから順にリストアップ」と明記されています。
   図3の SELECT 句で SUM(発言キーワード重み.重み) AS WEIGHT と総和を WEIGHT という列別名で算出しているので、
   ORDER BY 句 f では
   sql ORDER BY WEIGHT DESC
   とし、総和が大きい順（降順）に整列させます。
3. 以上より
   e：発言.否定的フラグ = '1'
   f：ORDER BY WEIGHT DESC

誤りやすいポイント

• 肯定・否定両方を判定しようとして 発言.肯定的フラグ = '0' まで条件に加えると、肯定・否定がともに ‘1’ の発言を除外してしまいます（表1に「両方のフラグに‘1’が入る場合もある」と明示）。
• ORDER BY で列名ではなく SUM(発言キーワード重み.重み) と関数を書くと可読性が落ち、RDBMS によってはエイリアスが優先されない場合があります。
• 重み降順を ASC と誤記すると、重要度の低い発言が先頭に並んでしまいます。

FAQ

解答の論理構成

• 着眼点①：要件の追加
  問題文の〔活用事例コンテンツの充実〕では、
  「活用事例ごとにキーワードを登録するだけでなく、活用シーンにもキーワードを関連付ける」
  と明記されています。現行の E-R 図には「活用シーン」と「キーワード」を直接結ぶ関連が存在しないため、新しい関連を設計する必要があります。
• 着眼点②：多対多関係の解消
  一つの活用シーンに複数のキーワードが付く可能性があり（例：学校行事→「運動会」「文化祭」）、逆に一つのキーワードが複数の活用シーンに付く可能性もあります（例：「運動会」→学校行事・スポーツ）。すなわち多対多関係なので、中間エンティティを設けて正規化します。
• 着眼点③：エンティティ名と属性
  多対多を解消する中間エンティティには、両方の主キーを複合主キーとして持たせるのが定石です。したがって
  エンティティ名：活用シーンキーワード
  属性：活用シーンID, キーワードID
  が最小構成となります。
• 着眼点④：関連の向きと記号
  図1の凡例に従い、
  ・「活用シーン」―(1)⇔(多)→「活用シーンキーワード」
  ・「キーワード」―(1)⇔(多)→「活用シーンキーワード」
  を記述すれば要件を満たす E-R 図になります。

誤りやすいポイント

• 活用シーンに直接「キーワードID」を入れる誤設計
  →多対多を 1 列で表そうとすると、同一シーンに複数キーワードを持てず失敗します。
• 主キーの取り違え
  →中間エンティティは両外部キーの複合主キーであり、別途連番を持つ必要はありません。
• 関連の矢印向き
  →図1の凡例では「1 対多」を→で表現します。方向を逆に描くと減点対象です。

FAQ