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

模範解答

解説

解答の論理構成

1. 表２・表３より、リボ払いは利用残高を翌月以降に繰り越すしくみである。
2. 図１で請求書に必ず印字される「前回支払後残高①」は、繰越しが発生する支払区分だけであることがわかる。具体的に表記されているのは
   • 「SHリボ　　36,585」
   • 「CAリボ　　23,456」
3. 「SH リボ前回支払後残高」「CA リボ前回支払後残高」は、次の請求書作成時点まで他テーブルから導出できない（取引が無くても残高は残る）ため、永続的に保持する列が必要。
4. 一方で「利用残高③＝①＋②」「支払後残高⑦＝③－⑤」などは、①・②・⑤があれば算出できるため保持不要。
5. よって“請求”テーブルの不足列は以下の２列に絞られる。
   • SH リボ前回支払後残高
   • CA リボ前回支払後残高

誤りやすいポイント

• CA１回払いの残高列を追加してしまう
  １回払いは翌月で必ず精算されるため繰越残高は論理的に０になり、保持不要です。
• 「今回請求金額合計」を列にしてしまう
  契約・利用明細から集計可能なので第３正規形の観点でも冗長です。
• 列名を本文と異なる略称に変えてしまう
  指示にあるとおり「本文中と同じ意味を表す列名は,本文中の用語を用いること」です。

FAQ

模範解答

解説

解答の論理構成

1. 図2のテーブルを確認
   • “契約（契約番号, 会員番号, 契約年月日, …）”
   • “カード（カード番号, 契約番号, 会員番号, …）”
2. 業務仕様の確認
   • 契約について【問題文】「(2) 契約　本会員とクレジットカード契約を結ぶ」
   • カード発行について【問題文】「(3) クレジットカードの発行　本会員及び家族会員に対してクレジットカードを発行する」
3. 推論
   • 契約を結べるのは本会員のみ ⇒ “契約”の会員番号ドメイン＝本会員番号。
   • カードは家族会員にも発行 ⇒ “カード”の会員番号ドメイン＝全会員番号。
4. 結論形成
   同一列名でも対象集合が異なるため、意味上の制約を答案にまとめる。

誤りやすいポイント

• 「家族カードも同じ契約にぶら下がるから“契約”にも家族会員番号が入る」と勘違いする。
• 列名が同一なので“同じドメイン”と思い込み、ビジネスルールを読み落とす。
• 「契約＝家族を含めた世帯契約」と解釈し、契約単位の定義をずらす。

FAQ

模範解答

解説

解答の論理構成

1. テーブル構造の確認
   表示されている「請求利用明細」テーブルの列は
   「契約番号, 支払年月日, 利用区分, 利用明細番号, カード番号, 利用履歴番号」。
2. 請求書側のキーを導く
   • 【問題文】では「契約単位に、本会員と家族会員を合わせて月ごとに利用代金明細書を作成」するとある。
   • さらに「利用区分別に利用明細番号を利用年月日順に付与」するため、１請求書（＝「契約番号」「支払年月日」）・１利用区分内で「利用明細番号」が重複しない。
   • よって「契約番号，支払年月日，利用区分，利用明細番号」で一意。
3. カード利用履歴側のキーを導く
   • 図２の「カード利用履歴」テーブルは「カード番号, 利用履歴番号」で主キーを構成すると読み取れる。
   • １つの利用履歴は“どの月の請求書に載るか”が「支払年月日」で決まる。
   • したがって「カード番号，利用履歴番号，支払年月日」でも一意。
4. “候補キー”なので複数列挙
   • いずれも重複が起こらず NULL 不可の組合せであり、主キー候補となる。

誤りやすいポイント

• 「利用明細番号」単独、または「契約番号＋利用明細番号」で唯一と思い込む
  → 利用区分が異なると同じ番号が再利用される。
• 「カード番号＋利用履歴番号」で十分と判断
  → 同一利用履歴が複数回請求されるケース（月跨ぎ）を想定できていない。
• 候補キーは１つしか答えてはいけないと誤解する。

FAQ

模範解答

解説

解答の論理構成

1. キー項目の洗い出し
   • 問題文より引用：
     「“会員” テーブルの項目は, NULL 不可となることが静的に決まらない」
     「列又は職業区分の区分値が追加された場合にも…行の追加だけで対応」
   • したがって「列名」も「区分値」もデータとして保持しなければ拡張要求を満たせません。
2. 判定に必要な三つの自然キー
   • 会員列名称 … どの列を対象にした制約か
   • 会員区分 … 本会員／家族会員など列挙型の区分値
   • 職業区分 … 有職／無職／学生など列挙型の区分値
3. 行の一意性と更新の容易さ
   • 複合主キーでも構いませんが、(会員区分, 職業区分) が NULL になるケース（「すべての区分に共通の制約」を表現）を扱いやすくするため Surrogate Key を採用します。
   • これを問題文の語句で表すと「一連番号」が適切です。
4. 列順序の決定
   • 実務的には主キーである「一連番号」を先頭に置き、その後に識別条件である三列を配置するのが自然です。
5. よって (b) は
   • 一連番号, 会員列名称, 会員区分, 職業区分

誤りやすいポイント

