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

模範解答

解説

解答の論理構成

1. 候補キーの導出
   • 表1で「電子会議番号」は電子会議を一意に識別する ⇒ 投稿を区別するには「投稿番号」と組み合わせれば良い。
     よって「{ 電子会議番号, 投稿番号 }」。
   • 同じく表1で「表示順」は「一つの分野内で表示順が重複することはない」。つまり分野内では「{ 分野番号, 表示順 }」が電子会議を一意に決める。そこに「投稿番号」を加えると投稿が一意になる ⇒ 「{ 分野番号, 表示順, 投稿番号 }」。
   • 以上 2 つが候補キー。
2. 部分関数従属性の検出
   • 候補キーの 1 つ「{ 電子会議番号, 投稿番号 }」に注目。
     【問題文】「電子会議のタイトル」を示す属性は「議題」。電子会議レベルの情報であり、キーのうち「電子会議番号」だけで決まる。
     よって「電子会議番号 → 議題」が部分関数従属性。
3. 推移的関数従属性の検出
   • 電子会議レベルで「電子会議番号 → 分野番号」が成り立つ（電子会議は 1 つの分野に属する）。
   • さらに分野レベルで「分野番号 → 分野名」が成り立つ（表1より「分野を一意に識別する番号」「分野の名称」）。
   • よって「電子会議番号 → 分野番号 → 分野名」が推移的関数従属性。
4. 以上により、模範解答と一致する。

誤りやすいポイント

• 「表示順」は電子会議レベルの属性であり、投稿を識別するキーと誤って単独で使ってしまう。
• 「{ 分野番号, 表示順 }」が電子会議を一意とする根拠を「表示順が分野ごとに連番」などと誤記し、【問題文】の「重複しない」条件を引用しない。
• 推移的従属性で「分野番号 → 分野名」を忘れ、「電子会議番号 → 分野名」を直接書いてしまう。

FAQ

模範解答

解説

解答の論理構成

1. 【表1】により関係 “電子会議投稿(電子会議番号, 議題, 分野番号, 分野名, 表示順, 作成者ユーザID, 投稿番号, 投稿本文, 投稿者ユーザID)” が定義されている。
2. 主キー候補は “電子会議番号, 投稿番号”（投稿を一意識別）である。
3. 関数従属性を整理すると
   • “分野番号 → 分野名”（同一分野で名称は一意）
   • “電子会議番号 → 議題, 分野番号, 表示順, 作成者ユーザID”（1 会議 1 レコード）
   • “電子会議番号, 投稿番号 → 投稿本文, 投稿者ユーザID”（投稿内容はこの複合キーで決定）
4. よって
   • 部分関数従属（例：電子会議番号 → 議題）が存在 → 第2正規形を満たさない。
   • 推移的関数従属（例：分野番号 → 分野名）が存在 → 第3正規形も満たさない。
5. 第3正規形へ分解

   分野(<u>分野番号</u>, 分野名)
   電子会議(<u>電子会議番号</u>, 議題, <span style="border-bottom: 1px dotted;">分野番号</span>, 表示順, <span style="border-bottom: 1px dotted;">作成者ユーザID</span>)
   投稿(<u>電子会議番号</u>, <u>投稿番号</u>, 投稿本文, <span style="border-bottom: 1px dotted;">投稿者ユーザID</span>)
   

   • 下線：主キー
   • 点線下線：外部キー
6. 以上により、すべての非キー属性が主キーに対して非推移的かつ完全関数従属となり、第3正規形が達成される。

誤りやすいポイント

• “表示順” を “分野番号” と直接結びつけてしまい、電子会議に属すると気付かない。
• 主キーを “電子会議番号” だけと誤認し、第1正規形を見落とす。
• 外部キー指定を忘れ、正規化後のリレーションが孤立する。

FAQ

模範解答

解説

解答の論理構成

1. (a) ユーザ表の空欄
   • 要件引用：【問題文】「ユーザは,一つのグループに必ず所属し,これを主務グループと呼ぶ。」
   • 主キーではなく, グループ表の「グループID」を参照するため外部キー。
   • よって 主務グループID。
2. (b) 設備表の空欄
   • 要件引用：【問題文】「設備には,必要に応じて,当該設備の管理を行うグループを一つ定めることができる。」
   • グループを参照する外部キー。
   • よって 管理グループID。
3. (c) メッセージ表の空欄
   • 要件引用：【問題文】「ユーザは,1人又は複数のユーザにメッセージを送信することができる。」
   • 送信元ユーザを保持し, ユーザ表を参照する外部キー。
   • よって 送信元ユーザID。
4. (d)(e) メッセージ送信先表の空欄
   • 受信者識別と開封日時が必要
     ・受信者…【問題文】「送信先のユーザがメッセージを開封すると, 開封日時が記録される。」
     ・主キー構造…同一メッセージに対し複数受信者 ⇒ (メッセージID, 受信者ID)で一意
   • 従い (d) は主キー送信先ユーザID、(e) は開封日時。
