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

模範解答

解説

解答の論理構成

1. “お気に入り”テーブルの列決定
   • 引用【問題文】(4)「会員はログイン後に任意のコンテンツをお気に入りとして登録」
   • 同じ(4)「お気に入りは、登録した日時の順に表示」
     → 必要列＝会員を特定する「会員番号」、対象コンテンツを特定する「コンテンツID」、表示順を決める「登録日時」。
     → 1 会員が同一コンテンツを複数登録しない運用なら、主キー＝(会員番号, コンテンツID)。
2. “サービス”テーブル
   • 引用【問題文】(3)「サービスは、Web サイトごとに複数提供され、Web サイト ID とサービスID の組合せによって識別」
     → 主キー＝(WebサイトID, サービスID)。
     → 外部キー：WebサイトID → “Webサイト”テーブル(想定)。
3. “コンテンツ”テーブル
   • 引用【問題文】(4)「コンテンツはコンテンツIDによって識別され」
   • さらに「サービスを構成」なのでサービスにも従属。
     → 主キー＝コンテンツID。
     → 外部キー：(WebサイトID, サービスID) → “サービス”テーブル。
4. “利用権限”テーブル
   • 引用【問題文】(5)「権限区分には… コンテンツ ID と会員区分の組合せでいずれかに定められる」
     → 主キー＝(コンテンツID, 会員区分)。
     → 外部キー：コンテンツID → “コンテンツ”テーブル、会員区分 → “会員”マスタ。
5. まとめて表記
   • お気に入り（＜主キー＞会員番号, コンテンツID, 登録日時）
   • サービス（＜主キー＞WebサイトID, サービスID, サービス名）
   • コンテンツ（＜主キー＞コンテンツID, ＜外部キー＞WebサイトID, サービスID, コンテンツ名, ディレクトリ）
   • 利用権限（＜主キー＞コンテンツID, 会員区分, 権限区分）

誤りやすいポイント

• 「b：コンテンツ」を「コンテンツ名」と取り違え、主キー列を誤記する。正しくは「コンテンツID」。
• “サービス”の主キーをサービスID単独にしてしまい、Webサイト間で重複する可能性を見落とす。
• “利用権限”で「権限区分」を主キーに含めてしまう。問題文は「コンテンツ ID と会員区分の組合せでいずれかに定められる」と明示。

FAQ

模範解答

解説

解答の論理構成

1. 【問題文】にある〔K部長の指摘事項〕「② “掲示板” テーブルは、第3正規形に正規化されていない。」が出発点。
2. “掲示板”テーブルの候補キーは【問題文】「掲示板は、Web サイト ID と掲示板 ID の組合せによって一意に識別される。」から“Web サイト ID”＋“掲示板 ID”。
3. “タイトル”や“説明文”は掲示板固有情報なので，“掲示板 ID”だけで一意になります。これは「複合キーの一部（掲示板 ID）のみ」への依存＝部分関数従属。
4. 部分関数従属が残っている関係は第2正規形を満たさないため，第1正規形止まりとなります。
5. したがって模範解答の「正規形：第1正規形」「判別根拠：…部分関数従属している。」が導かれます。

誤りやすいポイント

• 「列が重複しないし繰返しもないから第3正規形」と早合点しやすい。複合キーの依存関係をチェックしないミスが頻発。
• 「掲示板 ID が一意だから単一キー」と勘違いし，“Web サイト ID”を候補キー要素から外してしまう。
• 第2正規形と第3正規形の区別を「部分関数従属」「推移的関数従属」の違いで整理できず混同する。

FAQ

模範解答

解説

解答の論理構成

1. 現状把握
   “掲示板” にタイトルや説明文だけでなくメッセージ本文まで入っていると仮定すると、主キー〈WebサイトID, 掲示板ID〉に対しメッセージ本文は部分関数従属していない（メッセージ番号が必要）ため第３正規形違反。
2. 正規化手順
   ① 主キーを決定：掲示板‐レベルは〈WebサイトID, 掲示板ID〉、メッセージ‐レベルはさらに〈メッセージ番号〉を加える。
   ② 部分関数従属の排除：メッセージ本文・メッセージ投稿者会員番号・メッセージ投稿日時は掲示板キーに「従属＋追加識別子」が必要なので分離。
   ③ 推移的従属の排除：掲示板開設者など掲示板キーに直接依存する属性は残す。
