データベーススペシャリスト試験 2019年 午後1 問01

模範解答のキーワード整理

解答がこうなる理由

1. a：種目の「種目分類コード」
   問題文より

   「種目は,種目コードで識別し, 種目分類コードで, ランニング, 自転車レースなどに分類する。」
   したがって，種目(種目コード, 種目名, a) のaには 種目分類コード が入ります。

2. b：大会の「主催者番号」
   問題文より

   「大会は,大会番号で識別し, 大会名, 開催年月日, 開催場所の都道府県コード, 主催者番号を登録する。」
   よって，大会(大会番号, 大会名, b, 開催年月日, …) のbには 主催者番号 が入ります。

3. c：エントリ枠の「種目コード」
   問題文より

   「エントリ枠は, 大会番号とエントリ枠番号で識別し, エントリ枠名, …, 種目コード, …を登録する。」
   したがって，エントリ枠(..., c, 定員, …) のcには 種目コード が入ります。

4. d, e：参加申込みの主キー「大会番号」「会員番号」
   問題文より

   「参加申込みは, 大会番号, 会員番号で識別し, 参加申込年月日を登録する。」
   よって，参加申込み(d, e, エントリ枠番号, …) の識別に用いる d,e にはそれぞれ 大会番号，会員番号 を配置します。

5. f：参加費用の「入金年月日」
   問題文より

   「A社は, 会員の参加費用の支払を確認して入金年月日を登録し…」
   よって，支払確認日を表す属性として 入金年月日 が該当します。

6. g：参加費用から差し引く「使用ポイント」
   問題文より

   「会員は, 使用ポイントを登録し, 参加費用から使用ポイントを差し引いた額を支払う。」
   したがって，参加申込みテーブルの最後に 使用ポイント を置きます。

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

• 「参加申込み」の主キーを (大会番号, 会員番号) とすることを忘れ，エントリ枠番号を主キーと誤認する。
• 支払い関連の属性を「参加申込年月日」と混同し，入金年月日を違う名前で記述する。
• ポイント管理の属性を「ポイント残高」と混同してしまい，使用ポイントを見落とす。

試験対策としてのまとめ

• ER 図から関係スキーマへ変換する際は，参照整合性（外部キー）と識別キー（主キー）をしっかり押さえること。
• 問題文中の「識別する」「登録する」という表現は，スキーマ上の主キー・外部キーの手がかりになる。
• 支払・ポイントのフローは「いつ・何を登録するか」が明示されているので，属性名を迷ったらもう一度該当箇所を引用して確認する習慣をつける。
• 選択肢に似た用語が並ぶ場合は，常に前後の文脈（「～を確認して 登録 する」「～を 差し引く」）を手がかりに正確な用語を定着させる。

コアキーワード・論点整理

• 主催者–大会：１対多リレーションシップ
• 種目分類–種目：１対多リレーションシップ
• 種目–エントリ枠：１対多リレーションシップ
• 大会–エントリ枠：１対多リレーションシップ
• 運営サービス–大会運営サービス／大会–大会運営サービス：多対多を中間エンティティで表現
• アイテム–大会アイテム／大会–大会アイテム：多対多を中間エンティティで表現
• 会員–参加申込み：１対多リレーションシップ
• エントリ枠–参加申込み：１対多リレーションシップ
• エントリ枠–抽選エントリ枠：汎化／継承関係

解答の論理的説明

1. 主催者–大会
   問題文：「大会は，…主催者番号を登録する」
   → 大会テーブルが主催者番号を外部キーとして持つため，主催者１：大会多
2. 種目分類–種目
   問題文：「種目は，種目分類コードで…分類する」
   → 種目テーブルが種目分類コードを外部キーとして持つため，種目分類１：種目多
3. 種目–エントリ枠
   問題文：「エントリ枠は，…種目コード…を登録する」
   → エントリ枠テーブルが種目コードを外部キーとして持つため，種目１：エントリ枠多
4. 大会–エントリ枠
   問題文：「エントリ枠は，大会番号とエントリ枠番号で識別し…登録する」
   → 大会番号を外部キーとする複数のエントリ枠が１つの大会に紐づくため，大会１：エントリ枠多
5. 運営サービス–大会運営サービス／大会–大会運営サービス
   問題文：「主催者は，大会ごとに一つ以上の運営サービスを選択する．A社は…登録する」
   → 多対多を禁止しているため，中間エンティティ「大会運営サービス」を置き，運営サービス１：大会運営サービス多，大会１：大会運営サービス多
6. アイテム–大会アイテム／大会–大会アイテム
   問題文：「主催者は，大会ごとに利用するアイテムを複数登録することができる」
   → 同様に中間エンティティ「大会アイテム」を置き，アイテム１：大会アイテム多，大会１：大会アイテム多
