戦国IT

情報処理技術者試験の過去問対策サイト

データベーススペシャリスト試験 2022年 午後101


アフターサービス業務に関する次の記述を読んで, 設問に答えよ。

   住宅設備メーカーの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に示す。
データベーススペシャリスト試験(令和4年 午後I 問1 図1)
データベーススペシャリスト試験(令和4年 午後I 問1 図2)
3.〔修正改善要望の分析結果〕 に関する設計  修正改善要望に関する概念データモデルを図3に, 修正改善要望に関する関係スキーマを図4に示す。
データベーススペシャリスト試験(令和4年 午後I 問1 図3)
データベーススペシャリスト試験(令和4年 午後I 問1 図4)
 解答に当たっては, 巻頭の表記ルールに従うこと。 また, エンティティタイプ名,関係名,属性名は, それぞれ意味を識別できる適切な名称とすること。 関係スキーマに入れる属性名を答える場合, 主キーを表す下線, 外部キーを表す破線の下線についても答えること。

アフターサービス業務に関する次の記述を読んで, 設問に答えよ。

設問1現状の概念データモデル及び関係スキーマについて答えよ。

(1)図1中の欠落しているリレーションシップを補って図を完成させよ。

模範解答

データベーススペシャリスト試験(令和4年 午後I 問1 設問1-1解答)

解説

解答の論理構成

  1. サブタイプの派生を先に確定
    • 【問題文】「BP コードで識別し … 販売パートナー(以下, SLP という) と点検修理パートナー (以下, ASPという)がある」
      → BP をスーパータイプ,SLP と ASP をサブタイプとする。
  2. サブタイプから派生するリレーション
    • 【問題文】「SLP は … 問合せの登録を行う」
    • 【問題文】「Web 問合せに経由した SLP のBPコードを記録」
      → SLP と SLPweb問合せを 1:N で接続。
    • 【問題文】「ASP は … サービス地域の幾つかごとに1社と契約」
      → ASP とサービス地域を 1:N で接続。
  3. サービス地域以降の利用者側の連鎖
    • 【問題文】「EU は … 住所から定まるサービス地域」
      → サービス地域と EU を 1:N。
    • 【問題文】「登録製品には, … EU 番号を記録」
      → EU と登録製品を 1:N。
  4. 製品トラッキング
    • 【問題文】「案件は … 登録製品と関連付ける」
      → 登録製品と案件を 1:N。
    • 【問題文】「案件化した問合せ及びその後の問合せは案件に従属」
      → 案件と問合せを 1:N。
  5. 出張系リレーション
    • 【問題文】「出張手配は, 案件に対して1回行い」
      → 案件と出張手配を 1:1。
    • 【問題文】「手配された出張を実施すると」
      → 出張手配と出張実施を 1:1。
    • 【問題文】「担当した CE」→ CE と出張実施を 1:N。
    • 【問題文】「担当BPコード」→ BP (実質は ASP) と出張実施を 1:N。
    • 【問題文】「AS 実施記録として」→ 出張実施 と AS実施記録を 1:N。
    • 【問題文】「実施したMT コード」→ 点検修理項目 と AS実施記録を 1:N。
  6. 通話系リレーション
    • 【問題文】「通話した CC 要員の社員番号」
      → CC 要員 と 通話を 1:N。
    • Web問合せと発信通話の派生は図示済みなので新規線は不要。
  7. 設計方針の整合
    すべて 1:N または 1:1 であり「多対多のリレーションシップは用いない」を満たす。またサブタイプの判別属性は BP に「SLP フラグ」「ASP フラグ」を既に保有しているので要件 (5) も充足。

誤りやすいポイント

  • 「ASP と CE」を直接結ぶ線を描く
    CE は ASP に所属するが,担当 CE 情報は出張実施に記録するため CE―出張実施線が必要。ASP―CEは線ではなく CE に外部キー (BPコード) を置く形で表現済み。
  • 「問合せ―SLP」線を追加してしまう
    SLP と関連するのは“SLP 経由の Web 問合せ”のみであり,スーパータイプの問合せに直接つなぐと 0 件許容の判定が崩れる。
  • 「サービス地域―ASP」を N:N と誤認
    文中に「幾つかごとに1社と契約」とありサービス地域側が N,ASP 側が 1 になる。

FAQ

Q: 案件と出張手配は 1:1 ですか,1:N ですか?
A: 【問題文】「出張手配は, 案件に対して1回行い」と明記されているので 1:1 です。
Q: CE と BP(ASP) の両方を出張実施に持たせるのは冗長では?
A: CE がどの ASP に属するかは BPコード+CE番号でわかります。しかし設計方針 (2) で「多対多を用いない」ため,出張実施側に単純キーを持たせるなら CE と BP の両外部キーを置くのが最もシンプルです。
Q: CC要員と問合せはなぜ直接つながないのですか?
A: 問合せ経路として CC要員が関与するのは“通話”のみです。【問題文】「通話の場合, 通話した CC 要員の社員番号」と限定されているため,通話を介したリレーションで表現します。

関連キーワード: ER図設計, スーパタイプ, 1対多リレーション, 外部キー, 正規化

設問1現状の概念データモデル及び関係スキーマについて答えよ。

(2)図2中の(ア)〜(カ)に入れる一つ又は複数の適切な属性名を補って関係スキーマを完成させよ。

模範解答

ア:問合せ年月日時刻, 問合せ内容, 連絡先お名前, 連絡先電話番号, 媒体区分, 案件番号 イ:SLP製品使用者入力区分 ウ:SLPBPコード エ:通話社員番号, 通話時間, 通話成立フラグ, 通話音声, 受発区分 オ:発信元Web問合せ番号 カ:出張年月日, 出張時間帯

