ホーム > データベーススペシャリスト試験 > 2022年
データベーススペシャリスト試験 2022年 午後1 問01
アフターサービス業務に関する次の記述を読んで, 設問に答えよ。
住宅設備メーカーのA社は, アフターサービス業務 (以下, AS 業務という)のシステム再構築で, 業務分析を行って概念データモデルと関係スキーマを設計した。
〔現状業務の分析結果〕
1．社内外の組織, 人的資源の特性
(1) カスタマーセンター(以下, CCという)は, A社に一つだけある組織である。
(2) CC の要員であるカスタマー係 (以下, CC 要員という)は,社員番号で識別し、氏名をもつ。
(3) ビジネスパートナー (以下, BP という)は, A 社の協業先企業で, BP コードで識別し, BP 名, 所在地をもつ。 AS 業務の範囲のBP には, 販売パートナー(以下, SLP という) と点検修理パートナー (以下, ASPという)がある。
① SLP は、 販売店, 工務店など, A 社の製品をエンドユーザー (以下, EU という)に販売, 設置をする企業であり, 後述する問合せの登録を行う。 SLP はSLP フラグで分類し、 業種と前年販売高をもつ。
② ASP は, 点検修理の委託先企業で, 全国を数百のサービス地域に分け, サービス地域の幾つかごとに1社と契約している。 ASP は ASP フラグで分類し, 後述するカスタマーエンジニア (以下, CE という) の人数であるCE 数をもつ。
(4) CE は, ASP に所属する技術者で, ASP ごとのCE 番号であらかじめ登録している。 氏名をもつ。
(5) EUは,製品の利用者で, EU 番号で識別し,氏名,住所,住所から定まるサービス地域,電話番号,更新年月日をもつ。
2．製品などのもの, 点検修理項目の特性
(1) 製品は, A社が製造販売する製品で、 製品コードで識別し, 製品名をもつ。
(2) 製品シリーズは、製品の上位の分類で、 床暖房パネル, 乾燥機などがある。製品シリーズコードで識別し, 製品シリーズ名をもつ。
(3) 登録製品には、 販売した製品を利用するEU を登録する。
① 登録製品は, 製品製造番号で識別する。 登録製品には, 製品コード,利用者のEU 番号,登録製品の更新年月日を記録している。
②登録製品の利用者は、集合住宅での入退居や住宅の売買で変わり得るので把握の都度,利用している EU を登録又は更新する。
(4) 点検修理項目は、出張による点検修理で発生し得る CE の作業項目で, メンテナンスコード(以下, MT コードという)で識別し, 点検修理項目名をもつ。 動作確認,分解点検, ユニット交換などがある。
3．問合せの登録
(1) 製品使用者の使用上の不具合や違和感がA社に対する問合せとなる。
(2) 問合せは, 製品使用者から直接又はSLP 経由で CC に入る。
(3) 問合せの媒体は, Web 上の問合せフォームか電話による通話である。いずれであるか媒体区分で分類する。
(4) 一つの問合せは、 問合せフォームから入る1件の問合せ文又は1回の通話で,問合せ番号で識別し, 問合せ年月日時刻, 問合せ内容のほかに, 製品使用者への連絡のための情報として, お名前と電話番号を記録する。 この段階での連絡のための情報は, 登録されているEUのものとは関連付けない。
(5) 製品使用者が直接入れる問合せは通話と問合せフォームの両方があり得るが,SLP 経由の場合は問合せフォームからに限定している。
(6) 入った Web 問合せに対して CC 要員が製品使用者に電話をかける。 その Web 問合せが SLP 経由だった場合, 製品使用者にどの SLP から受け継いだかを伝えるために,Web 問合せに経由したSLP のBPコードを記録している。
(7) 通話は,成立しなくても1回の通話としている。 通話が成立しないケースは,受信の場合は CC 要員の応答前に切れるケース, 発信の場合は相手が話し中又は応答がないケースである。 通話の成立は通話成立フラグで分類する。
(8) 通話の場合, 通話した CC 要員の社員番号,通話時間, 受信か発信かの受発区分,音声データである通話音声を記録している。
(9) 問合せは, 製品使用者が勘違いしていたり他社製品であったりすることもありこの場合の問合せは,後述する案件化をすることなく終わる。
4．問合せの案件化
(1) 問合せに対して, 回答のために CC から電話をかける必要又は点検修理の必要があれば、問合せを案件化し, 案件番号を発番して案件を登録する。
(2) 案件は,対象製品が登録済みの登録製品に合致すればその登録製品と、合致しなければ新たな登録製品を登録して関連付ける。 その際, EU が未登録又は更新が必要であれば, EU の登録又は更新も併せて行う。
(3) 案件には, 案件の登録年月日と更新年月日, EU に対する回答内容, 案件の完結を判断するための完結フラグをもつ。
(4) 案件化した問合せ及びその後の問合せは案件に従属させる。
5．出張の手配
(1) 案件に対して,どのような内容で点検修理を要するか決まると出張手配を行う。
(2) 出張手配は, 案件に対して1回行い, EU に了解を得て出張年月日と出張時間帯を決める。
6．出張の実施
(1) 手配された出張を実施すると, 実施年月日と実施時間帯, 担当した CE, 解決したか判断するための解決フラグを記録する。
(2) また, 点検修理の内訳を AS 実施記録として, 実施したMT コード, 実施金額を記録する。
〔修正改善要望の分析結果〕
1．ユニット及び要管理機能部品の追加
(1) ユニットは, 部品の集合で, ユニットコードで識別し, ユニット名 ユニット概要, 製造開始時期, 製造終了時期をもつ。 熱交換器, 水流制御器などがある。
① 製品の故障は,いずれかのユニットで発生する。
② 製品シリーズごとに, 用いているユニットを登録する。
(2) 機能部品は, 主要な部品で, 機能部品番号で識別し,機能部品名, 後述する要管理內容,製造開始時期, 製造終了時期をもつ。 ポンプや液晶板などがある。
① 機能部品は、 複数ユニット間で共通化を進めている。
② 機能部品に起因する故障の頻発を予見した場合、 その機能部品を要管理機能部品として要管理内容を登録し, 組み込んでいるユニットと関連付ける。
2．FAQ 及びキーワードの整備
(1) 既出の問合せ内容と回答内容の組を FAQ として登録することで, 新たな問合せに対して FAQ を確認して迅速に正しい回答ができるようにする。
① FAQ は, FAQ 番号で識別し, 問合せ内容, 回答内容, 点検修理の必要性を分類する要点検修理フラグ, 発生度ランクをもつ。
② FAQ は, 点検修理が必要となる要点検修理 FAQ とその必要のないその他のFAQ に分類し, 要点検修理 フラグで分類する。
③ 要点検修理 FAQ には、対象のユニットが何か設定するとともに, 対応する点検修理項目を関連付けておく。
④ FAQ には,問合せ内容の解釈によって類似の FAQ が複数存在し得るので, 類似する FAQ を関連 FAQ として関連付け, 関連度合いを A〜Cの3段階に分けて関連度ランクとして設定する。
(2) FAQ 中に存在するキーワード (以下, KW という)をあらかじめ登録し, FAQ とその中で用いられる KW を関連付ける。 KWはKWそのもので識別し, 補足説明をもつ。
(3) 案件で EUへの回答に適用した FAQ は, 案件適用 FAQ として案件に関連付け,可能性の高い FAQ の順に可能性順位を記録する。
〔概念データモデルと関係スキーマの設計〕
1．概念データモデル及び関係スキーマの設計方針
(1) 概念データモデル及び関係スキーマの設計は、まず現状業務について実施し,その後に修正改善要望に関する部分を実施する。
(2) 関係スキーマは第3正規形にし, 多対多のリレーションシップは用いない。
(3) 概念データモデルでは, リレーションシップについて, 対応関係にゼロを含むか否かを表す “○” 又は“●”は記述しない。
(4) サブタイプが存在する場合、他のエンティティタイプとのリレーションシップは,スーパータイプ又はいずれかのサブタイプの適切な方との間に設定する。
(5) スーパータイプに相当する関係スキーマには,必ずサブタイプを分類する属性を明示する。
(6) 同一のエンティティタイプ間に異なる役割をもつ複数のリレーションシップが存在する場合, 役割の数だけリレーションシップを表す線を引く。
〔現状業務の分析結果〕 に基づく設計
現状の概念データモデルを図1に, 現状の関係スキーマを図2に示す。
3．〔修正改善要望の分析結果〕 に関する設計
修正改善要望に関する概念データモデルを図3に, 修正改善要望に関する関係スキーマを図4に示す。
解答に当たっては, 巻頭の表記ルールに従うこと。 また, エンティティタイプ名,関係名,属性名は, それぞれ意味を識別できる適切な名称とすること。 関係スキーマに入れる属性名を答える場合, 主キーを表す下線, 外部キーを表す破線の下線についても答えること。
設問1（1）：現状の概念データモデル及び関係スキーマについて答えよ。
図1中の欠落しているリレーションシップを補って図を完成させよ。
模範解答
解説
解答の論点整理
図１の概念データモデル（未完成）には，以下のリレーションシップが抜けています。
- CE（カスタマーエンジニア）と ASP の所属関係
- SLP（販売パートナー）と SLPweb問合せ の登録関係
- 通話（電話による問合せ）と CC要員（カスタマー係）の担当関係
これらを追加すると，業務の流れと「誰が／どの組織が関与したか」が全てモデル化され，問題文の要件を満たす概念データモデルが完成します。
① CE と ASP の所属関係
要件の引用
「CE は, ASP に所属する技術者で, ASP ごとの CE 番号であらかじめ登録している。氏名をもつ。」
解説
- 「所属する」という文言から，CE と ASP の間には 1 対多（ASP 1 社に複数の CE）のリレーションシップが必要です。
- 未完成の図１では CE が孤立しており，どの ASP に属するかが表現されていません。
- したがって，ASP → CE の矢印（あるいは実線）を引き，CE 側に外部キーとして ASP の主キー（BPコード）を持たせます。
ASP ---< CE
（ASP 1社に対して CE 複数）
② SLP と SLPweb問合せ の登録関係
要件の引用
「SLP は … AS 業務の範囲の BP には, 販売パートナー（SLP）… がある。… SLP は … 後述する問合せの登録を行う。」
「SLP 経由の場合は問合せフォームからに限定している。」
解説
- 「SLP が問合せの登録を行う」 ← 問合せの一種である SLPweb問合せ（問合せフォーム経由，かつ SLP 経由のもの）を SLP が起票する。
- 図１では問合せサブタイプ SLPweb問合せが定義されているものの，SLP からのリレーションシップが抜けています。
- これを補うには SLP → SLPweb問合せ の線を引き，SLPweb問合せ 側に外部キーとして BPコード（SLP を識別するキー）を持たせます。
SLP ---< SLPweb問合せ
（SLP 1社に対して複数の経由問合せ）
③ 通話 と CC要員 の担当関係
要件の引用
「通話の場合, 通話した CC 要員の社員番号 … を記録している。」
解説
- CC要員（カスタマー係）が受発信いずれの場合も通話を担当する。
- 未完成の図１では CC要員 が出張実施に結び付いているものの，通話業務とのリレーションシップが表現されていません。
- したがって，CC要員 → 通話 の線を引き，通話側に外部キーとして CC要員の社員番号を持たせます。
CC要員 ---< 通話
（CC要員 1名に対して複数の通話記録）
誤りやすいポイント
試験対策として覚えておくべきポイント
- 所属関係の明示
「～に所属する」「～をもつ」と書かれていたら，必ず実線でエンティティ同士の結び付けを行う。 - サブタイプの扱い
問合せのように「直接」「経由」「媒体別」で区分されたものは，サブタイプとしてまとめ，必要に応じて親子関係とサブタイプ間のリレーションを正しく表す。 - 担当者・策定者情報
作業ログ（通話，点検・修理など）は必ず「誰が担当したか」を外部キーで対応付け，業務履歴を完全にトレースできるようにする。 - 属性記述だけに頼らない
属性として「BPコードを持つ」と書かれていても，概念モデルでは属性ではなくリレーションシップとして明示的に線を引く。 - 問題文の逐語読み
関係の有無・多重度は問題文に明記されているので，「○人に対して×件」といった具体例を見逃さないようにする。
これらを意識して概念データモデルを描ければ，第３正規形への展開や関係スキーマ設計もスムーズになります。
設問1（2）：現状の概念データモデル及び関係スキーマについて答えよ。
図2中の（ア）〜（カ）に入れる一つ又は複数の適切な属性名を補って関係スキーマを完成させよ。
模範解答
ア：問合せ年月日時刻, 問合せ内容, 連絡先お名前, 連絡先電話番号, 媒体区分, 案件番号
イ：SLP製品使用者入力区分
ウ：SLPBPコード
エ：通話社員番号, 通話時間, 通話成立フラグ, 通話音声, 受発区分
オ：発信元Web問合せ番号
カ：出張年月日, 出張時間帯
解説
模範解答の論点整理
小問では，図２中の（ア）～（カ）に入る属性を，現状業務の記述を根拠として補完します。
ポイントは以下の６箇所です。
ポイントは以下の６箇所です。
補完した属性と根拠の引用
1. 問合せ（ア）の補完
- 「一つの問合せは…問合せ番号で識別し, 問合せ年月日時刻, 問合せ内容のほかに, 製品使用者への連絡のための情報として, お名前と電話番号を記録する。」（問題文【3.(4)】）
- 「問合せの媒体は, Web 上の問合せフォームか電話による通話である。いずれであるか媒体区分で分類する。」（問題文【3.(3)】）
- 「製品使用者が勘違い…この場合の問合せは…案件化をすることなく終わる。」（問題文【3.(9)】）
- 案件化した問合せは後の「案件」テーブルと関連付けるため，案件番号を外部キーとして保持します。
2. Web問合せ（イ）の補完
- 「製品使用者が直接入れる問合せは通話と問合せフォームの両方があり得るが, SLP 経由の場合は問合せフォームからに限定している。」（問題文【3.(5)】）
- Web問合せが「直接かSLP経由か」を区別する必要があるため，SLP経由かどうかを示すフラグを設けます。
3. SLPweb問合せ（ウ）の補完
- 「そのWeb問合せがSLP経由だった場合, 製品使用者にどのSLPから受け継いだかを伝えるために, Web問合せに経由したSLPのBPコードを記録している。」（問題文【3.(6)】）
4. 通話（エ）の補完
- 「通話の成立は通話成立フラグで分類する。」（問題文【3.(7)】）
- 「通話の場合, 通話したCC要員の社員番号, 通話時間, 受信か発信かの受発区分, 音声データである通話音声を記録している。」（問題文【3.(8)】）
5. 発信通話（オ）の補完
- 「入ったWeb問合せに対してCC要員が製品使用者に電話をかける。」（問題文【3.(6)】）
- 発信通話はWeb問合せから派生するため，発信元のWeb問合せ番号を外部キーとして保持します。
6. 出張手配（カ）の補完
- 「出張手配は, 案件に対して1回行い, EU に了解を得て出張年月日と出張時間帯を決める。」（問題文【5.(2)】）
受験者が誤りやすいポイント
- 案件番号の所在
問合せに「案件番号」を含めるのは，すべての問合せが案件化されるわけではないため任意の外部キーです。 - Web問合せとSLPweb問合せの役割分担
- Web問合せは「フォーム入力」という媒体のサブタイプ。
- SLPweb問合せは，さらに「SLP経由」という分類のサブタイプで，BPコードを保持。
この二重のサブタイプ関係を混同しないこと。
- 発信通話の外部キー
発信通話は通話のサブタイプで，必ずどのWeb問合せが発信の発端なのかを示すFKが必要です。 - 属性名の表記統一
問題文の用語を正確に引用し，「〇〇フラグ」「〇〇番号」といった語尾まであわせること。
試験対策として覚えておくべきポイント
- 問合せ～案件化～出張手配～出張実施の業務フローをテーブル構造に対応させる流れを押さえる。
- サブタイプ関係では，スーパタイプの主キーをサブタイプで外部キー兼主キーにする設計と，サブタイプ固有の属性をサブタイプ側で定義すること。
- テキストにある「…を記録する」「…で分類する」といったフレーズはすべて属性設定の根拠になる。
- 「フラグ」「番号」「年月日時刻」「区分」などの語句は，テーブル名・属性名にそのまま使われることが多いので，問題文から正確に抜き出す練習をしておく。
設問2（1）：修正改善要望に関する概念データモデル及び関係スキーマについて答えよ。
次の問いに答えて図3を完成させよ。
(a)図3中の（あ）〜（う）には、には,図1に示した現状の概念データモデル中のエンティティタイプ名のいずれかが入る。（あ）〜（う）に入れる適切なエンティティタイプ名を答えよ。
(b)図3中の欠落しているリレーションシップを補え
模範解答
(a)：
あ：製品シリーズ
い：点検修理項目
う：案件
(b)：
解説
解答の概要
設問では，修正改善要望に関する概念データモデル（図３）中の（あ）～（う）に入るエンティティタイプ名を特定し，さらに図３に明示されていないリレーションシップ（矢印）を補うことが求められています。
(a)（あ）～（う）に入るエンティティタイプ
｜ 空欄 ｜ エンティティタイプ名 ｜ 根拠となる記述
｜:----:｜:------------------:｜:---------------------------------------------
｜ （あ） ｜ 製品シリーズ ｜ 「製品シリーズは，製品の上位の分類で，製品シリーズコードで識別し，製品シリーズ名をもつ。」
｜ （い） ｜ 点検修理項目 ｜ 「点検修理項目は，出張による点検修理で発生し得る CE の作業項目で，メンテナンスコードで識別し，点検修理項目名をもつ。」
｜ （う） ｜ 案件 ｜ 「問合せに対して…案件化し，案件番号を発番して案件を登録する。」
｜:----:｜:------------------:｜:---------------------------------------------
｜ （あ） ｜ 製品シリーズ ｜ 「製品シリーズは，製品の上位の分類で，製品シリーズコードで識別し，製品シリーズ名をもつ。」
｜ （い） ｜ 点検修理項目 ｜ 「点検修理項目は，出張による点検修理で発生し得る CE の作業項目で，メンテナンスコードで識別し，点検修理項目名をもつ。」
｜ （う） ｜ 案件 ｜ 「問合せに対して…案件化し，案件番号を発番して案件を登録する。」
解説
- 空欄（あ）は，図３の最上段左端に位置し，「ユニット」「要管理機能部品」「KW」「い」と並列関係にあります。現状モデル（図１）で「製品シリーズ」はユニットや要管理機能部品と並列に上位分類として扱われるため，（あ）＝「製品シリーズ」となります。
- 空欄（い）は，最上段右端にあり，いわゆる修正改善要望のうち「点検修理項目」を拡張しているので，（い）＝「点検修理項目」です。
- 空欄（う）は，中段左側に独立して置かれ，「問合せ→案件→出張手配…」の流れの一部として，AS業務全体で重要な「案件」に相当します。
(b) 図３に欠落しているリレーションシップ
図３では，白塗りのエンティティ（製品シリーズ、ユニット，要管理機能部品，KW，点検修理項目，案件）と灰色の要素（a～f）が矢印で結ばれることで，それぞれの関係（リレーションシップ）を表現します。以下に，問題文中の要件から「補うべき」矢印（リレーションシップ）をまとめます。
-
製品シリーズ → a
「製品シリーズごとに，用いているユニットを登録する」ため，製品シリーズとユニット関連を表す a が必要。 -
ユニット → b
「ユニットは部品の集合…」に対応し，ユニットと機能部品の対応を表す b。 -
要管理機能部品 → b
「その機能部品を要管理機能部品として…組み込んでいるユニットと関連付ける」ため，要管理機能部品とユニット対応を表す b。 -
要管理機能部品 → FAQ
「FAQ のうち要点検修理FAQには，対象のユニットが何か設定するとともに…」の流れ上，要管理機能部品の管理情報とFAQとの関連を補う。 -
KW → c
「FAQ 中に存在するキーワード (KW) をあらかじめ登録し，FAQ と…関連付ける」ため，KWとFAQ関連を表す c。 -
KW → e
「案件で EU への回答に適用した FAQ は…案件適用 FAQ として…関連付け」する流れの中で，KW⇔案件適用FAQ 関係を表す e。 -
KW → 要点検修理FAQ
要点検修理FAQのうちキーワードで検索・絞り込みを行うため，KWと要点検修理FAQの直結リレーションを補完。 -
FAQ → c
KWとFAQの関係と対をなす形で，FAQ側からも c リレーション。 -
FAQ → e
FAQが案件適用FAQの要素となるためのリレーション e。 -
FAQ → f
「要点検修理FAQ」への分類・サブタイプ化を表すため，FAQ→f を設定。 -
要点検修理FAQ → f
サブタイプ「要点検修理FAQ」がユニットやFAQ要素を受けるための f。 -
点検修理項目 → f
「要点検修理FAQ には…対応する点検修理項目を関連付けておく」要件により，点検修理項目→f。 -
(う：案件) → d
「案件で EU への回答に適用した FAQ は…案件適用 FAQ として案件に関連付け」され，案件適用FAQを表す d。 -
(う：案件) → e
同じく案件→e による「FAQ適用順位を記録する」関係を補う。
まとめ：補うべきリレーションシップ一覧
受験者向けワンポイント
-
サブタイプと汎化
「要点検修理FAQ」はFAQのサブタイプ（要点検修理が必要なFAQ）として表現します。概念データモデルでは，汎化／特殊化を使い分け，関係スキーマでは「要点検修理フラグ」を持つサブタイプとして実装します。 -
多対多を避ける設計
KWとFAQ，FAQと案件，ユニットと機能部品など，本来は多対多関係となるものを中間エンティティ（c,d,e,fなど）で表現し，第3正規形を維持します。 -
業務要件からリレーションシップを読み取る
「どの情報がどの情報に依存／関連しているか」を要件文から丁寧に抽出し，図上の矢印やリレーションシップ要素に反映させることが合否のカギです。 -
名称の一貫性
エンティティ名・属性名は要件文と同じ名称を使い（改変禁止），スーパタイプ／サブタイプ属性（フラグ）も明示的に設計に含めることを忘れないようにしましょう。
設問2（2）：修正改善要望に関する概念データモデル及び関係スキーマについて答えよ。
図4中の（キ）～（シ）に入れる一つ又は複数の適切な属性名を補って関係スキーマを完成させよ。
模範解答
キ：製品シリーズコード, ユニットコード
ク：ユニットコード, 機能部品番号
ケ：FAQ番号, KW
コ：案件番号, FAQ番号, 可能性順位
サ：FAQ番号, 関連FAQ番号, 関連度ランク
シ：FAQ番号, MTコード
解説
キーワード・論点整理
- 多対多のリレーションシップは用いない → 多対多関係は中間リレーション（結合関係）としてモデル化
- 第３正規形の関係スキーマ設計 → 各テーブルが主キーとそれに従属する属性のみを持ち、属性間の推移的依存を排除
- 中間テーブルに必要な属性
- 外部キー（FK）として関係するエンティティの主キー
- 要件に応じた追加属性（可能性順位、関連度ランクなど）
- 設問対象の６つの多対多関係箇所
- 製品シリーズ ⇔ ユニット
- ユニット ⇔ 要管理機能部品
- FAQ ⇔ KW
- 案件 ⇔ FAQ（案件適用FAQ）
- FAQ ⇔ 関連FAQ（関連FAQとしての自己リレーション）
- 要点検修理FAQ ⇔ 点検修理項目（MTコード）
解答の論理的説明
以下、図 4 中の（キ）～（シ）それぞれについて、設問文の記述を引用しながら補完属性を説明します。
-
（キ）：製品シリーズ ⇔ ユニット
「【修正改善要望の分析結果】1.(1)② 製品シリーズごとに, 用いているユニットを登録する。」
→ 多対多関係を解消する中間テーブルには両エンティティの主キーである「製品シリーズコード」「ユニットコード」を外部キーとして持たせます。 -
（ク）：ユニット ⇔ 要管理機能部品
「【修正改善要望の分析結果】1.(2)② 機能部品を要管理機能部品として…組み込んでいるユニットと関連付ける。」
→ 「ユニットコード」「機能部品番号」を外部キーとして持つ中間テーブルが必要です。 -
（ケ）：FAQ ⇔ KW
「【修正改善要望の分析結果】2.(1)中段 ② 'FAQ とその中で用いられる KW を関連付ける。'」
→ FAQ番号 と KW（キーワード）を外部キーとして多対多の中間テーブルを作成します。 -
（コ）：案件 ⇔ FAQ（案件適用FAQ）
「【修正改善要望の分析結果】2.(3) '案件で EUへの回答に適用した FAQ は, 案件適用 FAQ として案件に関連付け, 可能性の高い FAQ の順に可能性順位を記録する。'」
→ 中間テーブルには「案件番号」「FAQ番号」および「可能性順位」属性を含めます。 -
（サ）：FAQ ⇔ 関連FAQ
「【修正改善要望の分析結果】2.(1)④ '類似する FAQ を関連 FAQ として関連付け, 関連度合いを A〜Cの3段階に分けて関連度ランクとして設定する。'」
→ 自己リレーションの中間テーブルとして「FAQ番号」「関連FAQ番号」「関連度ランク」を持ちます。 -
（シ）：要点検修理FAQ ⇔ 点検修理項目
「【修正改善要望の分析結果】2.(1)③ '要点検修理 FAQ には…対応する点検修理項目を関連付けておく。'」
→ 要点検修理FAQ と 点検修理項目（MTコード）を結ぶ多対多の中間テーブルに「FAQ番号」「MTコード」を持たせます。
受験者が誤りやすいポイント
- 多対多関係の見落とし
- 要件文中の「関連付ける」「登録する」という文言を見落とし、1対多として扱い中間テーブルを作らない。
- 中間テーブルに必要な追加属性の忘却
- 案件適用FAQ表に「可能性順位」、関連FAQ表に「関連度ランク」を入れ忘れる。
- 自己リレーションの取り扱い
- 関連FAQを自己結合と見なさず、FAQテーブルに同一カラムを追加しようとする。
- キーワード（KW）を重複登録カラムと誤認
- KWテーブルの主キー「KW」を外部キーに使うことを忘れる。
- MTコードの関連先を混同
- 要点検修理FAQとユニットコードのみを持つ既存スキーマに追加し、MTコードを登録製品や別テーブルに誤って結びつける。
試験対策まとめ
- 多対多（M:N）リレーションは必ず中間テーブルを作る
- 中間テーブルには
- 関係する全てのエンティティの主キーを外部キーとして持たせる
- 要件定義で指示された追加属性（順位やランクなど）を忘れずに
- 設問の要求範囲をしっかり把握し、不要な属性は記述しない
- 自己リレーションやサブタイプ・スーパータイプの規則を混同しない
- 第３正規形の原則に立ち返り、各リレーションの主キーと従属属性を整理すること
- 過去問や類題演習で、多対多関係の中間テーブル設計に慣れておくこと