データベーススペシャリスト 2021年 午後1 問01
データベース設計に関する次の記述を読んで、設問1〜3に答えよ。
B社は、複数の加盟企業向けに共通ポイントサービスを運営している。 今回、その基盤のシステム (以下、ポイントシステムという)を再構築することになり、データベース設計を開始した。
〔ポイントシステムの概要〕
1.会員
会員は、B社が発行したポイントカードの利用者であり、会員コードで識別する。
2.加盟企業
(1) 加盟企業は、B社と共通ポイントサービス加盟の契約をした企業であり、加盟企業コードで識別する。 コンビニエンスストア、レストランチェーンなど様々な業種の企業がある。 同じ加盟企業と複数回の契約をすることはない。
(2) 加盟企業は複数の店舗をもつ。 店舗は、加盟企業コードと店舗コードで識別する。
3.加盟企業商品と横断分析用商品情報
(1) 加盟企業商品
① 加盟企業が販売する商品を、B社から見て加盟企業商品と呼ぶ。
② 加盟企業は、商品をポイントシステムに登録するときに、当該加盟企業の商品コード(以下、加盟企業商品コードという)、商品名(以下、加盟企業商品名という)、JANコードを登録する。 加盟企業商品は、加盟企業コードと加盟企業商品コードで識別する。
③ 加盟企業商品コードは再利用されないが、加盟企業商品名と JANコードは再利用されることがある。 また、JANコードが設定されない商品もある。
(2) 横断分析用商品情報
① 横断分析用商品情報は、複数の加盟企業が同じ商品を扱っている場合に同一商品であると認識できるようにするものである。 横断分析用商品情報には、横断分析用商品コードと横断分析用商品名を設定し、横断分析用商品コードで識別する。 横断分析用商品名は一意になるとは限らない。
② B社は、加盟企業商品が追加される都度、既に同じ商品の横断分析用商品が-登録済みかどうかを確認し、登録済みと判断すればその横断分析用商品コードを登録済みでないと判断すれば新たな横断分析用商品コードを加盟企業商品に設定する。
③ 横断分析用商品コードの設定には、加盟企業商品の登録から数日を要する場合がある。
〔ポイントの概要〕
1.ポイント
ポイントは、加盟企業の販促のために会員に与える点数である。
2.ポイントの利用
(1) 会員は、自分のポイント残高を上限として、購入金額の一部又は全てをポイントで支払うことができる。 利用したポイント (以下、利用ポイントという)は、支払時にポイント残高から減算する。
(2) ポイントは、全ての加盟企業の店舗で利用できる。
(3) 利用ポイントを支払ごとに記録する。 1回の支払はレシート番号で識別する。
3.ポイントの付与
(1) 会員がポイントカードを提示して支払をすると、その支払で付与するポイントを記録する。 ポイントカードの提示がなければこの記録を作成しない。
(2) 付与ポイントを記録した時点では、付与ポイントの記録は会員のポイント残高に加算しない。 ポイント残高への加算は後述の日次バッチで行う。
(3) ポイントには、商品ごとの購入金額に対して付与するものと、支払方法ごとの支払金額に対して付与するものがある。
① 購入商品ごとの付与ポイント
・商品の購入金額 (購入数×商品単価) にポイント付与率を乗じて計算する。
・ポイント付与率は、通常は全加盟企業共通で決められている基準ポイント付与率を適用するが、後述のクーポンの利用によって変わることがある。
②支払方法ごとの付与ポイント
・支払においては、現金、ポイント利用、電子マネー利用など、1 回の支払で複数の支払方法を併用できる。
・支払方法ごとの付与ポイントは、各支払方法での支払金額に、ポイント付与率を乗じて計算する。
・各支払方法に対するポイント付与率は、ポイント設定で決めている。 ポイント設定はポイント設定コードで識別し、ポイント付与率、適用期間をもつ。ポイントを付与する支払方法にポイント設定を対応付ける。 同じポイント設定を、複数の支払方法に対応付けることがある。
(4) 付与ポイントは、小数第3位まで記録する。
(5) 会員がポイントで支払った分にもポイントを付与する。
4.付与ポイントのポイント残高への加算
(1) 毎日午前0時を過ぎると、支払ごとの付与ポイントの記録から、支払日時が前日の分を日次バッチで抽出し、集計して会員のポイント残高に加算する。
(2) 購入商品ごとの付与ポイントと支払方法ごとの付与ポイントを加算し、小数点以下を切り捨てたものが支払全体の付与ポイントとなる。
5.ポイントの後付け
(1) 会員がポイントカードを忘れた場合、会員が申告すると店員は支払時のレシートに押印する。 会員がこのレシートを1か月以内にこの店舗に持って行き、ポイントカードを提示すると、その支払で付与するポイントを記録する。
(2) 付与ポイントの記録は、レシートが発行された日時の記録となる。
〔クーポンの概要〕
1.クーポン
(1) B社は、クーポンという販促手段を用意している。 加盟企業は、自社の店舗に会員を呼び込むために、クーポンを企画する。
(2) クーポンは、会員に配布する紙片である。 会員が支払時にクーポンを提示すると、クーポンに設定されたポイント付与率を適用する。 店舗は、提示されたクーポンを回収する。
(3) クーポンの企画単位にクーポンコードを付与する。
(4) クーポンは、企画した加盟企業の店舗だけで利用できる。
(5) クーポンには、利用期間を設定している。
(6) 設定できるクーポンには、適用対象となる店舗を限定したクーポン、適用対象となる商品を限定したクーポン、及び、店舗も商品も限定しないクーポンがある。 ただし、商品の購入数を限定したクーポンは設定できない。
(7) 会員は、クーポンコードが異なる複数のクーポンを1回の支払で利用できる。
(8) クーポンの効果を測るために、クーポンがどの支払で利用されたか分かるように記録する。
2.クーポンの配布方法
(1) クーポンを企画した加盟企業は、B社に料金を支払い、クーポンの配布対象にしたい会員の抽出条件をB社に伝える。
(2) 会員の抽出は、支払時のポイント付与の記録を用いて行う。 抽出条件には、ある期間に特定の店舗を利用した、特定の商品を一定以上の金額分購入した、特定の支払方法で一定以上の金額を支払った、などがある。
(3) B社は、条件に合う会員を抽出し、クーポン配布リストとして登録する。 会員の抽出は、日次バッチで行う。
(4) クーポン配布リストに登録されている会員が、全加盟企業のいずれかの店舗を利用した場合に、クーポンを発行する。 同じ会員に同じクーポンを2回発行することはない。
(5) クーポンには、配布上限数と配布期間を設定している。
〔概念データモデルと関係スキーマの設計〕
概念データモデルを図1に、関係スキーマを図2に示す。