解説

解答の論理構成

  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

Q: 媒体別にテーブルを分割する必要はありますか?
A: 本問では媒体を示す “媒体区分” があるため一つの「問合せ」エンティティで管理し,媒体固有情報がある場合のみサブタイプ(Web問合せ・通話)を派生させています。
Q: “SLP製品使用者入力区分” と “SLPBPコード” を1つのテーブルに入れては駄目?
A: “SLP製品使用者入力区分” はWeb問合せ全体の属性ですが “SLPBPコード” は SLP 経由のときにだけ意味を持つため,サブタイプ “SLPweb問合せ” に分離すると非該当レコードで NULL が乱立するのを防げます。
Q: “出張手配” に出張先 EU 情報を持たせない理由は?
A: EU は “案件” 経由で一意に決まるので冗長です。第3正規形の原則どおり部分従属を排除します。

関連キーワード: データモデリング, 正規化, 外部キー, サブタイプ, 関係スキーマ

設問2修正改善要望に関する概念データモデル及び関係スキーマについて答えよ。

(1)次の問いに答えて図3を完成させよ。  (a)図3中の(あ)〜(う)には、には,図1に示した現状の概念データモデル中のエンティティタイプ名のいずれかが入る。(あ)〜(う)に入れる適切なエンティティタイプ名を答えよ。  (b)図3中の欠落しているリレーションシップを補え

模範解答

(a):  あ:製品シリーズ  い:点検修理項目  う:案件 (b): データベーススペシャリスト試験(令和4年 午後I 問1 設問2-1解答)

解説

解答の論理構成

  1. 「ユニット」に結び付ける既存エンティティを決定
    • 要件1②より「製品シリーズごとに, 用いているユニットを登録する。」
    • よって(あ)は「製品シリーズ」。
  2. 点検修理 FAQ と関連付ける既存エンティティを決定
    • 要件2①③より「要点検修理 FAQ には、…対応する点検修理項目を関連付けておく。」
    • よって(い)は「点検修理項目」。
  3. FAQ を案件にひも付ける既存エンティティを決定
    • 要件2③より「案件で EU への回答に適用した FAQ は, 案件適用 FAQ として案件に関連付け…」
    • よって(う)は「案件」。
  4. 欠落リレーションシップの補完(概要)
    • 製品シリーズ-ユニット:多対多を避けて橋渡しエンティティ(a)を作成。
    • ユニット-要管理機能部品:多対多を避けて橋渡しエンティティ(b)。
    • FAQ-KW:FAQ 中のキーワード抽出を表す橋渡し(c)。
    • 案件-FAQ:案件適用 FAQ を表す橋渡し(d)。
    • FAQ-FAQ:関連 FAQ を表す自己リレーション(e)。
    • 要点検修理FAQ-点検修理項目:橋渡し(f)。

誤りやすいポイント

  • 「ユニット」と「製品」を直接結び付ける誤答
    要件では「製品シリーズごとに」と明記され、「製品単位」ではない。
  • 「FAQ」をスーパータイプと誤認し「要点検修理FAQ」を独立エンティティで描かない
    第3正規形・サブタイプ規則(設計方針1(5))により「FAQ」の主キーを共有するサブタイプとして扱う必要がある。
  • 「FAQ と KW は多対多だが、橋渡しエンティティを忘れる」
    設計方針1(2)「多対多のリレーションシップは用いない」による。

FAQ

Q: なぜ「製品シリーズ」でなく「製品」ではいけないのですか?
A: 要件1②に「製品シリーズごとに, 用いているユニットを登録する。」と明示されています。シリーズ単位での共通部品管理が目的なので「製品」では要件を満たしません。
Q: 「要点検修理FAQ」を「FAQ」に包含せず別エンティティにしても良い?
A: 設計方針1(4)(5)が「サブタイプが存在する場合、スーパータイプ又はいずれかのサブタイプの適切な方との間に設定し、スーパータイプには分類属性を明示」と規定しているため、「FAQ」―「要点検修理FAQ」のサブタイプ構造が最適です。
Q: 同一エンティティ間リレーション(FAQ 間の関連度)はどう表しますか?
A: 設計方針1(6)に従い「FAQ」から「FAQ」へ役割を示す別線を引き、橋渡しエンティティ(e)を設けて関連度ランクを持たせます。

関連キーワード: 第3正規形, サブタイプ構造, 多対多回避, ブリッジテーブル, ERモデリング

設問2修正改善要望に関する概念データモデル及び関係スキーマについて答えよ。

(2)図4中の(キ)~(シ)に入れる一つ又は複数の適切な属性名を補って関係スキーマを完成させよ。

模範解答

キ:製品シリーズコード, ユニットコード ク:ユニットコード, 機能部品番号 ケ:FAQ番号, KW コ:案件番号, FAQ番号, 可能性順位 サ:FAQ番号, 関連FAQ番号, 関連度ランク シ:FAQ番号, MTコード

解説

解答の論理構成

  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

Q: なぜ(コ)に「可能性順位」が必要なのですか?
A: 【問題文】「可能性の高い FAQ の順に可能性順位を記録する」と明記されているため、案件と FAQ の組に属する属性として保持します。
Q: FAQ と KW の関係は 1 対多ではないのですか?
A: FAQ 内には複数 KW が含まれ、逆に同じ KW が複数 FAQ で繰り返し使われるため多対多となります。
Q: FAQ 自己関連で循環参照は問題になりませんか?
A: 主キーをFAQ番号, 関連FAQ番号で定義すれば通常の外部キー制約で整合性を取れるので問題ありません。

関連キーワード: 第3正規形, 多対多解消, 中間テーブル, スーパータイプ, 外部キー
← 前の問題へ次の問題へ →

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