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

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

• お気に入りテーブルの構成要素
  • 会員が「どのコンテンツ」を「いつ」お気に入り登録したかを管理
  • 登録日時で並び替えて表示する要件
• 主キーの設定
  • 会員番号（会員を一意に識別）
  • コンテンツID（コンテンツを一意に識別）
  • 登録日時（同じ会員・同じコンテンツの重複登録を防ぎ、表示順序にも利用）
• 外部キーの設定
  • サービス： (WebサイトID, サービスID) が主キー
  • コンテンツ：コンテンツID が主キー、WebサイトID, サービスID を外部キーとして参照
  • 利用権限：(コンテンツID, 会員区分) が主キー、コンテンツID を外部キーとして参照

2. 解答となる理由の論理的説明

1. お気に入りテーブルのカラム選定
   　問題文(4)にあるように、
   　> 「会員はログイン後に任意のコンテンツをお気に入りとして登録することができる。お気に入りは,登録した日時の順に表示される。」
   　
   　→ お気に入り登録を管理するには「会員番号」「コンテンツID」「登録日時」の３項目が必要です。
   　- 会員番号：どの会員かを示す
   　- コンテンツID：どのコンテンツかを示す
   　- 登録日時：登録順序の管理および同一組み合わせの重複防止
2. お気に入りテーブルの主キー
   　上記３項目を組み合わせて主キーとすることで、
   　- 同じ会員が同じコンテンツを同じ日時に重複登録することを防止
   　- 登録日時の昇順や降順での表示が可能
3. サービス／コンテンツ／利用権限テーブルのキー設定
   　(3)の記述により、
   　> 「サービスは,Web サイトごとに複数提供され,Web サイトID とサービスID の組合せによって識別される。」
   　→ サービスの主キーは (WebサイトID, サービスID)

3. 誤りやすいポイント・注意点

4. 主キー・外部キーの再掲

お気に入りテーブル

サービステーブル

コンテンツテーブル

利用権限テーブル

5. 試験対策としてのポイントまとめ

1. 要件文から主キー・外部キーを正しく抽出
   • 「識別する組合せ」「管理する順序」などのキーワードに注意
2. 正式な列名を用いる
   • 単に「コンテンツ」ではなく「コンテンツID」
3. 複合主キーの扱い
   • 重複防止や参照整合性のために必要なカラムを組み合わせる
4. 外部キー参照先の明示
   • どのテーブルのどの主キーを参照するかを明確に記述
5. 出題パターンに慣れる
   • 「○○IDで一意に識別する」といった定型文から即座にテーブル設計をイメージできるように演習を重ねること。

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

• 対象テーブル：掲示板
  • 定義されている主キー：(WebサイトID, 掲示板ID, メッセージ番号)
  • 非キー属性：タイトル，掲示板開設日時，説明文，掲示板開設者会員番号，メッセージ本文，メッセージ投稿者会員番号，メッセージ投稿日時
• 正規化の段階
  1. 第1正規形（1NF）：すべての属性が単一値である
  2. 第2正規形（2NF）：1NF ＋ 全ての非キー属性が主キー全体に対して完全関数従属
  3. 第3正規形（3NF）：2NF ＋ 非キー属性間で推移的関数従属しない
• 部分関数従属の発生箇所
  • タイトル や 説明文 などは「掲示板」単位（WebサイトID, 掲示板ID）にのみ依存し、メッセージ番号には依存しない

2. 解答の論理的説明

• 主キーは (WebサイトID, 掲示板ID, メッセージ番号) の複合キーです（問題文より「メッセージは，掲示板単位に連番のメッセージ番号によって，一意に識別される。」）。
• 第1正規形は満たされています。すべての属性が単一値をとっているためです。
• しかし，非キー属性のうち タイトル や 説明文 などは，同じ掲示板内のすべてのメッセージで同一の値になるため，「掲示板」を一意に識別する部分キー (WebサイトID, 掲示板ID) にのみ依存します。
  ⇒ 非キー属性が主キー全体ではなく一部にのみ依存している（部分関数従属）
• 部分関数従属を解消するには，「掲示板ヘッダー情報」を別テーブルに分割する必要があります。
• したがって，現在は 第1正規形 までしか満たしていません。

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

