DBスペシャリスト試験の概要と午後Ⅰ試験問1の解説

はじめに

昨年度に引き続き、本年も全5回で、情報処理技術者試験 データベーススペシャリスト試験（以下、DB試験）の対策講座を連載します。

連載のねらい

本連載のねらいは、

これからデータベーススペシャリスト試験（以下、DB試験）を受験する方が最小限の努力で合格するためのノウハウを伝授すること

です。孫子の兵法として、「彼を知り己を知れば百戦殆うからず」とあります。過去問題を解く（彼を知り）ことで、自身の強みや弱みを把握でき（己を知れば）、試験当日に向けて弱みを克服することで、試験合格への道が開けてきます。私がお勧めするのは、過去3年間の過去問題を解いて、正答を導けなかった箇所（分野）を重点的に学習することです。

連載のテーマ

各回の解説内容は、以下の通りです。

本連載では平成29年度の午後試験について解説しますので、過去問題を解いた上で（DB試験の過去問題はこちら）本連載の記事をご覧ください。なお、DB試験の概要や合格のテクニックについては昨年度の連載記事をご覧ください。

平成29年度DB試験の試験別合格率

平成29年度のDB試験の試験別受験者数と合格者数、合格率は以下の通りです。午前試験に比べ、午後試験の合格率が低くなっています。午前試験は、応用情報処理技術者試験や高度試験の知識、およびDB試験の午後試験の知識があれば合格できると考えられます。

午後Ⅰ試験の概要

午後Ⅰ試験の過去3年分の出題テーマは以下の通りです。

午後Ⅰ試験では3問中2問を選択し、90分で解答しなければなりません。問題の選択時間や解答の確認時間を考慮し、1問35分で解答することを目指しましょう。

平成29年度午後Ⅰ試験問1に挑戦！

それでは、平成29年度午後Ⅰ試験問1に挑戦してみましょう。問題文はこちらからダウンロードしてください。また、解答用紙はこちらに用意しました。解答例はこちらをご覧ください。

設問1の解説

(1)候補キー
候補キーを見つける際には、以下の内容に注目します。

1. 関係スキーマに含まれる属性に含まれる「エンティティ名＋番号」「エンティティ名＋ID」といった、候補キーになりそうな語句
2. 問題文や主な属性とその意味・制約の中に含まれる「一意」「一つの」など、識別に該当する語句

1.に該当する、図4の関係「電子会議投稿」の属性を見ると、「電子会議投稿番号」のように、単一属性で候補キーになりそうな属性は見つかりません。その代わり、「電子会議番号」と「投稿番号」という属性があることから、この２つの属性が複合キーになりそうです。

次に、2.に取り組みます。表1を見ると、属性名「投稿番号」の意味・制約に「電子会議番号との組合せで投稿を一意に識別する番号」と記載されています。やはり、{電子会議番号,投稿番号}が候補キーでした。そして、〔GWの主な機能〕3.コミュニケーション機能(4)にある「電子会議は，いずれか一つの分野に属し，分野ごとに定められた表示順に従って一覧表示される」より、電子会議は分野と表示順の組合せで識別できます。したがって、{電子会議番号,投稿番号}のうちの「電子会議番号」を「分野番号,表示順」に置き換えた、{分野番号,表示順,投稿番号}も候補キーです。他に候補キーに該当する属性の組がないことから、解答は「{電子会議番号,投稿番号},{分野番号,表示順,投稿番号}」です。

(1)部分関数従属性
図4の関係「電子会議投稿」の属性と〔GWの主な機能〕3.コミュニケーション機能(2)にある「電子会議には，例えば“プロジェクタの利用について”などの議題が定められる」、さらには、表1の属性「電子会議番号」の意味・特性「電子会議を一意に識別する番号」と「議題」の意味・特性「電子会議のタイトル」より、属性「議題」は候補キー{電子会議番号,投稿番号}の一部である電子会議番号に部分関数従属しています。したがって、部分関数従属性の有無は「あり」、部分関数従属性の解答は「電子会議番号→議題」です。

(1)推移的関数従属性
図4の関係「電子会議投稿」の属性と表1「主な属性とその意味・制約」の属性「分野番号」の意味・特性「分野を一意に識別する番号」、および「分野名」の意味・特性「分野の名称」より、属性「分野名」は「分野番号」に関数従属しています。また、候補キーの解答から、「電子会議番号→分野番号」が成り立ちますが、「分野番号→電子会議番号」は成り立ちません。以上のことから、関数従属性として「電子会議番号→分野番号→分野名」が成り立ちます。

したがって、推移的関数従属性の有無は「あり」、推移的関数従属性の解答は「電子会議番号→分野番号→分野名」です。

(2)正規形
(1)より、関係「電子会議投稿」には部分関数従属性があることから、関係「電子会議投稿」は第1正規形です。そのため、第3正規形にした結果としての関係スキーマを作成する必要があります。

(2)関係スキーマ

