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

解答の導き方

1. 属性の確認
   図2に「優先度（緊急度コード、 スケジュール影響度、 重大度コード、 ソフトウェア影響度、 優先度コード、 リソース投入度）」とあるため、関係の属性は次の6つです：
   緊急度コード、スケジュール影響度、重大度コード、ソフトウェア影響度、優先度コード、リソース投入度。
2. 図4から読み取れる関数従属性（FD）の抽出
   図4の矢印は属性間の関数従属性を示しているため、図4から次の4つのFDが読み取れます（矢印の向きに注意して読み取ること）：

• 緊急度コード → スケジュール影響度
• 重大度コード → ソフトウェア影響度
• ｛緊急度コード、重大度コード｝ → 優先度コード
• 優先度コード → リソース投入度

1. 候補キーの判定（段階的に）
   候補キーは「その集合から全属性が決定でき、かつ最小である集合」です。図4のFDを使って、主要候補を検証します。

• ｛緊急度コード、重大度コード｝ の閉包を求める（つまりこの集合から導ける属性を順に追加する）と：
  1. 初期：X = ｛緊急度コード、重大度コード｝
  2. 緊急度コード → スケジュール影響度 よりXに スケジュール影響度 を追加 → X = ｛緊急度コード、重大度コード、スケジュール影響度｝
  3. 重大度コード → ソフトウェア影響度 よりXに ソフトウェア影響度 を追加 → X = ｛緊急度コード、重大度コード、スケジュール影響度、ソフトウェア影響度｝
  4. ｛緊急度コード、重大度コード｝ → 優先度コード よりXに 優先度コード を追加 → Xに 優先度コードを追加
  5. 優先度コード → リソース投入度 よりXに リソース投入度 を追加
  6. 最終的にXは関係の全属性を含むため、｛緊急度コード、重大度コード｝ はスーパーキーであり、かつ最小性を以下で確認します。
• 最小性の確認（部分集合がスーパーキーでないこと）
  • 緊急度コード 単独の閉包は 緊急度コード と スケジュール影響度 にとどまり、全属性にならない。
  • 重大度コード 単独の閉包は 重大度コード と ソフトウェア影響度 にとどまり、全属性にならない。
  • 優先度コード 単独の閉包は 優先度コード と リソース投入度 にとどまり、全属性にならない。
  • 優先度コード を含む他の組合せ（例：｛優先度コード、緊急度コード｝）も、図4に「優先度コード → 重大度コード」のような逆方向のFDが示されていないため、重大度コードを導けず全属性にならない。図4では「優先度コード」から「緊急度コード／重大度コード」へ向かう矢印は示されていませんので、優先度コード単独や優先度コードを含む組合せがキーになることはありません。

1. 部分関数従属性・推移的関数従属性の判定と具体例（図3表記法に従う）

• 部分関数従属性の定義：複合候補キーの一部が非キー属性を決定する場合に「部分関数従属性がある」と言います。今回の候補キーは複合キー ｛緊急度コード、重大度コード｝ なので、その一部が非キー属性を決定しているかを調べます。図4により次が成り立つため、部分関数従属性は存在します。
  • 緊急度コード → スケジュール影響度
  • 重大度コード → ソフトウェア影響度
  図3の表記法に従うとそれぞれ「A → B」型で表せます（上記のとおり）。
• 推移的関数従属性の定義：候補キーが非キー属性を決定し、その非キー属性がさらに別の非キー属性を決定するような連鎖がある場合に「推移的関数従属性がある」と言います。図4から次の連鎖が読み取れるため、推移的関数従属性は存在します。
  • ｛緊急度コード、重大度コード｝ → 優先度コード → リソース投入度

誤りやすいポイント