解答に当たっては、巻頭の表記ルールに従うこと。 ただし、エンティティタイプ間の対応関係にゼロを含むか否かの表記は必要ない。
なお、エンティティタイプ間のリレーションシップとして “多対多” のリレーションシップを用いないこと。 エンティティタイプ名及び属性名は、それぞれ意味を識別できる適切な名称とすること。
設問1:図1,2について、(1)、(2)に答えよ。
(1)図2中の(a)〜(k)に入れる適切な属性名を答えよ。なお、主キーを構成する属性の場合は実線の下線を、外部キーを構成する属性の場合は破線の下線を付けること。(a, bは順不同、h, iは順不同、j, kは順不同)
模範解答
a:加盟企業コード
b:店舗コード
c:支払金額
d:購入数
e:ポイント設定コード
f:ポイント付与率
g:配布上限数
h:クーポンコード
i:会員コード
j:クーポンコード
k:レシート番号
解説
解答の論理構成
-
支払テーブルの (a)、(b)
“店舗は、加盟企業コードと店舗コードで識別する” とあるため、支払から店舗を参照するには両方を外部キーにする必要があります。
よって (a):加盟企業コード、(b):店舗コード。 -
支払方法明細の (c)
“支払方法ごとの付与ポイントは、各支払方法での支払金額に、ポイント付与率を乗じて計算する”。計算の基になる金額を保持する属性は “支払金額”。 -
購入商品明細の (d)
商品単価は既にスキーマに存在しており、購入金額は “購入数×商品単価” と定義されています。積の片方が欠けているので (d) は “購入数”。 -
支払方法の (e)
“各支払方法に対するポイント付与率は、ポイント設定で決めている” とあるため、支払方法が参照する外部キーは “ポイント設定コード”。 -
ポイント設定の (f)
ポイント設定は “ポイント付与率、適用期間をもつ” と説明されているので、“ポイント付与率” が欠けており (f) に当たります。 -
クーポン設定の (g)
“クーポンには、配布上限数と配布期間を設定している” とあるので、欠落している数値属性は “配布上限数”。 -
クーポン配布の (h)、(i)
“同じ会員に同じクーポンを2回発行することはない” → 主キーはクーポンコード+会員コード。よって (h):クーポンコード、(i):会員コード。 -
クーポン利用の (j)、(k)
“クーポンがどの支払で利用されたか分かるように記録する” → クーポン利用はクーポンコードとレシート番号の組で一意。したがって (j):クーポンコード、(k):レシート番号。
誤りやすいポイント
- 支払テーブルに店舗キーを置かず、店舗テーブルを “店舗ID” など単独キーと誤認する。
- 購入商品明細の (d) を “購入金額” としてしまい、計算用データ冗長を生む。
- クーポン配布の主キーを会員コード単独やクーポンコード単独で設定し、排他条件を実装側ロジックに委ねる。
- クーポン利用のキー構成を “クーポンコード+会員コード” と混同する。
FAQ
Q: 支払テーブルに店舗情報を入れると多重度が増えて正規形が崩れませんか?
A: 店舗は “1回の支払は必ず1店舗で行われる” という業務上の制約があるため、多重度は 1:1 と扱えます。ゆえに非キー属性の完全関数従属を壊すことはなく、第3正規形を保てます。
A: 店舗は “1回の支払は必ず1店舗で行われる” という業務上の制約があるため、多重度は 1:1 と扱えます。ゆえに非キー属性の完全関数従属を壊すことはなく、第3正規形を保てます。
Q: ポイント設定コードを支払方法に置くのではなく、支払方法明細に置く設計はダメですか?
A: “各支払方法に対するポイント付与率は、ポイント設定で決めている” とあるため、ポイント設定は支払方法そのものにひも付きます。明細に置くと、同じ支払方法コードに異なるポイント設定コードを登録できてしまい、一意性を保証できません。
A: “各支払方法に対するポイント付与率は、ポイント設定で決めている” とあるため、ポイント設定は支払方法そのものにひも付きます。明細に置くと、同じ支払方法コードに異なるポイント設定コードを登録できてしまい、一意性を保証できません。
Q: クーポン利用テーブルに付与ポイントや割引額を持たせるべきでは?
A: 要件で “クーポンがどの支払で利用されたか分かるように記録する” のみが求められています。金額情報は支払・明細側で集約できるため、ここではリレーションシップのトレーサビリティを重視しています。
A: 要件で “クーポンがどの支払で利用されたか分かるように記録する” のみが求められています。金額情報は支払・明細側で集約できるため、ここではリレーションシップのトレーサビリティを重視しています。
関連キーワード: 外部キー、主キー、正規形、多重度、ポイント付与率
設問1:図1,2について、(1)、(2)に答えよ。
(2)図1のリレーションシップは未完成である。必要なリレーションシップを全て記入し、図を完成させよ。
なお、図に表示されていないエンティティタイプは考慮しなくてよい。
模範解答

