データベーススペシャリスト試験 平成25年度春期

問1 では，データベースの基礎理論について出題した。全体として正答率は高かったが，キー属性，非キー 属性，推移的関数従属性などの基本的概念を正確には習得できていない答案が散見された。業務内容からデー タモデルを分析する際に，システム要件を考慮して的確にモデル化できるように基礎理論を身に付けてほし い。 設問1(3)は，関数従属性を表現する図を完成させる問題であったが，属性をキー属性と非キー属性のグルー プに分類することができていない解答が多かった。業務内容から属性を適切に分類し，関数従属性を判別でき るようにしてほしい。 設問2(1)は，関数従属性が，A→B→C，かつB→A の場合，A とC の間には推移的関数従属性は成立しない。 具体的には，リソースID→URI，URI→リソースID であり，このことを考慮せずにリソースID→URI→ ｛リソース名称，リソース種別，配信スキーマ｝などを推移的関数従属性とした誤った解答が多かった。推移 的関数従属性の正確な定義を理解して，識別できるようにしておいてほしい。 設問3(3)は，内自然結合演算と外自然結合演算の違いを問う問題であったが，他の設問に比べて正答率は低 かった。両者の演算結果の違いに関しての理解を深めてほしい。

問2 では，家庭向け清掃サービス業者の受注管理システムのデータベース設計について出題した。全体とし て，正答率は低かった。 設問1(3)は，正規形のレベルを問う問題であったが，正規化の基礎に関する理解不足が多く見られた。候補 キーが複数ある場合の正規化のレベル判定や部分関数従属性の有無，推移的関数従属性の有無の判定を誤って いた。正規化はデータベース論理設計の基礎であるので，その定義を正確に理解してほしい。 設問2(1)は，注文明細のうち，セットサービスの注文，個別サービスの注文，オプションサービスの注文の リレーションシップを問う問題であった。正答率は高かったが，参照元と参照先を逆に解答してしまっている ものが散見された。テーブル間の参照関係を問題文から正確に読み取り，かつ，表記ルールに倣って記述する ようにしてほしい。 設問3(2)は，注文の変更履歴を保持できるようにするためには，テーブルをどのように変更すればよいかに ついて問う問題であったが，正答率が低かった。変更年月日などの履歴の発生単位を主キーに加えるといった 履歴を含むテーブルとそのテーブルを外部参照する設計について，実践的な知識を高めるよう心がけてもらい たい。

問3 では，SQL の設計及び性能について出題した。 設問1 の正答率は高かった。システムカタログの統計情報から業務データの統計的な性質を理解し，SQL 文 の結果行数の見積りに役立たせることができることを学んでほしい。 設問2 の正答率は高かった。ここでは，画面のスクローリングを，一意なキーの順番に行を取得するSQL 文 を利用して行う場合，そのキーが複合列で構成されている場合に陥りがちな問題を出題したが，正しい結果行 を得るためにどのようにSQL 文を修正すればよいか，よく理解されていた。 設問3 は正答率が低かった。(1)では，〔問題点の指摘〕②が注文確定の際に実行されるSQL について述べて いることに気づいてほしかった。注文確定の際に実行されるのは，表3 に挙げたSQL のうち，SQL6 及びSQL7 である。そして，SQL7 がアクセスする“在庫”テーブルは〔テーブルの保守の見直し〕の対象ではないので， F さんが指摘したSQL はSQL6 ということになる。(2)では，行が蓄積されるテーブルに対するSQL のアクセス 経路が表探索の場合に起きる性能低下の問題を出題したが，SQL を実行するたびに処理時間が長くなる理由を 答えずに，表探索が索引探索に比べて処理時間が長くなる理由を答えている誤った解答が多かった。(3)で は，アクセス経路を変えないためには，C の統計更新処理を行わないか，もし統計更新処理を行う場合でもA の不要な行削除処理によって行数がゼロになる可能性がある場合に行うべきではないことに気づいてほしかっ た。

問1 では，OA 周辺機器メーカの物品購買管理システムの統合を題材に，概念データモデルの設計，現行シス テムから新システムへの移行時のテーブル設計について出題した。 設問1(1)では，調達先のサブタイプとその間のリレーションシップ，部品と在庫とのリレーションシップの 正答率が低かった。①調達先のサブタイプである支払先と仕入先が独立であること，②仕入先と支払先のリレ ーションシップが存在すること，③部品と在庫とのリレーションシップが1 対1 であることを，問題文から読 み取ってほしい。また，リレーションシップの表記について，巻頭の表記ルールに従っていない解答が散見さ れた。 設問1(2)では，都度発注見積明細と都度発注，定量発注見積明細と定量発注のリレーションシップの正答率 が低かった。業務の分析結果をよく読んで，1 対1 と1 対多のいずれであるかを判別してほしい。 設問1(3)では，当月分から翌月分に切替りがあることを読み取っていない解答が散見された。 設問2(1)では，在庫と部品のサブタイプとのリレーションシップを適切に記述していない解答が多かった。 設問2(2)では，納品のサブタイプを切り出していない解答が多かった。また，分納発注と納入指示のリレー ションシップを1 対多としていない解答が多かった。業務の分析結果からサブタイプを注意深く識別してほし い。 設問3(2)では，×とした理由の正答率が低かった。各テーブルについて，行の一意性以外の観点で工場番号 が必要となる理由を，問題文中のシステム統合方針から読み取ってほしい。 設問3(3)は正答率が低かった。工場番号の列を追加することで，全社で共通な列と，工場単位に異なる値を もち得る列があることに着目して解答を導いてほしい。

問2 では，概念データモデリング，関係スキーマについて出題した。(3)及び(4)の関係スキーマを完成させ る問題に比べて，(2)の概念データモデルを完成させる問題は正答率が低かった。日頃からモデル図を用いて 対象領域全体を把握する機会が不足していることの結果と思われる。 (2)の概念データモデルの完成については，特売企画のサブタイプ構造と売価のサブタイプ構造に誤りが多 く見られた。管理対象をインスタンスのレベルで把握し，インスタンス間にどのような対応関係が成立するの かを明確にして，サブタイプ構造を見極めるようにしてほしい。 比較的正答率の高かった(4)の関係スキーマの完成でも，“販売”と“販売明細”の親子関係で，主キーの誤 りと従属属性の配置の誤りは多く見られた。インスタンスの粒度を十分に意識して解答してほしい。また， “販売”と“販売明細”の従属属性について，導出可能であると判断して記述していない解答がしばしば見ら れた。概念データモデルや関係スキーマは，システム利用者とコミュニケーションするためのツールであり， システム利用者が認識している属性（帳票などに現れる属性）を分析者の判断で外すことは避けるべきであ る。 概念データモデリングに当たっては，感覚に頼らず，必要に応じて決定表や一般の表を用いて，インスタン スのレベルまで十分に考慮し，サブタイプの切り出しやリレーションシップの設定を行う習慣をつけてほし い。