• 「コード」という属性名だから必ず候補キーだと誤判断する。属性名だけで判定せず、図や与えられた関数従属性に基づいて決定可能性を確認すること。
• 属性説明（列の説明文）だけでFDを決めつけない。FDは図4の矢印や問題文で明示された関係から読み取るのが正しい判断基準です。
• 部分関数従属性と推移的関数従属性を混同する。部分従属性は「複合キーの一部 → 非キー」、推移的は「候補キー → 非キーA → 非キーB」のような連鎖を探すこと。
• 図3の表記法に従って書き表すのを忘れると減点につながる。出力形式は問題の指定に合わせること。

FAQ

解答の論理構成

1. 関係 “優先度” の候補キー決定
   • 図4より「{緊急度コード、重大度コード} → 優先度コード → リソース投入度」が成り立つ。
   • さらに「緊急度コード → スケジュール影響度」「重大度コード → ソフトウェア影響度」。
   • {緊急度コード、重大度コード} だけで全属性を導出でき、これが主キー。
2. 正規形の判定
   • 第1正規形は属性が単一値で満たす。
   • 第2正規形：非キー属性は主キー全体に完全関数従属していなければならない。
     • スケジュール影響度 は 緊急度コード のみで決定
     • ソフトウェア影響度 は 重大度コード のみで決定
     → 部分関数従属があるため第2正規形を満たさない。
   • よって現状は第1正規形。
3. 第3正規形への分解
   • 部分関数従属を解消
     • 緊急度 と 重大度 の各リストを分離。
   • 推移関数従属を解消
     • 優先度コード → リソース投入度 により「緊急度コード、重大度コード → 優先度コード → リソース投入度」がある。
     優先度コードを別表にし、リソース投入度をそこへ移す。
   • 得られた四つの関係は上記スキーマであり、すべて第3正規形を満たす。

誤りやすいポイント

• 「優先度コード」を主キーと誤認し、第2正規形と判断してしまう。
• 先に優先度コード表を切り出しただけで満足し、部分関数従属の解消を忘れる。
• 分解後の外部キーを明記しないため減点される。

FAQ

解答の論理構成

1. バグと工程
   • バグには「発見工程ID」「作り込み工程ID」「発見すべき工程ID」の3つの外部キー候補があります【表2】。
   • いずれも「工程ID」を参照するため、エンティティタイプ“工程”と“バグ”の間にリレーションシップを引きます。役割（発見・作り込み・発見すべき）が異なるので、同一対のエンティティに3本の線を描きます。
2. バグとバグ（自己参照）
   • 「同一原因バグID」は「既知のバグと同一原因のバグの場合は、その既知のバグを記録」【表1バグの原因調査】と定義されています。
   • これは“バグ”が別の“バグ”を指す自己参照関係なので、バグの箱から戻るループ線で表します。
3. バグとバグ種別
   • 「バグ種別ID」で“バグ種別”を参照するため、両者を結ぶリレーションシップが必要です【表2】。
4. バグと対応
   • 「バグID」と「対応連番号」の組で“対応”の主キーを構成する【表2】ので、1つのバグに複数の対応がぶら下がる関係（1対多）となります。
5. バグとメンバ（発見者）
   • 「発見メンバID」が「バグを発見したメンバ」【表1バグの登録】を示すため、発見者用のリレーションシップを引きます。
6. 対応とメンバ（担当者）
   • 「対応区分ごとにメンバを1人割り当てて登録」【表1バグへの対応】とあるので、対応担当者用のリレーションシップを追加します。
7. 対応と調査・修正・確認
   • “調査”、“修正”、“確認”は対応の区分ごとに発生するサブタイプです。Y字に分かれる線で1:N関係（1つの対応は調査・修正・確認のいずれか1つ）を示します。

誤りやすいポイント

• 「同一原因バグID」を見落とし、自己参照リレーションシップを描かない。
• 工程が3役（発見・作り込み・発見すべき）あるのに1本しか線を引かない。役割数だけ線が要ることに注意。
• 発見メンバと対応担当メンバの区別をつけず、メンバとバグ／対応を1本の線で済ませてしまう。
• 調査・修正・確認が“対応”のサブタイプであることを忘れ、独立エンティティとして描く。

