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

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

2. 解答に至る論理的プロセス

2.1 電子会議投稿に含まれる鍵候補の洗い出し

“電子会議を一意に識別する番号”

“投稿番号は電子会議番号との組合せで投稿を一意に識別”

“電子会議は…分野ごとに定められた表示順に従って一覧表示される。…一つの分野内で表示順が重複することはない。”

2.2 部分関数従属性の有無

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

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

4. 試験対策まとめ

1. ここがポイント（キーワード整理）

2. 解答に至る論理的プロセス

(1) 関係と主キーを確認

(2) 機能従属を洗い出す

(3) 正規形の判定

(4) 3NF へ分解

3. 受験者がよく間違えるポイント

1. 「2NF＝複合キーのときだけ問題」という誤解
   主キーが単一なら 2NF は自動的に満たされるが，複合キーの場合は今回のような“部分従属”が頻出。
2. 表示順や分野名を“従属関係なし”と見なすミス
   表示順は“分野単位で重複なし”と書かれており，電子会議番号に従属。分野名も分野番号に従属するので要注意。
3. 3NF 判定で「推移従属だけ」を見て 2NF を飛ばす
   まず 2NF を満たすかを確認し，次に 3NF の推移従属を調べる手順が鉄則。

4. 試験対策まとめ

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

1. 問題文中の「主務グループ」「管理を行うグループ」「メッセージ送信元」「メッセージ送信先」「開封日時」「参加可否回答」のそれぞれを、関係スキーマの空欄に当てはめる。
2. 主キーと外部キーの指定。

解答の根拠と論理展開

• 問題文：「ユーザは,一つのグループに必ず所属し,これを主務グループと呼ぶ。」
• → ユーザ関係には所属先グループを示す属性が必要 ⇒ 主務グループID
• 外部キー（ユーザ→グループ．グループIDを参照）

• 問題文：「設備には,必要に応じて,当該設備の管理を行うグループを一つ定めることができる。」
• → 設備関係には管理を行うグループIDを保持 ⇒ 管理グループID
• 外部キー（設備→グループ．グループIDを参照）

• 問題文：「ユーザは,1人又は複数のユーザにメッセージを送信することができる。」
• メッセージが誰から送られたかを識別する ⇒ 送信元ユーザID
• 外部キー（メッセージ→ユーザ．ユーザIDを参照）

• 関係スキーマ：メッセージ送信先（メッセージID，□d，□e）
• 問題文：「送信先のユーザがメッセージを開封すると,開封日時が記録される。」
• 空欄には「送信先ユーザID」「開封日時」を設定
  • 送信先ユーザID：主キーの一部（メッセージIDと組合せで一意）かつ外部キー（ユーザを参照）
  • 開封日時：非キー属性

• 関係スキーマ：スケジュール予約先（予約番号，予約先ユーザID，□f）
• 問題文：「スケジュールを予約されたユーザは,そのスケジュールに参加するか否かを回答することができる。」
• → 回答結果を表す属性 ⇒ 参加可否回答
• 非キー属性

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

1. 「主務グループID」と「管理グループID」を混同しやすい
   • 主務グループ：ユーザが必ず1つ所属
   • 管理グループ：設備に対して「必要に応じて」設定
2. メッセージ関係で「送信元ユーザID」と「投稿者ユーザID」など、用語の類似に注意
3. メッセージ送信先の主キー設定
   • (メッセージID, 送信先ユーザID) の複合主キーであること
4. 外部キーは参照先の主キー名と一致させるのが基本
5. 実線／破線の下線指定を忘れやすい
   • 主キー：実線下線
   • 外部キー：破線下線

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

• 概念モデル（ER図）で定義した役割や制約を、物理モデル（関係スキーマ）に正しくマッピングする練習を繰り返す。
• 問題文中の「必ず」「必要に応じて」「一つ又は複数」「一意に識別」などのキーワードから、主キー・外部キー・NULL制約の要否を判断する。
• 関係スキーマ設計では、属性名の一貫性（ID付与ルール）を守ると誤答を減らせる。
• 主キー／外部キーの表記方法（実線・破線）を確実に身につける。
• 練習問題を通じて、(a) に該当する文章→属性名への翻訳力を高めよう。

キーワードと論点整理

• エンティティタイプ間のリレーションシップ
  「実体（エンティティタイプ）がどのように関連し、業務ルール上必須か任意かを示す」
• 多重度（対応関係）と参加制約
  「1対多」「多対1」の区別、参加が必須なら●、任意なら○で表現
• ブリッジエンティティ
  「兼務グループ」「設備予約先」「スケジュール予約先」「メッセージ送信先」は多対多を分解
• 自己リレーションシップ
  「グループ」同士の上下位関係