解説
解答の論理構成
-
クーポン設定と店舗の関連
【問題文】「クーポンは、企画した加盟企業の店舗だけで利用できる。」
→ 多:多関係の解消として「クーポン設定対象店舗」を設置。
→ 結果:
・「クーポン設定」1 – N「クーポン設定対象店舗」
・「店舗」1 – N「クーポン設定対象店舗」 -
会員とクーポン配布
【問題文】「クーポン配布リストに登録されている会員が…クーポンを発行する。…同じ会員に同じクーポンを2回発行することはない。」
→ 「クーポン配布」はクーポンコード+会員コードで一意。
→ 「クーポン設定」1 – N「クーポン配布」、 「会員」1 – N「クーポン配布」。 -
クーポン利用と支払
【問題文】「クーポンがどの支払で利用されたか分かるように記録する。」
→ 「クーポン利用」エンティティを介し、 ・「クーポン設定」1 – N「クーポン利用」
・「支払」1 – N「クーポン利用」。 -
会員と支払
【問題文】「会員は…支払をする。」
→ 「会員」1 – N「支払」。 -
店舗と支払
【問題文】「会員が…この店舗に持って行き、ポイントカードを提示すると…」など、支払は店舗単位で行われる。
→ 「店舗」1 – N「支払」。 -
支払の明細展開
a. 支払方法
【問題文】「1 回の支払で複数の支払方法を併用できる。」
→ 「支払」1 – N「支払方法明細」1 – 1「支払方法」。
b. ポイント設定
【問題文】「各支払方法に対するポイント付与率は、ポイント設定で決めている。」
→ 「支払方法」1 – N「ポイント設定」。
c. 購入商品
【問題文】「商品の購入金額…」
→ 「支払」1 – N「購入商品明細」。
誤りやすいポイント
- 「クーポン設定」と「クーポン利用」を直接多対多で結んでしまい、中間エンティティを置かない。
- 「支払」と「支払方法」を1対1と誤認し、複数支払方法併用要件を落とす。
- 「店舗」―「支払」の関係を抜かし、どの店舗で発生した支払か管理できなくなる。
- 「ポイント設定」と「支払方法」を逆方向に張り、ポイント設定の履歴管理が不完全になる。
FAQ
Q: クーポン利用を「クーポン配布」だけで特定できないのですか?
A: 配布後に必ず利用されるとは限らず、さらに【問題文】「クーポンがどの支払で利用されたか分かるように記録する。」とあるため、支払とのリレーションが必須です。
A: 配布後に必ず利用されるとは限らず、さらに【問題文】「クーポンがどの支払で利用されたか分かるように記録する。」とあるため、支払とのリレーションが必須です。
Q: 「支払方法明細」と「ポイント設定」は本当に1 – Nですか?
A: はい。【問題文】「同じポイント設定を、複数の支払方法に対応付けることがある。」と明示されており、支払方法側がNとなります。
A: はい。【問題文】「同じポイント設定を、複数の支払方法に対応付けることがある。」と明示されており、支払方法側がNとなります。
Q: 多対多禁止指示はどう解釈すれば良いですか?
A: 「エンティティタイプ間のリレーションシップとして“多対多”のリレーションシップを用いないこと。」とあるため、中間エンティティ(例:クーポン設定対象店舗)で必ず1 – N – 1構造に分解します。
A: 「エンティティタイプ間のリレーションシップとして“多対多”のリレーションシップを用いないこと。」とあるため、中間エンティティ(例:クーポン設定対象店舗)で必ず1 – N – 1構造に分解します。
関連キーワード: リレーションシップ、正規化、参照整合性、連結エンティティ、カーディナリティ
設問2:図2中の関係 “加盟企業商品” について(1)〜(3)に答えよ。
(1)関係“加盟企業商品” の候補キーを全て答えよ。 また、部分関数従属性、推移的関数従属性の有無を、答案用紙のあり・なしのいずれかを○で囲んで示せ。“あり”の場合は、次の表記法に従って、その関数従属性の具体例を一つ示せ。
なお、候補キー及び表記法に示されている属性1,属性3,属性4が複数の属性から構成される場合は、{}でくくること。
なお、候補キー及び表記法に示されている属性1,属性3,属性4が複数の属性から構成される場合は、{}でくくること。模範解答
候補キー:{ 加盟企業コード、加盟企業商品コード }
{ 加盟企業コード、横断分析用品商品コード }
部分関数従属性:
有無:あり
具体例:加盟企業コード → 加盟企業名
加盟企業コード → 契約開始日
加盟企業コード → 契約終了日
横断分析用品商品コード → 横断分析用品名
推移的関数従属性
有無:あり
具体例:{ 加盟企業コード、加盟企業商品コード } → 横断分析用品商品コード → 横断分析用品名
解説
解答の論理構成
- 候補キーの洗い出し
- 加盟企業商品を識別する主キーは【問題文】「加盟企業コードと加盟企業商品コードで識別する。」から { 加盟企業コード、加盟企業商品コード }。
- 同一加盟企業内で同一の横断分析用商品コードは重複しない。したがって { 加盟企業コード、横断分析用商品コード } も一意性を保つ。
- 以上2組が候補キーとなる。
- 部分関数従属性の有無
- 複合キーの一部 → 非キー属性 の形が存在すれば“あり”。
・加盟企業コード → 加盟企業名、契約開始日、契約終了日
・横断分析用商品コード → 横断分析用商品名
いずれも複合キーの一部のみで決まるため部分依存が発生。
- 複合キーの一部 → 非キー属性 の形が存在すれば“あり”。
- 推移的関数従属性の有無
- 複合キー → 中間属性 → 非キー属性 の連鎖が存在すれば“あり”。
・{ 加盟企業コード、加盟企業商品コード } → 横断分析用商品コード → 横断分析用商品名 - よって推移依存が発生する。
- 複合キー → 中間属性 → 非キー属性 の連鎖が存在すれば“あり”。
- 具体例(解答用フォーマット)
- 部分関数従属性:加盟企業コード → 加盟企業名
- 推移的関数従属性:{ 加盟企業コード、加盟企業商品コード } → 横断分析用商品コード → 横断分析用商品名
誤りやすいポイント
- 「横断分析用商品コードだけが候補キー」と誤認する
複数の加盟企業が同じ横断分析用商品コードを共有するため単独ではキーにならない。 - JANコードを候補キーに含めてしまう
【問題文】「JANコードが設定されない商品もある。」ので一意性も NULL 回避も保証できない。 - 部分依存と推移依存を同一視する
部分依存は“複合キーの一部”、推移依存は“キー全体に依存→さらに他の属性に依存”という構造の違いを確認する。
FAQ
Q: JANコードが一意に見えるのに候補キーに含まれないのはなぜですか?
A: 【問題文】「JANコードが設定されない商品もある。」ため NULL 値が発生し得ます。一意性が保証されない属性は候補キーに採用できません。
A: 【問題文】「JANコードが設定されない商品もある。」ため NULL 値が発生し得ます。一意性が保証されない属性は候補キーに採用できません。
Q: “横断分析用商品名”を第3正規形に分離した方が良いのですか?
A: はい。推移的従属を排除するには “横断分析用商品” を独立表として持ち、“加盟企業商品” からは “横断分析用商品コード” だけを参照させるのが正規化の王道です。
A: はい。推移的従属を排除するには “横断分析用商品” を独立表として持ち、“加盟企業商品” からは “横断分析用商品コード” だけを参照させるのが正規化の王道です。
Q: 「加盟企業コード → 加盟企業名」以外にも部分依存を書く必要がありますか?
A: 解答欄は1例で良い場合が多いですが、【問題文】に基づき「加盟企業コード → 契約開始日」など同一グループの属性を挙げても正答になります。
A: 解答欄は1例で良い場合が多いですが、【問題文】に基づき「加盟企業コード → 契約開始日」など同一グループの属性を挙げても正答になります。
関連キーワード: 候補キー、部分関数従属、推移的関数従属、第3正規形
設問2:図2中の関係 “加盟企業商品” について(1)〜(3)に答えよ。
(2)関係 “加盟企業商品” の候補キーのうち、主キーとして採用できないものはどれか答えよ。 また、その理由を 45字以内で具体的に述べよ。
模範解答
採用できない候補キー:{ 加盟企業コード、横断分析用品商品コード }
理由:横断分析用品商品コードは加盟企業商品が登録された後に設定される場合があるから
解説
解答の論理構成
- 候補キー候補の洗い出し
関係 “加盟企業商品” は【問題文】で
“加盟企業商品は、加盟企業コードと加盟企業商品コードで識別する。”
と規定されています。また
“②…横断分析用商品コードを加盟企業商品に設定する。”
から { 加盟企業コード、横断分析用商品コード } も一意性を満たすため候補キーになり得ます。 - 主キー要件の確認
主キー列は「常に NOT NULL」である必要があります(エンティティ整合性制約)。 - NULL 発生の有無
同じく【問題文】の
“③ 横断分析用商品コードの設定には、加盟企業商品の登録から数日を要する場合がある。”
より、行登録時点では 横断分析用商品コード が未設定になるケースが明示されています。 - 結論
よって { 加盟企業コード、横断分析用商品コード } は主キー条件を満たさず「採用できない候補キー」となります。
誤りやすいポイント
- 「一意になれば主キーにできる」と思い込み、入力タイミングや NULL 可能性を無視する。
- 横断分析用商品コードが後日必ず埋まるから問題ないと考え、初期 NULL が許されない点を見落とす。
- 候補キーと主キーの区別(候補キーは複数可、主キーはその中で選定される1つ)を混同する。
FAQ
Q: 横断分析用商品コードが後で必ず入力されるなら、一時的に NULL でも問題ないのでは?
A: 主キー列は“常に” NOT NULL が必須です。途中で NULL が入る期間が存在するだけで主キー要件を満たせません。
A: 主キー列は“常に” NOT NULL が必須です。途中で NULL が入る期間が存在するだけで主キー要件を満たせません。
Q: では { 加盟企業コード、加盟企業商品コード } が主キーとして適切なのですか?
A: はい。両列は登録時に必ず値が決まり、再利用されないと【問題文】にあるため主キー条件を満たします。
A: はい。両列は登録時に必ず値が決まり、再利用されないと【問題文】にあるため主キー条件を満たします。
Q: 横断分析用商品コード単独をユニークキーにするのは可能?
A: 登録タイミングの問題を解消できる運用(NULL 不可)を敷くならユニークキー制約は付与できます。ただし主キーには不向きです。
A: 登録タイミングの問題を解消できる運用(NULL 不可)を敷くならユニークキー制約は付与できます。ただし主キーには不向きです。
関連キーワード: 候補キー、主キー、エンティティ整合性、NULL, 一意性
設問2:図2中の関係 “加盟企業商品” について(1)〜(3)に答えよ。
(3)関係 “加盟企業商品” は第1正規形、第2正規形、第3正規形のうち、どこまで正規化されているか答えよ。 第3正規形でない場合は、第3正規形に分解し、関係スキーマを示せ。 ここで、分解後の関係の関係名には、本文中の用語を用いること。
なお、主キーを構成する属性の場合は実線の下線を、外部キーを構成する属性の場合は破線の下線を付けること。
模範解答
正規形:第1正規形
関係スキーマ:加盟企業(加盟企業コード、加盟企業名、契約開始日、契約終了日)
加盟企業商品(加盟企業コード、加盟企業商品コード、横断分析用品コード、商品コード、加盟企業商品名、JANコード)
横断分析用品商品情報(横断分析用品商品コード、横断分析用品名)
解説
解答の論理構成
- 主キーの確認
【問題文】「加盟企業商品は、加盟企業コードと加盟企業商品コードで識別する。」
⇒ 主キー:{加盟企業コード、加盟企業商品コード} - 第1正規形の判定
・繰返し属性や多値属性は無い。よって第1正規形。 - 第2正規形の判定
・「加盟企業名、契約開始日、契約終了日」は“加盟企業コード”だけで決まる。
・主キーの一部にのみ従属する部分関数従属性が存在 → 第2正規形を満たさない。 - 第3正規形の判定
・「横断分析用商品名」は“横断分析用商品コード”で決まる。
・非キー → 非キーの推移的関数従属性が存在 → 第3正規形も満たさない。 - 分解手順
① “加盟企業コード”の従属性を独立
加盟企業(加盟企業コード、加盟企業名、契約開始日、契約終了日)
② “横断分析用商品コード”の従属性を独立
横断分析用商品情報(横断分析用商品コード、横断分析用商品名)
③ 残りを再構成
加盟企業商品(加盟企業コード、加盟企業商品コード、JANコード、加盟企業商品名、横断分析用商品コード)
以上3関係はいずれも主キーしか決定因子を持たず、第3正規形を満たします。
誤りやすいポイント
- 「加盟企業商品コードは再利用されない」→ だからといって単独キーにしない
(同一加盟企業を識別する“加盟企業コード”との複合が必要)。 - 「JANコードが設定されない商品もある」→ NULL可属性はキーにならない。
- 「横断分析用商品名」をそのまま残してしまい推移従属性を見落とす。
- 分解後に外部キーを付け忘れ、参照整合性を示せていない。
FAQ
Q: JANコードが一意ならキーに含めても良いのでは?
A: 【問題文】「JANコードが設定されない商品もある。」ため、一意制約を置けず主キーにはできません。
A: 【問題文】「JANコードが設定されない商品もある。」ため、一意制約を置けず主キーにはできません。
Q: “横断分析用商品コード”と“横断分析用商品名”を同じ関係に残したままでも第3正規形ですか?
A: いいえ。“横断分析用商品名”が“横断分析用商品コード”に従属しているので主キー以外の推移的従属性が残り、第3正規形になりません。
A: いいえ。“横断分析用商品名”が“横断分析用商品コード”に従属しているので主キー以外の推移的従属性が残り、第3正規形になりません。
Q: 分解後に「加盟企業商品名」はどのキーに従属しますか?
A: “加盟企業コード”+“加盟企業商品コード”の複合キーに完全関数従属します。
A: “加盟企業コード”+“加盟企業商品コード”の複合キーに完全関数従属します。
関連キーワード: 正規化、関数従属性、部分関数従属、推移的従属性、第3正規形
設問3:〔ポイントの概要〕 の4. で示した日次バッチについて、(1)、(2)に答えよ。
(1)日次バッチの集計処理では、付与ポイントの記録がポイント残高に加算されない場合がある。 それはどのような場合か。 本文中の用語を用いて 30字以内で述べよ。
模範解答
購入の翌日以降にポイントの後付けをしたとき
解説
解答の論理構成
- 日次バッチの対象
- 「毎日午前0時を過ぎると、支払ごとの付与ポイントの記録から、支払日時が前日の分を日次バッチで抽出し、集計して会員のポイント残高に加算する。」
⇒バッチは“前日”の支払日時を条件に抽出。
- 「毎日午前0時を過ぎると、支払ごとの付与ポイントの記録から、支払日時が前日の分を日次バッチで抽出し、集計して会員のポイント残高に加算する。」
- 後付けレコードのタイムスタンプ
- 「付与ポイントの記録は、レシートが発行された日時の記録となる。」
⇒後付けしても“支払日時”は購入時(レシート発行時)のまま。
- 「付与ポイントの記録は、レシートが発行された日時の記録となる。」
- 時系列のずれ
- 後付けが「購入の翌日以降」に行われると、 バッチは既に対象日(購入日)を処理済み → 抽出されない。
- 結果
- よって後付けポイントは残高に加算されず、設問の答えは「購入の翌日以降にポイントの後付けをしたとき」となる。
誤りやすいポイント
- 「後付けした日の翌日バッチで入る」と誤解し、支払日時と登録日時を混同する。
- 付与ポイントを即時加算と勘違いし、日次バッチの存在を見落とす。
- 「当日中の後付け」も漏れると決めつけるが、当日23:59までに登録されれば前日判定にかからないため集計対象になる。
FAQ
Q: 当日中に後付けした場合はどうなりますか?
A: 支払日時が当日であり、日次バッチは翌日午前0時以降に前日分を抽出するため、当日中の後付けは問題なく加算されます。
A: 支払日時が当日であり、日次バッチは翌日午前0時以降に前日分を抽出するため、当日中の後付けは問題なく加算されます。
Q: 後付け漏れを防ぐ対策はありますか?
A: 例として、日次バッチで「一定期間さかのぼって再集計」する、または後付け登録時にポイント残高へ即時加算する仕組みを設ける方法があります。
A: 例として、日次バッチで「一定期間さかのぼって再集計」する、または後付け登録時にポイント残高へ即時加算する仕組みを設ける方法があります。
Q: レコード再抽出を行うと二重加算の恐れは?
A: 支払+会員の複合キーや処理済フラグを設け、再抽出時に既加算レコードをスキップすれば防げます。
A: 支払+会員の複合キーや処理済フラグを設け、再抽出時に既加算レコードをスキップすれば防げます。
関連キーワード: バッチ処理、タイムスタンプ、遅延更新、トランザクション
設問3:〔ポイントの概要〕 の4. で示した日次バッチについて、(1)、(2)に答えよ。
(2)付与ポイントの記録をポイント残高に正しく加算するために、日次バッチの処理を変更することにした。 この処理に用いる属性を、関係 “支払” に一つ追加した。 その属性の役割を30字以内で述べよ。
模範解答
・ポイント残高に加算済みかどうかを判別する。
・ポイント残高への加算処理日が分かるようにする。
・付与ポイントの記録を作成し日で抽出できるようにする。
解説
解答の論理構成
- 日次バッチの仕様
【問題文】「支払ごとの付与ポイントの記録から、支払日時が前日の分を…会員のポイント残高に加算する」。 - 問題点
- 処理が失敗して再実行すると、同じ支払レコードが再度抽出され二重加算の恐れ。
- 将来“当日分を即時加算”など仕様変更があった場合も誤加算リスクが残る。
- 解決策
- 支払レコードに「加算済」を示す情報を付与。
- バッチは “未加算かつ対象日付” で抽出し、成功後にフラグを更新。
- したがって追加属性の役割
「ポイント残高に加算済みかどうかを判別する。」(30字以内)
誤りやすいポイント
- 抽出条件に「支払日時が前日」を使えば重複防止できると誤解する。
- 支払テーブルではなくポイント残高テーブル側にフラグを持たせようとする。
- 「加算済フラグ」と「ポイント残高更新日時」の違いを区別しない。
FAQ
Q: フラグと日付のどちらを設けるべきですか?
A: 要件は“重複加算防止”です。フラグでも日付でも達成できますが、再計算や監査が必要なら日付の方が有用です。
A: 要件は“重複加算防止”です。フラグでも日付でも達成できますが、再計算や監査が必要なら日付の方が有用です。
Q: バッチが途中失敗した場合の整合性は?
A: トランザクション管理で“加算→フラグ更新”を一括コミットすれば、失敗時にロールバックでき重複を防げます。
A: トランザクション管理で“加算→フラグ更新”を一括コミットすれば、失敗時にロールバックでき重複を防げます。
Q: 今後リアルタイム加算へ変更したい場合は?
A: このフラグ/日付があれば、リアルタイム処理で即時“加算済”を立てるだけで済み、日次バッチと共存できます。
A: このフラグ/日付があれば、リアルタイム処理で即時“加算済”を立てるだけで済み、日次バッチと共存できます。
関連キーワード: 遅延処理、フラグ管理、バッチ処理、冪等性、トランザクション制御


