平成26年度春期 データベーススペシャリスト 午後Ⅰ 問1

業務ルールから依存関係を読み解く

データモデルの問題では、用語の定義を暗記で当てはめる前に、示された業務ルールを根拠として、どの項目やエンティティが何によって決まり、どう対応しているかを一つずつ確かめる姿勢が大切です。

この問題で問われていること

確認すべき観点は一つ、「業務上の決まりごとが、データの一意性や対応関係としてどう表れているか」です。結論を出す前に、その根拠となる情報がどこにあるかを自分で指し示せるかを確かめてください。

視点

データモデルでは、ある値が決まると別の値も決まるか、一方の実体が他方といくつ結び付くか、といった性質は、名称や見た目ではなく業務上の前提から導かれます。同じ項目名でも前提が変われば性質が変わり得るため、自分の常識ではなく与えられた条件に基づいて判断することが重要です。

確認ポイント

• 判断の根拠にした業務上の条件を、与えられた情報の中から具体的に指し示せるか
• 自分の経験や一般的な常識で、与えられていない前提を補っていないか
• 一つの結論を出したら、同じ根拠で他の部分とも矛盾しないか見直したか

解説

ソフトウェア開発のバグ管理システムを題材にしたデータベース設計の問題です。関係“優先度”の関数従属性の分析と第3正規形への分解、概念データモデルのリレーションシップ記入、不足している属性と関係スキーマの補完、関係代数による検索式とその結果を問います。どの設問でも、問題文の業務ルールや表2の意味・制約、表3～5の具体例を根拠に答えを組み立てることが求められます。

問題の全体像

A社はBプロジェクトの立上げに合わせて、表計算ソフトで行っていたバグ管理をバグ管理システムに置き換えます。C君が概念データモデル（図1）と関係スキーマ（図2）を設計し、D部長が三つの指摘をしています。リレーションシップと一部属性の未記入、チームとメンバの組織構造の管理不備、成果物と修正成果物の関係の欠落です。公式解答例の出題趣旨によれば、ねらいは業務要件の分析能力、関数従属性・正規化理論を用いたデータモデルの分析能力、関係代数の適用能力を問うことです。採点講評では、関係スキーマの解答で主キーの実線の下線や外部キーの破線の下線を記入していない解答が散見されたとされています。関係スキーマを答える設問では、下線まで含めて答える必要があります。

設問1(1)

図4を見ると、{緊急度コード，重大度コード}の組から優先度コードが決まり、全ての属性がこの組に従属しています。表2のとおり、スケジュール影響度やソフトウェア影響度は、コードが異なっても同じ値になる場合があるため、コードを決定できません。したがって候補キーは{緊急度コード，重大度コード}だけです。緊急度コード→スケジュール影響度と重大度コード→ソフトウェア影響度は、候補キーの一部だけに従属しているので、部分関数従属性は「あり」です。また、{緊急度コード，重大度コード}→優先度コード→リソース投入度は、キーでない優先度コードを経由しているので、推移的関数従属性も「あり」です。公式解答例も、この二つの部分関数従属性と一つの推移的関数従属性を図3の意味欄の表記で示しています。

設問1(2)

部分関数従属性があるので、第2正規形の条件を満たしません。公式解答例では第1正規形です。分解は次のように行います。部分関数従属を切り出して、緊急度（緊急度コード，スケジュール影響度）と重大度（重大度コード，ソフトウェア影響度）を作ります。推移的関数従属を切り出して、優先度変換（緊急度コード，重大度コード，優先度コード）と優先度（優先度コード，リソース投入度）を作ります。公式解答例では、優先度変換の緊急度コードと重大度コードが主キー（複合キー）であり、同時にそれぞれ緊急度・重大度を参照する外部キーです。優先度コードは優先度を参照する外部キーです。主キーの実線の下線と外部キーの破線の下線を忘れずに付けます。

設問2(1)

