応用情報技術者 2021年 秋期 午後 問08

解答の論理構成

1. 問題文では、データ中心設計と対比される設計手法について
   「“X社がこれまで採用してきたa中心設計は、データの設計に先行して機能を設計し、機能に合わせて必要なデータを設計する手法である。”」
   と述べています。
2. キーワードは「機能を設計」→業務処理や処理手順（プロセス）から先に決めることを指します。
3. 伝統的に、データ中心設計の対概念は “プロセス中心設計” と呼ばれ、処理（プロセス）を起点にシステムを組み立てます。
4. よって a に入るのは「プロセス」であり、解答は
   a：プロセス
   となります。

誤りやすいポイント

• 「機能中心」「機能指向」と答えてしまう
  └ 設問は用語を “中心設計” という枠組みで対比しているため、「プロセス中心設計」という正式呼称が求められます。
• 「手続き」「アルゴリズム」など細部に引きずられる
  └ 機能の定義＝処理手順＝プロセスという一般的な整理を押さえると迷いません。
• “データ駆動” と“データ中心”を混同
  └ データ駆動は実装寄りの概念、ここでは上流設計手法の名称が問われています。

FAQ

解答の論理構成

1. 図1では「顧客──〈←→〉──b──〈→〉──商品」という関連が描かれています。
   • 「顧客」と「商品」の間に多対多が存在し、その解消用に中間エンティティ b が置かれていることが分かります。
2. 中間エンティティの名称は【現行システム機能の調査】にある業務用語から選ぶよう指示されています。
   • 同箇所には「(3) 購入機能　顧客が商品を購入し、料金を支払う機能。」という記述があります。
3. 顧客と商品を結び付ける業務行為は「購入」に相当し、しかも「購入」はエンティティとして実体（購入日時、数量、金額など）を持つのが自然です。
4. さらに図1では b と商品の間が「1対多」となっています。
   • 1つの購入に対し複数の「商品」が紐付く＝1回の購入で複数商品を買う、という実態を表しています。
5. 以上より、中間エンティティ b に入る適切な字句は【現行システム機能の調査】内の「購入」であることが論理的に導けます。

誤りやすいポイント

• 「支払」や「注文」と混同しやすい
  「支払」は決済手段との関連性が強く、図1では別途「支払」サブタイプが示されているため不適切です。
• cardinality の読み違え
  「1対多」を「多対多」と誤認すると「購入明細」など別名を考えてしまいがちです。
• 【問題文】以外の造語を入れてしまう
  設問は「〔現行システム機能の調査〕内の字句を使って答えよ」と明示しているため、そこに掲載されていない語を選ぶと失点します。

FAQ

解答の論理構成

1. 図1には、エンティティ「通常商品」から同じ「通常商品」へ向かう 1対多 の自己関連が描かれています。
2. この自己関連が何を示すかは、【現行システム機能の調査】の(2) 商品表示機能に記載された商品種別の説明から読み取ります。
3. 同説明には、商品種別として
   「通常商品のほか、通常商品を束ねたセット商品、特売商品、…」
   とあります。
4. 「通常商品を束ねた」という表現は、1つの“束ね役”となるエンティティ（親の通常商品）が複数の“束ねられる”エンティティ（子の通常商品）を持つ構造を示唆します。これはまさに1対多の自己関連の意味です。
5. よって、該当する関連が表す概念は 「セット商品」 です。

誤りやすいポイント

• 自己関連を「お勧め商品」や「事前予約商品」と取り違える
• 矢印の方向に着目せず、多対多や1対1と混同する
• 【現行システム機能の調査】以外の文章を根拠にしてしまい、指定どおりの字句を使えない
• 「セット商品」を「バンドル商品」など別表現に置き換えてしまう

FAQ

解答の論理構成

1. 問題は、概念データモデルにおけるサブタイプ間の集合関係を問うています。選択肢は「ア：共存」「イ：排他」「ウ：包含」の三つです。
2. まず「通常商品」と「事前予約商品」の関係を確認します。本文には

   「事前に予約することによって通常商品を割引価格で購入できる事前予約商品」
   とあります。ここから「事前予約商品」は「通常商品」を基に派生した下位集合であり、全ての事前予約商品は必ず通常商品に含まれます。よって集合関係は“包含”となり、c＝「ウ：包含」と判断できます。

3. 次に「通常商品」と「お勧め商品」の関係を確認します。本文には

   「顧客の購入履歴から算出したお勧め商品」
   とあり、算出結果として任意の通常商品が「お勧め商品」に選ばれるだけで、両者は相互に重複してもよい関係です。片方が必ず他方を含むわけでも、排他的でもありません。したがって“共存”関係となり、d＝「ア：共存」と決定されます。

誤りやすいポイント

• 「事前予約商品」が図上で「特売商品」の下位に描かれているため、通常商品とは無関係と誤解しやすいです。本文に書かれた定義を優先しましょう。
• 「お勧め商品」は機械的に算出されるため“特別な別物”と考え「排他」としてしまうミスが多いです。実際には通常商品ラベルを付けたまま“お勧め”ラベルが重畳するイメージです。
• “包含”と“共存”の違いを「サブタイプ階層か否か」で短絡的に判断しがちですが、集合論的に読み取ることが必要です。

