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

1. 論点整理

• 「請求」テーブルの構造
  契約単位で請求情報を管理するテーブルで，すでに次のカラムが定義されています。

  カラム名
  契約番号
  支払年月日
  銀行コード
  支店番号
  決済口座番号
  (a)

• 追加すべきカラムの条件
  1. 図１「ショッピングリボ払およびキャッシング支払の明細」で示される項目
  2. 他の項目から導出可能なものは持たない
• 図１該当箇所（問題文からの引用）
  「(3) ショッピングリボ払い及びキャッシング支払の明細
  　利用残高（前回支払後残高＋今回利用金額），今回請求金額（元金＋(利息, 手数料)），支払後残高などを支払区分ごとに示す。」

2. 解答の根拠

1. 「ショッピングリボ払およびキャッシング支払の明細」で要求される列
   問題文中に次の記述があります。

   「利用残高(前回支払後残高+今回利用金額)，今回請求金額(元金+(利息,手数料))，支払後残高などを支払区分ごとに示す。」

   ここで「前回支払後残高」は明細の必須項目として列挙されているため，テーブルにも保持します。
2. 支払区分ごとに２種類必要
   支払区分は「SH リボ」(ショッピングリボ) と「CA リボ」(キャッシングリボ) があるため，
   明細２行分を別カラムで表す必要があります。
3. 「他の項目から導出可能な項目は列としてもたない」
   問題文にも

   「図1中の項目のうち,ほかの項目から導出可能な項目は列としてもたないものとする。」
   と定義されています。

   • 「利用残高」＝前回支払後残高＋今回利用金額
   • 「支払後残高」＝利用残高−元金
     はいずれも導出可能なので，テーブルには持ちません。

SH リボ前回支払後残高, CA リボ前回支払後残高

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

• 「利用残高」「支払後残高」を追加しがち
  明細表に並んでいるため、ついテーブルに持たせたくなります。しかし問題文で「導出可能なものは列としてもたない」とあるとおり、これらは計算式で求められる項目です。
• 支払区分ごとにまとめてしまう
  「リボ前回支払後残高」とひとまとめにせず，SH系とCA系で個別のカラムが必要です。
• 呼称の間違い
  問題文や図中の用語をそのまま使うことが求められています。「前回支払後残高」を省略せず，正式名称「SH リボ前回支払後残高」「CA リボ前回支払後残高」と記述しましょう。

4. 試験対策まとめ

• 「導出可能な項目は列として持たない」という設計ルールを必ず確認する。
• 明細表とテーブル設計の対応を行う際には，「明細に表示するがテーブルに持たない」ものを確実に区別する。
• 問題文と図で用いられている用語は正確にトレースする。
• 支払区分などの分類は，必要に応じてカラムを複数設ける（まとめない）。

完成形：請求テーブル

1. キーワード・論点の整理

• 「本会員番号に限定」
• 「すべての会員を対象」

2. 論理的な解答根拠の説明

契約
「本会員とクレジットカード契約を結ぶ。」
（…）

クレジットカードの発行
「本会員及び家族会員に対してクレジットカードを発行する。」

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

• テーブル上の列名が同じ「会員番号」なので、同じ性質だと誤解しやすい。
• 「家族会員にも契約がある」と思い込みやすいが、家族会員はあくまで本会員の契約に紐づいたカード保有者です。
• 「契約テーブルに家族会員のレコードが登録されている」と思うと混乱しますが、家族カードは契約テーブルではなくカードテーブルで管理されます。

4. 試験対策ポイント

• 契約（contract） は常に「本会員」と結ぶルールであることを押さえる。
• カード（card） は「本会員／家族会員」のいずれにも発行できる点を区別して覚える。
• テーブル設計の際、同じ列名でも外部キー先の意味範囲が異なる場合があることを意識する。

参考：両テーブルの比較

キーワード整理

• 候補キー（Candidate Key）
  → テーブル内の各レコードを一意に識別できる最小の属性の組み合わせ