FAQ

解答の論理構成

1. バグ表に必要な属性の洗い出し
   • 【問題文】「登録時のバグのステータスは『未着手』」
   • 「ステータスが『解決済』のバグについて完了日を記録し、ステータスを『クローズ済』に更新」
   • よってバグの状態管理には“ステータス”と“完了日”が不可欠 → (a)(b) に充当。
2. 対応表に必要な属性の洗い出し
   • 【問題文】「その対応がどの作業であるかを、対応区分として記録」
   • 「対応区分ごとにメンバを1人割り当てて登録」
   • 作業種別を示す“対応区分”と割り当てられた“メンバID”が要件 → (c)(d) に充当。
3. 順不同指定の確認
   • 問題指示により“a,bは順不同”“c,dは順不同”なので、ペア内の並びは評価に影響しない。

誤りやすいポイント

• “完了日”を対応側に置いてしまうミス。完了日はバグ全体のライフサイクル終了を示すためバグ表に属する。
• “対応メンバID”を氏名で設計する誤り。IDでないと他表（メンバ）との参照整合性が取れない。
• “対応区分”と“ステータス”を混同するミス。前者は作業種別、後者はバグ解決プロセス全体の状態。

FAQ

解答の導き方

1. 要件から抜き出す
   • 「チームは、チームIDで一意に識別され、チーム名、リーダを任されたメンバ、上位階層のチームが定められている。」とあるため、チームは同じチームの別レコードを参照して「上位階層」を表現できる属性が必要です。図2のチームには 上位チームIDがないので、この要件を満たしていません。
   • 「メンバは、メンバIDで一意に識別され、所属するチームが定められている。メンバは、主担当として必ず一つのチームに所属するほか、他の一つ又は複数のチームを兼任する場合もある。」とあるため、メンバとチーム間に「主担当（1つ）」と「兼任（0～複数）」の関係があることが分かります。図2のメンバに単一の 兼任チームID属性しかないと複数兼任を表せず、関係モデルとして不適です。
2. 不具合の特定（設計上の論理）
   • 要件が「上位階層のチームが定められている」と明示しているのにチーム表に上位を示す属性がない → 上位チームを管理できない。
   • 要件が「他の一つ又は複数のチームを兼任する場合もある」と明示しているのにメンバ表が単一の兼任チームIDで表現している → 複数兼任を管理できない。
3. 解消方法の検討と決定
   • 「上位階層のチーム」は同じチーム表内の別の行を参照する自己参照外部キー（上位チームID）で表現します。別表として分離すると同一のチーム情報が分散して更新整合性を損なうため、自己参照が適切です。
   • 「兼任」はメンバとチームの多対多関係なので、中間表（兼任）で表現します。中間表は (メンバID, 兼任チームID) の複合主キーを持ち、両者を外部キーで参照します。
   • さらに、チームのリーダはメンバの存在を参照するため、リーダメンバIDを メンバ.メンバIDへの外部キーとします。主担当は必須なので 主担当チームIDは NOT NULLとしてチームを参照します。
4. 最終的な解答（簡潔表示）
   不具合：① チームの上位階層のチームを管理できない。
   不具合：② メンバが兼任しているチームを複数管理できない。
   関係スキーマ（修正版）
   • チーム(チームID PK, チーム名, リーダメンバID FK→メンバ.メンバID, 上位チームID FK→チーム.チームID)
     • 備考：上位チームIDはトップ階層の場合NULLを許す。リーダメンバIDは既存のメンバを参照する外部キーとする。
   • メンバ(メンバID PK, 氏名, 主担当チームID FK→チーム.チームID NOT NULL)
     • 備考：要件により主担当チームIDは必須とする。
   • 兼任(メンバID, 兼任チームID)
     • 主キー：PK = (メンバID, 兼任チームID)
     • 外部キー：メンバID FK→メンバ.メンバID、兼任チームID FK→チーム.チームID

