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

核心となるキーワード・論点整理

• セミナー担当ファイルの主キー設定
• 主キー: レコードを一意に特定するためのキー
• セミナーID、担当役割、担当者ID の関係性
• 【問題文】にある担当役割が複数担当者を持つこと、一人の担当者が複数の役割を兼務できる点

なぜ「セミナーID，担当役割，担当者ID」が主キーとなるのか

セミナー担当ファイルの属性（問題文より）

設計背景と論拠

• セミナー担当ファイルは、「1つのセミナーに対して、複数の担当役割が存在し、その役割ごとに複数の担当者が割り当て可能」（問題文（1）の記述）
• また、「一人の担当者が複数の担当役割を兼務する場合もある」（問題文（1））
• したがって、
  • 同じセミナーIDで、異なる担当役割に同じ担当者IDが割り当てられるケースがある
  • 同じセミナーIDで、同じ担当役割に複数担当者IDが割り当てられるケースがある
• このため、単にセミナーID、担当役割、または担当者IDのどれか一つ、または二つの組み合わせだけではレコードを一意に特定できない。
• 3つすべてを組み合わせて初めて「1つのセミナーにおける役割別・担当者ごとの割り当て」を一意に識別できる。

受験者が誤りやすいポイント・ひっかけ

• リーダーフラグを主キーに含めるべきと誤解する:
  リーダーフラグは「リーダーか否かの属性」であり、主キーとしては不適切。なぜなら、「1」か「g」の2値をとるだけで、それ自体でレコードを特定できない。
• 担当役割や担当者IDだけで主キーを構成しようとする誤り:
  担当者は複数の役割を兼務できるため、担当者IDだけでは一意に特定できず、担当役割も考慮する必要がある。
• セミナーIDだけで主キーとする誤り:
  一つのセミナーに複数の担当者や役割が存在するため、セミナーID単独では不十分。
• 「セミナーID」と「担当役割」のみでは不十分:
  複数担当者が同じ役割を担当できるため、担当者IDを含める必要がある。

試験対策として覚えておくべきポイント

• 主キーとは何かを明確に理解すること
  → 主キーはレコードの一意性を保証するためのキー。 "一意に識別できる属性の組み合わせ" であること。
• 複合主キー（複数属性から成る主キー）を適切に設定するケースがあること
• 担当者や役割などの多対多の関係をモデリングするときは複合キーになることが多い
• 不要な属性（状態やフラグなど）は主キーに含めない
• 問題文中の役割権限や多重性の関係に注意し、それを元に主キーを考える

「セミナーID」「担当役割」「担当者ID」

模範解答の核心となるキーワードや論点

• (a)：検索対象ファイル → 「受講申込ファイル」
• (b)：重複チェックの対象項目 → 「メールアドレス」

解答となる理由の論理的説明

• 「当該セミナーIDで、(a)ファイルを検索し、入力された(b)と同じ(b)が存在すればエラー」

• (a)には「受講申込」、
• (b)には「メールアドレス」が入ることになります。

受験者が誤りやすいポイント・ひっかけ

1. ファイル名の混同
   「セミナー担当」や「受講」ファイルなど、似た名前のファイルが複数登場するため混乱しやすいです。
   → 重複チェックは受講申込者の情報、すなわち「受講申込ファイル」を検索します。
2. 重複チェックの対象項目の誤認
   氏名や会社名で重複判定すると誤り。
   → 問題文に「同一メールアドレスで申込みが重複していないかを判定」と明示されているため、メールアドレスが正解です。
3. セミナーIDとの組合せチェックを忘れる
   重複は「同一セミナーID、同一メールアドレス」で判断します。
   → 「当該セミナーIDで」とあるため、セミナーごとに申込の重複をチェックする点も重要です。

試験対策として覚えておくべきポイント

• 申込者の重複判定は本人を特定できる項目（メールアドレス）で判定することが多い。
• ファイルやテーブル名は設問の文脈に沿って理解し、似た名前でも役割が異なるファイルの混同に注意。
• 重複判定の際に必ずセミナーIDなどの条件も含めて検索すること。
• 問題文中の「～に基づき」「～が記載されている」などの記述をよく読み、条件を正確に把握すること。

参考：表2の該当部分再掲

模範解答の核心キーワード・論点整理

• 申込確認画面が表示されている間に起こる変化
• 他者の申込みが確定されること
• その結果、定員に達し、超過してしまう可能性
• 定員超過の判定が申込確認画面表示後の再チェックで必要になる理由

解答が導かれる論理的な説明

「D課長は指摘及び追加要望を受け、次のような設計変更を行った。
・申込確認画面で確定ボタンが押されたときに再度申込判定の処理を行うようにし、エラーになった場合はエラーメッセージを表示して処理を終了する。」

受験者が誤りやすいポイント・ひっかけになりやすい箇所

• 「申込入力～申込判定」での1回の定員チェックだけで安全と考えること
  → 実際は申込確認画面が表示されている間にも他の申込が進行する可能性があるため、その時点の情報は古い。