リレーションシップ一覧と設計意図

1. ユーザ ― 所属 ― グループ
   • 要件：「ユーザは,一つのグループに必ず所属し,これを主務グループと呼ぶ。」
   • 多重度：ユーザ(●1) ― グループ(○0..*)
     （各ユーザは必ず１グループ／各グループは０人以上のユーザ）
2. ユーザ ― 兼務グループ
   • 要件：「ユーザは,一つ又は複数のグループに兼務として所属することができる。」
   • 多重度：ユーザ(○0..*) ― 兼務グループ(●1)
     （各ユーザは０件以上の兼務／各兼務は必ず１ユーザ）
3. グループ ― 兼務グループ
   • 要件：兼務グループは「ユーザID, グループID」の組合せで定義
   • 多重度：グループ(○0..*) ― 兼務グループ(●1)
     （各グループは０件以上の兼務／各兼務は必ず１グループ）
4. 予約 ― ユーザ
   • 要件：「予約（予約者ユーザID）」
   • 多重度：予約(●1) ― ユーザ(○0..*)
     （各予約は必ず１ユーザ／各ユーザは０件以上の予約）
5. 予約 ― 設備予約先
   • 要件：「設備予約とは,…設備を予約する…設備予約先(予約番号, 設備ID)」
   • 多重度：予約(●1) ― 設備予約先(○0..*)
     （各予約は０件以上の設備予約先／各設備予約先は必ず１予約）
6. 設備 ― 設備予約先
   • 要件：「設備には…管理を行うグループを…定めることができる。」
   • 多重度：設備(○0..*) ― 設備予約先(●1)
     （各設備は０件以上の予約先／各設備予約先は必ず１設備）
7. 予約 ― スケジュール予約先
   • 要件：「スケジュール予約先(予約番号, 予約先ユーザID, …)」
   • 多重度：予約(●1) ― スケジュール予約先(○0..*)
     （各予約は０件以上のスケジュール先／各先は必ず１予約）
8. ユーザ ― スケジュール予約先
   • 要件：「スケジュール予約されたユーザは…」
   • 多重度：ユーザ(○0..*) ― スケジュール予約先(●1)
     （各ユーザは０件以上のスケジュール先／各先は必ず１ユーザ）
9. メッセージ ― メッセージ送信先
   • 要件：「メッセージ送信先(メッセージID, …)」
   • 多重度：メッセージ(●1) ― メッセージ送信先(○0..*)
     （各メッセージは少なくとも１送信先／設計上０件許容されるが、運用では１件以上）
10. ユーザ ― メッセージ送信先
    • 要件：「ユーザは,1人又は複数のユーザにメッセージを送信することができる。」
    • 多重度：ユーザ(○0..*) ― メッセージ送信先(●1)
      （各ユーザは０件以上の受信／各送信先は必ず１ユーザ）
11. グループ ― 上位グループ（自己リレーション）
    • 要件：「グループには,上位のグループを一つ定めることができる。」
    • 多重度：グループ(○0..*) ←──→ グループ(○0..1)
      （親グループは０件または１件／子グループは０件以上）

解答導出のロジック

1. 業務要件の読み取り
   • 「必ず所属」「一つ又は複数」「0人もあり得る」などの表現から、多重度と参加制約を判断。
2. 多対多の分解
   • 「兼務」「設備予約」「スケジュール予約」「メッセージ送信」は多対多の性質があるため、中間エンティティで「–先」「–グループ」を設計。
3. ER記法との整合
   • 必須参加を●、任意参加を○で表し、図３の黒丸／白丸に対応させる。
4. 自己リレーションの扱い
   • グループ同士の上下位は、自己結合で「0..1／0..*」とする。

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

• 「必ず１つ所属」と「兼務は任意」を混同しやすい
• 多対多を直接結ばず「中間エンティティ」を立てる点
• 自己リレーションシップ（グループの上下位）を見落とす
• 「0件許容」と「1件以上必須」を示す○と●を逆に記載する

試験対策ポイント

• 要件文中の「必ず」「できる」「存在しない場合はNULL」などのキーワードで、多重度と参加制約を即座に判断
• 多対多は必ずブリッジエンティティで分解
• ER図の記号（●＝必須、○＝任意）を正確に使い分ける
• 自己リレーションは「同じエンティティを親子関係で結ぶ」パターンとして覚えておく

キーワード・論点整理

• 指摘事項①：ロールを管理するデータ構造が設計されていない
  → 問題文中に「ロールは,ロール ID で一意に識別し,ロール名をもつ」「ユーザには…一つ又は複数のロールを付与でき…一つのロールを複数のユーザに付与することもできる」とある
