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番号で識別し、氏名、住所、住所から定まるサービス地域、電話番号、更新年月日をもつ。

1. 製品は、A社が製造販売する製品で、製品コードで識別し、製品名をもつ。
2. 製品シリーズは、製品の上位の分類で、床暖房パネル、乾燥機などがある。製品シリーズコードで識別し、製品シリーズ名をもつ。
3. 登録製品には、販売した製品を利用するEUを登録する。
   • ① 登録製品は、製品製造番号で識別する。登録製品には、製品コード、利用者のEU番号、登録製品の更新年月日を記録している。
   • ② 登録製品の利用者は、集合住宅での入退居や住宅の売買で変わり得るので、把握の都度、利用しているEUを登録又は更新する。
4. 点検修理項目は、出張による点検修理で発生し得るCEの作業項目で、メンテナンスコード（以下、MTコードという）で識別し、点検修理項目名をもつ。動作確認、分解点検、ユニット交換などがある。

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. 問合せは、製品使用者が勘違いしていたり他社製品であったりすることもあり、この場合の問合せは、後述する案件化をすることなく終わる。

1. 問合せに対して、回答のためにCCから電話をかける必要又は点検修理の必要があれば、問合せを案件化し、案件番号を発番して案件を登録する。
2. 案件は、対象製品が登録済みの登録製品に合致すればその登録製品と、合致しなければ新たな登録製品を登録して関連付ける。その際、EUが未登録又は更新が必要であれば、EUの登録又は更新も併せて行う。
3. 案件には、案件の登録年月日と更新年月日、EUに対する回答内容、案件の完結を判断するための完結フラグをもつ。
4. 案件化した問合せ及びその後の問合せは案件に従属させる。

1. 案件に対して、どのような内容で点検修理を要するか決まると出張手配を行う。
2. 出張手配は、案件に対して1回行い、EUに了解を得て出張年月日と出張時間帯を決める。

1. 手配された出張を実施すると、実施年月日と実施時間帯、担当したCE、解決したか判断するための解決フラグを記録する。
2. また、点検修理の内訳をAS実施記録として、実施したMTコード、実施金額を記録する。

1. ユニットは、部品の集合で、ユニットコードで識別し、ユニット名、ユニット概要、製造開始時期、製造終了時期をもつ。熱交換器、水流制御器などがある。
   • ① 製品の故障は、いずれかのユニットで発生する。
   • ② 製品シリーズごとに、用いているユニットを登録する。
2. 機能部品は、主要な部品で、機能部品番号で識別し、機能部品名、後述する要管理内容、製造開始時期、製造終了時期をもつ。ポンプや液晶板などがある。
   • ① 機能部品は、複数ユニット間で共通化を進めている。
   • ② 機能部品に起因する故障の頻発を予見した場合、その機能部品を要管理機能部品として要管理内容を登録し、組み込んでいるユニットと関連付ける。

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. 概念データモデル及び関係スキーマの設計は、まず現状業務について実施し、その後に修正改善要望に関する部分を実施する。
2. 関係スキーマは第3正規形にし、多対多のリレーションシップは用いない。
3. 概念データモデルでは、リレーションシップについて、対応関係にゼロを含むか否かを表す"○"又は"●"は記述しない。
4. サブタイプが存在する場合、他のエンティティタイプとのリレーションシップは、スーパータイプ又はいずれかのサブタイプの適切な方との間に設定する。
5. スーパータイプに相当する関係スキーマには、必ずサブタイプを分類する属性を明示する。
6. 同一のエンティティタイプ間に異なる役割をもつ複数のリレーションシップが存在する場合、役割の数だけリレーションシップを表す線を引く。

現状の概念データモデルを図1に、現状の関係スキーマを図2に示す。

修正改善要望に関する概念データモデルを図3に、修正改善要望に関する関係スキーマを図4に示す。

解答に当たっては、各頭の表記ルールに従うこと。また、エンティティタイプ名、関係名、属性名は、それぞれ意味を識別できる適切な名称とすること。関係スキーマに入れる属性名を答える場合、主キーを表す下線、外部キーを表す破線の下線についても答えること。