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

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

• 各リレーションがどのエンティティを表し，どのリレーションと結合されるか
• 外部キー参照の対象リレーションと対応する候補属性
• 主キー構成属性の判別
• 問題文中の用語と図２の属性名の整合

2. 解答の論理的説明

1. 支払 リレーションの (a),(b)
   支払には「レシート番号」「会員コード」に加え，どの店舗で支払ったかを識別する必要があります。
   問題文より，

   「店舗は, 加盟企業コードと店舗コードで識別する。」
   したがって，支払リレーションに加えるべき未定義属性は

   • 加盟企業コード
   • 店舗コード
     の２つです。これらは「店舗」リレーションの主キーを参照する外部キーとなるため，破線下線で示します。
2. 支払方法明細 リレーションの (c)
   問題文より，

   「ポイントの利用…利用ポイントは, 支払時にポイント残高から減算する。」
   しかし支払方法明細では「各支払方法での支払金額にポイント付与率を乗じて計算する」という記述から，
   支払方法明細には「支払金額」を記録する必要があります。よって (c) は

   • 支払金額
     です。
3. 購入商品明細 リレーションの (d)
   問題文より，

   「商品の購入金額 (購入数×商品単価) にポイント付与率を乗じて計算する。」
   「購入商品明細」には何個購入したかを記録する「購入数」が必要です。よって (d) は

   • 購入数
     です。
4. 支払方法 リレーションの (e)
   問題文より，

   「各支払方法に対するポイント付与率は, ポイント設定で決めている。ポイント設定はポイント設定コードで識別し, ポイント付与率, 適用期間をもつ。」
   従って「支払方法」リレーションには，どのポイント設定を適用したかを示す外部キーとして

   • ポイント設定コード
     が必要です。破線下線で示します。
5. ポイント設定 リレーションの (f)
   問題文より，

   「ポイント設定は…ポイント付与率, 適用期間をもつ。」
   したがって，未定義属性は

   • ポイント付与率
     です。
6. クーポン設定 リレーションの (g)
   問題文より，

   「クーポンには, 配布上限数と配布期間を設定している。」
   よって

   • 配布上限数
     が未定義属性に対応します。
7. クーポン配布 リレーションの (h),(i)
   問題文より，

   「同じ会員に同じクーポンを2回発行することはない。」
   をもって，主キーは (クーポンコード, 会員コード) の組合せです。よって

   • クーポンコード（主キー）
   • 会員コード（主キー，かつ「会員」リレーション参照の外部キー）
     の２属性となります。
8. クーポン利用 リレーションの (j),(k)
   問題文より，

   「会員が支払時にクーポンを提示すると…クーポンがどの支払で利用されたか分かるように記録する。」
   よって主キーは，

   • クーポンコード
   • レシート番号
     の組合せで，それぞれ「クーポン設定」「支払」リレーションを参照する外部キーにもなります。

3. 誤りやすいポイント

• 支払リレーションで (a),(b) を「会員に紐付く支払」と混同し，会員コードを二重で入れがち。実際は店舗情報を表す別属性です。
• 支払方法明細 (c) と「利用ポイント」を混同し，利用ポイントとするとポイント消費量を記録してしまい誤り。
• クーポン関係で主キーを忘れ，「配布日時」を含めてしまうケース。ですが「同じ会員に同じクーポンを２回発行しない」前提があるため，配布日時は主キーには不要です。

4. 試験対策まとめ

• 実体‐関係モデルから関係スキーマに落とし込む際， 主キー と 外部キー の区別を明確に！
• 「何を識別するためのキーか」「どのリレーションを参照する外部キーか」を，問題文の「識別する」「参照する」記述から正確に読み取る。
• クーポンやポイントの付与など複数のバッチ処理が関わる場合でも，スキーマ設計の観点では 識別子 と 参照先 の関係に着目する。
• 誤りやすいのは「属性名が似ているもの」「主キーか外部キーかのケアレスミス」。一度書いたら「この属性はなにを参照して，主キーに含まれているか」を必ずセルフチェックする習慣を。

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

なぜその解答になるのか──論理的根拠の引用と解説

1. クーポン設定→クーポン設定対象店舗→店舗
   • 「クーポンは，企画した加盟企業の店舗だけで利用できる」
   • エンティティ「クーポン設定」と「店舗」を直接結べないため，中間エンティティ「クーポン設定対象店舗」を介して
     • クーポン設定対象店舗.(クーポンコード)→クーポン設定.(クーポンコード)
     • クーポン設定対象店舗.(加盟企業コード,店舗コード)→店舗.(加盟企業コード,店舗コード)
