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

模範解答

解説

解答の論理構成

1. 支払テーブルの (a),(b)
   “店舗は,加盟企業コードと店舗コードで識別する” とあるため，支払から店舗を参照するには両方を外部キーにする必要があります。
   よって (a)：加盟企業コード，(b)：店舗コード。
2. 支払方法明細の (c)
   “支払方法ごとの付与ポイントは,各支払方法での支払金額に、ポイント付与率を乗じて計算する”。計算の基になる金額を保持する属性は “支払金額”。
3. 購入商品明細の (d)
   商品単価は既にスキーマに存在しており，購入金額は “購入数×商品単価” と定義されています。積の片方が欠けているので (d) は “購入数”。
4. 支払方法の (e)
   “各支払方法に対するポイント付与率は, ポイント設定で決めている” とあるため，支払方法が参照する外部キーは “ポイント設定コード”。
5. ポイント設定の (f)
   ポイント設定は “ポイント付与率, 適用期間をもつ” と説明されているので，“ポイント付与率” が欠けており (f) に当たります。
6. クーポン設定の (g)
   “クーポンには,配布上限数と配布期間を設定している” とあるので，欠落している数値属性は “配布上限数”。
7. クーポン配布の (h),(i)
   “同じ会員に同じクーポンを2回発行することはない” → 主キーはクーポンコード＋会員コード。よって (h)：クーポンコード，(i)：会員コード。
8. クーポン利用の (j),(k)
   “クーポンがどの支払で利用されたか分かるように記録する” → クーポン利用はクーポンコードとレシート番号の組で一意。したがって (j)：クーポンコード，(k)：レシート番号。

誤りやすいポイント

• 支払テーブルに店舗キーを置かず，店舗テーブルを “店舗ID” など単独キーと誤認する。
• 購入商品明細の (d) を “購入金額” としてしまい，計算用データ冗長を生む。
• クーポン配布の主キーを会員コード単独やクーポンコード単独で設定し，排他条件を実装側ロジックに委ねる。
• クーポン利用のキー構成を “クーポンコード＋会員コード” と混同する。

FAQ

模範解答

解説

解答の論理構成

1. クーポン設定と店舗の関連
   【問題文】「クーポンは, 企画した加盟企業の店舗だけで利用できる。」
   → 多：多関係の解消として「クーポン設定対象店舗」を設置。
   → 結果：
   ・「クーポン設定」1 – N「クーポン設定対象店舗」
   ・「店舗」1 – N「クーポン設定対象店舗」
2. 会員とクーポン配布
   【問題文】「クーポン配布リストに登録されている会員が…クーポンを発行する。…同じ会員に同じクーポンを2回発行することはない。」
   → 「クーポン配布」はクーポンコード＋会員コードで一意。
   → 「クーポン設定」1 – N「クーポン配布」、
   「会員」1 – N「クーポン配布」。
3. クーポン利用と支払
   【問題文】「クーポンがどの支払で利用されたか分かるように記録する。」
   → 「クーポン利用」エンティティを介し、
   ・「クーポン設定」1 – N「クーポン利用」
   ・「支払」1 – N「クーポン利用」。
4. 会員と支払
   【問題文】「会員は…支払をする。」
   → 「会員」1 – N「支払」。
5. 店舗と支払
   【問題文】「会員が…この店舗に持って行き, ポイントカードを提示すると…」など、支払は店舗単位で行われる。
   → 「店舗」1 – N「支払」。
6. 支払の明細展開
   a. 支払方法
   【問題文】「1 回の支払で複数の支払方法を併用できる。」
   → 「支払」1 – N「支払方法明細」1 – 1「支払方法」。
   b. ポイント設定
   【問題文】「各支払方法に対するポイント付与率は, ポイント設定で決めている。」
   → 「支払方法」1 – N「ポイント設定」。
   c. 購入商品
   【問題文】「商品の購入金額…」
   → 「支払」1 – N「購入商品明細」。

誤りやすいポイント

• 「クーポン設定」と「クーポン利用」を直接多対多で結んでしまい、中間エンティティを置かない。
• 「支払」と「支払方法」を1対1と誤認し、複数支払方法併用要件を落とす。
• 「店舗」―「支払」の関係を抜かし、どの店舗で発生した支払か管理できなくなる。
• 「ポイント設定」と「支払方法」を逆方向に張り、ポイント設定の履歴管理が不完全になる。

FAQ

模範解答

解説

解答の論理構成

1. 候補キーの洗い出し
   • 加盟企業商品を識別する主キーは【問題文】「加盟企業コードと加盟企業商品コードで識別する。」から { 加盟企業コード, 加盟企業商品コード }。
   • 同一加盟企業内で同一の横断分析用商品コードは重複しない。したがって { 加盟企業コード, 横断分析用商品コード } も一意性を保つ。
   • 以上２組が候補キーとなる。
2. 部分関数従属性の有無
   • 複合キーの一部 → 非キー属性 の形が存在すれば“あり”。
     ・加盟企業コード → 加盟企業名, 契約開始日, 契約終了日
     ・横断分析用商品コード → 横断分析用商品名
     いずれも複合キーの一部のみで決まるため部分依存が発生。
3. 推移的関数従属性の有無
   • 複合キー → 中間属性 → 非キー属性 の連鎖が存在すれば“あり”。
     ・{ 加盟企業コード, 加盟企業商品コード } → 横断分析用商品コード → 横断分析用商品名
   • よって推移依存が発生する。
4. 具体例（解答用フォーマット）
   • 部分関数従属性：加盟企業コード → 加盟企業名
   • 推移的関数従属性：{ 加盟企業コード, 加盟企業商品コード } → 横断分析用商品コード → 横断分析用商品名

誤りやすいポイント