公式解答例の図は、矢印を「1側→多側」（矢じりが多側）として描いています。各関係の読み取り方は次のとおりです。①バグの自己参照：同一原因バグIDにより、一つの既知バグに対して同じ原因のバグが複数対応します。バグからバグへ戻る1対多の線を1本引きます。②工程→バグ：発見工程ID・作り込み工程ID・発見すべき工程IDは役割が異なるため、工程1対バグ多の線を3本引きます。③バグ種別→バグ：バグ種別IDにより1対多を1本引きます。④メンバ→バグ：発見メンバIDにより1対多を1本引きます。⑤バグ→対応：対応はバグIDと対応連番で識別されるため、バグ1対対応多を1本引きます。⑥メンバ→対応：対応ごとにメンバを1人割り当てる（対応メンバID）ため、1対多を1本引きます。⑦対応をスーパータイプとし、調査・修正・確認を対応区分で分かれるサブタイプとして結びます。3者は対応とそれぞれ1対1で、同じ主キー（バグID，対応連番）を持ちます。採点講評では、この設問は正答率が低かったとされています。業務ルールや属性の意味から、関係の向きと本数を丁寧に拾うことが重要です。

設問2(2)(a)

表1には、バグについて登録・更新される項目が書かれています。そのうち図2のバグに無いものを探します。登録時は‘未着手’で、その後‘調査中’‘修正中’‘確認中’‘解決済’‘クローズ済’と更新される「ステータス」が必要です。公式解答例では、a・bは「ステータス」と「完了日」の順不同です。

設問2(2)(b)

表1のバグのクローズで「ステータスが‘解決済’のバグについて完了日を記録し」とあります。そのため、バグに「完了日」が必要です。公式解答例では、aとの順不同で完了日です。

設問2(2)(c)

表1のバグへの対応に「その対応がどの作業であるかを、対応区分として記録する」とあります。表2にも対応区分の定義があります。これは対応に持たせる属性で、サブタイプ（調査・修正・確認）を区別する役割も果たします。公式解答例では、c・dは「対応区分」と「対応メンバID」の順不同です。

設問2(2)(d)

表1に「対応ごとにメンバを1人割り当てて登録する」とあるので、対応はメンバを参照する外部キーを持ちます。公式解答例では「対応メンバID」です（cとの順不同）。設問2(1)のメンバ→対応のリレーションシップは、この属性に対応します。

設問2(3)(a)

Bプロジェクトの概要(1)(2)では、組織は階層構造で、チームには上位階層のチームが定められています。しかし図2のチームには、上位チームを表す属性がありません。公式解答例では「チームの上位階層のチームを管理できない。」です。25字以内に収めるため、「上位階層のチーム」と「管理できない」の二つの要素を押さえます。

設問2(3)(b)

概要(3)では、メンバは主担当チームのほかに、一つ又は複数のチームを兼任する場合があります。しかし図2のメンバには兼任チームIDが一つしかなく、複数の兼任を表せません。公式解答例では「メンバが兼任しているチームを複数管理できない。」です。「兼任」と「複数」が要点です。

設問2(3)(c)

公式解答例の関係スキーマと、主キー・外部キーは次のとおりです。①チーム（チームID，チーム名，リーダメンバID，上位チームID）：主キーはチームIDです。リーダメンバIDはメンバを参照する外部キー、上位チームIDはチーム自身を参照する外部キー（自己参照）です。②メンバ（メンバID，氏名，主担当チームID）：主キーはメンバIDです。主担当チームIDはチームを参照する外部キーです。兼任チームIDは多値なので、メンバからは取り除きます。③兼任（メンバID，兼任チームID）：主キーは二つの属性の組（複合主キー）です。1人が複数チームを兼任でき、1チームに複数の兼任者がいるためです。そのうえで、メンバIDはメンバを参照する外部キー、兼任チームIDはチームを参照する外部キーでもあります。答案では主キーに実線の下線、外部キーに破線の下線を付けます。

設問2(4)