• 主キーの範囲を誤認
  「掲示板テーブルは掲示板単位かメッセージ単位か？」を曖昧にすると，部分従属の有無を見落としやすい。
• 1NF→2NFへの移行条件の理解不足
  「単一値」だけで2NFを満たすと誤解しがち。「完全従属」の要件も確認すること。
• 「サービス」や「掲示板」を別テーブル化した想定で考えてしまい，J君設計のままのテーブル構造を正しく把握できないミス

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

• 正規形のチェック手順
  1. 1NF：すべての属性が原子値か
  2. 2NF：（1NF）かつ非キー属性が主キー全体に完全関数従属か
  3. 3NF：（2NF）かつ非キー属性間に推移的従属がないか
• 「主キーの候補」→「候補キー」→「部分従属・推移従属」を意識的に整理
• 部分従属の典型例：複合キーの一部にのみ依存するヘッダー属性は，明らかに別テーブル化すべき
• 問題文で示されるキーの定義（「…単位に連番」「…の組合せによって識別」）は関数従属性を判断する大きなヒントになることを習得すること

コアとなるキーワード・論点整理

1. 第3正規形（3NF）
2. エンティティ分離（掲示板とメッセージの分解）
3. 複合主キーの設定
4. 自己参照（親メッセージ番号による返信ツリー管理）
5. 外部キーによる参照整合性

解答の論理的根拠

1. 「掲示板」テーブルが第3正規形に正規化されていない

   「② ‘掲示板’ テーブルは,第3正規形に正規化されていない。」

   － 元の設計（図3）では，掲示板の情報と投稿メッセージの情報が１つのテーブルに混在しており，
   投稿メッセージの本文や投稿者，会員番号，投稿日時など「掲示板エンティティ」から独立した属性が存在します。
   これは，第1に「繰り返し属性の発生」，第2に「メッセージ属性＝主キー（WebサイトID＋掲示板ID）に対して部分関数従属または推移的関数従属が起きている」ため，第3正規形を満たしません。
2. 返信の親子関係が管理できない

   「③ 掲示板に投稿されたメッセージに対する返信が,どのメッセージに対する返信であるかを管理できない。」

   － 問題文では，

   「メッセージの返信が行われると，返信対象の投稿メッセージ (親メッセージ)との関係はツリー構造で表示される。」
   とありますが，元のテーブル定義に「親メッセージ番号」を格納する列がなく，どの投稿への返信かを示せません。

正規化後のテーブル構造

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

1. 「親メッセージ番号」を忘れる
   – 返信用の自己参照を管理する列を設計に入れないと，設問③の要件を満たせません。
2. 複合主キーの粒度を誤る
   – メッセージ番号は「掲示板単位に連番」（問題文より）なので，単独では一意にならず，WebサイトID＋掲示板IDと組合せた複合主キーにする必要があります。
3. 掲示板開設者（会員番号）と投稿者（会員番号）の区別
   – どちらも会員テーブルを参照しますが，外部キーのカラム名を変えておかないと混同しやすいです。

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

• 第3正規形(3NF) の定義：主キー以外の属性が，主キーに対して「完全関数従属」かつ「非推移的関数従属」を満たすこと。
• エンティティ分割：１つのテーブルに複数の概念（ここでは掲示板とメッセージ）が混在していないかを常にチェックする。
• 複合主キー：自然キーをそのまま使う場合，キーの粒度（範囲）に応じて複合キーが必要になるケースを理解しておく（例：投稿メッセージ番号は掲示板毎にリセット）。
• 自己参照制約：ツリー構造や階層構造を管理する場合，親参照用の外部キーを用意する。
• 外部キーの意味を明確に：同じ会員番号でも，開設者と投稿者など役割が異なることがあるため，カラム名とリレーションを正しく設計する。

解答のポイント整理

• 会員区分の一般化／特殊化（Generalization）
  「会員」をスーパークラスとし，「期限付き会員」「一般会員」「有償会員」をサブクラスとして表現する
• サービス区分の一般化／特殊化
  「サービス」をスーパークラスとし，「無償サービス」「有償サービス」をサブクラスとして表現する
• 購入サービス（購入履歴）をアソシエーションエンティティとして設置
  有償会員がどの有償サービスを購入したかを管理するため，「購入サービス」を独立エンティティで表す