• 「会員列名称」を列にせず、制約を列ベースの固定列（氏名_NOT_NULL など）で持たせてしまうと、列追加のたびにテーブル定義を変更しなければならなくなります。
• (会員区分, 職業区分) を主キーにすると、両方が NULL の行を複数持てず「全区分共通の制約」を複数行で登録できないため拡張性が落ちます。
• 区分値を整数コードで扱う場合でも、問題文は「本文中と同じ意味を表す列名は,本文中の用語を用いること」と指示しているので、列名にコードや略称を使わないよう注意が必要です。

FAQ

模範解答

解説

解答の論理構成

1. “利用区分”と“支払区分”の整理
   • 【問題文】「利用区分には、ショッピング（SH）, キャッシング（CA）があり」
   • 支払区分は表２により “１回払い〔1〕”，“２回払い〔2〕”，“ボーナス１回払い〔3〕”，“リボ払い〔4〕”。
2. CR 枠と CR 残高の対応表を確認
   • 【問題文】「表３」に次の行がある。
     • 「S2 残高」／「S2 枠」：利用区分 1、支払区分 2 及び 3
     • 「CA 残高」／「CA 枠」：利用区分 2、支払区分 すべて
     • 「C1 残高」／「C1 枠」：利用区分 2、支払区分 1
3. 決定表 [a]・[b] の読替
   • [a] は “利用区分 1” が並ぶ＝ショッピング系。
   • 既に「SH枠－SH残高」「S1 枠－S1 残高」が登場しているため、残る支払区分 2・3 用の行が (d)。
   • よって (d)＝「S2 枠－S2 残高」。
4. (c) の導出
   • [b] で “利用区分 2” が多く、ここで (c) 行が判定に使われている。
   • 利用区分 2 全般で使われるのは「CA 枠－CA 残高」。
   • よって (c)＝「CA 枠－CA 残高」。
5. (e) の導出
   • CA のうち “支払区分 1” だけを対象にした個別行が必要。
   • 表３の「CA1 回払い残高」／「C1 枠」が該当するため (e)＝「C1 枠－C1 残高」。

誤りやすいポイント

• 「SH2 回払い」と「ボーナス１回払い」を別々に管理すると早合点し、(d) を２行に分けてしまう。
• 「CA 枠－CA 残高」があれば個別枠は不要と思い込み、(e) の存在を見落とす。
• 表３の略称と決定表の記号を対応付けずに暗記しようとして混乱する。

FAQ

模範解答

(a) テーブル名：会員テーブル 　 不具合の内容：複数の家族会員がいたとき，家族番号と続柄を全員分登録できない。 (b) ：

解説

解答の論理構成

1. 事実の整理
   • 家族属性はカード発行時点で決まる（家族カード単位の情報）。
   • 問題文は「同一人に対しては、一つの会員レコードだけを対応させる」と明示。
2. 不具合の指摘
   • 会員行に「家族番号」「続柄」を置くと、本会員フラグ＝1 かつ家族会員フラグ＝1 の場合に複数値を保持できず、家族が 2 人以上いると上書きや欠落が生じる。
   • これは第１正規形違反（列に複数値）。
3. 解決方針
   • 家族カードごとに家族番号と続柄を管理すれば、１人が複数の家族カードを持ってもカード行で 1:1 に保持できる。
   • 追加テーブルは禁止されているので、「カード」テーブルへ列移動。
4. 列操作
   • 「会員」テーブル：家族番号，続柄 → 削除
   • 「カード」テーブル：家族番号，続柄 → 追加
     これで会員⇔カードが 1 対多となり整合性が保たれる。

誤りやすいポイント

• 「家族番号」を契約単位と誤解し「契約」テーブルへ移そうとする
• 新テーブル（例：家族会員テーブル）を作ってしまい“作成せずに”の条件違反
• 会員区分削除の指示と列移動を混同し、不要列まで削る
• 続柄はリファレンス情報だから削除だけで良いと判断し追加を忘れる

FAQ

模範解答

解説

解答の論理構成

1. 仕様把握
   • 【問題文】「3回以上の分割払について、新たに支払区分を一つだけ追加」とあり、支払回数が可変になる。
   • 同じく「今回の請求が何回目の支払になるのかを回数で示す」と指示。
2. “カード利用履歴” への影響
   • 取引登録時点で総回数を確定する必要がある。
   • 既設列では 2 回までしか保持できず拡張性がない。
     ⇒ 総回数を表す単独列「分割回数」を追加。
3. “請求利用明細” への影響
   • 毎請求サイクルごとに「今回が○回目」「今回請求金額」を出力する必要。
   • テーブル設計上、請求情報の粒度と一致するのは “請求利用明細”。
     ⇒ 「今回回数」「今回請求金額」を追加。
4. 主キー・外部キーに変更はなく、列の追加のみで要件を満たせる。

誤りやすいポイント

• 「第1回支払金額」「第2回支払金額」で対応できると誤解し、列追加を省いてしまう。3回以上では不足します。
• 「今回回数」を “カード利用履歴” に入れるミス。これは請求タイミングごとに変化する値なので別テーブルが妥当です。
• 列名の表記ブレ（「分割支払回数」など）で減点。列名はシンプルに「分割回数」「今回回数」「今回請求金額」とします。

FAQ