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

1. 模範解答のキーワード・論点整理

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

2.1 周辺施設表（カテゴリコード, カテゴリ名, 施設ID, 施設エリアコード, 施設名, 駐車場ID, 所要時間, 施設経度, 施設緯度）の意味を整理

1. “駐車場” ↔ “施設” は多対多（問題文 4. より）。
2. 周辺施設表は「ある駐車場とある施設の“関係”」を保持し，徒歩所要時間はこの関係の属性。
3. 施設そのものを識別するのは 施設ID（文字列）または 施設経度＋施設緯度（位置が一意）のいずれか。
4. しかし 1. の通り，同じ施設が複数駐車場にひも付くため，施設を識別するだけでは行を一意に決められない。

2.2 候補キーの検討

1. 施設ID は施設を一意に識別。
2. 駐車場ID は駐車場を一意に識別。
3. 従って {施設ID, 駐車場ID} なら 1 行に一意。
4. 緯度経度にも「同一位置に複数施設は存在しない」制約があるので，施設経度＋施設緯度 ≒ 施設ID と同格の識別力。よって {施設経度, 施設緯度, 駐車場ID} も候補キー。
5. 逆に {施設ID} だけ，{施設経度, 施設緯度} だけ では候補キーにならない (多対多の片側)。

2.3 部分関数従属性の有無

• 施設ID → 施設名
• 施設ID → カテゴリコード
• 施設ID → 施設エリアコード
  いずれも「主キーの部分（施設ID）」だけで決まる ⇒ 部分関数従属性あり。

2.4 推移的関数従属性の有無

• 施設ID → カテゴリコード → カテゴリ名
  のように，中間属性（カテゴリコード）を経由して最終属性が決まる ⇒ 推移的関数従属性あり。

【引用】
(4) 施設の分類をカテゴリという。…施設は，いずれか一つのカテゴリに属する。

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

4. 試験対策として覚えておきたいポイント

1. 「多対多」を“関係エンティティ”で表すときは，両側の主キーを合わせないとレコードは一意にならない。
2. 図や文章に「一つ又は複数」「属する」などの表現があれば，カーディナリティ（1:1, 1:N, N:M）のヒントになる。
3. 緯度・経度のように「位置が一意」と書かれている場合は，自然キー候補になる。
4. 部分関数従属性・推移的関数従属性のチェックは「①主キーを分解し片方で決まる物はないか」「②中間属性を経由して決まる物はないか」の２段階で行うと漏れにくい。
5. 3NF への正規化では
   • 候補キーを決める
   • 部分関数従属性 → 第１正規形違反
   • 推移的関数従属性 → 第２正規形違反
     と段階的に考えると整理しやすい。

１．核心となるキーワード・論点整理

• 関係「周辺施設」の属性
  周辺施設（カテゴリコード、カテゴリ名、施設ID、施設エリアコード、施設名、駐車場ID、所要時間、施設緯度、施設経度）
• 主キー候補
  駐車場と施設の多対多関係を表すので、〈駐車場ID, 施設ID〉が主キー
• 正規化の要件
  • 第１正規形（1NF）：集合的属性や繰り返し属性を排除
  • 第２正規形（2NF）：主キーの部分集合に対する従属性（部分従属）を排除
  • 第３正規形（3NF）：非キー属性間の推移的従属性を排除
• 分解後の関係スキーマ（モデル解答）
  • カテゴリ（カテゴリコードカテゴリ名）
  • 施設（施設ID施設名, 施設緯度, 施設経度, カテゴリコード, 施設エリアコード）
  • 周辺施設（駐車場ID, 施設ID所要時間）

２．なぜその解答になるのか

(1) 主キーと関数従属性の確認

「駐車場には，一つ又は複数の周辺施設が定められている。一つの施設は，複数の駐車場の周辺施設として定められる場合がある。」
という記述から，多対多の関係を表す関係スキーマであることがわかります。
したがって主キーは〈駐車場ID, 施設ID〉の組合せとします。