• 第2正規化
  関係「電子会議投稿」から候補キー{電子会議番号,投稿番号}と{分野番号,表示順,投稿番号}に部分関数従属する属性を異なる関係に分離します。ここでは、表1より、関係「電子会議投稿」に含まれる、候補キー以外の属性の関数従属状況を列挙します。
• 議題：候補キーの一部である「電子会議番号」に部分関数従属する
• 分野名：候補キーの一部である「分野番号」に部分関数従属する
• 作成者ユーザID：候補キーの一部である「電子会議番号」に部分関数従属する
• 投稿本文：候補キーに完全関数従属する
• 投稿者ユーザID：候補キーに完全関数従属する

以上のことから、関係「電子会議投稿」を第2正規化した結果は以下の通りです。


分野（分野番号，分野名）
電子会議（電子会議番号，議題，分野番号，表示順，作成者ユーザID）
投稿（電子会議番号，投稿番号，投稿本文，投稿者ユーザID）

なお、関係「電子会議投稿」から電子会議に関する属性を分離したことから、元の関係名「電子会議投稿」の関係名を「投稿」としました。また、属性「作成者ユーザID」と「投稿者ユーザID」はともに関係「ユーザ」の主キー「ユーザID」を参照する外部キーです。
• 第3正規化
  第2正規形の3つの関係について、推移的関数従属性は見つかりません。したがって、第2正規形がそのまま第3正規形です。

設問2の解説

(1)適切な属性名
問題文中の名詞句より、保持する必要がある属性を見つけます。また、問題文中に複数の関係名があり、動詞句が関係間の関連を表す語句の場合、外部キーを定義する必要があります。

• (a)
  〔GWの主な機能〕1.利用者管理機能(4)の「ユーザは，一つのグループに必ず属し，これを主務グループと呼ぶ」より、関係「ユーザ」には、関係「グループ」の主キーを参照する外部キー「主務グループID」が必要です。
• (b)
  〔GWの主な機能〕2.予約機能(2)の「設備には，必要に応じて，当該設備の管理を行うグループを一つ定めることができる」より、関係「設備」には、関係「グループ」を参照する外部キー「管理グループID」が必要です。
• (c)
  〔GWの主な機能〕3.コミュニケーション機能(1)の「ユーザは，1人または複数のユーザにメッセージを送信することができる」より、関係「メッセージ」には、送信元のユーザ情報を保持する外部キーが必要です。また、「送信先のユーザがメッセージを開封すると」との記述より、この外部キーの属性名は「送信元ユーザID」とします。
• (d)(e)
  〔GWの主な機能〕3.コミュニケーション機能(1)の「ユーザは，1人または複数のユーザにメッセージを送信することができる」より、関係「メッセージ送信先」の主キーは、複合キー{メッセージID,送信先ユーザID}です。この「送信先ユーザID」は、関係「ユーザ」の主キーを参照する外部キーです。また、〔GWの主な機能〕3.コミュニケーション機能(1)の「送信先のユーザがメッセージを開封すると，開封日時が記録される」より、関係「メッセージ送信先」には、属性「開封日時」が必要です。したがって、(d)と(e)は「送信先ユーザID」と「開封日時」です（（d)と(e)は順不同）。
• (f)
  〔GWの主な機能〕2.予約機能(1)の「スケジュールを予約されたユーザは，そのスケジュールに参加するか否かを回答することができる」より、関係「スケジュール予約先」には属性「参加可否回答」が必要です。

(2)概念データモデルのリレーションシップの完成
ここでは、図4よりリレーションシップを導出した上で、問題文からゼロを含むかどうか決定します。

• 関係「グループ」
  図4より、属性「上位グループID」は、主キー「グループID」を参照する外部キーです。また、〔GWの主な機能〕1.利用者管理機能(2)に「グループには，上位のグループを一つ定めることができる」とあります。これは、「グループには上位のグループを一つ定めても定めなくてもよい」という意味であり、上位グループが存在しない場合があります。その一方で、「グループとは，GW上の組織である」とあることから、組織階層の最下位にあるグループには下位グループは存在しません。そのため、上位グループから見た下位のグループもゼロの場合があります。以上のリレーションシップは以下の通りです。

• 関係「ユーザ」
  (1)(a)の解説より、外部キー「主務グループID」が関係「グループ」の主キーを参照しています。さらに、〔GWの主な機能〕1.利用者管理機能(4)の「ユーザは，一つのグループに必ず所属し，これを主務グループと呼ぶ」「上位グループの中には，ユーザが一人も所属しないグループがある」より、ユーザに対応する主務グループは必ず存在しますが、グループに対応するユーザは存在しない場合があります。以上から、関係「ユーザ」と「グループ」のリレーションシップは以下の通りです。



