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

ポイント整理

1. 候補キー（最小キー）の決定
2. 部分関数従属性の有無と具体例
3. 推移的関数従属性の有無と具体例

1. 関係“優先度”の構成

2. 候補キーの決定

• 関係内のすべての属性を一意に決定できる
• 最小性（不要な属性を含まない）

• 緊急度コードだけでは，ソフトウェア影響度や優先度コード，リソース投入度を決定できません。
• 重大度コードだけでも同様です。
• {緊急度コード, 重大度コード} の組合せであれば，図4の c／a／b から，スケジュール影響度・ソフトウェア影響度・優先度コードが決まり，さらに優先度コード→リソース投入度（d）によって関係内の全属性を決定できます。
• また，この組合せを構成要素のいずれか一方だけに減らすと決定能力を失うため，最小性も満たします。

3. 部分関数従属性の有無と具体例

• 緊急度コード → スケジュール影響度
• 重大度コード → ソフトウェア影響度

4. 推移的関数従属性の有無と具体例

1. {緊急度コード, 重大度コード} → 優先度コード
2. 優先度コード → リソース投入度

5. 受験上の留意点

• 「候補キー」には必ず最小性が求められることを忘れない。
• 部分関数従属性は第二正規形(2NF)違反，推移的関数従属性は第三正規形(3NF)違反の典型例。
• 図4の矢印が示す関数従属性をもれなく読み取る練習が重要。
• 「優先度コード」だけで候補キーと誤解しやすいが，それ単独では「スケジュール影響度」「ソフトウェア影響度」を決定できない点を確認する。

1. キーワード・論点整理

2. なぜ「第１正規形」止まりなのか

1. 【問題文】図４より，関係“優先度”には上表の４本の関数従属性が成り立つことが読み取れる。
2. 主キー候補は {緊急度コード, 重大度コード} であり，これは複合キーである。
3. 非キー属性のうち
   • スケジュール影響度 は “緊急度コード → スケジュール影響度” によって 主キーの一部(緊急度コード)にのみ依存。
   • ソフトウェア影響度 は “重大度コード → ソフトウェア影響度” によって 主キーの一部(重大度コード)にのみ依存。
   ⇒ どちらも「部分関数従属」に該当し，第２正規形を満たさない。
4. よって，「第１正規形までは満たすが，第２正規形に到達していない」と結論付けられる。

3. 第３正規形への分解

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

5. 試験対策まとめ

1. 正規化判定の手順
   ① 主キー候補を列挙（複合か単一かを必ずメモ）。
   ② 全ての関数従属性を書き出し，部分従属 → 推移従属の順にチェック。
2. 図による関数従属性の読み取り
   ・集合で囲われた箱は「複数属性の組」を示す。
   ・矢印は必ず 片方向。逆方向が成り立つとは限らない。
3. 分割パターンの暗記
   ・「部分従属を切る」→ 主キーの一部＋従属属性で別関係を作成
   ・「推移従属を切る」→ 従属先の非キー属性を主キーとする関係を作成
4. 表示のルール
   ・試験解答では主キー属性に下線（あるいはタグ）を付け，外部キーは（外）など注記して明示する。
5. 典型的なひっかけ
   ・「主キーが単一に見える名前のコードがある」＝必ずしも主キーとは限らない。FD（関数従属性）を確認して判断する。

核心となるキーワード・論点整理

• エンティティタイプ：
  バグ、メンバ、対応、調査、修正、確認、工程、バグ種別
• リレーションシップのパターン：
  • 発見（バグ ← メンバ）
  • 発見工程／作り込み工程／発見すべき工程（バグ ←→ 工程）
  • 属する（バグ ←→ バグ種別）
  • 実施する／担当する（バグ ←→ 対応 ←→ メンバ）
  • 上位‐下位関係（対応―〈ISA〉→ 調査・修正・確認）

なぜこのリレーションシップになるか――設問文の引用と対応

1. バグ ← 発見者 ← メンバ
   「バグを発見したメンバは、バグの発見日、発見した工程、発見したメンバ、発見内容を登録する。登録時のバグのステータスは『未着手』である。」
   → １人のメンバは複数のバグを発見でき、１件のバグは必ず１人の発見者（メンバ）を持つ。
2. バグ ← 発見工程・作り込み工程・発見すべき工程 ←→ 工程
   問題文でバグ属性として「発見工程ID」「作り込み工程ID」「発見すべき工程ID」が定義されている。
   → 同じ「工程」エンティティに対して、異なる役割（発見・作り込み・本来発見すべき）で３本のリレーションシップを張る。
3. バグ ← 属する ←→ バグ種別
   「バグ種別とは、バグの原因を分類するための区分であり、バグ種別名及び成果物の修正有無が定められている。」
   → １件のバグは必ず１つのバグ種別を記録し、１つのバグ種別は多数のバグを分類する。