FAQ

解答の論理構成

1. 変更頻度の確認
   【問題文】では顧客管理機能について「過去3年間に顧客種別の追加に関する機能変更が1回だけ」と述べられています。したがって顧客種別に関する変更は少なく、テーブル構造を複雑化させる必要性は高くありません。
   → 選択肢「イ」は妥当な理由です。
2. 属性差異の有無
   一般個人顧客と会員個人顧客は、会員かどうかを除けば共通項目がほぼ同一です。
   → 「属性に大きな差がない」ので一つのテーブルで管理する設計は合理的です。
   → 選択肢「ア」は妥当な理由です。
3. 集計・分析クエリの効率
   販売実績集計など全個人顧客を横串で扱う処理では、テーブルが分かれていると JOIN や UNION が増えます。単一テーブルなら単純な集計で済むのでデータベース負荷を抑えられます。
   → 選択肢「エ」は妥当な理由です。
4. 列追加時の影響範囲
   個別テーブル方式なら、例えば会員属性を追加しても一般個人顧客テーブルには影響しません。逆に単一テーブルでは列追加が全レコードに及び、ソフトウェアの影響調査範囲は広がります。
   → 「テーブルへの列追加時に…影響調査の範囲が小さくなる」という説明は実際とは逆で、不適切です。
   → 選択肢「ウ」がふさわしくない理由となります。

誤りやすいポイント

• 「列追加＝影響縮小」と早合点する
  単一テーブル設計では列追加・変更が全行・全画面に及ぶため、実際には影響調査が増えます。
• 「変更が少ない＝別テーブルにすべき」と誤解
  変更頻度が低いものは安定しているため、設計を簡潔にまとめた方が保守性が高まるケースが多いです。
• 集計性能と正規化のバランスを取り違える
  正規化だけに注目して細分化し過ぎると、読み取り主体のシステムでは集計クエリが複雑化し性能を損なう恐れがあります。

FAQ

解答の論理構成

• 【問題文】には「“②ソフトウェアの肥大化を防止するために顧客クラスを定義し、顧客クラスを継承するクラスとして一般個人顧客、会員個人顧客、法人顧客の三つのクラスを設計した。”」とある。
• 「顧客」クラスには【図02】に示される「顧客番号」「顧客種別コード」「配送先住所」「配送先氏名」「配送先電話番号」など、顧客種別に関係なく共通する属性・メソッドがまとめられている。
• サブクラス（一般個人顧客、会員個人顧客、法人顧客）は、自分に固有の要素だけを追加し、共通要素は親クラスを継承して利用する。
• したがって、同じコードや処理を複数クラスに重複して持つ必要がなくなり、実装量の増加を抑制できる。
• よって「顧客種別によらない共通な処理を一か所で定義できるから」という結論になる。

誤りやすいポイント

• 「共通処理が一か所」と言及せず「継承を使うから」とだけ述べてしまい、理由が曖昧になる。
• 「属性をまとめたから」と属性面だけを書き、メソッド（処理）を統合した意義に触れない。
• 「コード量が減る」と効果だけを書き、なぜ減るのか（重複排除）を示さない。

FAQ

解答の論理構成

• 本文には「③特売商品テーブル、セット商品テーブルなど商品種別ごとに多数のテーブルを作成するのではなく、商品種別と商品の二つのテーブルを作成し、運用環境へのリリース時の作業量を低減する設計」と記載されています。
• この設計方針により、商品種別を追加しても既存の二つのテーブルに行やデータを追加するだけで済み、新しい物理テーブルは不要になります。
• 運用環境へリリースする際に最も手間が掛かるのはスキーマ変更に伴う DDL 実行・権限設定・バックアップ調整などのデータベース作業です。
• したがって、商品種別追加時に「テーブルを増やさなくて済む」ことこそが“作業量を低減”の中核であり、答えは「データベースへのテーブル追加作業」となります。

誤りやすいポイント

• 「画面やクラスの追加作業」と誤解し、データベース作業ではないと答えてしまう。
• 「列追加」と混同し、テーブル構造そのものを増やさない設計だと読み取れない。
• 「運用環境＝本番サーバー全体のデプロイ」と広く捉え、具体的な作業名を書かずに抽象的に答えて減点される。

FAQ

解答の論理構成

• 商品表示機能の要件として、問題文は「商品種別ごとに画面の表示方法が異なる」と明示しています。
• 表示ロジックが種別ごとに異なる場合、共通部分（商品共通属性）と差分（種別固有の表示処理）を切り分けると保守性が高まります。
• そこで Y 君は「商品クラス」を上位に置き、下線部④で「商品種別ごとに個別のクラス」を設計しました。
• こうすることで、異なる表示処理をそれぞれの下位クラスに実装でき、「機能変更の頻度が高い」商品表示機能でも変更の局所化が可能になります。
• 以上から、クラス分割の直接的な理由は「画面の表示方法が異なるから」となります。

誤りやすいポイント

• 「商品種別が多い」こと自体を理由に挙げてしまい、表示方法の違いに触れない。
• データベース設計（テーブルを2つにまとめた点）と混同し、テーブル構造の簡素化を理由に書いてしまう。
• 「変更容易性」だけを抽象的に述べ、具体的に何が変わるのかを示さない。

FAQ