システムアーキテクト 2012年 午後1 問03

解答の論理構成

1. 要件確認
   【問題文】“同一時限に開催されるセッションを複数予約することはできない。”
   → 同一時限内での重複登録を防ぐ必要がある。
2. 主キー候補
   【問題文】“セミナ番号、申込ID、選択したセッションの時限を設定する方法”
   → 時限を含めれば、申込者×時限で一意になる。
3. 一意制約の効果
   主キーに含まれる列では重複行が登録できない。したがってプログラムで
   ・登録前に同時限の既存レコード検索
   ・重複時のエラー制御
   を実装する必要がなくなる。
4. 作成負荷の軽減
   重複チェック用のSQL・例外処理・画面メッセージなどが不要となり、コーディング・テスト工数を削減できる。

誤りやすいポイント

• 「時限」を主キーに入れると“セッションIDが不要になる”と誤解しやすいが、セッションそのものの識別には「セッションID」が別に存在する。
• “プログラムがまったく不要”ではなく、登録以外の機能（表示・更新）は残ることを忘れがち。
• 「1対多」の制約と「一意制約」を混同して記述してしまう。

FAQ

解答の導き方

• 顧客 ●―――○> 顧客招待
• 顧客招待 ○――――○ 受講申込
• 受講申込 ●―――●> 受講セッション
• セミナ ●―――●> セッション
• セッション ●―――○> 受講セッション

1. 顧客 ●―――○> 顧客招待
   理由：顧客招待は必ず元の顧客を参照して作成されるため、顧客招待が存在するときは対応する顧客が必須です。本文の記述「事務局はこれに基づいて、『顧客招待』に顧客を登録する。」がこれを示します。逆に営業が招待する顧客を選ぶため、ある顧客が招待を持たないことがあり得ます（顧客側は任意）。
2. 顧客招待 ○――――○ 受講申込
   理由：受講申込は招待された顧客による場合もあれば、顧客以外の一般申込もあるため、どちらの側も存在しないことがあり得ます（双方任意）。さらに「なお、1回のセミナに同一顧客から複数回申し込むことはできない。」とあるので、招待と申込はセミナ単位で高々1件の対応になります。したがって相互に0または1の1対1関係（○――――○）が妥当です。
3. 受講申込 ●―――●> 受講セッション
   理由：申込時に必ず選択するセッションがあり、本文に「申込者は申込時に1～5個のセッションを予約する。」とあるため、受講申込には少なくとも1件の受講セッションが対応します。また受講セッションは申込みの内容として記録されるため、受講セッションが存在するなら対応する受講申込は必須です。よって両端必須の1対多（受講申込→受講セッション）です。
4. セミナ ●―――●> セッション
   理由：本文に「1回のセミナでは、20～30個のセッションが開催され」とあるように、セミナは必ず複数のセッションを持ち、各セッションは特定のセミナに属します。したがって両端必須の1対多です。
5. セッション ●―――○> 受講セッション
   理由：図のエンティティ定義で「受講セッション」には「セッションID」が属性として存在するため（図1のE-R図から）、受講セッションは必ず対応するセッションを参照します。一方で、あるセッションは参加者ゼロであり得るため、セッション側から見て受講セッションが存在しないことがあり得ます。よってセッションは必須、受講セッションは任意の1対多です。

誤りやすいポイント

• ●／○の読み違い：端につく ●／○は「相手が存在する場合にこの側のインスタンスが必ず存在するか」を示す点を忘れやすい。逆向きに読んでしまうと多重度を取り違える。
• 顧客招待と受講申込を安易に1対多とする誤り：招待があっても申込がない場合や、申込が招待なしで発生する場合があるため、ここは双方任意の1対1になる点を確認すること。
• 受講申込と受講セッションの必須性を見落とすと設計ミス：申込は必ず1件以上の受講セッションを持つ（1～5個）ので、受講申込があって受講セッションが0件になる設計は要件違反。
• セッションと受講セッションの方向を誤認：セッション側は参加者ゼロを許容するため任意側になるが、受講セッションが存在する場合は必ず該当セッションが存在する点を押さえること。

FAQ

解答の論理構成

1. 【問題文】引用
   「(1)各セッションの会議室のaが、当該セッションの会議室のaよりもbセッションを選択する。」
   ここで比較対象は会議室そのものの属性で、後段の説明に「定員が多い会議室への変更を行う」とある。よって
   (a) = “定員”、(b) = “多い”。
2. 次の段階
   「(2)選択したセッションの中から、cが当該セッションのcよりもdセッションを選択する。」
   会場変更の目的は“より広い部屋へかつ使われ方が軽いセッション”への入替えです。セッション側の混雑度を示す値は「予約人数」であり、条件は“少ない”ほうが望ましい。したがって
   (c) = “予約人数”、(d) = “少ない”。
3. 倍率計算で裏付け
   「(3)選択したセッションのcを、選択したセッションの会議室のaで割って倍率を求め…」
   (c)/(a) は “予約人数/定員” という混雑率を示す式になり、整合が取れる。
4. 最後の入替え対象
   「(4)選択したセッションのeと当該セッションのeを入れ替える。」
   会議室そのものを入れ替えるので、エンティティ「セッション」が保持する識別子 “会議室ID” を交換すると判断できる。よって
   (e) = “会議室ID”。

誤りやすいポイント

• “予約人数が多いセッションを選ぶ”と逆に読んでしまう。実際は空いている方（少ない）を選びます。
• (a) を“会議室ID”と誤解し、倍率計算が成り立たなくなる。
• (e) を“定員”とすると物理的な部屋交換ができず矛盾します。

FAQ

解答の導き方