(2) 第1正規形の判定

• 繰り返し属性や集合属性は含まれておらず，スカラ値のみ
  → 第1正規形を満たす

(3) 第2正規形の判定

• 施設名, 施設緯度, 施設経度, カテゴリコード, カテゴリ名, 施設エリアコード
  といった属性があり，これらは「施設ID」のみに機能的従属します。
  → 非キー属性が主キーの一部（施設ID）に対して部分従属しているため，第2正規形を満たさない

(4) 第3正規形の判定

• 施設ID → 施設名, 施設緯度, 施設経度, カテゴリコード, 施設エリアコード
• カテゴリコード → カテゴリ名
• 施設エリアコード → （エリア名など）

(5) 第3正規形への分解

• まず「カテゴリコード→カテゴリ名」に分離し，関係 カテゴリ(カテゴリコード, カテゴリ名) を作成
• 次に，「施設ID→（施設属性）」と「カテゴリコード」などを格納する 施設(施設ID, 施設名, 施設緯度, 施設経度, カテゴリコード, 施設エリアコード)
• 最後に多対多関係と固有属性（所要時間）だけを残し，周辺施設(駐車場ID, 施設ID, 所要時間) とする

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

• 主キーの設定ミス
  「施設IDのみ」や「駐車場IDのみ」を主キーとしてしまい，正しい候補キーを取りこぼす
• 2NFと3NFの判定混同
  部分従属性と推移的従属性の違いをあいまいに覚えている
• 実体（施設、カテゴリ）と関係（周辺施設）を一つの表にまとめたままにする
  M:N関係の表現方法として，必ず中間表を用いる

４．試験対策まとめ

1. 関数従属性を洗い出し，主キー候補と比較する
2. 各正規形の要件を手順でチェック
   • 1NF：スカラ値であるか
   • 2NF：部分従属性の有無
   • 3NF：推移的従属性の有無
3. 分解手順を身につける
   • 部分従属性を排除 → 中間表を作成
   • 推移的従属性を排除 → 実体ごとの表を分離
4. 過去問を用い，主キー設定→FD→正規形判定→分解 の流れを反復して練習することで，本番でもスムーズに対応できるようにしておきましょう。

キーワードと論点整理

• 駐車場は「いずれか一つのエリアに属する」 → 駐車場テーブルにエリアコードを持たせる
• 月極駐車場契約は「会員」と「月極駐車場」に紐づく → 契約テーブルに会員ID・駐車場IDを持たせる
• 会員時間貸駐車場利用は「会員による時間貸駐車場利用を記録」 → 会員IDを持たせる
• ポイント付与フラグは「支払額に対してポイント付与済みかどうかを識別」 → 利用テーブルにそのままフラグを持たせる

解答一覧

※(b),(c) は順不同。

解答の理由付け

1. (a) 駐車場エリアコード
   「駐車場及び施設は,いずれか一つのエリアに属する」（問題文）ため，
   駐車場テーブルにエリアを参照する外部キーとして 駐車場エリアコード を持たせます。

   駐車場(駐車場ID, 駐車場名, …, 駐車場経度, 駐車場緯度, ──駐車場エリアコード──)
   

2. (b),(c) 月極駐車場契約テーブル
   月極契約は「会員が … 契約書類を送付して … 契約が成立する」「会員だけが利用できる月極駐車場」であるため，
   契約レコードはどの会員のどの駐車場契約かを識別できるよう
   • 駐車場ID（どの駐車場か）
   • 会員ID（どの会員の契約か）
     を外部キーとして持ちます。

   月極駐車場契約(契約番号, ──駐車場ID──, ──会員ID──, 契約開始日, 契約終了日)
   

3. (d) ポイント付与フラグ
   「支払額に対してポイント付与済みかどうかを識別するフラグ」（表１）をそのまま利用し，
   ポイントを付与したかどうかを保持する通常属性として ポイント付与フラグ を配置します。