4. バグ ← 実施する ←→ 対応 ← 担当 ←→ メンバ
   「バグへの対応…対応区分ごとにメンバを1人割り当てて登録する。」
   「各対応を開始したら…開始日時を、終了したら終了日時を、それぞれ更新する。」
   → バグと対応は１対多、対応とメンバも１対多の関係。
5. 対応 ―〈ISA〉→ 調査／修正／確認
   「バグへの対応…各作業を総称して対応と呼び、その対応がどの作業であるかを、対応区分として記録する。」
   「バグの原因調査…」「バグの修正…」「バグの修正内容の確認…」
   → 対応は上位エンティティ、調査・修正・確認はサブタイプ（特殊化）として表現。

関係（リレーションシップ）一覧

※「対　応」と「調査・修正・確認」の関係は，特殊化（ISA）として線を引きます。

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

1. 工程との３重リレーションシップの抜け
   「発見工程ID」「作り込み工程ID」「発見すべき工程ID」の３つすべてを忘れずに線を引く。
2. ISA（一般化/特殊化）の見落とし
   対応と調査／修正／確認は単なる１対多ではなく，特殊化の関係になる。
3. 役割名付きリレーションシップの認識不足
   同一エンティティ間で異なる役割がある場合は、線を役割の数だけ引く。

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

• エンティティと役割：属性名やリレーションシップ名から「どのエンティティと結びつくか」を明確に読む。
• ER モデルの表現：
  • 多重度や役割名は省略可でも，「異なる役割での複数線」を忘れない。
  • 特殊化（ISA）は，上位‐下位関係と看做す。
• 本文から図への反映：問題文中の “～ID” 属性が示す対象先と役割名を正確に把握して関係線を引く。

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

• （a），（b）は関係「バグ」の属性
  • （a）：バグの現在の状況を示す「ステータス」
  • （b）：クローズ時に記録する「完了日」
• （c），（d）は関係「対応」の属性
  • （c）：どの作業（原因調査・修正・確認）かを示す「対応区分」
  • （d）：当該対応を担当する「対応メンバID」

なぜその解答になるのか

（a）ステータス

「登録時のバグのステータスは『未着手』である。」
「ステータスを『調査中』に更新する。」
「ステータスを『修正中』に更新する。」 …

（b）完了日

「完了日を記録し，ステータスを『クローズ済』に更新し，一連のバグ解決プロセスを完了する。」

（c）対応区分

「その対応がどの作業であるかを，対応区分として記録する。」

（d）対応メンバID

詳細：該当リレーションの再掲

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

1. 「完了日」と「登録日」「開始日時」「終了日時」を混同しやすい
   • 「登録時の発見日」「対応開始日時」「対応終了日時」など多数の日時項目があるため，最終クローズの「完了日」を見落としがちです。
2. 「対応区分」と「対応連番」を取り違える
   • 図２には既に「対応連番」があるので，新たに追加するのは「対応区分」である点を正確に区別しましょう。
3. 属性名をプロセス記述に即して付ける
   • 問題文中に「〜を記録する」「〜を決定する」といった表現でプロセスが定義されている箇所をそのまま属性名に転用すると正解しやすくなります。

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

• バグ解決プロセスの各ステップで何を「登録」「更新」するかを整理する習慣をつける。
• 概念データモデル（E-R図）からリレーションスキーマへの移行では，実業務で使用する用語をそのまま属性名に用いること。
• 複数の日時属性がある場合，プロセスの開始・終了・クローズそれぞれの目的を正しく把握しておく。
• スキーマ設計では，「キー制約」「外部キー制約」とともに，必要な非キー属性が抜けていないかをチェックリスト化すると漏れを防げる。

1️⃣　キーワード・論点の整理

2️⃣　解答になるまでの論理的プロセス

(1) 不具合①：チームの階層が表現できない

チーム(チームID, チーム名, リーダメンバID)

(2) 不具合②：メンバの兼任が複数保持できない

メンバ(メンバID, 氏名, 担当チームID, 兼任チームID)

1. 兼任が 2 件以上→列を増やす？ ⇒ 可変長列はNG
2. 兼任の無い行→NULL が多発

(3) 改善後スキーマ

3️⃣　受験者が陥りやすいワナ

4️⃣　試験対策まとめ

• 自己参照外部キーで組織階層や部品構成ツリーを表すのは頻出。
• 「複数可」の要求が出たら “別リレーション” を作るのが鉄則（第１正規形）。
• 橋渡し表（交差表）の主キーは「両外部キーの組合せ」。
• 問題文の要求仕様を必ず属性にマッピングする習慣を持つ。
• 正規化は「NULL 値が大量に出ないか？」「列を増減せずに拡張できるか？」でチェック。