誤りやすいポイント

• 兼任をメンバ表の単一属性（兼任チームID）で表すと第一正規形に反し、複数値を扱えない。
• 上位チームを別表に分けるとチーム情報が分散し更新・削除の整合性が難しくなる（自己参照が適切）。
• リーダメンバIDを外部キーにし忘れると、存在しないメンバをリーダに指せて整合性が崩れる。
• 主担当チームIDをNULL許可にすると「必ず一つ」の要件を満たさない。
• 兼任の中間表で主キーを設定しないと同一組合せの重複登録を防げない。

FAQ

解答の論理構成

1. 成果物を表すエンティティの必要性
   • 【問題文】(5) で「成果物は、成果物IDで一意に識別される」とある。したがって、成果物IDが主キーとなる基本表「成果物」を設ける。
   • 同じ段落に「成果物名」「成果物の作成工程、作成担当チーム」が列挙されているため、属性として追加。
   • 「作成工程」は表4「工程」、「作成担当チーム」は“チーム”と参照関係を持つため、それぞれ外部キー (FK) を設定。
2. バグ修正と成果物の多対多関係
   • 【問題文】「バグの修正担当に割り当てられたメンバは…一つ又は複数の成果物の修正を行う」とあり、1回の修正対応が複数成果物に影響します。
   • 逆に、同一成果物が複数のバグ修正に関与する可能性もあるため、多対多 (n:m) 関係を解消する中間表が必須。
   • 修正作業は“対応”で管理され、図2に「対応（バグID, 対応連番、…）」が既に存在する。主キーは (バグID、対応連番)。
   • よって、中間表「修正成果物」を作成し、主キーを (バグID、対応連番、成果物ID) として三つを全て外部キーにする。
3. 主キー・外部キーの整理
   • 成果物
   • PK：成果物ID
   • FK1：作成工程ID → 工程.工程ID
   • FK2：作成担当チームID → チーム.チームID
     • 修正成果物
   • PK：バグID、対応連番、成果物ID
   • FK1：(バグID, 対応連番) → 対応.(バグID, 対応連番)
   • FK2：成果物ID → 成果物.成果物ID

誤りやすいポイント

• 成果物の属性を“対応”や“バグ”に直接追加してしまい、第3正規形を崩す。
• 「修正成果物」の主キーに 対応連番 を含め忘れ、1バグ1成果物しか登録できない設計にしてしまう。
• 「作成工程ID」をNULL可と考えてしまうが、【問題文】に「作成工程」が必ず定められるとあるため非NULLとする。

FAQ

解答の論理構成

1. 項番②の条件確認
   【問題文・表7】
   “バグが発見された工程と、そのバグを本来発見すべきと考えられる工程が同一のバグ”
   → 同一関係 “バグ” に含まれる “発見工程ID”、“発見すべき工程ID” を比較。
   → 表6「選択」の書式：R〔X = Y〕
   したがって
   e：バグ〔発見工程ID = 発見すべき工程ID〕
2. 射影部は例①から踏襲
   ・選択演算の直後に 〔バグID〕 を付けるので、演算対象となる関係名は「バグ」。
   f：バグ
3. 項番③の条件確認
   【問題文】
   “品質分析の対象とするバグは、成果物の修正が必要なバグ種別が設定されたバグである。”
   ・“成果物の修正が必要” ⇒ 表2 “修正有無” が “あり”
   ・“バグ種別が設定されたバグ” ⇒ “バグ種別ID” により “バグ” と “バグ種別” を結合する必要がある。
4. 関係代数演算の組み立て
   (1) 結合条件
   表6「結合」：R〔RA = SA〕S
   RA：バグ種別ID（バグ側）
   SA：バグ種別ID（バグ種別側）
   よって
   g：バグ種別ID
   (2) 結合する相手の関係
   h：バグ種別
   (3) 選択条件
   “修正有無 = ‘あり’”
   i：修正有無
   j：あり
