データベーススペシャリスト 2022年 午後1 問01

解答の導き方

1. 問合せ（媒体）の分岐（Web問合せ／通話／SLP経由）
   • 根拠として問題文に「問合せの媒体は、 Web上の問合せフォームか電話による通話である。」とあるので、問合せは少なくとも「Web問合せ」と「通話」を区別して表す必要があります。したがって図上で「問合せ」から「Web問合せ」と「通話」へ線を引き、それぞれを識別するようにします。
   • また「問合せは、 製品使用者から直接又はSLP経由でCCに入る。」かつ「SLP経由の場合は問合せフォームからに限定している。」なので、SLP経由のWeb問合せを表す「SLPweb問合せ」は「Web問合せ」側の特殊なケースとして扱い、SLPと関連付けます（Web問合せ ← SLPweb問合せ → SLP）。
2. Web問合せと通話の関係（発信通話の扱い）
   • 「入ったWeb問合せに対してCC要員が製品使用者に電話をかける。」とあるため、あるWeb問合せがきっかけでCC要員が発信する通話が発生します。一方で「通話の場合、…受信か発信かの受発区分、音声データである通話音声を記録している。」とあり、通話自体は着信・発信の両方を含む一般的な記録です。
   • ここから導かれる設計方針は、発信で「Web問合せに紐づく通話」を明示的に結び付けることです。設計上は「発信通話」をWeb問合せと通話を結ぶ関連（連関エンティティ）としてモデル化します（Web問合せ — 発信通話 — 通話）。発信通話は「通話」の部分集合であるが、発信がWeb問合せ由来であることを明示する役割を持つため、単に「通話のサブタイプ」とするよりも、Web問合せとの結び付きを表す独立の関連で扱うほうが図意が明確になります。
3. 通話とCC要員
   • 「通話の場合、通話したCC要員の社員番号、通話時間、受信か発信かの受発区分、音声データ…を記録している。」から、通話は必ずCC要員と関連します。従って図上で「通話」と「CC要員」を結びます（通話側にCC要員の社員番号を参照できるようにする）。
4. 問合せと案件の関係
   • 「問合せに対して、 …問合せを案件化し、 案件番号を発番して案件を登録する。」かつ「案件化した問合せ及びその後の問合せは案件に従属させる。」とあるので、問合せは（任意に）案件に紐づきます。したがって図では問合せと案件を関連付け、問合せ側に案件番号を参照する形（問合せが案件に従属する）で表現します。
5. 登録製品／EU／案件の流れ
   • 「登録製品には、販売した製品を利用するEUを登録する。」とあり、登録製品はEUを参照します。さらに「案件は、対象製品が登録済みの登録製品に合致すればその登録製品と…関連付ける。」とあるので、登録製品→案件の関係（案件が登録製品を参照）を図に含めます。これによりEU → 登録製品 → 案件 という流れが明確になります。
6. 出張手配・出張実施・AS実施記録と関連
   • 「出張手配は、 案件に対して1回行い…出張年月日と出張時間帯を決める。」より、出張手配は案件に結び付くので「案件 → 出張手配」を描きます。
   • 「手配された出張を実施すると、 実施年月日と実施時間帯、 担当したCE, 解決フラグを記録する。」から、出張実施は担当CEを参照します。したがって出張実施 ←→ CE を結びます。
   • 出張実施とAS実施記録については「AS 実施記録として、 実施したMTコード、実施金額を記録する。」かつ AS実施記録が複数の点検修理項目（MTコード）を持ち得るため、出張実施とAS実施記録（さらにAS実施記録は点検修理項目のMTコードを参照）を結びます。
7. CC要員と出張実施（重要な誤り回避）
   • 図1ではCEボックスとCC要員ボックスから出張実施ボックスへ線が伸びる意図があるため、説明する際に「CE → CC要員」のように誤って表現してはいけません。CEとCC要員は別役割であり、どちらも出張実施に役割を持つ（CEは技術担当、CC要員は手配・事務側の担当を示す等）ため、図上ではCEとCC要員それぞれから出張実施へ線を引きます（CEとCC要員を直接つなぐ線は不要・誤り）。