2. クーポン設定→クーポン配布→会員
   • 「クーポン企画単位にクーポンコードを付与する」「クーポン配布リストに登録されている会員が…クーポンを発行する」
   • よって
     • クーポン配布.(クーポンコード)→クーポン設定.(クーポンコード)
     • クーポン配布.(会員コード)→会員.(会員コード)
3. クーポン設定→クーポン利用→支払
   • 「会員は，クーポンを提示するとポイント付与率を適用する」「クーポンがどの支払で利用されたか分かるように記録する」
   • よって
     • クーポン利用.(クーポンコード)→クーポン設定.(クーポンコード)
     • クーポン利用.(レシート番号)→支払.(レシート番号)
4. 支払→店舗
   • 「会員は…店舗で利用できる」「支払はレシート番号で識別する」および図2の未定義属性［a］［b］は「加盟企業コード,店舗コード」
   • よって
     • 支払.(加盟企業コード,店舗コード)→店舗.(加盟企業コード,店舗コード)
5. 支払→支払方法明細／購入商品明細
   • 支払明細は「支払方法明細」「購入商品明細」に分かれる（図1中央フロー）
   • よって
     • 支払方法明細.(レシート番号)→支払.(レシート番号)
     • 購入商品明細.(レシート番号)→支払.(レシート番号)
6. 購入商品明細→加盟企業商品
   • 「加盟企業商品は…加盟企業商品コードで識別」「購入商品明細に加盟企業コード,加盟企業商品コードを持つ」
   • よって
     • 購入商品明細.(加盟企業コード,加盟企業商品コード)→加盟企業商品.(加盟企業コード,加盟企業商品コード)
7. 支払方法明細→支払方法
   • 「支払方法ごとの付与ポイントは…支払方法コードで識別」「支払方法明細に支払方法コードを持つ」
   • よって
     • 支払方法明細.(支払方法コード)→支払方法.(支払方法コード)
8. 支払方法⇔ポイント設定（M:Nの解消）
   • 「ポイント設定は…ポイント付与率,適用期間をもつ。ポイントを付与する支払方法にポイント設定を対応付ける。同じポイント設定を，複数の支払方法に対応付けることがある」
   • ERモデリングでは多対多は認められないため，
     • 支払方法とポイント設定を中間エンティティ（例：支払方法ポイント設定）でつなぎ，
     • 支払方法ポイント設定.(支払方法コード)→支払方法.(支払方法コード)
     • 支払方法ポイント設定.(ポイント設定コード)→ポイント設定.(ポイント設定コード)

リレーションごとの外部キーまとめ

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

1. 図2の未定義［a］［b］を見落とし，「支払」に店舗識別情報が必要なことを忘れる。
2. 購入商品明細と加盟企業商品は複合キー（加盟企業コード＋加盟企業商品コード）で結ぶこと。
3. 支払方法とポイント設定の M:N をそのまま「多対多リレーションシップ」で記述しない。必ず中間エンティティで解消する。
4. クーポン関連のエンティティ（設定→対象店舗→店舗、配布→会員、利用→支払）の結びつきを一つでも欠けると受付されない。

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

• ER図で「多対多」は使わず，中間エンティティで1:N×N:1に分解する。
• 複合キーのリレーションでは，主キーだけでなく全てのキー属性を外部キーとして参照する。
• 業務要件を読むとき，「どのエンティティのどの属性がリレーションシップの鍵になるか」「実体どうしを橋渡しする中間テーブルが必要か」を常に意識する。
• 図2の空欄（a～k）が何を指すかを要件文に当てはめて特定する練習をしておく。

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

• 候補キー
  最小性を満たす superkey。関係スキーマのすべてのタプルを一意に識別でき、かつどれかを削ると一意性を失う組み合わせ。
• 部分関数従属性
  複合キーの一部から非キー属性が関数従属している場合。
• 推移的関数従属性
  キー属性 → 非キー属性Ａ → 非キー属性Ｂ のように，非キー属性Ａを介して別の非キー属性Ｂが従属している場合。

解答の根拠・論理的説明

1. 関係スキーマの再掲

2. 候補キーの検討

• 問題文に「加盟企業商品は,加盟企業コードと加盟企業商品コードで識別する。」とある通り，
  {加盟企業コード, 加盟企業商品コード} は一意にタプルを識別できます。
• さらに「横断分析用商品情報には…横断分析用商品コードで識別する。」「登録済みと判断すればその横断分析用商品コードを…加盟企業商品に設定する。」という記述から，
  同一の商品を扱う複数の加盟企業商品でも「横断分析用商品コード」は同じになるため，
  {加盟企業コード, 横断分析用商品コード} もタプルを一意に識別できます。
