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

模範解答

解説

解答の論理構成

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

誤りやすいポイント

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

FAQ

模範解答

解説

解答の論理構成

1. 「顧客」―「顧客招待」
   【問題文】「営業担当は…顧客を選び、その一覧を事務局に提出する。」
   → 招待側は必ず「顧客」に紐付く（●）、しかし全顧客が招待されるとは限らない（○）。招待は１顧客に複数可なので１対多。
2. 「顧客招待」―「受講申込」
   【問題文】「顧客以外の受講希望者の参加申込みも受け付けている。」
   → 招待されても申込しない場合がある、招待されずに申込する場合もある。よって双方とも任意（○―○）、かつ１対１でなく多対多は設定されていないので１対１(0/1) で表現。
3. 「受講申込」―「受講セッション」
   【問題文】「申込者は…1～5個のセッションを予約する。」
   → 申込が存在すれば必ず１件以上の受講セッション（●）、１申込に最大５件なので１対多。逆に受講セッションは申込なしに存在しないので受講セッション側は必須（●）だが、図では申込側に実線（１）・受講セッション側に○（多）。
4. 「セミナ」―「セッション」
   【問題文】「各セミナは…20～30個のセッションが開催され。」
   → セミナが存在すれば必ずひとつ以上のセッション（●）、セッションは必ずどこかのセミナに属する（●）。１対多。
5. 「セッション」―「受講セッション」
   【問題文】「各セッションに定員を設定し…予約人数が定員に達した場合…」
   → セッションは予約０件の可能性あり（○）、受講セッションは必ず対象セッションを持つ（●）。矢印で多側が受講セッション。

誤りやすいポイント

• 「顧客招待」と「受講申込」を“招待がある＝必ず申込する”と誤解し、○―●にしてしまう。
• 「受講申込」はセッション選択必須という条件を見落とし、○―○で描くミス。
• 矢印の向きを逆にして 1対多を取り違える。
• 「セッション」は必ず１セミナに所属するが“セッションなしセミナ”はない点を見落とす。

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. 追加要件の理解
   【問題文】では「セミナの開催場所と内容によって、重要顧客を選定する。」と明言しています。つまり同じ顧客でもセミナごとに重要度が変動します。
2. データが発生するタイミング
   • 営業担当が顧客を選定 → 「その一覧を事務局に提出する。」
   • 事務局は「『顧客招待』に顧客を登録する。」
     ここで初めて“顧客 × セミナ”の組が生成されます。
3. 属性追加先の決定
   • 「顧客」…顧客固有の静的情報を保持。セミナ依存の属性を置くと重複。
   • 「受講申込」…来場時点で生成され、招待されていない一般参加も含む。招待段階の情報を持てない。
     よって「顧客招待」に“重要顧客区分”を付与するのが要件を最も自然に満たします。

誤りやすいポイント

• 「顧客」に区分を付けると、セミナごとに重要度が変わる要件と矛盾する。
• 「受講申込」を選ぶと、招待されない一般参加にまで属性が付与され無意味なNULLが増える。
• “来場時に判定すればよい”と誤解し、動的判定ロジックで解決しようとしてしまう。

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