1. キーワード・論点の整理

• 指摘事項③
  「成果物と, バグの修正を行ったときに修正した成果物の情報を管理する関係スキーマが設計されていない」
• 必要なリレーション
  1. 成果物を管理するリレーション（主キー, 属性, 外部キー）
  2. バグの修正対応と成果物の関係を管理するリレーション

2. なぜこの設計になるのか

（1）成果物リレーションの設計根拠

「成果物は, 成果物ID で一意に識別される。成果物には, 成果物名, 成果物の作成工程, 作成担当チームが記される。」

• 成果物ID：主キー
• 作成工程ID：工程リレーションの外部キー
• 作成担当チームID：チームリレーションの外部キー

（2）修正成果物リレーションの設計根拠

「バグの修正担当に割り当てられたメンバは，…一つ又は複数の成果物の修正を行う。修正後，修正内容と，修正した成果物を記録し…」

• １件の「バグの修正」（バグID＋対応連番） で複数の成果物を修正する可能性がある → 多対多を中間リレーションで実現
• 修正対応を特定するキー：バグID＋対応連番
• 修正対象の成果物を示す：成果物ID

3. リレーションスキーマ例

• 「●」は主キー属性を示す
• 外部キーは参照先リレーション(参照先属性)を矢印で表記

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

• 既存の「修正」リレーションは「修正内容」を管理するためのもので、「どの成果物を修正したか」を管理していない点
• １つの修正対応で複数成果物を扱えるため、多対多を単純に「修正」リレーションに成果物IDを列挙するような設計は不適切
• 中間リレーション（修正成果物）で必ず複合主キーを設定し、外部キー制約を正しく張る

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

• 「…が記される」「…を記録する」という文言はリレーションの属性設計要件
• 多対多の関係は中間テーブル（中間リレーション）で解消する
• リレーションスキーマには必ず主キーと外部キーを明示する
• 概念データモデル（ER図）と論理設計（リレーションスキーマ）の対応関係を意識すること
• 問題文の「指摘事項」をもれなく拾い、設計漏れがないように注意する

キーワードの整理

解答が導かれる論理的な理由

項番②の選択条件 (e)

「バグが発見された工程と、そのバグを未発見すべきと考えられる工程が同一のバグについて、そのバグIDの値を求める。」

項番③の結合と選択条件 (f, g, h, i, j)

「品質分析の対象とするバグは、成果物の修正が必要なバグ種別が設定されたバグである。」

( ( バグ ⨝〔バグ.バグ種別ID = バグ種別.バグ種別ID〕 バグ種別 )
 〔修正有無 = 'あり'〕 )〔バグID〕

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

1. 属性名の一致を忘れない
   「発見工程ID」「発見すべき工程ID」など似た語が多いため，どちらの属性同士を比較しているか要注意です。
2. 結合の方向
   結合演算⨝は演算子自体に順序はありませんが，どの属性をキーに結合するか明示する必要があります。
3. 選択と射影の順序
   ・条件を絞る選択演算は，結合後でも結合前でも可能な場合がありますが，射影演算（〔バグID〕など）は最後に行い，余計な属性を除去します。
4. 定数のクオート
   文字列定数（'あり'など）はシングルクオートで囲むことを忘れずに。

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

• 関係代数の基本演算（選択〈σ〉，射影〈π〉，結合〈⨝〉）の記法を正確に使い分ける。
• 選択は R〔属性 比較演算子 定数／他属性〕，射影は R〔属性リスト〕，結合は R ⨝〔R.属性 = S.属性〕 S の形式。
• ER図（概念データモデル）からリレーションスキーマを作る際は，主キー・外部キーを必ず定義し，リレーション間の関連が一目で分かるようにする。
• 「品質分析の対象となるバグ」といった業務的要件を正しく読み取り，必要な結合・選択条件を抜けなく設計する練習を積む。

1. 解答のキーワード・論点整理

• 対象工程の特定
  関係代数式中の「工程〔工程ID = 'K3'〕」は，表4より K3＝プログラム設計工程 を指す。
• 前工程の抽出
  「工程〔順序番号 < 順序番号〕 (工程〔工程ID = 'K3'〕)」は，プログラム設計（順序番号3）より順序番号が小さい工程，すなわち 順序番号1,2の工程（基本設計/詳細設計） を選択する。
• バグとの結合
  「バグ〔作り込み工程ID = 工程ID〕」と結合することで，そのバグの作り込み工程IDが前工程に該当するものを抽出する。
• 「作り込み工程」の意味
  問題文より，「作り込み工程ID」は「バグの原因を作り込んだと考えられる工程」を示す。

2. 解答に至る論理的説明

2.1 関係代数式の再掲