• リレーションシップ
  • 会員―サブクラス間：継承（ISA）
  • サービス―サブクラス間：継承（ISA）
  • 有償会員―購入サービス間：1対多
  • 有償サービス―購入サービス間：1対多

解答がこのようになる論理的説明

・会員の区分として,一般会員,期限付き会員の他に,“有償会員”を新規に追加する。
・サービスの区分として, “有償サービス”を新設する。〔新データベースのテーブル構造の設計〕で定義したサービスは“無償サービス”とする。
・有償会員が購入したサービスを管理するために,“購入サービス”を新たに定義する。

1. 「会員」という概念（エンティティタイプ）に，
   一般会員・期限付き会員に加えて「有償会員」をサブタイプとして追加
2. 同様に，「サービス」を「無償サービス」と「有償サービス」にサブタイプ分割
3. 「有償会員」と「有償サービス」の間は多対多の可能性があるため，
   両者をつなぐ購入サービス（購入日や支払金額などの属性を持つアソシエーションエンティティ）を設置

エンティティ・リレーションシップ一覧（例）

• 会員―期限付き会員, 会員―一般会員, 会員―有償会員：ISA（1対1，部分／全カバレッジ）
• サービス―無償サービス, サービス―有償サービス：ISA
• 有償会員–購入サービス：1対多
• 有償サービス–購入サービス：1対多

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

1. 「有償会員」を単なる属性（会員区分の項目値）で済ませてしまう
   → 概念データモデルでは“継承”で表現し，各サブタイプ固有の属性（支払情報など）を持てるようにする
2. 「購入サービス」をリレーションのみで表し，多対多の実体を置かない
   → 購入年月日や課金種別など，購買ごとの属性を持つため独立エンティティが必要
3. サービスの“無償／有償”を属性値にしてしまい，サブタイプの区分化をしない
   → 将来的な拡張（有償サービス固有属性の追加）を考慮し，サブタイプ化しておくこと

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

• 「継承（ISA）」の記法：スーパークラス／サブクラス間で属性やキーをどう受け継ぐかを明確に
• 多対多の関係を持つ場合は「アソシエーションエンティティ（連関エンティティ）」を設ける
• 業務要件に「特定の属性をもつグループ（有償会員／有償サービス）」があるときは，属性ではなくエンティティ分割を検討
• 要望文からは必ず「何を追加するのか」「どのような管理を求められているのか」を正確に抜き出す
• 概念データモデルでは，属性／エンティティ／リレーションシップの位置づけを厳密に区別して記述すること

1. 核心となるキーワード・論点整理

• メルマガの識別：
  「メルマガは Web サイトID と メルマガID の組合せによって一意に識別し、メルマガ名を管理する」
• バックナンバの管理：
  「配信したメルマガは、バックナンバとしてメルマガ本文を配信日時ごとに管理する」
• 購読情報の管理：
  「会員は、利用している Web サイトについて、複数のメルマガを購読できる。会員が購読しているメルマガごとに、購読開始日を管理する」
• 関係の把握：
  • Webサイト ⇔ メルマガ（1:N）
  • メルマガ ⇔ バックナンバ（1:N）
  • 会員 ⇔ 購読メルマガ（N:M／購読開始日の属性付き）

2. 解答になる理由と論理的説明

1. 「メルマガは Web サイトID と メルマガID の組合せによって一意に識別し、メルマガ名を管理する」
   ⇒ メルマガを登録するテーブルとして、主キーに（WebサイトID, メルマガID）を持ち、メルマガ名を属性として持つ。
2. 「配信したメルマガは、バックナンバとしてメルマガ本文を配信日時ごとに管理する」
   ⇒ バックナンバ用テーブルとして、（WebサイトID, メルマガID, 配信日時）を主キーとし、メルマガ本文を属性として持つ。
3. 「会員は、利用している Web サイトについて、複数のメルマガを購読できる。会員が購読しているメルマガごとに、購読開始日を管理する」
   ⇒ 会員とメルマガの購読関係を表す中間テーブルを用意し、（WebサイトID, メルマガID, 会員番号）を主キーとして購読開始日を属性として持つ。

3. テーブル構造の再掲

メルマガ