3. 返信管理
   問題文(7)で「返信対象の投稿メッセージ (親メッセージ)」と明示されているため、メッセージ表に自己参照外部キー〈親メッセージ番号〉を設ける。NULL ならルート投稿、値ありなら返信投稿。
4. 完成形
   模範解答と同一の２表構成となり、指摘②③は同時に解消される。

誤りやすいポイント

• メッセージの主キーに「親メッセージ番号」を入れてしまう
  → 返信がない投稿で NULL を許せなくなり、主キー条件を満たせません。
• 掲示板開設者会員番号・メッセージ投稿者会員番号を単なる列として外部キー制約を設定し忘れる
  → 整合性欠如で孤児レコードが発生します。
• 「掲示板ID」だけを掲示板表の主キーにする
  → Web サイトを跨いで ID が重複する可能性を排除できません。

FAQ

模範解答

解説

解答の論理構成

1. 会員側
   • 要件より「一般会員」「期限付き会員」「有償会員」の３区分が必要。
   • ３者はいずれもスーパークラス「会員」の下位エンティティなので，左側３枠に順に記入。
2. サービス側
   • 既存サービス＝無償であるため「無償サービス」
   • 追加要件で「有償サービス」を新設
   • したがって，右上２枠は「無償サービス」「有償サービス」
3. 有償会員と有償サービスの関係
   • 要件文「“購入サービス”を新たに定義する。」から，多対多対応用の連結エンティティが必要
   • 右下枠に「購入サービス」を配置し，有償サービスと１対多，有償会員と１対多で結ぶ
4. リレーションシップ命名
   • 会員と無償サービス：閲覧や登録を表す語として汎用性の高い「利用」
   • 有償会員と購入サービス：金銭対価が発生する行為であるため「購入」

誤りやすいポイント

• 「購入サービス」をリレーションシップ（菱形）で描き，エンティティ枠を使わない
• 「有償サービス」と「無償サービス」を同じエンティティにまとめてしまい区分属性で済ませようとする
• 無償サービスにも購入リレーションシップを付けてしまう（要件外）

FAQ

模範解答

解説

解答の論理構成

1. まずメルマガ自体を定義
   • 【問題文】「“メルマガは Web サイト IDとメルマガ ID の組合せによって一意に識別し、メルマガ名を管理する。」
     ⇒ 実体：メルマガ
     ⇒ 主キー： WebサイトID , メルマガID
     ⇒ 属性：メルマガ名
2. 会員とメルマガの多対多関係を解消
   • 【問題文】「会員は、利用している Web サイトについて、複数のメルマガを購読できる。」
     ⇒ N 対 N を 1 対 N × N 対 1 に分割する中間表が必要
     ⇒ 実体：購読メルマガ
     ⇒ 主キー： WebサイトID , メルマガID , 会員番号
     ⇒ 属性：購読開始日
3. 配信履歴（バックナンバ）を管理
   • 【問題文】「配信したメルマガは、バックナンバとしてメルマガ本文を配信日時ごとに管理する。」
     ⇒ 実体：バックナンバ
     ⇒ 主キー： WebサイトID , メルマガID , 配信日時
     ⇒ 属性：メルマガ本文
4. 参照整合性
   • 購読メルマガ と バックナンバ の外部キーは（ WebサイトID , メルマガID ）で メルマガ を参照。
   • 購読メルマガ の外部キー（ 会員番号 ）は 会員 を参照。
     これで全文要件をカバーし、第 3 正規形も満たします。

誤りやすいポイント

• メルマガID を単独主キーにして「 WebサイトID を列追加」しただけにする → 複数サイトで ID が重複したとき一意性が崩れる。
• 購読メルマガ の主キーを（ 会員番号 , メルマガID ）とし WebサイトID を含め忘れる → 異なる Web サイトのメルマガを区別できなくなる。
• バックナンバ で 配信日時 を PK に入れず、最新だけ保持する想定にしてしまう → 履歴閲覧要件を満たせない。

FAQ

模範解答

解説

解答の論理構成

1. 手順1の目的を確認
   • 【問題文】“旧データベースと項目の構成方法が異なるデータを編集する。”
   • 具体作業：“分割・統合” によって新DBと同じ項目構成に合わせる。