公式解答例は、成果物（成果物ID，成果物名，作成工程ID，作成担当チームID）と修正成果物（バグID，対応連番，成果物ID）の二つです。成果物の主キーは成果物IDです（概要(5)で一意に識別される）。作成工程IDは工程を、作成担当チームIDはチームを参照する外部キーです。採点講評では、「作成工程」「作成担当チーム」と問題文の語句をそのまま属性名にした解答が散見されたとされています。工程とチームの関係スキーマは既に設計済みなので、ID属性の外部キーとして持たせる必要があります。修正成果物の主キーは、バグID・対応連番・成果物IDの三つを合わせた複合主キーです。表1には、一回の修正で一つ又は複数の成果物を修正するとあります。そのためバグIDと対応連番だけでは、同じ修正対応で直した複数の成果物を区別できず、成果物IDまで含める必要があります。外部キーは二つです。{バグID，対応連番}の組が、修正（対応のサブタイプ）の主キーを参照します。成果物IDは成果物を参照します。

設問3(1)(e)

項番②は、発見された工程と本来発見すべき工程が同じバグを求めます。同じ関係“バグ”の中の2属性を比べるので、表6の選択「R[X 比較演算子 Y]」を使います。公式解答例は「バグ[発見工程ID = 発見すべき工程ID]」で、その結果をバグIDに射影します。

設問3(1)(f)

項番③の分析対象は、成果物の修正が必要なバグ種別が設定されたバグです（バグ管理の概要(4)）。修正有無はバグ種別にあるため、まずバグ種別を‘あり’で選択します。次にその結果とバグを結合し、バグIDに射影します。式の形は（f[g = g]（h[i = j]））[バグID]で、結合「R[RA=SA]S」の左側Rにあたるfは、公式解答例では「バグ」です。

設問3(1)(g)

結合の条件はバグとバグ種別に共通の属性で、公式解答例では「バグ種別ID」です。左辺はバグのバグ種別ID、右辺は内側の選択結果（バグ種別）のバグ種別IDです。

設問3(1)(h)

括弧内の中間関係は、修正が必要なバグ種別を取り出す選択演算です。対象の関係は、公式解答例では「バグ種別」です。

設問3(1)(i)

選択条件の片方は属性「修正有無」です。表6の備考には「X、 Yのいずれか一方は、定数でもよい」とあり、公式解答例ではiとjは順不同です。

設問3(1)(j)

選択条件のもう片方は定数「‘あり’」です（表2で、成果物の修正が必要なものには‘あり’が設定される）。公式解答例では、iとの順不同です。

設問3(2)(k)

項番④の式は内側から読みます。まず工程[工程ID=‘K3’]でプログラム設計（順序番号3）を取り出します。次に工程[順序番号 < 順序番号]で、それより順序番号が小さい工程（K1基本設計、K2詳細設計）を求めます。公式解答例は「プログラム設計工程よりも前の工程」または「基本設計又は詳細設計工程」です。条件は工程名を含めて20字以内です。

設問3(2)(l)

最後に、バグの作り込み工程IDと、求めた工程の工程IDで結合しています。作り込み工程IDは、バグの原因を作り込んだと考えられる工程です（表2）。そのため公式解答例は「原因を作り込んだ」です。採点講評では(2)の正答率が低かったとされています。演算に使う属性の意味まで確認することが大切です。

設問3(3)(ア)

表3で発見工程IDと発見すべき工程IDが等しい行を探します。B1（K5=K5）とB4（K6=K6）が該当します。B2・B3は発見すべき工程IDがNULLで、B5はK7とK2で異なります。公式解答例では「B1，B4」です。

設問3(3)(イ)

表5で修正有無が‘あり’のバグ種別はS1・S2・S4・S6です。表3でこれらが設定されたバグは、B1（S2）、B4（S4）、B5（S1）です。B3はS3（なし）、B2はNULLなので含まれません。公式解答例では「B1，B4，B5」です。

設問3(3)(ウ)

作り込み工程IDがK1またはK2のバグを探します。B1（K2）とB5（K1）が該当します。B4はK3で、順序番号3は「3より小さい」に当たらないので含まれません。公式解答例では「B1，B5」です。

学習のポイント

部分関数従属性・推移的関数従属性の見分け方、1対多と自己参照・複数役割のリレーションシップの書き方、関係スキーマでの主キー（実線の下線）と外部キー（破線の下線）の明記、入れ子の関係代数式の評価手順を重点的に学びましょう。