• 請求利用明細テーブルの属性
  図2の記述を基に整理すると、次の６属性がある（図中では「利用履歴番号」が重複記載されていますが、
  １つは「利用明細番号」を指すものと解釈します）。

  カラム名	意味
  契約番号	クレジットカード契約を一意に識別する番号
  支払年月日	請求（明細書）を発行する年月日
  利用区分	ショッピング（SH）／キャッシング（CA）などを区分する値
  利用明細番号	明細書中での明細行に連番で付与される番号
  カード番号	利用したクレジットカードを一意に識別する番号
  利用履歴番号	カードごとの利用イベント（③利用履歴）に対して付与された番号

• 模範解答の候補キー
  ① 契約番号＋支払年月日＋利用区分＋利用明細番号
  ② カード番号＋利用履歴番号＋支払年月日

解答の論理的説明

1. 「請求利用明細」テーブルの役割
   問題文（「3．利用代金明細書の作成」(2)）には、

   「利用明細番号を利用年月日順に付与し, 利用明細番号順に示す」
   とあるように、１回の請求（支払年月日）ごとに、契約単位・利用区分単位で行を特定するための 利用明細番号 が必要です。

2. 候補キー①の妥当性
   • 契約単位かつ請求単位（支払年月日）で明細書を作成
   • さらに利用区分（SH／CA）ごとに連番を振る
   • よって、
     「契約番号 ＋ 支払年月日 ＋ 利用区分 ＋ 利用明細番号」
     という組み合わせは、テーブル中で必ず一意にレコードを特定できます。
   • 最小性についても、これら４属性のいずれかを除くと同一レコードを区別できなくなるため、最小のキーとなります。
3. 候補キー②の妥当性
   • 請求利用明細は「どのカードで」「いつ（支払年月日）」「どの利用イベント（利用履歴番号）か」という観点でも一意に特定可能
   • 問題文 (2) に

     「同じ会員の場合はカードごと利用ごとに付番される利用履歴番号の順に利用明細番号を付与」
     とあることから、カード番号＋利用履歴番号 は利用イベントを一意に識別

   • ただし明細書単位でまとめるために 支払年月日 を加えないと、同一利用履歴が異なる請求月にまたがるケースで重複する可能性がある
   • 以上から、
     「カード番号 ＋ 利用履歴番号 ＋ 支払年月日」
     もまた 最小かつ一意 な候補キーになります。

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

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

1. 候補キーの定義
   • テーブル内のレコードを一意に識別でき、かつ不要な属性が含まれない最小の属性集合
2. 明細テーブルのキー設計
   • 親側（契約）と請求月を必須要素として含める
   • SH／CA や明細行番号など、業務仕様で連番を振る単位がキーに含まれる
3. 業務要件の読み落とし防止
   • 問題文中の「～ごとに連番を振る」「～ごとに管理する」といったキーワードは、キー設計のヒント
4. 複数のキー候補
   • ひとつのテーブルでも「複数の候補キー」を検討できることを意識する
   • 主キーはその中から業務上ふさわしいものを選択するが、候補キーはすべて挙げられるようにすること。

1. 模範解答につながるキーワード・論点整理

2. なぜその解答になるのか ― 論理的な導出手順

1. 問題文の前提
   －「“会員”テーブルの項目は，NULL 不可となることが静的に決まらない」
   －「列ごとに NOT NULL 制約を定義できない」
   ⇒ 行レベルで必須／任意を切り替えられる仕組みが必要。
2. “項目チェック”テーブルで管理したい情報
   ① どの列（項目）か　…… 列を識別する「会員列名称」
   ② どの種別の会員か　…… 「会員区分」（本会員／家族会員）
   ③ 本会員の場合さらにどういう職業か　…… 「職業区分」（有職／無職／学生）
   ④ 必須かどうかの結果フラグ（図４の別欄）
   ⑤ 行を一意に識別し，後の増分にも耐えられる主キー
   ＝ 「一連番号」（サロゲートキー）
3. 拡張性の検証
   ・会員テーブルに列が追加　→「会員列名称」値を増やせば良い
   ・会員区分や職業区分が追加　→ その組合せ分だけ行を追加すれば良い
   → 列構造は変えずに行追加だけで吸収できる。