• 「横断分析用商品コードだけが候補キー」と誤認する
  複数の加盟企業が同じ横断分析用商品コードを共有するため単独ではキーにならない。
• JANコードを候補キーに含めてしまう
  【問題文】「JANコードが設定されない商品もある。」ので一意性も NULL 回避も保証できない。
• 部分依存と推移依存を同一視する
  部分依存は“複合キーの一部”、推移依存は“キー全体に依存→さらに他の属性に依存”という構造の違いを確認する。

FAQ

模範解答

解説

解答の論理構成

1. 候補キー候補の洗い出し
   関係 “加盟企業商品” は【問題文】で
   “加盟企業商品は, 加盟企業コードと加盟企業商品コードで識別する。”
   と規定されています。また
   “②…横断分析用商品コードを加盟企業商品に設定する。”
   から { 加盟企業コード, 横断分析用商品コード } も一意性を満たすため候補キーになり得ます。
2. 主キー要件の確認
   主キー列は「常に NOT NULL」である必要があります（エンティティ整合性制約）。
3. NULL 発生の有無
   同じく【問題文】の
   “③ 横断分析用商品コードの設定には, 加盟企業商品の登録から数日を要する場合がある。”
   より，行登録時点では 横断分析用商品コード が未設定になるケースが明示されています。
4. 結論
   よって { 加盟企業コード, 横断分析用商品コード } は主キー条件を満たさず「採用できない候補キー」となります。

誤りやすいポイント

• 「一意になれば主キーにできる」と思い込み，入力タイミングや NULL 可能性を無視する。
• 横断分析用商品コードが後日必ず埋まるから問題ないと考え，初期 NULL が許されない点を見落とす。
• 候補キーと主キーの区別（候補キーは複数可、主キーはその中で選定される１つ）を混同する。

FAQ

模範解答

解説

解答の論理構成

1. 主キーの確認
   【問題文】「加盟企業商品は,加盟企業コードと加盟企業商品コードで識別する。」
   ⇒ 主キー：{加盟企業コード, 加盟企業商品コード}
2. 第1正規形の判定
   ・繰返し属性や多値属性は無い。よって第1正規形。
3. 第2正規形の判定
   ・「加盟企業名，契約開始日，契約終了日」は“加盟企業コード”だけで決まる。
   ・主キーの一部にのみ従属する部分関数従属性が存在 → 第2正規形を満たさない。
4. 第3正規形の判定
   ・「横断分析用商品名」は“横断分析用商品コード”で決まる。
   ・非キー → 非キーの推移的関数従属性が存在 → 第3正規形も満たさない。
5. 分解手順
   ① “加盟企業コード”の従属性を独立
   加盟企業(加盟企業コード, 加盟企業名, 契約開始日, 契約終了日)
   ② “横断分析用商品コード”の従属性を独立
   横断分析用商品情報(横断分析用商品コード, 横断分析用商品名)
   ③ 残りを再構成
   加盟企業商品(加盟企業コード, 加盟企業商品コード, JANコード, 加盟企業商品名, 横断分析用商品コード)
   以上３関係はいずれも主キーしか決定因子を持たず，第3正規形を満たします。

誤りやすいポイント

• 「加盟企業商品コードは再利用されない」→ だからといって単独キーにしない
  （同一加盟企業を識別する“加盟企業コード”との複合が必要）。
• 「JANコードが設定されない商品もある」→ NULL可属性はキーにならない。
• 「横断分析用商品名」をそのまま残してしまい推移従属性を見落とす。
• 分解後に外部キーを付け忘れ，参照整合性を示せていない。

FAQ

模範解答

解説

解答の論理構成

1. 日次バッチの対象
   • 「毎日午前0時を過ぎると, 支払ごとの付与ポイントの記録から, 支払日時が前日の分を日次バッチで抽出し, 集計して会員のポイント残高に加算する。」
     ⇒バッチは“前日”の支払日時を条件に抽出。
2. 後付けレコードのタイムスタンプ
   • 「付与ポイントの記録は,レシートが発行された日時の記録となる。」
     ⇒後付けしても“支払日時”は購入時(レシート発行時)のまま。
3. 時系列のずれ
   • 後付けが「購入の翌日以降」に行われると、
     バッチは既に対象日(購入日)を処理済み → 抽出されない。
4. 結果
   • よって後付けポイントは残高に加算されず、設問の答えは「購入の翌日以降にポイントの後付けをしたとき」となる。

誤りやすいポイント

• 「後付けした日の翌日バッチで入る」と誤解し、支払日時と登録日時を混同する。
• 付与ポイントを即時加算と勘違いし、日次バッチの存在を見落とす。
• 「当日中の後付け」も漏れると決めつけるが、当日23:59までに登録されれば前日判定にかからないため集計対象になる。

FAQ

模範解答

解説

解答の論理構成

1. 日次バッチの仕様
   【問題文】「支払ごとの付与ポイントの記録から, 支払日時が前日の分を…会員のポイント残高に加算する」。
2. 問題点
   • 処理が失敗して再実行すると、同じ支払レコードが再度抽出され二重加算の恐れ。
   • 将来“当日分を即時加算”など仕様変更があった場合も誤加算リスクが残る。
3. 解決策
   • 支払レコードに「加算済」を示す情報を付与。
   • バッチは “未加算かつ対象日付” で抽出し、成功後にフラグを更新。
4. したがって追加属性の役割
   「ポイント残高に加算済みかどうかを判別する。」（30字以内）

誤りやすいポイント

• 抽出条件に「支払日時が前日」を使えば重複防止できると誤解する。
• 支払テーブルではなくポイント残高テーブル側にフラグを持たせようとする。
• 「加算済フラグ」と「ポイント残高更新日時」の違いを区別しない。

FAQ