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

模範解答

解説

解答の論理構成

1. ファイル構造を確認
   引用：【問題文】表1「セミナー担当」の主な属性

   セミナーID, 担当役割, 担当者ID, リーダーフラグ

2. 業務ルールを整理
   引用：【問題文】

   “三つの担当役割について、それぞれ複数名の担当者を設定でき、一人の担当者が複数の担当役割を兼務する場合もある。”
   “一つの担当役割に複数名を設定した場合は、その中でリーダーを一人設定する。”
   ① 同じセミナーで同じ担当役割に複数の担当者が入り得る。
   ② 同じ担当者が別の役割にも就き得る。
   ③ リーダーフラグは役割内の序列を示すだけで、組合せの一意性を保証しない。

3. 一意性判定
   ① 「セミナーID」だけ → 同じセミナー内で複数役割・複数担当者が存在し重複。
   ② 「セミナーID，担当役割」 → 同一役割内で複数担当者が存在し重複。
   ③ 「セミナーID，担当役割，担当者ID」 → 業務ルール上同一組合せは1件だけ。
   したがって、この3項目を複合したときに初めて一意性を確保できます。
4. 結果
   主キー：セミナーID，担当役割，担当者ID

誤りやすいポイント

• リーダーフラグを主キーに含めてしまう
  “1”と“g”は単なる区分値であり、同じ担当者に対し値が変更される可能性があるため主キー不適。
• 担当者ID単独で一意だと勘違い
  同じ担当者が複数セミナー・複数役割を担当できるので不十分。
• 「担当役割＋担当者ID」で済むと考える
  セミナーが異なれば同じ役割・同じ担当者の組合せが再登場するため不足。

FAQ

模範解答

解説

解答の論理構成

1. 重複チェックの仕様確認
   • 【問題文】“セミナーについて同一メールアドレスで申込みが重複しておらず”
     ⇒ 重複判定は「メールアドレス」をキーに行うと読み取れます。
2. 対象ファイルの特定
   • 表1「受講申込」ファイルの主な属性に “メールアドレス” が含まれ、申込みデータを保持している。
   • したがって重複確認時に検索すべきファイルは「受講申込」。
3. 置換箇所への適用
   • 表2「申込判定（重複）」の文脈
     “当該セミナーIDで、(a)ファイルを検索し、入力された(b)と同じ(b)が存在すればエラー”
   • (a) は「受講申込」、(b) は「メールアドレス」として整合が取れる。
4. 結論
   • (a)＝受講申込、(b)＝メールアドレス。

誤りやすいポイント

• 申込入力画面で入力する項目をそのままファイル名と誤解し、(a) に「セミナー」などを入れてしまう。
• メールアドレス以外の個人情報（氏名や受講ID）で重複チェックすると読み違える。
• 表1と表2の対応を確認せず、業務フローだけで推測してしまう。

FAQ

模範解答

解説

解答の論理構成

1. まず【問題文】表2「申込判定（定員）」では、
   「受講申込ファイルのレコード件数がセミナーファイルの定員以上のときは…処理を終了」
   とし、OKなら「申込確認画面を表示」します。
2. しかし確定ボタンを押す処理は、同じ表2の「申込確認」に記載された別ステップで実行されます。
3. 【指摘及び追加要望】では、
   「申込確認処理について、今のままでは確定ボタンを押した際に定員を超過する可能性がある」
   と明示されており、申込判定後〜確定ボタン押下までの間に他者がレコードを登録すると、定員チェックをすり抜けることになります。
4. したがって「申込確認画面が表示されている間に他者の申込みが確定されて定員に達した場合」が定員超過となる状況であり、模範解答につながります。

誤りやすいポイント

• 「申込判定（定員）」だけで完全に防げると考え、確定時の再チェックを忘れる。
• 申込確認画面表示直後の“保留”状態を意識せず、同時実行問題を見落とす。
• 定員超過の原因を「同一メールアドレス重複」と混同してしまう。

