令和3年度 秋期 応用情報技術者試験 午後 問題 問8 ネットスーパーシステムの再構築におけるデータ中心設計の適用

データ中心設計(DOA: Data Oriented Approach)と対比される代表的なシステム設計手法は、プロセス中心設計(POA: Process Oriented Approach)です。

本文中において、X社がこれまで採用してきた手法は「データの設計に先行して機能を設計し，機能に合わせて必要なデータを設計する手法」と説明されています。このように業務の機能（プロセス）を中心にしてシステム構造を決定していくアプローチをプロセス中心設計と呼びます。したがって、空欄 a には「プロセス」が入ります。

図1の概念データモデルを見ると、空欄 b のエンティティは以下の関連を持っています。

• 「顧客」と1対多の関連（顧客が1、bが多）
• 「商品」と多対多の関連
• 「支払」と1対1の関連

〔現行システム機能の調査〕の「(3) 購入機能」には、「顧客が商品を購入し，料金を支払う機能」と記述されています（料金の支払が図1の「支払」に当たります）。
業務の構造上、1人の顧客は複数回の購入を行い（1対多）、1回の購入には複数の商品が含まれ、1つの商品も複数回購入されます（多対多）。また、1回の購入に対して1回の支払いが紐付きます（1対1）。

これらのエンティティ間の関係性を全て満たす業務イベントは「購入」であるため、空欄 b には「購入」が入ります。

高得点のポイント

• 〔現行システム機能の調査〕の記述から、指定された字句を正確に抜き出すこと。

図1の概念データモデルにおいて、「通常商品」自身を始点とし終点とする1対多の関連（自己参照の関連）が描かれています。これは、ある「通常商品」のデータが、他の複数の「通常商品」のデータと階層的またはグループ的に紐付くデータ構造を表しています。

〔現行システム機能の調査〕の「(2) 商品表示機能」を確認すると、商品の種別として「通常商品を束ねたセット商品」という記述があります。
1つの「セット商品」は、それ自体が商品として扱われつつ、内部的に複数の「通常商品」から構成されます。このように同一エンティティ内で「全体と部分」の関係を持つため、自己参照の1対多の関連で表現されます。

したがって、この関連が意味するものは「セット商品」となります。

高得点のポイント

• 〔現行システム機能の調査〕の記述から、通常商品の集合体を指す字句を正確に抜き出すこと。

図1の概念データモデルにおけるサブタイプの分類ルールに関する問題です。

空欄 c は、「通常商品」と「事前予約商品」の間の関係を問うています。
〔現行システム機能の調査〕の「(2) 商品表示機能」には、「事前に予約することによって通常商品を割引価格で購入できる事前予約商品」と記述されています。
これは、事前予約商品が通常商品という大きな枠組みの中の一部（特定の販売形態）であることを示しています。このように、上位のエンティティ（スーパークラス）の集合の中に、下位のエンティティ（サブクラス）の集合が完全に含まれる関係を 包含 関係と呼びます。したがって、正解は ウ です。

各選択肢の解説

• ア 共存: 1つのインスタンスが複数のサブタイプに同時に属することができる関係です。通常商品と事前予約商品は階層（包含）の関係にあるため、共存とは呼びません。
• イ 排他: あるインスタンスが複数のサブタイプのいずれか1つにしか属さない関係です。通常商品と事前予約商品は同列のサブタイプではないため、排他ではありません。

図1の概念データモデルにおけるサブタイプの分類ルールに関する問題です。

空欄 d は、「通常商品」と「お勧め商品」の間の関係を問うています。
図1では、「商品」のサブタイプとして、「通常商品・特売商品・タイムセール商品」のグループと、「お勧め商品」のグループが、別々のサブタイプ記号（白抜き三角）で接続されています。
「通常商品」などは販売形態による分類であり、互いに重複しない（排他）関係にありますが、「お勧め商品」は「顧客の購入履歴から算出した」という全く別の観点（レコメンド）による分類です。
そのため、ある商品が「通常商品」でありながら、同時に「お勧め商品」として扱われることがあり得ます。このように、1つのインスタンスが複数のサブタイプに同時に属することができる関係を 共存 関係と呼びます。したがって、正解は ア です。

各選択肢の解説

• イ 排他: 1つの商品が通常商品とお勧め商品のどちらか一方にしかなれない関係を指しますが、実際には両立し得るため誤りです。
• ウ 包含: お勧め商品の中には特売商品などが選ばれる可能性もあり、通常商品の中に完全に含まれるわけではないため誤りです。

〔顧客管理機能の設計〕において、Y君は「システム性能に重点を置きつつ、顧客管理機能への変更が他機能に与える影響を小さくする設計」を目指しています。
個人顧客を「一般個人顧客」と「会員個人顧客」の2つのテーブルに分けた場合と、「個人顧客」という1つのテーブルにまとめた場合の違いについて検討します。