4. 主キー構成
   行を一意に識別できなければ重複登録の恐れがある。
   サロゲートキーとしての「一連番号」を置き，さらに論理的同一性を担保するため「会員列名称＋会員区分＋職業区分」も含め複合一意性を確保する設計が妥当。
   ⇒ (b) の欄には「一連番号，会員列名称，会員区分，職業区分」を並べて主キーを示す。

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

4. 試験対策まとめ ― 覚えておきたい知識

1. 動的必須制約は「マスタ＋制御テーブル」で実現
   ・テーブル名／列名／条件列（区分値など）／必須フラグ
   ・列追加や区分値追加に耐える行追加方式を優先。
2. 主キー設計の原則
   ・業務的に一意な列で足りても，保守・変更を考えてサロゲートキーを置く選択肢を忘れない。
   ・特に「設定テーブル」「制御テーブル」では (サロゲートキー＋論理的複合キー) の併用が有効。
3. テーブル・列命名は「本文中と同じ用語を使う」
   → 試験問題では用語ぶれが減点対象になることがあるので注意。
4. NULL 制御の典型的アプローチ
   ・列定義レベル (NOT NULL)
   ・CHECK 制約 (複雑条件は難)
   ・トリガ／アプリケーション
   ・今回のように「制御テーブル＋アプリ側バリデーション」

キーワードと論点整理

• CR枠／CR残高の制限チェック
  問題文にある「今回の利用金額が, CR枠から CR残高を差し引いた範囲内であること (範囲を超えた場合は “CR枠エラー”)」
  → 各利用形態ごとに「利用可能額＝該当枠 − 該当残高」を計算し、今回利用金額と比較する。
• 利用区分・支払区分による枠と残高の対応
  表３より、

  CR残高名称	略称	利用区分	支払区分	CR枠名称	上限値
  CA１回払い残高	C1残高	2	1	C1枠	30万
  CAリボ残高	Cリ残高	2	4	Cリ枠	20万
  SH２回＋ボーナス１回合計残高	S2残高	1	2及び3	S2枠	30万
  …	…	…	…	…	…

• 決定表(c)～(e)の位置
  小問の決定表は、利用区分・支払区分の組合せごとに「判定用の利用可能額」を埋める形式です。
  • (c): CA（利用区分＝2）のリボ払い／１回払い共通の枠チェック
  • (d): SH（利用区分＝1）の２回払い・ボーナス１回払いの枠チェック
  • (e): CAの１回払い（支払区分＝1）の枠チェック

解答の論理的説明

1. 【問題文】より
   「今回の利用金額が, CR枠から CR残高を差し引いた範囲内であること (範囲を超えた場合は “CR枠エラー”)」
   → 枠チェックの基本式は

   利用可能額 = 該当CR枠 − 該当CR残高
   

2. 表３で「利用区分・支払区分ごとに管理されるCR残高」と「対応するCR枠名称」が定義されている。
   • CA全体のチェックには「CA枠 − CA残高」
   • SHの２回払／ボーナス１回払合計には「S2枠 − S2残高」
   • CA１回払いには「C1枠 − C1残高」

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

1. 総枠（CR総枠）と各種枠の混同
   • 「CR総枠 − CR総残高」ではなく、各利用形態ごとの枠／残高を使う。
   • CA利用なのにSH枠でチェックしてしまうと誤り。
2. SH２回払いとボーナス１回払いの区別
   • 表３中では「SH2回払いとボーナス１回払いの合計残高」をまとめて S2残高 とし、専用の S2枠 を設けている。
3. CAリボとCA１回払いの混同
   • CA全体チェック用は CA枠−CA残高。
   • しかし、CA１回払い単独でチェックする際は C1枠−C1残高。

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

• 表３の「CR残高名称／略称／CR枠名称」の対応をしっかり暗記する。
• 決定表では必ず「該当枠 − 該当残高」で利用可能額を算出するという基本原則を押さえる。
• 利用区分・支払区分の組み合わせごとに、どの枠・残高を使うか判断する練習問題を解き、パターンを体得する。