• 問合せ — Web問合せ：根拠「問合せの媒体は、 Web上の問合せフォームか電話による通話である。」
• 問合せ — 通話：同上。
• Web問合せ — SLPweb問合せ — SLP：根拠「問合せは、 製品使用者から直接又はSLP経由でCCに入る。」かつ「SLP経由の場合は問合せフォームからに限定している。」
• Web問合せ — 発信通話 — 通話（発信通話はWeb問合せと通話を結ぶ連関）：根拠「入ったWeb問合せに対してCC要員が製品使用者に電話をかける。」および「通話は受発区分を記録する。」
• 通話 — CC要員：根拠「通話の場合、通話したCC要員の社員番号…を記録している。」
• 問合せ — 案件（問合せが案件に従属する形で関連）：根拠「問合せを案件化し、…案件化した問合せ及びその後の問合せは案件に従属させる。」
• 登録製品 — 案件（案件は対象の登録製品を参照する）：根拠「案件は、対象製品が登録済みの登録製品に合致すればその登録製品と…関連付ける。」および「登録製品には、…EUを登録する。」（EU→登録製品）
• 案件 — 出張手配 — 出張実施 — AS実施記録 — 点検修理項目 の連鎖：根拠「出張手配は、案件に対して1回行い…」「手配された出張を実施すると、…担当したCE…を記録する。」「AS 実施記録として、 実施したMTコード、 実施金額を記録する。」
• 出張実施 — CE：根拠「手配された出張を実施すると、…担当したCE…を記録する。」
• 出張実施 — CC要員（図上の役割として明示）：根拠（図の意図および手配・運用の流れ）と「CCから電話をかける」「案件化・手配の主体がCCである」ことから、CC要員の関与を出張実施側に表現します（CEとCC要員を直接つなぐのは誤り）。

誤りやすいポイント

• 発信通話を単に「通話のサブタイプ」として表現すること。発信通話は「Web問合せに紐づく発信という事象」を示すため、Web問合せと通話を結ぶ連関（あるいは発信のための交差点）として扱うほうが意図が明確になる。
• CEとCC要員を混同して「CE → CC要員」のような関係線を引くこと。両者は別個の役割であり、どちらも出張実施に関与する点を明示する（CEとCC要員それぞれから出張実施へ線を引く）。
• 問合せと案件の向き（誰が参照するか）を誤ること。仕様文の「案件化した問合せは案件に従属」とあるため、問合せ側に案件番号を持たせる（問合せが案件を参照する）実装が一般的である点を押さえる。
• 通話は「成立した通話のみ」と誤解すること。仕様に「通話は、成立しなくても1回の通話としている。」とあるので、不成立の通話も記録対象である。
• AS実施記録と点検修理項目の関連を忘れると、どのMTコードを実施したか追えなくなる。問題文に明示された通り、AS実施記録は実施したMTコード（点検修理項目）を参照する。

FAQ

解答の論理構成

1. （ア）問合せ
   • 【問題文】“問合せは、… 問合せ番号で識別し、問合せ年月日時刻、問合せ内容のほかに、… お名前と電話番号を記録… 媒体区分で分類する。”
   • “案件化した問合せ…は案件に従属”より 案件番号 を外部キーとして追加。
2. （イ）Web問合せ
   • 【問題文】“製品使用者が直接入れる問合せは通話と問合せフォーム… SLP経由の場合は問合せフォームからに限定”
   • SLP経由か否かを区別するため “SLP製品使用者入力区分” を設定。
3. （ウ）SLPweb問合せ
   • 【問題文】“Web問合せに経由したSLPのBPコードを記録”
   • SLPのBPを指す SLPBPコード を外部キーとして定義。
4. （エ）通話
   • 【問題文】“通話の場合、通話したCC要員の社員番号、通話時間、… 通話成立フラグ、… 受発区分、音声データである通話音声を記録”
   • 社員番号はCC要員表への外部キーなので下線破線。
5. （オ）発信通話
   • 【問題文】“発信の場合… CC要員が製品使用者に電話をかける” “発信通話”はWeb問合せ起点で派生するため “発信元Web問合せ番号” を設定。