• 「申込みが重複しない」のみを問われていると誤解するケース
  → 重複チェックも重要だが、今回の設問は確定時の定員超過に関するものなので、別の観点。
• 通信遅延・ユーザインターフェイスのタイムラグの影響が理解できていないケース
  → UI表示と実際のDB状態はタイムラグがあるため、その間に状態変化が起こり得ることを押さえる必要がある。

試験対策としてのポイント・覚えておくべき知識

• 並行処理の問題点（レースコンディション）に注意する
  → ユーザが画面に表示された情報をもとに操作している間に、別ユーザの操作で状態が変わってしまうことがある。
• 最終処理直前にも条件チェックを設ける二重チェックの重要性
  → 申込み確定のような重要な処理は、トランザクション的に整合性を保つために確定処理直前に再確認が必要。
• ユーザインターフェイスのタイムラグと業務処理の整合性を考慮した設計
  → システムが複数利用者で使われる場合、情報の最新化と処理同期をどう担保するか設計思想を理解しておく。

まとめ

模範解答の核心キーワード・論点整理

• チェック内容（40字以内）:
  「当該受講IDの受講ファイルの接続フラグが '0' のときはエラーとしない」
  → 接続フラグの値に応じてエラー判定を行わない例外的なフローを記述。
• 受講ファイルの更新処理（30字以内）:
  「受講ファイルの接続フラグに ‘1’ を設定して更新する」
  → 再ログイン時の接続フラグの再設定。
• ポイント:
  ・接続フラグ属性の役割
  ・切断検知時の値変更（“0”→“g”で切断検知、模範解答では説明の“0”は設問に合わせた例示）
  ・再ログイン時のフラグ更新（再接続許可）

解答の論理的説明

• 「受講ファイルに、接続フラグという属性を追加し、初期値として”1”を設定する。別途、接続が切れたことを検知した際に接続フラグに“g”を設定するようにする。」
• 「その上で、再接続する際の①ログイン時の受講IDに関するチェック及び受講ファイルの更新処理を新たに追加する。」

1. 受講IDチェックの内容:
   再ログイン時に入力された受講IDについて受講ファイルを参照する。もし「接続フラグが“0”（あるいは “g”と読み換えられる可能性あり）」であれば、通信障害等で接続が切れた状態と判断し、エラーとせず再ログインを許可する。
   → つまり「接続フラグが ‘0’ のときはエラーとしない」という表現は切断中の受講IDを許可する旨の意図を表しています。
2. 接続フラグの更新処理:
   再ログインで正常接続が確立したため、それに対応して受講ファイルの接続フラグを ‘1’ に設定し、接続中の状態に戻す。

受験者が誤りやすいポイントの解説

• 接続フラグの値の理解が曖昧になる:
  問題文中では「初期値として ‘1’」「接続が切れた時 ‘g’」となっているため、「 ‘0’」という値が模範解答に含まれていることに違和感を感じるかもしれません。
  → 模範解答の ‘0’ は例示として、「切断検知状態の値（ ‘g’ ）を含め接続断時はエラーとしない」という意味合いと捉えるのが正しい。
  受験時には、問題文の指示に忠実かつ意味合いで理解することが重要です。
• 「接続フラグの更新」を単純に「ログイン履歴の記録」などと誤解する:
  実際は接続の状態管理をしており、‘1’は「接続中」、‘g’は「切断中」の意味です。
  更新処理は単なるフラグの切り替えであり、物理的なログイン動作とは切り離して理解しましょう。
• 「再接続」や「ログイン時のチェック」と合わせて記述する際の文字数制限:
  40字・30字以内で明確かつ簡潔に説明する必要があるため、冗長にならず適切なキーワードを使うことが求められます。

試験対策のための覚えておくべきポイント・知識

1. 模範解答の核心となるキーワードや論点の整理

• 移動対象の属性：アンケートURL
• 移動先のファイル：受講申込ファイル
• 理由の鍵：
  • 指摘・追加要望で「アンケートURLを受講IDごとの個別URLに変更」するため、
  • それに伴い、一意の個別URL（すなわち受講IDに紐づく情報）を管理しやすくするために属性の移動が必要。

2. なぜその解答になるのか（問題文の記述からの論理的説明）

• 現状の「アンケートURL」の属性は表1の「セミナー」ファイルにあります。

  ファイル名	主な属性（下線は主キー）
  セミナー	セミナーID, セミナー名, セミナー内容, 開催日時, 終了時刻, 定員, アンケートURL

• 改善要望として、

  「アンケートURLにアクセスした際に、入力画面で受講ID及び氏名を入力させるのではなく、あらかじめ受講ID及び氏名を埋め込んだページを開いて回答させるようにしたいので、個別のアンケートURLを送してほしい」

  つまり、これまでの「セミナー単位」のURLから、申込者毎（受講IDごと）の**「個別のURL」**にする必要があります。
• ここで「個別のURL」は受講IDごとの情報であるため、「アンケートURL」は「受講IDを持つ受講申込」ファイルに移すのが自然です。
• 受講申込ファイルの属性（表1より）

  ファイル名	主な属性（下線は主キー）
  受講申込	受講ID, セミナーID, 氏名, 会社名, 部署名, 役職名, メールアドレス, 申込日時

