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

解答の導き方

1. 図1の主要項目と対応表（要点）

• 「契約者の住所、氏名」 → 会員テーブルの氏名・住所から取得可能です。
• 「支払年月日」 → 請求テーブル自身の列です（図2に既にある）。
• 「利用明細」 → 請求利用明細テーブルとカード利用履歴を結合すれば再現できます（図2に両方のテーブルがある）。
• 「今回請求金額合計」 → 利用明細／支払区分ごとの今回請求金額を合計すれば導出できます。
• 「契約内容（リボ払い元金支払定額、CA手数料 等）」 → 契約情報またはシステム定数から取得できます。
• 「ショッピングリボ払い及びキャッシング支払の明細」に印字される各値（前回支払後残高、今回利用金額、利用残高、今回請求金額、元金、利息・手数料、支払後残高等）については、どこまでを格納すべきかを検討します。

1. 「前回支払後残高」が導出可能かの検討

• 本文に「利用残高(前回支払後残高+今回利用金額)」とあり、また図2の契約テーブルには "CR総残高、 SH残高、 S1残高、 S2残高、 SU残高、 CA残高、 C1残高、 CJ残高" （図2の契約列） のように支払区分別の残高を持っていることが分かります。さらに「今回利用金額」は請求利用明細＋カード利用履歴の支払区分／利用金額から集計できます。したがって一般に次式で復元できます。
  $前回支払後残高=利用残高-今回利用金額$
  ここで「利用残高」は契約テーブルの該当支払区分の残高（図2のS1残高 等）を指します。つまり、技術的には各支払区分の「前回支払後残高」は他の既存列から導出可能です。

1. ではなぜ (a) に列を追加するのか／どの列を追加するか

• ただしビジネス上と仕様（本文）の観点で重要なのは「リボ払いは繰越し（リボ残高）を持ち、利息計算や今回請求額の決定に直接使われる」点です（本文に「リボ残高があれば、（支払定額＋リボ残高の利息）を支払う。」とある）。リボは月をまたいで残高が継続するため、請求書に印字される「前回支払後残高」は請求作成時点のスナップショットとして厳密に再現可能である必要があります。
• 他の支払区分（例えばSH1回、CA1回、SH2回/ボーナス等）は原則として翌回支払で精算されるか、または契約テーブルの該当残高と当月の利用明細から復元可能であり、問題文の条件「ほかの項目から導出可能なら列として持たない」に従えば請求テーブルに永続列を追加する必要はありません。図1の例でCA1回に「前回支払後残高」が印字されている例は確かにある（未入金がある等の例外）が、その値は契約側の該当残高と当月利用を使って復元できます。

1. 具体例で整合性確認（図1の数値を利用）

• 図1のSHリボ行を見れば、前回支払後残高36,585 + 今回利用金額31,500 = 利用残高68,085、今回請求金額10,451 = 元金10,000 + 利息451となっており、利息算出に前回支払後残高が直接使われていることが分かります。リボの利息計算や「元金支払定額（10,000円）」の扱いを正しく再現するには、請求作成時の「前回支払後残高」を請求レコードとして保持する方が確実です。

誤りやすいポイント

• 図1にCA1回の「前回支払後残高」があることに惑わされ、CA1前回残高を必ず (a) に入れてしまう。図1の例は実例であり得るが、復元可能な項目は「列として持たない」方針に従い不要です。
• すべての支払区分の「前回支払後残高」を請求テーブルに追加してしまう（冗長化・正規化違反）。問題文の条件に反します。
• 「利用残高」と「前回支払後残高」を混同すること。利用残高は契約側の現時点の集計残高（図2の該当列）であり、前回支払後残高は前回請求時の支払後残高（スナップショット）を意味します。差分関係を明確に認識してください。

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ

解答の論理構成

1. “利用区分”と“支払区分”の整理
   • 【問題文】「利用区分には、ショッピング（SH）、キャッシング（CA）があり」
   • 支払区分は表2により “1回払い〔1〕”、“2回払い〔2〕”、“ボーナス1回払い〔3〕”、“リボ払い〔4〕”。
2. CR枠とCR残高の対応表を確認
   • 【問題文】「表3」に次の行がある。
     • 「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” だけを対象にした個別行が必要。
   • 表3の「CA1回払い残高」／「C1枠」が該当するため (e)＝「C1枠－C1残高」。

誤りやすいポイント

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

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