6. （カ）出張手配
   • 【問題文】“出張手配は、… EUに了解を得て出張年月日と出張時間帯を決める”
   • 対象案件は主キー “案件番号” に統合済みなので、残る2属性 “出張年月日”、“出張時間帯” を追加。

誤りやすいポイント

• 問合せと案件のタイミングを混同し、「案件番号」を問合せ側に置き忘れる。
• “SLP経由”の区分を属性でなく別エンティティで表そうとして正規化条件を崩す。
• “通話社員番号”を単なる属性とし、CC要員との外部キー関係を付け忘れる。
• “発信元Web問合せ番号”を必須にし忘れ、発信通話とWeb問合せの対応が不明確になる。

FAQ

解答の導き方

1. （あ）＝製品シリーズ

• 根拠：「製品シリーズごとに、用いているユニットを登録する。」という記述があり、図3の（あ）からユニットへ向かう経路（最終的に網掛けaにつながる構造）と整合します。したがって（あ）は製品シリーズと判断します。
• 補足：設計方針で「多対多のリレーションシップは用いない」とあるため、製品シリーズとユニットの関係は中間の関係スキーマ（a）として実装します。

1. （い）＝点検修理項目

• 根拠：「要点検修理FAQには、対象のユニットが何か設定するとともに、対応する点検修理項目を関連付けておく。」という記述により、要点検修理FAQ（図3中に明示）と点検修理項目が関連することが明らかです。図3で（い）が要点検修理FAQとfで結ばれている配置から、（い）は点検修理項目と解します。

1. （う）＝案件

• 根拠：「案件でEUへの回答に適用したFAQは、案件適用FAQとして案件に関連付け、可能性の高いFAQの順に可能性順位を記録する。」という記述があり、図3で（う）から下の網掛けdへ向かい、FAQも同じdへつながっていることから、dは案件とFAQを結ぶ「案件適用FAQ」を表します。したがって（う）は案件です。

• 属性：製品シリーズコード、ユニットコード
• 主キー: 製品シリーズコード, ユニットコード（複合）
• 外部キー: 製品シリーズコード → 製品シリーズ(製品シリーズコード)、ユニットコード → ユニット(ユニットコード)
• 根拠：「製品シリーズごとに、用いているユニットを登録する。」を実現するための中間表（多対多を避けるための実装）です。

• 属性：ユニットコード、機能部品番号
• 主キー: ユニットコード, 機能部品番号（複合）
• 外部キー: ユニットコード → ユニット(ユニットコード)、機能部品番号 → 要管理機能部品(機能部品番号)
• 根拠：「その機能部品を要管理機能部品として要管理内容を登録し、組み込んでいるユニットと関連付ける。」および「機能部品は、複数ユニット間で共通化を進めている。」から、ユニット⇔要管理機能部品は中間表で表します。

• 属性：FAQ番号、KW
• 主キー: FAQ番号, KW（複合）
• 外部キー: FAQ番号 → FAQ(FAQ番号)、KW → KW(KW)
• 根拠：「FAQ中に存在するキーワードをあらかじめ登録し、FAQとその中で用いられるKWを関連付ける。」をそのまま関係スキーマ化したものです。
• 注意点（サブタイプとの関係）：「サブタイプが存在する場合、他のエンティティタイプとのリレーションシップは、スーパータイプ又はいずれかのサブタイプの適切な方との間に設定する。」という設計方針から、KWとFAQの関連はスーパータイプであるFAQに設定します。要点検修理FAQ（サブタイプ）はFAQをスーパータイプとして持つため、KWはFAQ側で扱えばサブタイプにも適用可能です。

• 属性：案件番号、FAQ番号、可能性順位
• 主キー: 案件番号, FAQ番号（複合）
• 外部キー: 案件番号 → 案件(案件番号)、FAQ番号 → FAQ(FAQ番号)
• 根拠：「案件でEUへの回答に適用したFAQは、案件適用FAQとして案件に関連付け、可能性の高いFAQの順に可能性順位を記録する。」に対応する関係です。可能性順位は属性として保持します。