7. 会員–参加申込み／エントリ枠–参加申込み
   問題文：「参加申込みは，大会番号, 会員番号で識別し…」「会員は…エントリ枠を指定して参加申込みを行う」
   → 会員１：参加申込み多，エントリ枠１：参加申込み多
8. エントリ枠–抽選エントリ枠（汎化／継承）
   問題文：「抽選の場合は，抽選年月日を登録する．抽選エントリ枠は…」
   → 抽選エントリ枠をサブタイプとして，エントリ枠との汎化／継承関係を設定

リレーションシップ一覧

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

1. 参加申込みの複合主キー
   同一大会に同一会員が複数回申込みできない仕様は「参加申込みは，大会番号, 会員番号で識別」と記載されていることに由来します。
2. 多対多リレーションシップの禁止
   「大会⇔運営サービス」「大会⇔アイテム」は一見多対多ですが，必ず中間エンティティ（大会運営サービス，大会アイテム）で分解する必要があります。
3. 汎化／継承の取り扱い
   抽選エントリ枠は「抽選年月日」を持つサブタイプであり，エントリ枠との汎化／継承関係を正しく描くことが求められます。

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

• 要件文の「識別方法」「登録項目」から外部キー設定を導出するクセをつける。
• 多対多は禁止 → 中間エンティティ（関連エンティティ）を必ず挿入する。
• 汎化／継承は，スーパタイプ・サブタイプの属性・リレーションシップを整理して表現。
• 複合主キーはビジネスルールを反映 → 要件と主キー候補に矛盾がないか都度確認する。

1. 本問のキーワードと論点整理

• 先着順／抽選 の二つの参加者決定方式
• 条件項目
  • 募集期間に対する本日（前／中／後）
  • 参加申込数（未満／到達／以下／超過）
  • 抽選年月日に対する本日（前／当日／後）
• アクション行
  • エントリ枠状態を「募集中」にする
  • エントリ枠状態を「抽選中」にする
  • 抽選実施
  • エントリ枠状態を「参加者確定」にする

2. 解答がこうなる理由／問題文の引用

2-1. 先着順の場合

③ エントリ枠が先着順の場合
・募集期間が終わったら ‘参加者確定’にする。
・参加申込数が定員に達したら、募集期間中であっても‘参加者確定’にする。
① エントリ枠の登録においては,初期値を‘募集前’にする。
② 募集期間中は‘募集中’にする。

1. 募集前 → 状態変更なし（初期値は ‘募集前’ のまま）
2. 募集期間中かつ参加申込数＜定員 → ‘募集中’
3. 募集期間中かつ参加申込数＝定員 → ‘参加者確定’
4. 募集終了後 → ‘参加者確定’

2-2. 抽選の場合

③ エントリ枠が抽選の場合
・募集期間が終わり, 参加申込数が定員以下だったら ‘参加者確定’にする。
・募集期間が終わり, 参加申込数が定員を超えていれば‘抽選中’にし, その後、抽選年月日に抽選を実施した上で ‘参加者確定’にする。
① エントリ枠の登録においては,初期値を‘募集前’にする。
② 募集期間中は‘募集中’にする。
⑥ エントリ枠状態が ‘募集中’の間だけ, 参加申込みを受け付ける。

3. 完成した決定表

• R1～R4：先着順の４パターン
• R5～R10：抽選の６パターン
  • R8：募集終了後 & 超過かつ抽選日前 → ‘抽選中’
  • R9：募集終了後 & 超過かつ抽選当日 → 抽選実施
  • R10：募集終了後 & 超過かつ抽選日後 → ‘参加者確定’

4. 受験者が誤りやすいポイント

1. 「抽選実施」と「参加者確定」を同時に扱うか分離するか
   抽選当日に抽選を行うだけでなく、参加者を確定する処理も必要ですが、決定表ではアクション行を分離して扱います。
2. 締切後・抽選前の期間
   募集終了後で参加申込数が超過している間は「抽選中」の状態となり、抽選日当日までは再度エントリ枠状態を『抽選中』にする必要はありません。日付変化の評価ポイントを整理しましょう。
3. 先着順／抽選の前提条件を切り分ける
   先着順と抽選では条件・アクションが大きく異なるため、まず方式ごとに行を分けて考えるとミスが減ります。

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

• 仕様書の「いつ」「どの条件で」「何をする」を必ず引用して切り出す
  → 本問題では「募集期間前／中／後」と「参加申込数」「抽選年月日」を整理する。
• 状態遷移は「日付変更時」「申込受付時」の２つで再評価される
  → 日次バッチ的な評価とイベント発生時評価を決定表で共通化。