5. 全体式（括弧配置の説明）
   ① f（バグ）とh（バグ種別）をg（バグ種別ID）で結合
   ② その結果に対しi = j（修正有無 = ‘あり’）で選択
   ③ 射影で 〔バグID〕 を取り出す
   表7が示す多重括弧はこの順序を表している。

誤りやすいポイント

• “同一のバグ” を別関係との結合と誤読し、不要な 工程 との結合を書いてしまう。
• “修正有無” を “なし” と逆に書くミス。設問は “修正が必要” と明示している。
• 選択と結合の括弧位置を省略し、演算の優先順位で減点される。

FAQ

解答の論理構成

1. 表4よりK3の 工程名 は「プログラム設計」、順序番号 は3である。
2. 式 (工程〔順序番号 < 順序番号〕 (工程〔工程ID = 'K3'〕)) は、自己結合を用いて 順序番号 が3より小さい工程を抽出している。よって「基本設計（K1）」と「詳細設計（K2）」が対象。
3. バグ〔作り込み工程ID = 工程ID〕 との結合により、作り込み工程IDがこれら前工程を示すバグのみ残る。
4. したがってkは「プログラム設計工程よりも前の工程・基本設計又は詳細設計工程」と説明できる。
5. 作り込み工程IDは表2で「バグの原因を作り込んだと考えられる工程」を示すため、lは「原因を作り込んだ」となる。

誤りやすいポイント

• 順序番号 < 順序番号 を単なる誤記と勘違いし、比較元が同一タプルだと解釈してしまう。
• 作り込み工程IDを「修正工程」と誤読し、バグ修正時点の工程と混同する。
• 「前工程」と聞いて「テスト工程より前」など別の基準を想像してしまう。

FAQ

解答の論理構成

1. 項番②（ア）
   • 検索内容：「バグが発見された工程」と「発見すべき工程」が同一。
   • 判断基準：バグのタプルで「発見工程ID = 発見すべき工程ID」。
   • 【表3】より
     • B1：K5＝K5 → 該当
     • B4：K6＝K6 → 該当
     • B2, B3, B5はNULLもしくは不一致 → 非該当
   • 結果：B1, B4
2. 項番③（イ）
   • 検索内容：「成果物の修正が必要なバグ種別」が設定されたバグ。
   • 判断基準：
     • 【問題文】(4)「成果物の修正が必要なバグ種別が設定されたバグ」
     • 【表5】で「修正有無」が「あり」のバグ種別IDはS1, S2, S4, S6。
   • 【表3】より
     • B1：S2 → あり
     • B4：S4 → あり
     • B5：S1 → あり
     • B2：NULL、B3：S3（なし） → 除外
   • 結果：B1, B4, B5
3. 項番④（ウ）
   • 関係代数式読解
     • 工程〔工程ID = 'K3'〕で得たタプルの「順序番号」は3。
     • そのサブクエリ外側の「工程〔順序番号 < 順序番号〕」は3より小さい工程 → 順序番号1, 2（K1, K2）。
     • バグ〔作り込み工程ID = 工程ID〕で「作り込み工程ID」がK1またはK2のバグを抽出。
   • 【表3】より
     • B1：作り込み工程ID = K2 → 該当
     • B5：作り込み工程ID = K1 → 該当
     • B2, B3（NULL）、B4（K3） → 非該当
   • 結果：B1, B5

誤りやすいポイント

• NULL比較は常に偽になるため「K5 = NULL」は成立しないことを忘れがちです。
• 「修正有無」は“バグ”ではなく“バグ種別”に属する属性であり、直接バグ表を見ても判断できません。
• 順序番号の大小比較を読み違え、「≤」と誤解してK3を含めてしまうミスが頻発します。

FAQ