• 属性：FAQ番号（関連元）、関連FAQ番号（関連先）、関連度ランク
• 主キー: FAQ番号, 関連FAQ番号（複合）
• 外部キー: FAQ番号 → FAQ(FAQ番号)、関連FAQ番号 → FAQ(FAQ番号)
• 根拠：「類似するFAQを関連FAQとして関連付け、関連度合いをA〜Cの3段階に分けて関連度ランクとして設定する。」ので、FAQ同士を結ぶ自己参照の中間表を置き、両方ともFAQを参照します。図3でFAQからeへ二本の線が出ているのは、FAQが「関連元」「関連先」の二つの役割を持つためです。

• 属性：FAQ番号、ユニットコード、MTコード
• 主キー: FAQ番号, ユニットコード, MTコード（複合）
• 外部キー: (FAQ番号, ユニットコード) → 要点検修理FAQ(FAQ番号, ユニットコード)、MTコード → 点検修理項目(MTコード)
• 根拠：「要点検修理FAQには、対象のユニットが何か設定するとともに、対応する点検修理項目を関連付けておく。」とあるため、既に図4で要点検修理FAQが (FAQ番号, ユニットコード) をキーとして持つ構造になっていることに注意し、点検修理項目（MTコード）との関連はその複合キーを外部キーとして参照する中間表で表現します。これにより、ある要点検修理FAQ（特定のFAQと その対象ユニット）に対して複数の点検修理項目を関連付けられます。

誤りやすいポイント

• cとeを取り違える（cはFAQとKWの中間表、eはFAQ同士の自己参照（関連FAQ））。問題文の「FAQとその中で用いられるKWを関連付ける」と「類似するFAQを関連FAQとして関連付ける」を区別すること。
• 要点検修理FAQのキー構成を見落とす（要点検修理FAQは図4で (FAQ番号, ユニットコード) を持つ）。fを作るときにFAQ番号 のみを参照してしまうとユニットとの関係を失う。
• 案件適用FAQに「可能性順位」を入れ忘れる。問題文で順序を保存することが明記されている。
• 関連FAQを単方向（ただの関連先のみ）で定義してしまうと、FAQが二つの役割を持つこと（関連元・関連先）を表現できない。設計ルール通り「役割の数だけ線を引く」ことを実装上反映する。
• サブタイプの扱いを誤る（関係を不適切にサブタイプ側だけに作る）。設計方針の「スーパータイプ又はいずれかのサブタイプの適切な方との間に設定する」を踏まえる。

FAQ

解答の論理構成

1. ユニット関連
   • 【問題文】「製品シリーズごとに、用いているユニットを登録する」→「製品シリーズ」と「ユニット」は多対多。よって中間表（キ）に両方の主キー製品シリーズコード、ユニットコードを配置。
2. 機能部品関連
   • 「機能部品を…ユニットと関連付ける」→多対多。「ユニット」「機能部品番号」を主キーとする中間表（ク）を作る。
3. FAQと KW
   • 「FAQ…を登録し、FAQとその中で用いられるKWを関連付ける」→多対多。FAQの主キーFAQ番号とKWの主キーKWで（ケ）。
4. FAQと案件
   • 「案件でEUへの回答に適用したFAQは、案件適用FAQとして案件に関連付け、可能性順位を記録する」→「案件」対「FAQ」が多対多で付加属性あり。主キー案件番号、FAQ番号＋非キー属性「可能性順位」→（コ）。
5. FAQの自己関連
   • 「類似するFAQを関連FAQとして関連付け、関連度ランクを設定」→FAQの自己多対多。自分と関連先を区別するためFAQ番号、関連FAQ番号を主キーとし「関連度ランク」を持つ（サ）。
6. FAQと点検修理項目
   • 「要点検修理FAQ…対応する点検修理項目を関連付けておく」→多対多。FAQ側キーFAQ番号と点検修理項目のキーMTコードで（シ）。

誤りやすいポイント

• FAQとKWを「カンマ区切りの列」で持たせてしまい第1正規形違反になる。
• FAQ間自己関連で「FAQ番号」しか置かず重複を許してしまい主キーが欠落。
• 「可能性順位」を主キーに含めてしまい、FAQを重複登録できなくなる。
• 点検修理項目との関連を「要点検修理FAQ」の中に埋め込み、多値属性扱いにして正規化を崩す。

FAQ