データベーススペシャリスト試験を受ける前に知っておきたい3つの極意
はじめに
本記事はQiita Advent Calendar "IT資格取得をテーマに学びをシェアしよう！【PR】Udemy Advent Calendar 2021" 12/20(月)分の記事です。
…またですか？
はい。またです。
これで高度情報処理技術者試験のタイトルは6つ目になります。
今回も受験記書くの？
今回はテクニカルスペシャリスト試験の合格ですし、体験記とかを書く気は特になかったんですよ。
データベーススペシャリストについては山のように合格体験記も残っていますし、(良くも悪くも)コモディティ化されている区分1なので、あえて何かを書く必要もないと思ったんですが、昨日祝杯を上げながらこの一連のツイートをした際に、
まぁそういうわけで、当日はしれっと無関係な面をしておいて、実は受けていた、っていう話でございました。
— dimeiza@技術士(情報工学部門) 攻略ガイドブック (@dimeiza) 2021年12月17日
データベースは正直言って初学者で、外野も良いところなんですが、何とかなってしまうもんですね。
スペシャリストを名乗ってよいのか今でも疑問ですが、まぁ入り口に立った、ということで。
この話は私がデータベーススペシャリスト試験を受ける前に知っておきたかった3つの受験テクニックだなぁ、と気づいたので、翌年以降受験する人のための道標として残しておこうと思ったのです。
というわけで、極意などという若干釣りっぽいタイトルですが、以降の話は体験記でもなければ、データベース技術の能力向上などといった高尚な話でもなく、純然たる受験テクニックの話です。
1. 出題パターンと傾向を熟知しておく。
統計資料を見る限り、ここ数年の易化傾向は見て取れます。DBの合格率は17%も。
— dimeiza@技術士(情報工学部門) 攻略ガイドブック (@dimeiza) 2021年12月17日
ただ、実際受けてみると存外手強かったんですよ。
DBは問題形式が決まりきっていることで有名ですが、今年の問題は日本語を大分捻っていて『例年通りには行かせねぇぞ』という作問側の強い意志を感じたぐらいでした。
出題パターンについては、過去問を何年かパラパラめくっていくとすぐに分かる事かとは思います。
データベーススペシャリスト試験の午後I、午後IIは、大抵以下の形式に則って出題されています。
- 問題文の要件から概念データモデルのリレーションシップを引き、関係スキーマの空白を埋める。
- いわゆる論理設計問。
- 問題文に記述された性能に関する与件から、パフォーマンスを明らかにし向上を図る。
- いわゆる物理設計問。
- 問題文に記述されたシステム構成と業務フローから、SQLの穴埋めを行う。
データベーススペシャリスト試験合格の一番の近道は、
- 上記の各形式に対して明示的に備えつつ、
- 自分はどの形式が最も得意であり、
- IPAはどの形式に対して最も優遇してくるか
を知っておくことです。
各形式に対して明示的に備える
これはまんべんなく過去問を解いていれば問題なくできることです。
午後I、午後IIでは問題選択をすることになって、結局一部の問題は解かず終いになるわけですが、後述するように、自分がどの形式を得意とするか知っておくためには、まず過去問を解いて体感しておく必要があります。
また、全形式の問題を解いておけば、万が一、自分が最も得意としている形式が非常に難化している場合に、避けて通るための保険にもなります。
どの形式が得意かを知っておく
受験生のバックグラウンドによって、各形式に対する得意、不得意が出てくると思います。
- 日本語読解と概念の整理を得意とする人
- SQLの組み立てを得意とする人
- 計算とパフォーマンス把握を得意とする人
自分がどの形式を得意としているかは、本番における問題選択の基準、判断材料として重きを占めることになります。
どの形式が最も優遇されるかを知っておく
これはデータベーススペシャリスト試験経験者の間でよく言われていることですが、午後IIで出題される2問については、
- 1問は論理設計問で、大半の人がこれを選ぶ(本命)
- もう1問はそれ以外の問題で、選ぶ人は少ない(大穴、冒険)
という話がされることがあります。論理設計問以外の問の方は比較的難易度が高い問題のことも多いそうです。
このため、本番では論理設計問を安牌として選択するのが一般的な戦略になっています。
ただ、今年の午後I問1辺りは論理設計問としては日本語の捻りが強く、過去で1,2を争う難問とも言われていて、必ずしも安全な道とは限らないのですが、論理設計問が攻略の基本にあることは、この区分の常識感として知っておいたほうが良いでしょう。
2. 概念データモデル、関係スキーマ、問題文を三位一体で解く。
これは上述の戦略に従って、論理設計問を選択した際の鉄則です。
特に時間制限の厳しい午後1問1は、文章から関係スキーマを抽出しづらく、敗北の可能性を色濃く感じた一幕もありました。
— dimeiza@技術士(情報工学部門) 攻略ガイドブック (@dimeiza) 2021年12月17日
関係スキーマ、概念データモデル、問題文を三位一体で俯瞰して解くのがDB午後問の極意ですが、日本語記述を変えるだけでこうも対処しづらくなるのか、と戦慄したひと時でしたね。
論理設計問の解き方の根本とも言える考え方で、当たり前と言えば当たり前ですが、概念データモデルと関係スキーマに欠落している情報は、問題文からだけではなく、他方からも補う必要があります。
概念データモデルの配置から関係スキーマの内容を類推する
概念データモデルで予め配置されている情報は、回答者が線を引きやすいように配置されています。
この線の引き方を見ると、
- ん？ この情報とこの情報が上下配置されてて交差もしなさそう…ひょっとして外部キー関係？
- この情報とこの情報、多分サブタイプ関係だけど、関係スキーマには片方書かれてなくね？
みたいな関係性が暗示的に読み取れることがあるので、ここから関係スキーマの穴埋めを疑っていったりすることもできます。
関係スキーマの表記と概念データモデルを照合する。
関係スキーマ上、主キーや外部キー表記が予めされている場合、この関係性がきちんと概念データモデルに反映されているかを確認しておくことは大事です。
外部キー、サブタイプ表記のような、データモデル間の関係を正確に表現することが論理設計問最大の出題趣旨で、出題者は問題を解いていく中で、新たな関係を解答用紙に記入していくことになるわけですが、この時、
- 一方に予め暗黙的に表現されている関係性が、関係スキーマと概念データモデルの両方に反映されているか
だけではなく、
- 回答者が回答した新たな関係性が、関係スキーマと概念データモデルの両方に反映されているか
ということも求められるので、これを意識的に確認する観点からも、関係スキーマの外部キー表現と概念データモデルのそれについて、平仄を取る癖をつけることはとても大事になります2。
関係性を明示、暗示する問題文の表現を拾い切る。
解答を求められる関係性や属性名は、大抵問題文から拾うことになるので、普通、問題文は慎重に見ることになりますが、
- 識別する。
- 一意になる。
- 一意になるとは限らない。
- 設定されないこともある。
- 対応付ける。
- 設定できる。
- 設定できない。
これらの述語が出てきた場合、かなりの確率で概念データモデルや関係スキーマの関係性を表現しているので、この述語で説明されている主体について、概念データモデルや関係スキーマ上の取扱を確認しなければなりません。
ただ、もっと恐ろしいのは、関係を暗示しているのはこうした決まりきった表現とは限らないことです。
- (適用率が)変わることがある。
- 複数回することはない。
のような、一見紋切り型でない述語であっても、この関係性を表現するデータ構造を実現せよ、という含意があって、概念データモデルと関係スキーマに影響を及ぼすことがあります。
問題文の中に埋もれている、こうした暗示的な表現を拾って他2つに表現できるか、という点は、回答の画竜点睛を入れる上で重要になってきます。
三位一体で見れるかは問題選択にも影響する
問題文、関係スキーマ、概念データモデルのそれぞれに断片表現された関係性を、関係スキーマ、概念データモデルに完全に表現し切るのが、論理設計問の最終的なゴールです。
そのためにはこの3つを三位一体として俯瞰し、矛盾点と記述不足を洗い出す必要があるわけですが、
- このスタンスで試験に臨めるかは問題選択にも影響するし、勝敗を分けそうだな
と実感したのは、試験が近づいた9月頃のことでした。
実際そのとおりだったのですが、もっと早い段階で気づいておきたかったことでもあります。
3. 迷ったら線を引け
DB午後問におけるもう一つの極意『迷ったら線を引け』に救われた側面もありますね。
— dimeiza@技術士(情報工学部門) 攻略ガイドブック (@dimeiza) 2021年12月17日
答練中は関係スキーマと日本語の文章上、確信がないと概念データモデルに関係を引けない傾向がありましたが、この極意のおかげで、本番中はためらわずに線を引けていて、解答にもだいぶ合致している感がありました。
これは試験が近づいた時にどこかで聞いたんですよね3。
これも論理設計問を解く時のポイントの一つです。
論理設計問で『線を引く』というと、大抵は以下2つを指しますが、
- 概念データモデル上で関係表現をするためのリレーションシップを引く。
- 関係スキーマで主キー(下線)、外部キー(下破線)を表現する
ここで私が念頭に置いている線は、リレーションシップの線です。
概念データモデルでリレーションシップを引く場合、大抵は関係スキーマで外部キーの関係を表現してから引くと思うんですよ。
外部キーになっているかどうかの確信がつかない時はなかなか線が引きにくいと思うんですが、こういう時は予め線を引いておいて、関係性を仮置きした後で、引き続きデータモデルを分析していく、というのが、私が最後に従った極意でした。
これは事実かどうかちょっとわからないんですが、概念データモデルに余計な線が引かれていた場合であっても、減点はされないと言われています4。
予め概念データモデルで線を引いておけば、関係スキーマ上で発見した外部キー関係を万一概念データモデルに反映しそびれていたとしても、失点しない可能性があるわけです。
得点テクニックの話ではあるんですが、同時に『関係性の仮定において積極性を失わないこと』という指針でもあります。
もしリレーションシップの必要性が疑われるのであれば、まず存在を仮定した上で、その先の分析を進めてみましょう。
さいごに
この3つが、私がデータベーススペシャリスト試験を受ける直前で得た気づきであり、合格した後になって『私に最も必要なテクニックだった』と思い直した3つです。
この辺は受験攻略本を深く読むと、ある程度暗示的に書いてあったりするんですが、特にこの3つにフォーカスして説明された情報源を見たことがなかったので、来年度の受験生の準備に資するべく、書いてみることにしました。
データベーススペシャリストに挑む動機5は皆様様々だと思いますが、勘所を押さえれば私のような門外漢6でも、足止めされずに一発突破できますので、良ければ上記を参考にして挑んでみてください。