模範解答の論点整理

• 不具合のあるテーブル：会員テーブル
• 管理すべき属性：家族番号・続柄
• 発生している問題点：複数の家族会員を会員テーブルで扱えない
• 解決方法：会員テーブルから該当列を削除し，カードテーブルに追加

解答に至る論理的説明

1. 不具合の所在
   問題文中に，「複数の家族会員がいたとき，家族番号と続柄を全員分登録できない」とあり，
   → 家族会員の情報（家族番号・続柄）を「会員」テーブルで持つ設計に無理があることが示されています。
2. 属性の所属を見直す根拠
   • 「クレジットカードの発行」では，本会員カード・家族カードごとにカード番号を付与する。
   • 「家族会員には、利用明細の表示順を表す家族番号を付与する」「続柄」を登録するとある。
     → 家族番号・続柄は「カード発行単位」の情報であり，カードテーブルに置くのが自然です。
3. テーブル構造の修正
   • 会員テーブルから「家族番号」「続柄」を削除
   • カードテーブルに「家族番号」「続柄」を追加
     これにより，１会員が複数の家族カードをもつ場合でも属性を個別に管理できます。

誤りやすいポイント

• 家族番号・続柄を「契約」や「請求利用明細」テーブルに置いてしまう
  → これらは“カード発行”の属性であり，契約単位や請求明細単位の情報ではありません。
• 「家族構成」などの汎用的な列名を使ってまとめてしまう
  → 複数値属性になりがちで，正規化の観点から不適切です。

設問(b)の変更内容まとめ

試験対策としてのまとめ

• 属性は「どの実体(エンティティ)の情報か」を明確に切り分ける
• １つのセルに複数の値を持たせない（正規化の基本）
• 主キー・外部キーの役割を意識し，リレーションシップ単位で属性を配置する
• 漏れや重複を防ぐため，「単位（カード発行／契約／会員）」を問題文で確認する習慣をつける

1. 模範解答の核心となるキーワードや論点

• 「分割払」の支払方法を拡張する
  → 支払区分を追加するだけでなく，利用履歴にも「何回分割で支払うか」を記録する必要がある
• 「今回の請求が何回目の支払になるのかを回数で示す」
  → 請求明細に，「今回回数」を示す列が必要
• 「今回請求金額」を明細に表示
  → 分割回数に応じた「今回請求金額」を保持する列が必要

2. なぜその解答になるのか【問題文の引用を交えた説明】

「分割払について,6回、12回、24回などの多様な支払方法を選べるようにする。」
利用明細に対して分割回数の情報がなければ，あとでどの支払区分に属するかも，請求時の回数管理もできません。したがって，カード利用履歴テーブルに「分割回数」を追加します。

「請求時の利用明細欄に、今回の請求が何回目の支払になるのかを回数で示すことにする。」
これは請求側の明細表示要件です。請求明細ごとに「今回回数」を示すため，請求利用明細テーブルに「今回回数」を追加します。

3. 誤りやすいポイント

• 分割回数と今回回数を混同する
  • 分割回数：契約時（利用時）に何回で支払うかの総回数
  • 今回回数：請求月ごとに「今回が第●回目か」を示す番号
• 追加すべきテーブルを取り違える
  • 分割回数は「カード利用履歴」に記録
  • 今回回数／今回請求金額は「請求利用明細」に記録
• 「今回請求金額」を忘れる
  • 分割回数だけ記録しても，請求明細に金額が出せない

4. 追加すべきカラム一覧

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

• 要件（業務仕様）→ エンティティ（テーブル）→ 属性（カラム）への変換手順を常に意識する
• 「いつ」「どこで」「何を示す」情報かで，属性をどのテーブルに置くか判断する
• 分割払の管理では
  1. 利用時に「総回数」を記録
  2. 請求時に「何回目か」と「今回の金額」を記録
     の２段階で設計する
• 記載例や問題文のキーワードを正確に拾い，カラム名は問題文の表記ルールに合わせること（例：「今回回数」「分割回数」「今回請求金額」）