• それ以外の組み合わせでは，JANコードや商品名は再利用される場合があり，最小性を保った一意性が担保できないため，以下の２つが候補キーとなります。
  1. {加盟企業コード, 加盟企業商品コード}
  2. {加盟企業コード, 横断分析用商品コード}

3. 部分関数従属性の有無と具体例

• 複合キーの一部（＝部分）から非キー属性が決まる関係が存在するか？
• 実際に存在するので「あり」に○。具体例として，以下のような従属性があります。
  • 「加盟企業コード→加盟企業名」
    ―「加盟企業は…加盟企業コードで識別する」かつ「加入企業１つに対し加盟企業名は一意」
  • 「加盟企業コード→契約開始日」「加盟企業コード→契約終了日」
  • 「横断分析用商品コード→横断分析用商品名」
    ―「横断分析用商品コードで識別する」ので同コードの横断分析用商品名は一意

4. 推移的関数従属性の有無と具体例

• キー属性→非キー属性Ａ→非キー属性Ｂ の形を探すと，以下があります。
  • {加盟企業コード, 加盟企業商品コード} → 横断分析用商品コード → 横断分析用商品名
• よって「あり」に○。具体例を表記すると：

  {加盟企業コード, 加盟企業商品コード}→横断分析用商品コード→横断分析用商品名
  

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

1. 候補キーの最小性の見落とし
   「横断分析用商品コード」単独をキーと誤認しやすいが，複数加盟企業の商品に同じコードを付与するため一意性が保てません。
2. 部分関数従属性と推移的関数従属性の混同
   • 部分従属性…複合キーの一部に依存
   • 推移的従属性…キーから非キーＡを経由して非キーＢに依存
     それぞれ定義を押さえ、具体例を整理しましょう。

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

• 複合キーの一部で決まる属性があれば「部分関数従属性あり」。非キー属性間の「仲介」をチェックして推移的があれば「推移的関数従属性あり」。
• 定義を暗記するだけでなく，設計図（ER図・関係スキーマ）から具体的な関数従属性を抜き出す練習を重ねること。
• 候補キーは「最小の属性集合で一意性を持つもの」を必ず確認する習慣をつけると誤りが減ります。

1. 模範解答のキーワード・論点

• 候補キー
• 主キーに要求される「レコード登録時点で必ず値が設定されていること」
• 「横断分析用商品コードは後日設定される」属性は主キーに不適

2. 解答の理由

「横断分析用商品コードの設定には，加盟企業商品の登録から数日を要する場合がある」
とあり，
「B社は，加盟企業商品が追加される都度…登録済みでないと判断すれば新たな横断分析用商品コードを加盟企業商品に設定する」

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

• 「横断分析用商品コードは一意に識別できるから主キーに使える」と考える
  → 一意性だけでなく 登録時点の NULL 禁止 も主キーの必須要件です。
• JANコードや加盟企業商品名をキー候補に挙げる
  → JANコードは「設定されない商品もある」「再利用されることがある」，商品名も再利用されるのでキーに不適です。

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

• 主キーは 必ず一意かつ非 NULL の属性・属性集合から選ぶ
• 候補キーと主キーは，「レコード登録時点で確定している」 ことを確認する
• 業務要件で「後付け」「バッチ処理」で設定される属性は主キーに使わない
• 候補キー抽出の際は「属性の一意性」「NULL 許容」「設定タイミング」の３点を必ずチェックする

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

2. なぜその解答になるのか（問題文引用付きの論理説明）

2.1 主キーの確認

2.2 機能従属性の洗い出し

1. 「同じ加盟企業と複数回の契約をすることはない。」
   → 加盟企業コードが決まれば、加盟企業名・契約開始日・契約終了日は一意に決まる。
   ⇒ (加盟企業コード) → {加盟企業名, 契約開始日, 契約終了日}
2. 「横断分析用商品情報には, … 横断分析用商品コードで識別する。」
   → 横断分析用商品コードが決まれば横断分析用商品名は一意。
   ⇒ (横断分析用商品コード) → {横断分析用商品名}
3. 「加盟企業商品は, 加盟企業コードと加盟企業商品コードで識別する。」
   → 主キー全体が決まればJANコード・加盟企業商品名・横断分析用商品コードが決まる。
   ⇒ (加盟企業コード, 加盟企業商品コード) → {JANコード, 加盟企業商品名, 横断分析用商品コード}

2.3 正規化判定

1. 第1正規形：繰返し属性は無いので満たす。
2. 第2正規形：主キーの一部（加盟企業コード）のみに依存する属性（加盟企業名など）があるため 不合格。
3. 第3正規形：そもそも2NFを満たさないので当然 不合格。さらに横断分析用商品コード → 横断分析用商品名 という推移的従属も存在。

