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

• 【図2】より「緊急度コード、スケジュール影響度、重大度コード、ソフトウェア影響度、優先度コード、リソース投入度」。

• 【図4】がそのまま関数従属性を示す。
  • 「緊急度コード → スケジュール影響度」
  • 「重大度コード → ソフトウェア影響度」
  • 「{緊急度コード、重大度コード} → 優先度コード」
  • 「優先度コード → リソース投入度」

• どの属性集合が他の全属性を決定するかを確認。
• 「緊急度コード」と「重大度コード」を組みにすると「優先度コード」が決定でき、さらに「リソース投入度」も導出可能。したがって {緊急度コード、重大度コード} が候補キー。
• 片方のコードだけでは残り全属性を決定できない（スケジュール影響度またはソフトウェア影響度しか決まらない）。

• 候補キーが複合なので、その部分集合への従属を調べる。
• 「緊急度コード → スケジュール影響度」および「重大度コード → ソフトウェア影響度」は部分関数従属性。

• 候補キーから直接ではなく、中間属性を経由して決まる従属性。
• 「{緊急度コード、重大度コード} → 優先度コード → リソース投入度」が該当。

• 【図3】の意味の欄の記法で
  • 部分：　緊急度コード → スケジュール影響度 ／ 重大度コード → ソフトウェア影響度
  • 推移：　{緊急度コード、重大度コード} → 優先度コード ／ 優先度コード → リソース投入度

• 図4より「{緊急度コード、重大度コード} → 優先度コード → リソース投入度」が成り立つ。
• さらに「緊急度コード → スケジュール影響度」「重大度コード → ソフトウェア影響度」。
• {緊急度コード、重大度コード} だけで全属性を導出でき、これが主キー。

• 第1正規形は属性が単一値で満たす。
• 第2正規形：非キー属性は主キー全体に完全関数従属していなければならない。
  • スケジュール影響度 は 緊急度コード のみで決定
  • ソフトウェア影響度 は 重大度コード のみで決定
  → 部分関数従属があるため第2正規形を満たさない。
• よって現状は第1正規形。

• 部分関数従属を解消
  • 緊急度 と 重大度 の各リストを分離。
• 推移関数従属を解消
  • 優先度コード → リソース投入度 により「緊急度コード、重大度コード → 優先度コード → リソース投入度」がある。
  優先度コードを別表にし、リソース投入度をそこへ移す。
• 得られた四つの関係は上記スキーマであり、すべて第3正規形を満たす。

• 【問題文】「登録時のバグのステータスは『未着手』」
• 「ステータスが『解決済』のバグについて完了日を記録し、ステータスを『クローズ済』に更新」
• よってバグの状態管理には“ステータス”と“完了日”が不可欠 → (a)(b) に充当。

• 【問題文】「その対応がどの作業であるかを、対応区分として記録」
• 「対応区分ごとにメンバを1人割り当てて登録」
• 作業種別を示す“対応区分”と割り当てられた“メンバID”が要件 → (c)(d) に充当。

• 問題指示により“a,b は順不同”“c,d は順不同”なので、ペア内の並びは評価に影響しない。

• チーム階層：【問題文】(1)(2)
  「上位階層のチーム」が必須。
• メンバ兼任：【問題文】(3)
  「他の一つ又は複数のチームを兼任」⇒多対多。

• チーム関係に「上位チームID」がない。
• メンバ関係に単一列「兼任チームID」があるだけで複数値不可。

• ①階層構造を管理できず組織図が作れない。
• ②兼任が複数ある場合に属性の繰返しまたはNULL発生。

• チーム(チームID、チーム名、リーダメンバID, 上位チームID(FK→チーム.チームID))
• メンバ(メンバID、氏名、主担当チームID(FK→チーム.チームID))
• 兼任(メンバID(FK→メンバ.メンバID)、兼任チームID(FK→チーム.チームID)、PK=(メンバID, 兼任チームID))

• 【問題文】(5) で「成果物は、成果物 ID で一意に識別される」とある。したがって、成果物IDが主キーとなる基本表「成果物」を設ける。
• 同じ段落に「成果物名」「成果物の作成工程、作成担当チーム」が列挙されているため、属性として追加。
• 「作成工程」は表4「工程」、「作成担当チーム」は“チーム”と参照関係を持つため、それぞれ外部キー (FK) を設定。

• 【問題文】「バグの修正担当に割り当てられたメンバは…一つ又は複数の成果物の修正を行う」とあり，1 回の修正対応が複数成果物に影響します。
• 逆に、同一成果物が複数のバグ修正に関与する可能性もあるため、多対多 (n:m) 関係を解消する中間表が必須。
• 修正作業は“対応”で管理され、図2 に「対応（バグID, 対応連番、…）」が既に存在する。主キーは (バグID、対応連番)。
• よって、中間表「修正成果物」を作成し、主キーを (バグID、対応連番、成果物ID) として三つを全て外部キーにする。

• PK：成果物ID
• FK1：作成工程ID → 工程.工程ID
• FK2：作成担当チームID → チーム.チームID
  • 修正成果物
• PK：バグID、対応連番、成果物ID
• FK1：(バグID, 対応連番) → 対応.(バグID, 対応連番)
• FK2：成果物ID → 成果物.成果物ID

K3

工程名

順序番号

3

(工程〔順序番号 < 順序番号〕 (工程〔工程ID = 'K3'〕))

順序番号

3

バグ〔作り込み工程ID = 工程ID〕

作り込み工程ID

作り込み工程ID

• 検索内容：「バグが発見された工程」と「発見すべき工程」が同一。
• 判断基準：バグのタプルで「発見工程 ID = 発見すべき工程 ID」。
• 【表３】より
  • B1：K5＝K5 → 該当
  • B4：K6＝K6 → 該当
  • B2, B3, B5 は NULL もしくは不一致 → 非該当
• 結果：B1, B4

• 検索内容：「成果物の修正が必要なバグ種別」が設定されたバグ。
• 判断基準：
  • 【問題文】(4)「成果物の修正が必要なバグ種別が設定されたバグ」
  • 【表５】で「修正有無」が「あり」のバグ種別 ID は S1, S2, S4, S6。
• 【表３】より
  • B1：S2 → あり
  • B4：S4 → あり
  • B5：S1 → あり
  • B2：NULL、B3：S3（なし） → 除外
• 結果：B1, B4, B5

• 関係代数式読解
  • 工程〔工程ID = 'K3'〕で得たタプルの「順序番号」は 3。
  • そのサブクエリ外側の「工程〔順序番号 < 順序番号〕」は 3 より小さい工程 → 順序番号 1, 2（K1, K2）。
  • バグ〔作り込み工程ID = 工程ID〕で「作り込み工程 ID」が K1 または K2 のバグを抽出。
• 【表３】より
  • B1：作り込み工程 ID = K2 → 該当
  • B5：作り込み工程 ID = K1 → 該当
  • B2, B3（NULL）、B4（K3） → 非該当
• 結果：B1, B5