購読メルマガ

バックナンバ

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

• 「WebサイトID」を抜かして、メルマガIDだけをキーにしがち。
  → 問題文で「Web サイトID と メルマガID の組合せ」と明記されている点を必ず踏まえること。
• バックナンバのテーブルに「配信日時」を含めない、または主キーに含めないミス。
  → 「配信日時ごとに管理する」とあるため、主キーの一部になる。
• 購読テーブルを作らずに「会員」テーブル側に購読開始日を追加しようとする。
  → 会員×メルマガの多対多関係を適切に解消する中間テーブルが必要。

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

• 要件定義文には「○○と××の組合せで識別」「○○ごとに管理する」といった主キー／複合キー設計のヒントが隠れている。
• 多対多 (N:M) の関係は、中間テーブルで表現し、属性（例：購読開始日）は中間テーブルに持たせる。
• 履歴やログのように「日時」で管理するものは、日時をキーの一部に含めるケースが多い。
• 問題文中の用語（例：メルマガ名、購読開始日、バックナンバ等）はそのまま列名として用いることで、設問の要件を満たしやすい。

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

• 手順1の作業内容：「旧データベースの項目のデータを分割・統合して、新データベースの項目のデータとする」
• WebサイトB：氏名カラムを「姓」「名」に分割する
• WebサイトC：住所カラムから「都道府県」を分割する

解答の根拠と論理的説明

1. 手順1の指示
   「旧データベースの項目のデータを分割・統合して、新データベースの項目のデータとする。」
   → 旧システムでは１つの項目にまとめられているデータを、新DBの設計に合わせて分割または統合する必要があることを示す。
2. WebサイトBの場合
   • 問題文：
     「表２　WebサイトBから抽出した会員データ（一部）」では，
     氏名(漢字) が “斎藤△太郎” のように姓と名が「△」（空白）で一括管理されている。
   • 新DB設計では「一般会員」テーブルに「姓」「名」を別々の列として定義しているため，
     旧データの「氏名」を「姓」「名」に分割する必要がある。
   【関連引用】
   「旧データベースと項目の構成方法が異なるデータを編集する。」
   「WebサイトBの会員番号は流用し…」 などの記述から，氏名の構成方法が異なることがわかる。
3. WebサイトCの場合
   • 問題文：
     「表３　WebサイトCから抽出した会員データ（一部）」では，
     住所欄に「東京都文京区◯◯2－28－8－102」のように都道府県以下が一括管理されている。
   • 新DB設計の「一般会員」テーブルには「都道府県」列と「住所」列を別に持つため，
     旧データの住所から都道府県を抽出（分割）する必要がある。
   【関連引用】
   「旧データベースの項目のデータを分割・統合して、新データベースの項目のデータとする。」

誤りやすいポイントと注意点

• WebサイトBで「氏名」を分割する際，漢字氏名ではなくフリガナ部分を分割対象と間違えない。
• WebサイトCで住所を分割する場合，「市区町村」や「番地」ではなく，手順1で指定されている「都道府県」のみを切り出す。
• 分割の際には一律のルール（都道府県リストなど）を使って誤抽出を防ぐ。

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

• 手順1は「分割・統合」であることを理解し、旧項目→新項目の対応関係を明確にする。
• 複数のデータ要素が１つの項目にまとまっている場合は「分割」を行う。
• 分割対象は新DB設計書の列定義を必ず参照する。
• 氏名や住所など、業務でよく扱う複合データの分割方法（区切り文字の扱い、正規化の考え方）を押さえておく。

キーワードと論点整理

• 採番範囲の重複：Web サイト A と B の会員番号の付与ルールが異なるが、使用する番号の範囲に重なりがある
• 一意制約違反：同じ会員番号が重複すると新データベースのキー制約（主キーの重複禁止）に抵触する
• 手順2 の作業方法：

  「Web サイト A 及び B の会員番号は流用し、会員番号列のない Web サイト C のデータは、Web サイト A 及び B に存在しない会員番号を新規に付与する。」

解答の論理的説明

• Web サイト A の番号は「連番7桁＋入会年の西暦下2桁」（表1 注1）
• Web サイト B の番号は「00000000〜99999999 の連番」（表2 注2）
  という異なる方式ですが、番号の実数値範囲が重複します。
  その結果、両サイトから同一番号が移行対象に含まれると、
  新データベースの会員テーブルで主キー（一意制約）違反が発生します。

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