5. (f) スケジュール予約先表の空欄
   • 要件引用：【問題文】「スケジュールを予約されたユーザは, そのスケジュールに参加するか否かを回答することができる。」
   • 回答結果を保持する属性が必要 ⇒ 参加可否回答。主キーでも外部キーでもないため下線なし。

誤りやすいポイント

• (a) を「所属グループID」と書く
  「主務」という語を落とすと兼務との区別が付かず不正確。
• (d) の下線種別
  受信者IDを外部キーと判断し破線にすると主キー要件を満たせない。
• (f) を NULL で済むと思い属性自体を作らない
  参加可否の回答結果は履歴ではなく最新値で良いので列が必要。

FAQ

模範解答

解説

解答の論理構成

1. 業務規約の抜き出し
   • 「ユーザは,一つのグループに必ず所属し」
   • 「ユーザは,一つ又は複数のグループに兼務として所属することができる」
   • 「スケジュール予約及び設備予約は,…いずれか一方を予約することもできる」
   • 「ユーザは,1人又は複数のユーザにメッセージを送信することができる」
     これらがカードィナリティ判定の根拠になる。
2. １対多か多対多かの判定
   • 主務グループ：ユーザ側が必須１，グループ側は０以上 → グループ●―○ユーザ
   • 兼務：ユーザとグループは多対多なので中間エンティティ「兼務グループ」を設置し，両端とも“●○”
   • 予約と２種の予約先：１件の予約に対して０以上の予約先が付く → 予約●●→○設備予約先／○スケジュール予約先
3. “○／●”の付与
   “必須”＝●，“任意”＝○ と読み替える。例：
   • 「ユーザは,…必ず所属」だからユーザ―グループ間はユーザ側●，グループ側○ではなく逆になることに注意（グループ０件でもユーザが居ない場合がある）。
4. 以上を全組み合わせに適用し，解答例の１１本に帰着する。

誤りやすいポイント

• 主務と兼務を一つのリレーションシップで済ませてしまい，多対多解消用エンティティを作らない。
• “ユーザは必ず主務グループに属する”という文からグループ側も必須と誤解する。実際は「上位のグループの中には,ユーザが一人も所属しないグループが存在」し得る。
• 「予約→設備予約先」「予約→スケジュール予約先」における“０件でも良い”という条件を見落とし“●”を付けてしまう。

FAQ

模範解答

解説

解答の論理構成

1. ロールを概念レベルで抽出
   • 原文「(3) ロールとは, GW 上の役割である。」より、独立したエンティティ。主キーは「ロールID」。名称属性として「ロール名」が必要。
2. ユーザとロールは多対多
   • 原文「ユーザには,必要に応じて一つ又は複数のロールを付与でき,一つのロールを複数のユーザに付与することもできる。」
   • 多対多は中間表で分解→「ロール付与先（ロールID, ユーザID）」を新設。両方が外部キー＆複合主キー。
3. ワークフローとの接続
   • 「決裁ルート」の各行は “申請ひな形 × ステップ” ごとに承認主体を示す。「承認者区分」でロール指定が来たとき、どのロールを示す識別子が必要。
   • よって「決裁ルート」に「承認ルートID」を追加し、外部キーとして「ロールID」を参照させる（模範解答と同じ）。
4. 主キー・外部キーの明示
   • ロール：主キーロールID
   • ロール付与先：主キーロールID, ユーザID（同時に両列が外部キー）。

誤りやすいポイント

• 承認者を示す列を「承認ユーザID」や「承認グループID」に統合しようとしてしまう
  → ロールは別概念なので別列が必要です。
• ロール付与先の主キーを単独列で作る
  → 多対多なので複合主キーにしないと、一人のユーザに同じロールが重複登録できます。
• 「承認ルートID」を新規テーブルに置くと勘違い
  → 追加先は既存の「決裁ルート」です。

FAQ

模範解答

解説

解答の論理構成

1. 承認履歴は差戻し後も “その都度新規登録”【問題文】により行が追加される。
2. 現設計では主キー候補が “申請ひな形番号, 申請連番, ステップ番号” のみなので、差戻し後に同じ “ステップ番号” 行を挿入すると主キーが重複＝不具合発生。
3. 同一申請内で承認行を連番管理している属性 “承認連番”【表1】は重複しないため、これを主キーに含めれば各履歴が一意になる。
4. 第3正規形の観点
   ・主キー以外の属性は “承認連番” に完全従属し、かつ推移従属も生じない。
5. よって修正後の関係スキーマは次のとおり。

承認（＜主キー＞ 申請ひな形番号, 申請連番, 承認連番,
     ＜外部キー＞ ステップ番号, 承認者ユーザID,
     承認処理結果, コメント, 承認日時）

誤りやすいポイント

• “承認連番” を外部キーと誤解し、主キーに含め忘れる。
• 第3正規形を意識せず “承認者ユーザID” を主キーに追加してしまう。
• “差戻し” ではなく “否認” 時に重複すると勘違いする。
• “承認連番” の採番単位（申請ひな形番号ごと・申請連番ごと）を読み飛ばす。

FAQ