• 受講者の来場（図1の属性：来場日時）
  セミナ受付では「受講者の来場を記録する」とあり、受付で記録される情報は図1の受講申込の属性「来場日時」と対応します。来場したかどうかのリアルタイム判定に使えます。
• 受講者の入室（図1の属性：入室日時）
  セッション入口で「受講者の予約を確認し、受講者の入室を記録するとともに入室人数をカウントする」（表1 セッション入室）とあるため、各受講者の入室ログは受講セッションの属性「入室日時」に対応します。誰がいつ入室したかの順序把握に使えます。
• 現在の入室数（図1の属性：入室人数）
  図1のセッションに属性「入室人数」があり、入室日時の記録を集計して算出される実際の入室数は、残席判定や空席待ちの入室判断に直接必要な値です。

誤りやすいポイント

• 申込日時を混同する：申込日時は登録時刻であり、来場の有無やリアルタイムの在室判定には使えません。
• 退室検知を前提にしない：本文は「入室時刻を記録することにより、受講人数をカウントする」と記載しており、退室時刻の記録や退出による人数減算は明記されていません。退室検知を前提にすると要件とずれます。
• 予約人数と入室人数の混同：予約人数は事前の希望者数であり、実際に入室している人数は入室記録（入室日時）の集計で得られる「入室人数」です。
• 属性名の取り違え：設問は図1中の属性名を用いる指示があるため、表現は図1の属性名（来場日時、入室日時、入室人数）を正確に使う必要があります。

FAQ

解答の導き方

1. 要件の読み取り
   　役員の要望に「セミナの開催場所と内容によって、重要顧客を選定する。」とあり、重要顧客の判定はセミナごとに変わることが示されています。
2. 運用の記述確認
   　表2の顧客招待の追加点に「営業担当は、当該セミナに招待したい顧客を選んだとき、重要顧客については、顧客の一覧にその区分を付けて事務局へ提出する。」とあるため、重要顧客区分は招待時点で設定・管理されるべき属性です。
3. E-R図の粒度確認
   　図1のエンティティタイプ「顧客招待」は主キーに「セミナ番号」「顧客ID」を持つため、セミナ単位かつ顧客単位で属性を保持できます。
4. 他エンティティの除外理由
   　「顧客」に追加すると全セミナ共通の属性になり、セミナごとの差異を表現できません。
   　「受講申込」は申込み時に作成される（申込み処理で登録されるため）、招待時点の判定を表すには不適切です。
5. 結論
   　以上より、重要顧客区分はセミナごとの顧客選定を表す「顧客招待」に追加するのが適切です。

誤りやすいポイント

• 「顧客」に追加してしまう：属性が全セミナで共通になり誤った設計になる。
• 「受講申込」に追加してしまう：受講申込は申込み時に作成され、招待時点の情報を表現できない。
• 「受講セッション」に追加してしまう：重要顧客は顧客単位の属性であり、セッション単位に持たせるのは不適切（冗長・矛盾の元）。
• 図の破線や関係線の省略を見誤る：図示の省略があるが、エンティティの主キーと業務フローで粒度を判断すること。
• 属性の粒度（セミナ単位かグローバルか）を明確にしないまま配置する。

FAQ

解答の論理構成

1. 受付時に参照する媒体の確認
   【問題文】「セミナ受付」には
   「受講者から受講票を提示してもらい、申込IDを記録した受講カードを発行し…」
   とあり、提示するのは紙の「受講票」。よって (f)＝受講票。
2. キーとなる属性
   同じ段落に「申込ID」が明示されているため (g)＝申込ID。
3. 参照するエンティティ
   「申込みの内容は『受講申込』『受講セッション』で登録される。」
   申込IDで検索すべきテーブルは “受講申込”。従って (h)＝受講申込。
4. 取得したい値
   重要顧客かどうかを判断するには顧客を特定する必要がある。エンティティ「受講申込」には「顧客ID」が含まれるので (i)＝顧客ID。
5. 入室時の媒体の違い
   【問題文】「各会議室の入口にICカードリーダを設置して、受講者は受講カードをかざして入室する。」
   入室処理で使うのはICカード＝「受講カード」。よって (j)＝受講カード。

誤りやすいポイント

• “受講票” と “受講カード” を混同して (f)、(j) を逆にするケース
• 重要顧客判定には「会社名」などを想像し (i) に別属性を入れてしまうミス
• 参照エンティティを「顧客」や「受講セッション」と誤認し (h) を誤答するパターン
• 「申込ID」の位置付けを読み飛ばし、同一セミナ内で一意であることを忘れる失点

FAQ

解答の論理構成

1. 現行システムの課題
   【問題文】では、課題(1)として
   「受講者が予約したセッションを実際に受講したかは把握できない。」
   と明記されている。
   これはフォロー営業に必要な情報が不足していることを示す。
2. 新システムの機能追加
   新システム要件(3)で
   「受講者が受講カードをかざすことによって、…セッションの受講を記録する。」
   とあり、入室実績をデータベースに残す設計が示されている。
3. フォロー営業処理
   表1「フォロー営業」には
   「セミナ終了後、営業担当が受講者へフォロー営業ができるよう、受講者の一覧表を作成する。」
   とある。
   ここで作成される一覧表には、上記の入室記録が反映される。
4. 帰結
   したがって、新システム稼働後に渡せる確実な情報は
   「受講者がどのセッションを受講したか」という実受講情報である。

誤りやすいポイント

• 「予約セッション」と「実受講セッション」を混同しやすい。問われているのは後者。
• 「来場有無」だけではフォロー営業に十分と考えてしまうが、入室実績まで記録して初めて改善点となる。
• 重要顧客通知機能と混同し、重要顧客情報自体が答えだと思い込む。

FAQ