(バグ〔作り込み工程ID = 工程ID〕 ⨝
 (工程〔順序番号 < 順序番号〕 (工程〔工程ID = 'K3'〕)))
 〔バグID〕

2.2 各部分の意味

1. 工程〔工程ID = 'K3'〕
   表4より

   工程ID	工程名	順序番号
   K3	プログラム設計	3
   → プログラム設計工程を取り出す

2. 工程〔順序番号 < 順序番号〕 (工程〔工程ID = 'K3'〕)
   「順序番号3より小さい」工程を選択

   工程ID	工程名	順序番号
   K1	基本設計	1
   K2	詳細設計	2

3. バグ〔作り込み工程ID = 工程ID〕
   バグの「作り込み工程ID」と工程の「工程ID」が一致するタプルを結合
   → 作り込み工程が基本設計／詳細設計であるバグを取得
4. 〔バグID〕（射影）
   最後にバグIDだけを取り出す

3. なぜ「k=基本設計又は詳細設計工程」「l=原因を作り込んだ」か

• k：基本設計又は詳細設計工程
  「プログラム設計工程よりも前の工程」を具体名で表現すると，表4の順序番号から 基本設計（1）と 詳細設計（2）です。
• l：原因を作り込んだ
  問題文の「作り込み工程ID」は「バグの原因を作り込んだと考えられる工程」を示すため，具体的に「原因を作り込んだ」と記述します。

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

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

1. 関係代数の基本操作
   • 射影（π），選択（σ），結合（⋈）の使い方
2. 表記と実データの対応
   • 「工程ID = 'K3'」→ 実際の工程名・順序番号を表4から即座に引けるように
3. 条件句の読み取り
   • 「順序番号 < 順序番号」の左右どちらがどちらを指すか，カッコのネストも含めて文脈で正確に理解
4. 設問語句の具体化
   • k, lのように設問文中の抜けを埋める場合は，必ず「○○工程」「○○と考えられる」など具体的名称＋意味をセットで20字以内／15字以内にまとめる
5. 演算結果の意図
   • 最終的に何を検索しているのか（例：前工程で原因が作り込まれたバグ）を言語化できるようにすること

模範解答の核心となるキーワードや論点

1. 検索②
   • キーワード：「発見された工程」と「発見すべき工程」が同一
   • 条件：
     • 発見工程ID = 発見すべき工程ID
2. 検索③
   • キーワード：「成果物の修正が必要なバグ種別が設定されたバグ」
   • 条件：
     • バグ種別ID とバグ種別表の 修正有無 = ‘あり’ を結合・抽出
3. 検索④
   • キーワード：「作り込み工程ID が，ある工程より順序番号の小さい工程ID と一致するバグ」
   • 条件：
     1. 工程表から基準工程 ‘K3’ より順序番号が小さい工程ID を取得
     2. バグ表の 作り込み工程ID と①の工程ID が一致

解答の理由

データの参照

② 発見工程と発見すべき工程が同一のバグ

発見工程ID = 発見すべき工程ID

③ 品質分析対象のバグ（成果物の修正が必要なバグ種別）

1. バグ表とバグ種別表を，バグ種別ID で結合
2. バグ種別表の「修正有無 = ‘あり’」を条件に抽出

• S1, S2, S4, S6 は「あり」
• S3, S5, S7 は「なし」

• B1 (S2 → あり)
• B4 (S4 → あり)
• B5 (S1 → あり)

④ 作り込み工程ID が基準工程より前の工程と同じバグ

(バグ〔作り込み工程ID = 工程ID〕 ⨝
  (工程〔順序番号 < 順序番号〕(工程〔工程ID = 'K3'〕)))

1. 基準工程 ‘K3’ の順序番号は 3（表4）
2. ‘K3’ より順序番号 < 3: K1, K2
3. バグ表の 作り込み工程ID が K1 または K2 のバグを抽出

• B1 の作り込み工程ID = K2 → 該当
• B5 の作り込み工程ID = K1 → 該当
• B4 の作り込み工程ID = K3 → 基準と同じ → 除外

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

• 発見工程ID と「作り込み工程ID」「発見すべき工程ID」を混同しない。
• NULL 値は比較条件に合致しない（＝等しくない）ことに注意。
• 「品質分析対象」はあくまで “修正有無 = ‘あり’” のバグ種別である点を忘れない。
• 工程間の「順序番号」を理解せずに工程IDの文字列比較をしない（K1＜K3 ではなく 1＜3 の比較）。

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

• 関係代数の 選択，射影，結合 の書き方と意味を確実に理解する。
• NULL を含む比較条件の結果は FALSE（もしくは排除）になることを押さえる。
• 「工程ID と順序番号」は別属性。ソートや大小比較は順序番号で行う。
• 問題文のキーワード（例：「同一」「必要な」「基準より小さい」など）を設計した結合・抽出条件に正しく反映する。