4. (e) 会員ID
   「会員が時間貸駐車場を利用するときにポイント付与する／しないを判断」（問題文）ため，
   会員の時間貸駐車場利用を記録するテーブルに 会員ID を外部キーで持たせます。

   会員時間貸駐車場利用(駐車場ID, 利用連番, ──会員ID──, ポイント付与フラグ)
   

誤りやすいポイント

• (a) を「施設エリアコード」としてしまう
  ⇒ 駐車場テーブルの文脈なので 駐車場 のエリアコード。
• (b),(c) の順序
  ⇒ 順不同なので「どちらが先でも可」ですが，両方とも外部キー である点を押さえる。
• (d) を主キーや外部キー扱いしてしまう
  ⇒ 「フラグ」は参照キーではなく情報保持用の通常属性。
• (e) と (d) の混同
  ⇒ 時間貸利用テーブルには「利用者（会員）を示す会員ID」と「付与済みフラグ」の両方を持つ。

試験対策としてのまとめ

1. 概念モデルの関係を関係スキーマ上で外部キーとして実装
   • 1対多：多側に親の主キーを外部キー
   • 多対多：中間テーブルで両側の外部キー
2. 問題文中の制約・意味を正確に拾う
   • 「いずれか一つに属する」→必ず外部キー制約
   • 「識別するコード・番号」は主キーか外部キー
3. 属性名をそのまま正確に引用
   • 試験では表１などに示される名称を正確に記述すること
   • 誤字・略称を避ける
4. 主キー／外部キーの下線記法を覚える
   • 主キー：実線下線
   • 外部キー：破線下線

キーワードと論点整理

解答の理由・論理的解説

関係性一覧

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

1. 属性の有無に引きずられない
   「時間貸駐車場利用」リレーションスキーマにパターン番号の属性がないので，「時間帯別料金パターン」への関係を忘れやすい。
   → 業務ルールからパターンを参照する必要性を常に意識すること。
2. 会員利用と非会員利用の切り分け
   「時間貸駐車場利用」と「会員時間貸駐車場利用」の２つの利用エンティティを混同しやすい。
   → 問題文の「会員カードを提示して支払った支払額」は専用の管理が必要であると示されている点を見落とさない。
3. サブタイプ（駐車場区分）と契約・利用の関連
   駐車場を「月極／時間貸」に分けたサブタイプ設計が示されているが，サブタイプ間のリレーションを考慮し忘れることがある。
   → 「駐車場 → 月極駐車場契約／時間貸駐車場利用」のフローを常に整理する。

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

1. 業務ルールから概念モデルを描く
   画面例や属性一覧だけでなく，「誰が」「何を」「どのように」行うかの記述を正しく読み取る。
2. 属性の有無でリレーションを省略しない
   関係スキーマの属性欄にキーがなくても，業務フロー上は明らかに必要な参照関係が抜け落ちると不整合を招く。
3. 会員／非会員，契約／利用を区別
   同じ「利用」でも，月極と時間貸，さらに会員利用と非会員利用で管理方法が異なる点を丁寧に整理する。
4. サブタイプ設計のポイント
   上位エンティティ（駐車場）と下位エンティティ（月極駐車場，時間貸駐車場）の関係，およびそれぞれの契約・利用エンティティの結び付けを押さえる。

1. モデル解答のキーワード整理

• 「複数月のポイントを合算して交換する場合でも」
• 「古い付与年月から順に消費」
• 「未消費残高を正確に管理」

2. 解答に至る理由の論理的説明

(1) 要件としてのポイント消費ルール

「交換を行うと, 付与年月が古いポイントから順に消費され, その内容が記録される。」

(2) 現状スキーマの不備

• １回の交換で複数月分のポイントをまとめて消費する場合
• ある月のポイントを一部だけ消費して残りを次月以降に繰り越す場合

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

• 「交換年月日」と「付与年月」を混同し，交換日時だけ管理すれば足りると考えてしまう。
• ポイント交換テーブルに「付与年月」を設けたことで，多月分の消費も問題ないと思い込む。
• 実際には１レコードで扱える付与年月は１つだけなので，複数月のポイント消費には対応できない点を見落としやすい。

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