• 必要な追加
  1. ロールを表す関係（エンティティ）
  2. ユーザとロールの多対多を表す関係（関連）
  3. 「承認者区分」が“ロール指定”の場合にそのロールを参照するための属性

解答に至る論理的理由

1. 【ロールを表す関係】
   問題文：「ロールは,ロール ID で一意に識別し,ロール名をもつ。」
   したがって，下記のようにロールを管理する新規関係を追加します。

   関係名	属性	主キー	備考
   ロール	ロールID, ロール名	ロールID	–

2. 【ユーザとロールの多対多関係】
   問題文：「ユーザには…複数のロールを付与でき,一つのロールを複数のユーザに付与することもできる。」
   多対多を実現する中間テーブルを追加します。

   関係名	属性	主キー	外部キー
   ロール付与先	ロールID, ユーザID	(ロールID, ユーザID)	ロールID → ロール(ロールID)
   			ユーザID → ユーザ(ユーザID)

3. 【承認者をロールで指定できるように属性追加】
   問題文：「ステップには,承認可能なユーザ,グループ又はロールを指定する。ユーザ,グループ又はロールのいずれで指定されているかは、承認者区分で識別する。」
   既存の 決裁ルート 関係には「承認ユーザID」「承認グループID」しかなく，「ロール指定」の場合の参照先がありません。
   したがって，決裁ルート 関係に「承認ルートID」を追加し，
   • 承認者区分＝“ロール指定”のときはこの「承認ルートID」で ロール を参照
   • 他区分のときは NULL とする
     ことで，各区分に応じた承認者情報を保持できます。

   関係名	追加属性
   決裁ルート	承認ルートID

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

• 「ロールID」を直接 ユーザ 関係に追加して１対多と勘違いし，多対多を表現しきれない
• 承認者区分＝ロールの場合の参照属性を忘れて「承認ユーザID」「承認グループID」しか使えないままにする
• 属性名を「承認ロールID」としてしまうが，設問や模範解答に合わせて「承認ルートID」を正確に記述する

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

• 多対多の関係は中間テーブル（関係）を設け，両者の主キーを外部キーかつ複合主キーとして設定する
• エンティティ（概念）として明示されたものは必ず対応する関係（テーブル）を設計する
• 「区分」と「参照先属性」のペアはセットで設計し，区分に応じて適切な外部キー属性を持たせる
• 模範解答の表記や固有名詞は問題文と同じ用語・名称を正確に引用することが重要

キーワードと論点整理

• 指摘事項②の不具合
  「一度承認を行った申請が差戻しされた後、再度承認処理を行ったとき」に既存の承認テーブルで主キー制約違反や上書きが発生する。
• 原因
  オリジナル設計では承認を識別するキーに「承認連番」を含めておらず、同一ステップで再承認すると既存レコードと衝突する。
• 修正
  承認テーブルの主キーに「承認連番」を追加し、再承認を別レコードとして登録できるようにする。

解答理由の論理的説明

1. 【問題文】より
   「ステップの承認者をグループ又はロールで指定している場合…再度承認処理を行うことはできない」
   とあり、差戻し後に同じステップへ戻るケースがあることが前提。
2. 承認処理の登録要件
   「承認処理を行うと, その都度処理内容がデータベースに新規登録される。」
   しかし、元スキーマで主キーが
   （申請ひな形番号, 申請連番, ステップ番号）
   のみだと、再承認時に同一キーで新規行を追加できず、エラー又は上書きとなる。
3. 結果
   「一度承認を行った申請が差戻しされた後、再度承認処理を行ったとき」に不具合発生。
4. 対策
   承認を一意に識別するため、主キーに「承認連番」を含める。
   これにより、同一ステップで何度承認しても別レコードとして管理可能になる。

修正後の関係スキーマ

• （申請ひな形番号, 申請連番）→申請(申請ひな形番号,申請連番)
• （申請ひな形番号, ステップ番号）→決裁ルート(申請ひな形番号,ステップ番号)
• 承認者ユーザID → ユーザ(ユーザID) |

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

• 「承認連番」は単なる連番と考えがちだが、主キーに含めないと差戻し後の再承認で一意性を担保できない。
• 差戻し（ステップ番号が同じ状態へ戻る）と否認（申請が終了）を混同しない。否認は最終状態へ遷移し再承認は起きない。

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

• 再度同一キーで追加すべきケースには、必ず「複数回分」を識別する連番やタイムスタンプを主キーに含める。
• 第3正規形では、主キー以外の属性が互いに依存し合わないことを確認し、必要な識別子を欠かさず設計する。
• ER／リレーション設計で「多重登録」の要件を常に洗い出し、キー設計と突き合わせるクセをつける。