• 決定表の列は「互いに重複しない条件の組合せ」を並べ、全パターンを網羅
  → 本問は 4＋6 ＝ 10 パターンに整理できる。
• 採点上、条件セル／アクションセルの「－」「X」の配置ミスが致命的
  → 受験時は一度全体を俯瞰し、「該当セルは何を意味するか」を声に出して確認しましょう。

模範解答のキーワードと論点整理

なぜその解答になるのか（要件との対応）

1. ① 属性追加
   問題文に

   「多段階抽選の対象のエントリ枠には、後続のエントリ枠を一つ設定する。」
   とあるため，「抽選エントリ枠」関係に 後続エントリ枠番号 属性を追加し，
   ある枠で落選した会員がどの枠に回るかを表現できるようにします。

2. ② 属性削除
   問題文に

   「エントリ枠の抽選ごとに抽選結果を登録する。」
   とあるため，参加申込みテーブル(参加申込み)にある 抽選結果 属性では，
   抽選を複数回行った際の履歴を残せません。
   そこで，参加申込み側の 抽選結果 属性を削除し，代わりに専用テーブルで結果を持たせます。

3. ③ 関係追加
   同じく

   「エントリ枠の抽選ごとに抽選結果を登録する。」
   という仕様を実現するため，新たに 抽選結果 テーブルを設けます。
   これにより，１会員が複数回の抽選を受けた経緯をすべて記録できます。

解答例

• 関係名：抽選エントリ枠
• 追加属性：後続エントリ枠番号

• 関係名：参加申込み
• 削除属性：抽選結果

• 実線下線（<u>…</u>）は主キーを，破線下線（text-decoration: underline dashed;）は外部キーを示します。
• 主キー：大会番号＋会員番号＋エントリ枠番号
• 外部キー：大会番号 → 大会， 会員番号 → 会員， エントリ枠番号 → エントリ枠

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

1. 「後続エントリ枠番号」を どのテーブル に追加するか
   → 多段階抽選方式の対象は「抽選エントリ枠」，エントリ枠 ではありません。
2. ②の削除対象を見誤る
   → 「抽選年月日」ではなく，参加申込み テーブルの 抽選結果 属性を削除します。
3. 抽選履歴を残すためのテーブル追加
   → 「抽選結果」を属性で持つだけでは履歴が消えるので，必ず新規テーブルで管理します。

試験対策ポイント

• 要件文のキーワードに忠実に：追加・削除すべき属性名や関係名は要件と完全一致させる。
• 履歴管理と最新値管理の違い：最新結果のみ → 属性， 履歴管理 → 別テーブル
• 主キー／外部キーの表記ルールを確実にマスターしておく。
• 多段階処理など 業務フロー が変わる要件は，概念モデル・関係モデルのどちらに影響するかを常に意識する。

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

• ポイント有効期限
  「ポイントの有効期限は, 付与された日から1年であり, 有効期限を超過したポイントは消失する。」
• 使用順序
  「ポイントの使用は, 有効期限の近いものから行う。」
• 従来の会員ポイント関係スキーマ
  会員ポイント(会員番号, ポイント残高)
• 変更後に求められる要件
  1. 付与ごとの有効期限を判定できる
  2. いつ付与されたポイントかがわかる
  3. 使用済みポイントを記録し，残高を算出できる

なぜこの解答になるのか

ポイントの有効期限は, 付与された日から1年であり, 有効期限を超過したポイントは消失する。
ポイントの使用は, 有効期限の近いものから行う。

• どの付与分がいつ消失するか
• どの付与分から先に使用すべきか

1. 付与ポイント
2. そのうち使用済みのポイント

• 「ポイント付与年月日＋1年」を有効期限として計算できる
• 総付与ポイントから使用済みポイントを差し引いて残高を算出できる
• 有効期限の近いものから使用済みポイントを割り当てる運用を実現できる

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

1. 「ポイント残高」を残すだけ
   変化前の「ポイント残高」だけを残すと，期限切れと使用済みの区別がつかず要件を満たせません。
2. 「有効期限」を直接属性化
   “有効期限年月日”を属性として持たせても，「どれだけ使用されたか」を管理できず，また使用順序の計算が煩雑になります。
3. 付与履歴を切り捨てる
   複数回にわたる付与をまとめてしまうと，個々の有効期限管理が不可能です。

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

• 有効期限管理が必要な属性は「付与日時などの時点」と「個別の数量」を分けて管理する。
• 使用順序が定まっている場合（FIFOやLIFOなど）は，どの時点で付与されたかをキーにする。
• 「残高」だけでなく「使用済み量」を別属性として持たせることで，履歴から現在の残高を導出できる。
• 関係スキーマ設計では，業務要件を漏れなく属性に落とし込むことを常に意識する。