• 受講申込ファイルは受講IDを主キーに持つので、個別URLを管理するのに適しています。
• よって、「アンケートURL」属性を「セミナー」ファイルから「受講申込」ファイルに移すことが合理的です。

3. 受験者が誤りやすいポイント・ひっかけの解説

• 誤りやすい点1：「アンケートURL」はセミナー単位の情報だからセミナーファイルに残すべきと考えること
  → 旧仕様ではそうでしたが、個別URLの送信は「受講者（受講ID）個別」の対応なので、「受講申込」ファイルに移動する必要がある点が肝です。
• 誤りやすい点2：「アンケートURL」をアンケートファイルに移動する選択
  → アンケートファイルは回答結果を管理するファイルであり、URLそのものを参照・管理するファイルではありません。URLは申込時に管理されるべきなので適切ではありません。
• 誤りやすい点3：「オンラインルーム」ファイルや「受講」ファイルに移す選択
  → これらのファイルはセミナーの開催や受講受付を管理するためのものであり、URL管理とは対象が異なります。

4. 試験対策として覚えておくべきポイントや知識

• 属性の移動や正規化の考え方
  属性は「その属性の意味が属する対象に応じて管理ファイルを決める」べき。今回のようにURLが個別参加者（受講ID）に対応する場合、そのキーを主キーとするファイルに移す必要があります。
• 受講IDや申込者個別情報と紐づく属性は「受講申込」ファイルに管理されることが多い
  申込み情報・個別URL・メールアドレス等は受講IDを主キーとする「受講申込」ファイルにまとめます。
• 設問では具体的なファイル名と属性名の正確な表記が求められる
  「受講申込ファイル」や「アンケートURL」は正しい名称で記述しましょう。
• 設計変更の意図を正しく読み取ることが重要
  ・個別URL→個別の受講IDに対して紐づくこと
  ・その管理は受講申込ファイルが適当であることを理解すること

1. 模範解答の核心キーワード・論点整理

2. 解答の理由と問題文の引用を用いた論理的説明

(c) 申込率の分母

• 問題文（セミナー管理業務の概要（1））にて「セミナーには…受講する人数について定員を設定している」と明記。
• 表1「セミナーファイル」の属性に「定員」が含まれていることから、「セミナーファイルの定員」が該当。

(d) 受講率の分子

• 「受講率は受講申込者数に対する受講者数の割合」とあるため、
• 受講者は「受講ファイルのレコード件数」で表されます（表1参照）。
• 「受講ファイル」には受講IDが主キーとなっており、実際にセミナーでログインし受講した記録を表す。

(e) 受講率の分母

• 問題文中「受講率は受講申込者数に対する受講者数の割合」と記載。
• 受講申込数は「受講申込ファイル」に記録されているレコードの数で表現可能。

(f) 平均評価点の分子

• アンケートに関する記述で、「受講した者は10点満点で評価点を入力する」とあります。
• 「平均評価点はアンケートに回答した受講者の評価点の平均点」との定義に合致。
• したがって(f)は、アンケートファイルに登録されている各受講者の評価点を合算したものになります。

3. 誤りやすいポイント・ひっかけ対策

(c) 定員と関連する項目の混同

• 誤って「受講申込ファイルのレコード件数」や「受講ファイルのレコード件数」を入れてしまうことがある。
• 「申込率」は定員に対する申込数の割合と定義されているため、必ず「定員」を分母にする点を間違えないよう注意。

(d) 受講者数の混乱

• 「申込者数」と「受講者数」の違いを理解しておくこと。
• 受講者数は実際にセミナーを受講した人数であり「受講ファイル」に格納。
• 申込者数ではないので混同しない。

(f) 評価点の合計

• 「アンケートファイルの評価点の合計」と言う表現が適切で、単純に平均点を計算するだけでなく評価点の総和を分子に置く。
• また「受講しなかった者の評価点は空白（、日を設定）」であり、計算対象は「受講有無が“有”」に限定される点に注意。

4. 試験対策として覚えておくべきポイント

• ファイルと属性の関係性を正確に把握すること
  問題文の表や説明にあるファイル名・属性をしっかり把握し、「誰の情報がどのファイルに格納されているか」を理解する。
• 計算式中の分子・分母の意味に注意を払うこと
  例えば、申込率は「申し込んだ人数 ÷ 定員」、受講率は「実際受講した人数 ÷ 申し込み人数」など、比率は必ず分母・分子の意味を確認。
• 「受講」「申込」「アンケート」の違いをしっかり区別すること
  申込みをしたが受講しない人もいるため、申込と受講は異なる概念であることを意識。
• 問題文中の注記や用語の定義は必ず参照する
  例：受講有無が「有」は受講した者、アンケート評価点の取り扱いなど、設計の制約やルールを理解する。
• データベース設計の基本を理解し、主キーやリレーションを押さえること
  どのファイルが主キーでレコード件数がどう計算されるかを意識できると有利。