2.4 第3正規形への分解

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

4. 試験対策のまとめ

1. 第2正規形のチェック手順
   ① 主キーを部分的に決定する非キー属性が無いか探す。
   ② あればその部分キー＋属性で別リレーションを作成。
2. 第3正規形のチェック手順
   ① 2NFを満たしていることを確認。
   ② 非キー → 非キー の機能従属が無いかを探す（推移的従属）。
   ③ あれば従属先を別リレーションへ。
3. 機能従属性の根拠は必ず “業務ルール” に求める。
   問題文から根拠を抜き出す癖をつける。
4. 答案記述の作法
   ・主キー：実線下線、外部キー：破線下線。
   ・関係名・属性名は「本文中の用語」を忠実に使用。
   ・分解後の関係が2つ以上ある場合、意味のまとまりを意識して命名。
5. ひっかけ回避
   ・「コード」属性があると大抵はそれが主キー。
   ・「〜は一意」「再利用しない」＝決定性あり。
   ・「〜ごとに識別」＝複合主キーの合図。

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

• 日次バッチ：「毎日午前0時を過ぎると，支払ごとの付与ポイントの記録から，支払日時が前日の分を日次バッチで抽出し，集計して会員のポイント残高に加算する。」
• ポイント後付け：「会員がポイントカードを忘れた場合…レシートが発行された日時の記録となる。」
• 対象外となる条件：ポイント後付けの「支払日時」が前日の期間に含まれない

なぜ「購入の翌日以降にポイントの後付けをしたとき」になるのか

1. ポイント通常付与の場合
   「支払ごとの付与ポイントの記録」は、支払日時が記録される。
2. 日次バッチの抽出条件
   「支払日時が前日の分」を抽出して、ポイント残高に加算する。
3. ポイント後付けの場合
   • 「付与ポイントの記録は，レシートが発行された日時の記録となる。」
   • 会員が後日（購入の翌日以降）にレシートを持参してポイント後付けをすると、
     レコードの支払日時は購入日の日時となる。
   • その購入日は日次バッチの「前日」の範囲外になるため、抽出対象とならず、ポイント残高に加算されない。

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

• 「ポイント後付けは１か月以内」という期間条件に着目しやすいが、日次バッチが参照するのは“支払日時”
• 「後付けの申告日＝支払日時」と誤解しやすいが、実際はレシート発行日時が支払日時として記録される
• 問われているのは「加算されない場合」であり、「後付けできる期間」ではない

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

• 日次バッチの集計対象は支払日時が前日のレコードであること
• ポイント後付け時の記録タイミングは「レシートが発行された日時」であること
• 購入翌日以降に登録された後付けは、支払日時のズレにより日次バッチで取り込まれない点を押さえること

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

• 「ポイント残高に加算済みかどうかを判別する」→日次バッチで二重加算を防止
• 「ポイント残高への加算処理日が分かるようにする」→いつ処理したか記録
• 「付与ポイントの記録を作成日で抽出できるようにする」→抽出条件の明確化

解答がこれになる理由と論理的説明

「毎日午前0時を過ぎると, 支払ごとの付与ポイントの記録から, 支払日時が前日の分を日次バッチで抽出し, 集計して会員のポイント残高に加算する。」
とあります。
この仕組みのままだと、

1. まだ加算していないレコードだけを抽出できない
2. 過去に一度でも加算済みのレコードと区別がつかない
   という課題が生じます。
   そこで「関係 ‘支払’ に属性を一つ追加」し、

• 日次バッチ実行前後でレコードを区別（未加算／加算済み）
• 加算処理日を保持していつ処理したか分かる
  ようにする必要があります。

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

• 「支払日時」だけで管理できると思い込む
  → 支払日時は支払いそのものの日付であり、加算の有無や処理日を示さない。
• 「付与ポイントの記録作成日」を使う案
  → レシート発行日とは異なる、バッチ処理のタイミングを別途管理する必要がある。
• 「利用ポイント」や「付与ポイント」を加工して代用しようとする
  → 実際のポイント付与額と処理状態は別次元の情報なので混同不可。

試験対策として覚えておくべき知識

• バッチ処理での「増分抽出」には必ず処理済み判別属性（フラグや処理日）が必要
• 「支払日時」「作成日時」「処理日時」はそれぞれ別の意味を持つ
• 再実行時にも安定して同じ結果を得るための「冪等性（べきとうせい）」設計
• データベース設計では、**業務的な状態管理（未処理・処理済み）**を属性として表現する

属性追加の例（関係スキーマ再掲）