2. WebサイトB（表２）の列構成を確認
   • 列 “氏名漢字” に “斎藤△太郎” の形式で姓と名が同一セルに格納。
   • 新DBでは【問題文】表１と同様に “姓(漢字)”“名(漢字)” が別列。
   • よって “姓名分離” が必須。
3. WebサイトC（表３）の列構成を確認
   • “住所” 列には “東京都文京区◯◯2－28－8－102” のように都道府県＋市区町村以下が混在。
   • 新DBでは表１・表２と同様に “都道府県” 列が独立している。
   • よって “都道府県抽出” が必要。
4. 以上より編集内容をまとめる
   • B：氏名列を 姓 と 名 に切り出す。
   • C：住所列から 都道府県 を切り出す。

誤りやすいポイント

• “フリガナを統一” など手順3で求められる標準化と混同する。
• C の編集対象を “メールアドレス” と誤認し、重複チェックを挙げてしまう。
• “分離” と “統合” の両方を羅列し、20字以内を超過する。

FAQ

模範解答

解説

解答の論理構成

1. 【問題文】の手順2の作業方法
   「Web サイト A 及び B の会員番号は流用」すると定義されています。
2. 各サイトの採番規則
   • 表1 注1: 「連番7桁＋入会年の西暦下2桁」
   • 表2 注2: 「『00000000』〜『99999999』の連番」
3. 規則を重ね合わせると，例えば A の「001234501」と B の「000012345」など，先頭の

   0

   を含めた 9 桁/8 桁の違いを無視できないまま流用すると，同一値が発生するリスクがある。
4. 新 DB では会員番号が主キーとなるため，重複は「一意制約違反」を招き，移行が停止する。
5. よって模範解答のように「番号範囲が重複→一意制約違反」と整理される。

誤りやすいポイント

• 「9桁と8桁だから重複しない」と思い込む
  先頭ゼロ有無や桁埋め処理で同一キーになるケースを見落としがちです。
• Cサイトに番号を付番する作業だけを問題視し，A・Bの衝突を失念する。
• 重複時の影響を「データが上書きされる」と誤答し，一意制約違反という RDB のエラーを示せない。

FAQ

模範解答

解説

解答の論理構成

1. 手順3の目的
   【問題文】“標準データに変換する”と明示。よって変換候補を抽出。
2. 氏名フィールドの差異
   表1“斎藤”，表2“斎藤△太郎”のように旧字体と新字体が混在。さらに“△”＝空白の有無も不統一。旧→新字体に統一すれば検索一致率が向上。
3. 住所フィールドの差異
   表1“文京区◯◯◯2-28-8-102”，表2“文京区〇〇２－２８－８－１０２”のように全角数字・漢数字・ハイフン種別が混在。算用数字＋半角ハイフンへ統一すればソート／範囲検索が容易。
   また、“千葉県千葉市中央区●1－1”と市町村合併後の“千葉市”のように古い地名が残る可能性がある。最新地名へ更新することで郵送トラブルを防ぐ。
4. 以上より、模範解答の二点が適切。

誤りやすいポイント

• 「フリガナをカタカナへ統一」は手順3の例“ひらがなに変換”と重複するため不可。
• “メールアドレスのドメイン統一”は業務要件外。標準化対象は氏名・住所など“個人情報”に限定する。
• 二つ挙げよ→「住所の全角→半角」と「市町村合併後の修正」を別回答にすると30字超えや重複扱いになる恐れ。

FAQ

模範解答

解説

解答の論理構成

1. 【問題文】では手順4の作業方法に「この作業を行うための具体的な判定基準、ルールは別途定義する。」とあります。これは“判定＝同一人物かどうか”を意味します。
2. さらに冒頭で「各 Web サイトの重複した会員データを統合する」と述べられており、目的は重複レコードの統合です。
3. 手順1〜3で形式統一までは完了していますが、まだ重複行は残存します。そこで、同一人物と考えられる複数行を「特定」する処理が必要になります。
4. 以上より、(d)には「複数の Web サイトを利用している，同一人物であると考えられる会員の会員データを特定する」が妥当となります。

誤りやすいポイント

• 「削除」や「統合」と書いてしまう
  手順4は“候補の特定”であり、削除・統合は手順5以降です。
• 判定基準の作成と誤解する
  判定基準は「別途定義する」と既に書かれているため、(d)は基準作成ではなく特定作業です。
• 「重複データの検索」だけを書く
  “同一人物であると考えられる”という主旨を明示しないと減点対象となります。

FAQ