選択肢 ウ は「テーブルへの列追加時に顧客管理機能のソフトウェアの影響調査の範囲が小さくなるから」としていますが、1つのテーブルに情報をまとめている場合、そのテーブルに列を追加した際の影響範囲は、テーブルを参照するすべてのプログラムに及ぶ可能性があり、テーブルを分けている場合よりもむしろ影響範囲が大きくなる（または変わらない）と考えられます。したがって、1つのテーブルにまとめた理由としては不適切であり、これが正解となります。

各選択肢の解説

• ア 一般個人顧客と会員個人顧客で属性に大きな差がないから: 図2のソフトウェアのクラス図を見ると、会員には「X社電子マネー番号」があるのみで他の属性は共通です。属性の差が小さければ、統合して1テーブルにする（不要な列はNULLを許容する等）のが自然であり、理由として適切です。
• イ 顧客種別には，多くの変更が入らないことが予想されるから: 〔現行システム機能の調査〕(1)で、過去3年間に顧客種別の変更が1回しかなかったとされています。変更頻度が低いため、変更容易性（テーブルを分ける）よりもテーブル数を減らして性能を優先する理由として適切です。
• エ 販売実績の集計などを行う場合に，二つのテーブルではテーブル結合が多くなり，データベースサーバの負荷が大きいから: 個人顧客全体を対象とした集計処理を行う際、テーブルが分かれているとUNIONやJOINなどの結合処理が必要となり、性能が低下します。システム性能に重点を置く目的と合致するため、理由として適切です。

図2のソフトウェアのクラス図において、親となる「顧客」クラスには、「顧客番号」や「配送先住所」などの共通の属性と、それらを取得する「get顧客番号()」などの共通の操作（メソッド）が定義されています。

サブクラスである「一般個人顧客」「会員個人顧客」「法人顧客」は、この「顧客」クラスを継承しています。継承を利用することで、顧客種別に関わらず共通して行われる処理（属性の定義や取得メソッドなど）を、スーパークラスである「顧客」クラスの一か所にまとめて定義することができます。

これにより、各サブクラスに同じコードを重複して記述する必要がなくなり、プログラム全体のコード量が削減されるため、ソフトウェアの肥大化を防止できます。

高得点のポイント

• クラスの継承を利用して、共通する処理（属性や操作）をまとめていることに言及できているか。
• 共通処理を一箇所で定義することで、コードの重複を防げるという論理を含められているか。

〔商品表示機能の設計〕において、Y君は変更容易性に重点を置き、図3の論理テーブルのクラス図にあるように「特売商品テーブル、セット商品テーブルなど商品種別ごとに多数のテーブルを作成するのではなく、商品種別と商品の二つのテーブルを作成」する設計としました。

もし商品種別ごとに個別のテーブルを作成する設計にした場合、新しい商品種別（例：新春福袋商品など）を追加するたびに、データベースに対して新しくテーブルを作成（追加）する作業（DDLの実行など）が必要となります。本番の運用環境へのリリース作業において、データベースの構造変更（テーブル追加）はリスクと作業時間を伴います。
一方、商品種別と商品を2つのテーブルに統合したY君の設計であれば、新しい商品種別を追加する際は、「商品種別」テーブルに新しいレコード（行データ）を1件追加するだけで済むため、テーブル構造自体の変更は発生しません。

したがって、運用環境へのリリース時に低減できる作業は「データベースへのテーブル追加作業」となります。

高得点のポイント

• 削減される作業が「テーブルを追加する作業（データベースの構造変更）」であることを明確に記述できているか。
• 「データベースの変更」といった曖昧な表現ではなく、「テーブルの作成・追加」であるという具体性を持たせられているか。

〔現行システム機能の調査〕の「(2) 商品表示機能」を確認すると、商品の特徴として「商品種別ごとに画面の表示方法が異なる」という記述があります。

図3のソフトウェアのクラス図を見ると、親の「商品」クラスを継承する形で、子クラス（特売商品、セット商品など）がそれぞれ定義されており、各子クラスが個別に「画面表示()」という操作（メソッド）を持っています。
これは、ソフトウェア上で商品種別ごとに固有の表示ロジックをカプセル化（個別に実装・オーバーライド）するためです。
このようにクラスを分けておくことで、機能変更の頻度が高い商品表示機能において、ある商品種別の表示方法を変更したい場合に、他の商品種別のプログラムに影響を与えずに安全に修正を加えることができます。

理由を「商品表示機能の特徴の観点から」述べるため、業務要件である「画面の表示方法が異なるから」という点を指摘する必要があります。

高得点のポイント

• 〔現行システム機能の調査〕に明記されている「商品種別ごとに画面の表示方法が異なる」という特徴を的確に捉えられているか。
• クラスを分割した理由を、この表示方法の差異に求める論理を簡潔に表現できているか。