• 関係「設備」
  (1)(b)の解説より、外部キー「管理グループID」が関係「グループ」の主キーを参照しています。また、〔GWの主な機能〕2.予約機能(2)の「設備には，必要に応じて，当該設備の管理を行うグループを一つ定めることができる」より、管理グループが存在しない設備があります。また、〔GWの主な機能〕1.利用者管理機能(4)の「上位グループの中には，ユーザが一人も所属しないグループがある」より、ユーザがいないグループには管理する設備も存在しないと推測できます。以上から、関係「設備」と「グループ」のリレーションシップは以下の通りです。



• 関係「メッセージ」
  (1)(c)の解説より、外部キー「通信元ユーザID」が関係「ユーザ」の主キーを参照しています。また、〔GWの主な機能〕3.コミュニケーション機能(1)の「ユーザは，1人又は複数のユーザにメッセージを送信することができる」より、送信元は必ず1つあります。その一方で、メッセージを送信しないユーザもいることから、関係「設備」と「グループ」のリレーションシップは以下の通りです。



• 関係「メッセージ送信先」
  (1)(d)(e)の解説より、主キーの一部である「メッセージID」が関係「メッセージ」の主キーを参照しています。また、〔GWの主な機能〕3.コミュニケーション機能(1)の「ユーザは，1人又は複数のユーザにメッセージを送信することができる」より、メッセージには送信先が最低1つ必要です。その一方で、メッセージには必ず送信先が必要であるため、関係「メッセージ」と「メッセージ送信先」のリレーションシップは以下の通りです。



• 関係「予約」
  図4より、外部キー「予約者ユーザID」は関係「ユーザ」の主キーを参照しています。また、〔GWの主な機能〕2.予約機能の「GWでは，スケジュール予約および設備予約を行うことができる」より、予約はユーザがすることから、予約に対応するユーザは1名必要です。その一方で、予約をしていないユーザがいると推測できることから、関係「予約」と「ユーザ」のリレーションシップは以下の通りです。



• 関係「設備予約先」
  図4より、複合キーの一部である「予約番号」は関係「予約」の主キーを参照しています。また、「予約番号」は複合キーの一部であることから、該当する予約は必ず存在します。その一方で、〔GWの主な機能〕2.予約機能の「GWでは，スケジュール予約および設備予約を行うことができる」より、予約にはスケジュール予約も含まれることから、予約は必ずしも設備予約先に対応していない場合があります。したがって、関係「予約」と「設備予約先」のリレーションシップは以下の通りです。



• 関係「スケジュール予約先」
  関係「設備予約先」と同様に導出できます。関係「予約」と「スケジュール予約先」のリレーションシップは以下の通りです。

設問3の解説

(1)新たに追加する関係
〔GWの主な機能〕1.利用者管理機能(4)に「また，ユーザには一つ又は複数のロールを付与でき，一つのロールを複数のユーザに付与することもできる」とあります。したがって、関係「ユーザ」と関係「ロール」には多対多の関連があります。したがって、両方の主キーを複合キーとして持つ、連関エンティティを追加します。以上より、追加する関係は以下の通りです。

(1) 属性を追加する関係
〔GWの主な機能〕4.ワークフロー機能(3)に「ステップには，承認可能なユーザ，グループ又はロールを指定する。ユーザ，グループ又はロールのいずれかで指定されているかは，承認者区分で識別する」とあります。図4より、属性「承認者区分」は関係「決裁ルート」にあり、関係「決裁ルート」には属性「承認ユーザID」「承認グループID」はありますが、ロールに関する属性がありません。そこで、関係「決裁ルート」に属性「承認ロールID」を追加します。

(2) 指摘事項②の発生状況
〔GWの主な機能〕4.ワークフロー機能(5)や図1に、一度承認した申請を差戻すことがあると明記されており、同じステップを複数回繰り返す場合があります。ところが、図4の関係「承認」の主キーが{申請ひな形番号,申請連番,ステップ番号}となっているため、一度承認した申請が差戻しされた後、再度承認処理を行った場合、同一申請ひな形番号、申請連番において、同一ステップ番号が複数使用され、整合性制約に違反します。そこで、解答例は「一度承認を行った申請が差戻しされた後、再度承認処理を行ったとき」とします。

(2) 指摘事項②の修正後の関係スキーマ
表1の属性「承認連番」の意味・制約に「申請ひな形番号ごと・申請連番ごとに1から始まり，承認処理を行うごとに1ずつ加算される番号」とあります。そこで、「ステップ番号」の代わりに「承認連番」を複合キーに加えます。また、〔GWの主な機能〕4.ワークフロー機能(2)に「決裁ルートとは，申請ひな形ごとに定められた，申請を処理する承認経路であり，一つ以上のステップによって構成される」とあります。そのため、関係「承認」の属性の組{申請ひな形番号,ステップ番号}は関係「決裁ルート」の主キーを参照する外部キーとなります。したがって、関係「承認」の関係スキーマは以下の通りです。

おわりに

今回は、平成29年度午後Ⅰ試験問1の解き方を紹介しました。最低限、設問2までは確実に正解できるようにしておきましょう。次回は、平成29年度午後Ⅰ試験問2の解き方を紹介します。