1. ポイント管理システムでは「付与年月ごとの残高」と「消費年月ごとの消費量」を正確にトレースできる設計が必須
2. FIFO（古いポイントから順に消費）ルールは要件定義に忠実に反映する
3. 交換や利用のテーブル設計では，１回の取引で複数の付与年月を扱えるように詳細な履歴テーブルを用意する
4. スキーマ設計時には，「何をキーに残高を管理するか」「何を列として記録するか」を要件と照らして一つずつ検証すること

模範解答のキーワード整理

1. (a) 不要年月
2. (b) 新設する関係「ポイント消費」の属性
   • 会員ID （外部キー）
   • 付与年月 （主キー）
   • 交換年月日 （主キー）
   • 消費ポイント
3. (c) 「ポイント消費」への具体的なデータ投入例

解答選択の論理的根拠

1. 【(a) 不要年月 の選択理由】
   問題文の関係スキーマ「ポイント交換」には
   「会員ID、交換年月日、付与年月、商品コード、数量」
   が定義されています。しかし「ポイント交換」は商品と数量を管理するものであり，「付与年月」はポイント付与履歴を参照するための外部情報です。
   —————————————
   「ポイント交換（会員ID、交換年月日、付与年月、商品コード、数量）」
   —————————————
   よって、この関係から「付与年月」を削除（不要年月）し，ポイント消費を別に管理するのが正しい設計です。
2. 【(b) ポイント消費 の属性設計】
   解答表に示されている要件を整理すると，ポイント消費は「いつ付与されたポイントを」「いつの交換で」「いくつ消費したか」を管理する必要があります。
   また，付与の元となった「ポイント付与」レコードとの対応付けには「会員ID」「付与年月」が必要です。
   さらに，ひとつの交換（交換年月日）で複数の付与年月からポイントを順に消費する（FIFO）ため，交換年月日も主キーに含めます。
   以上から，関係「ポイント消費」は以下のように設計します。

   属性名	役割
   会員ID	外部キー
   付与年月	主キー／外部キー
   交換年月日	主キー
   消費ポイント

3. 【(c) ポイント消費 の具体例】
   問題文の「図1 ポイント付与履歴」「図2 ポイント交換履歴」をもとに，最古のポイントから順に消費量を按分します。
   • 2015-06-10 の交換（消費合計300）は
     • 2015-04付与分 250 → 消費ポイント＝250
     • 残 50 → 2015-05付与分から消費ポイント＝50
   • 2015-07-20 の交換（消費合計100）は
     • 2015-05付与分 残10 → 消費ポイント＝10
     • 残90 → 2015-06付与分から消費ポイント＝90
   これを表にまとめると，前節の表のとおりです。

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

• 「付与年月」を削除する対象として誤って「交換年月日」や「商品コード」を選んでしまう。
  → ポイント消費を管理するには「交換年月日」が必須であるため，そちらは残す。
• 消費の按分（FIFO）を考慮せず，一つの交換イベントを一行にまとめてしまう。
  → 複数の「付与年月」からポイントを消費する場合は，消費レコードが分割される。
• 主キー／外部キーの設定を忘れる。
  → 会員IDは「会員」テーブルへの外部キー，付与年月＋交換年月日は複合主キー。

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

1. 関係の分割設計
   一つの関係で扱う情報が複数の役割を兼ね始めたら，責務に応じて新規関係を設ける。
2. FIFO 消費のモデル化
   「どの時点で付与された資源をいつ消費したか」を記録する場合，付与側と消費側を別関係とし，外部キーで関連付ける。
3. 複合主キーの設定
   1 件の消費記録を一意に識別するのに必要な属性を漏らさない。
4. 論理設計の要件読み取り
   問題文中の「〜ごとに消費」「〜から順に消費」「…が記録される」といった表現を設計要件として確実に表現する。