FAQ

模範解答

解説

解答の論理構成

1. 状態管理の前提を確認
   • 「受講ファイルに、接続フラグという属性を追加し、初期値として”1”を設定」「接続が切れたことを検知した際に接続フラグに“0”を設定」とある。
   • よって “1” は接続中、“0” は切断を示す。
2. チェックの目的を抽出
   • 「再接続する際の①ログイン時の受講IDに関するチェック」を新設。
   • 目的は多重ログイン防止と切断後の再ログイン許可の両立。
3. チェック内容を導出
   • “1” のときは既に接続中なのでエラー扱い。
   • “0” のときは切断済みなので再ログインを許可（エラーとしない）。
4. 更新処理を導出
   • 再ログインが成功したら状態を接続中に戻す必要があるため、「接続フラグに“1”を設定して更新」。
   • これで再度切断されるまで多重ログインを防げる。

誤りやすいポイント

• “0” と “1” の意味を逆に覚え、許可・拒否を取り違える。
• 更新処理を忘れ、再ログイン後も “0” のままにしてしまう。
• 「エラーとしない」ではなく「エラーとする」と誤記して減点。

FAQ

模範解答

解説

解答の論理構成

1. 変更要求を確認
   • 【問題文】「セミナー終了後に受講申込者に送信するアンケートURLを、受講IDごとの個別のURLに変更する。」
     ⟹ URLの管理単位がセミナー（1対多の“1”側）から受講申込（1対1）側へ変わる。
2. 現行設計を確認
   • 【問題文】表1「セミナー」ファイルの主な属性に「アンケートURL」が存在。
     ⟹ 現行は“セミナー単位”に1つだけ保持。
3. 個別URL運用との不整合
   • 受講IDは「受講申込」ファイルの主キー 受講ID で管理。個別URLを生成・送信する対象は受講申込者であり、セミナーIDでは一意にならない。
4. ファイル移動の妥当性
   • 「受講申込」ファイルは受講IDをキーに持ち、申込み者単位でレコードを保持しているためURLを追加しても第3正規形を損なわない。
5. よって「アンケートURL」を「受講申込」ファイルに移すのが最適。

誤りやすいポイント

• 「受講」ファイルに移すと誤解する
  （受講ファイルはログイン受付時に作成されるため、未受講の申込者にURLが送れなくなる）。
• URLを追加ではなく複製だと考え、両方のファイルに残してしまう
  （一意性・更新時異常の原因）。
• 「個別」を“セミナーごとに生成し直す”と解釈し、現行のままと判断する。

FAQ

模範解答

解説

解答の論理構成

1. (c) の判定
   • 表３「申込率（%）」は「受講申込ファイルのレコード件数 ÷ (c) × 100」と規定。
   • 分母は定員そのものです。定員は【表1】「セミナー」ファイルの属性に「定員」が存在。
   • よって「セミナーファイルの定員」。
2. (d) の判定
   • 表３「受講率（%）」の分子は受講者数。受講者は【表1】「受講」ファイルに１レコードずつ記録。
   • したがって「受講ファイルのレコード件数」。
3. (e) の判定
   • 同じ式の分母は申込者数。申込者は【表1】「受講申込」ファイルに１レコードずつ記録。
   • よって「受講申込ファイルのレコード件数」。
4. (f) の判定
   • 「平均評価点（点）」の分子は受講者が入力した「評価点」の総計。
   • 評価点は【表1】「アンケート」ファイルの属性「評価点」で保持。
   • 合計を求めるため「アンケートファイルの評価点の合計」。

誤りやすいポイント

• 「受講率」の分子・分母を逆にしてしまう。
• 「定員」をレコード件数と誤認し「セミナーファイルのレコード件数」と答えるミス。
• 「評価点」をレコード件数と勘違いし「アンケートファイルのレコード件数」としてしまう。

FAQ