• 「Web サイト C に番号がないこと」ばかり注目し、A と B の重複を見落としやすい
• 異なるフォーマットだから重複しないと誤解しがち（実際は数値範囲で重なる）
• 手順2 の「流用」という表現が「そのまま衝突なく使える」と解釈されやすい

試験対策としてのまとめ

• 主キー統合時は「採番方式」だけでなく「数値や文字列の実際の範囲」を必ず確認する
• 異なる運用サイト間でのキー重複リスクを洗い出し、必要ならプレフィックス付与や再採番ルールを設計する
• データ移行時の手順（分割・統合・統一）それぞれで発生し得る制約違反を想定し、対策を明確にする

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

2. 解答が妥当な理由の論理的説明

1. 旧字体→新字体
   • WebサイトBの氏名には「髙橋△次郎」のように旧字体（髙）が使われている（表２）。
   • WebサイトAや表３では「高橋」が使われている。
   • 「過去のデータを最新データに変換する方法が明確な場合は，最新データに更新する」という指示に合致。
2. 住所表記の標準化
   • 番地以降の表記には，
     • WebサイトA：2-28-8-102
     • WebサイトB：２－２８－８－１０２（全角数字＋全角ハイフン）
     • WebサイトC：東京都文京区◯◯2－28－8－102（前半くっつき表記）
       とバラつきがある。
   • 算用数字＋ハイフンに統一することで検索性・ソート性が向上し，「表記のばらつきを解消する」要件を満たす。
   • また，「市町村合併などで変更された住所を現在のものに修正する」ことも，「過去のデータを最新データに更新する」要件に含まれる。

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

• 「30字以内」であるため，書きすぎてポイントがぼやける
  → 旧字体→新字体変換，住所番地の数字・ハイフン統一，最新住所への更新のいずれか二つをコンパクトに。
• 「住所の標準化」で市町村名の更新を挙げずに，数字→算用数字だけを挙げてしまう
  → 市町村合併による変更も「最新データに更新する」一環とみなされる。
• 半角⇔全角変換だけを挙げ，ハイフンの種類（全角・半角）に触れない
  → 算用数字＋半角ハイフンで統一することまで記載する。

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

• 手順3の狙いは「表記ゆれの解消」「過去→最新へのデータ更新」
• 「標準化」の具体例として，以下を押さえる
  • 文字種変換：旧字体→新字体／全角数字→半角数字／ひらがな→カタカナ
  • 形式統一：日付形式（YYYY-MM-DDなど），電話番号（ハイフン位置），住所（番地表記）
  • 名称更新：市町村合併，商号変更など
• 「30字以内」の解答では，主語を省略して動詞＋目的語を中心に記述する練習をする。

キーワードと論点整理

• 複数の Web サイト
• 同一人物
• 会員データの特定（重複排除／重複検出）
• データ移行における重複排除フェーズ

なぜこの解答になるのか

「複数の既存 Web サイトのデータベースから，‘一般会員’ テーブルに相当する登録済の会員データを入手し，整理した。」
「各 Web サイトの重複した会員データを統合することを視野に入れ，データの移行作業の検討を行った。」

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

• 「キーの統一」「表記の標準化」と混同しやすい
  → 手順2・3で既にキー統一や表記統一を行っている点に注意する。
• 手順4を「メールアドレスで抽出」「住所で抽出」など具体的手法と解釈しがち
  → 手順4では**何を行うか（重複会員の特定）**を示すのが問われており，
  具体的な判定基準やルールは別途定義とされている。
• 「データ確認」「問い合わせ」とだけ書くとあいまいになる
  → 「同一人物であると考えられる会員データを特定する」という意図を明確に記述する。

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

1. データ移行の基本手順
   1. 構造変換（分割・統合）
   2. キー統一
   3. 表記標準化
   4. 重複検出・統合（同一人物の特定）
   5. 確定・承認
2. 各手順の目的を整理し，「何を行うか」を簡潔に述べられるようにする。
3. 設問文中に「別途定義する」とある場合，具体的手法ではなく大枠の作業内容を答える。