データベーススペシャリストの試験を受けて面白かったのでどんな試験だったか呟いてみる

こないだデータベーススペシャリストに合格して、解いてる間は自分が冗談を本気に受け取る性質なところもありIPAの試験は受けることすら揶揄される感じがあってつらかったのですが、年度によっては偏ったものもあると思ったものの全体として解いたり調べたりしてて楽しい問題だなぁと思ったので、その内容についてのポエムです。

書いてる人について

一ヶ月で合格しました系の記事を求めている人に申し訳ないんですが、元々DB周りの話が好きで結構アプリケーションで触るSQLとかindexの付け方とかテーブル設計のための業務知識の眺め方の基礎みたいなのは新人並みには勉強してました。

それでもやっぱり全然足りなくて悔しい思いをすることがあったのですが、どこから手をつけていいかわからず、もう少し系統立てて勉強してみたいなという気持ちがあって受験しました。

事前に読んでいた本は

〔入門〕はじめてのデータベース

書き込み式SQLのドリル 改訂新版

SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus)

SQLアンチパターン

あたりで、中二病により

エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド

を持っていましたが、鍵本を使うような事態まで担当したことがあまりなく、幾らかのテーブル設計とindex設計して失敗したーしなかったーって一年くらいやったあと、偉い人の鶴の一声でAndroidに転向した感じで、今回の受験は趣味です。

試験用の勉強期間は2ヶ月くらい。

試験の概要

問題の構成はIPAの情報処理技術者の高度試験におなじみの、午前1, 2, 午後1, 2の四部構成です。

基本的には午前を除き、問題で具体的に取り扱うのは、RDBMSだけです。特に午後はそうです。いま、NoSQLのデータベースを全く使っていないサービスは少ないのではないかという時代にRDBMSだけという気持ちもありますが、自分にとっては、十分価値はありました。

午前1は受けていないのでおいておいて、午前2は他の分野も合わせた用語問題と簡単な正規化やトランザクションの排他制御などについて問われる形となっていてNoSQLについての用語はここに少しだけ出ます。

個人的に一番豪華なのは午後1で、午後1は試験範囲のいろんな分野がぎゅっと濃縮されており、

• テーブルの正規化・非正規化に関する検討。具体的に言うと、まず、中途半端に正規化されたテーブルが提示されてそれをどこまで正規化してるか答えさせてから正規化。正規化されてない場合の問題点をいちいち説明させる
• データベースの移行について、移行用のクエリの形や移行方法を2~3種並べてどの程度時間がかかるか計算させる
• データベースのトランザクションの排他制御について、それっぽいクエリを5つくらい並べてロックがどの組み合わせでかかるか具体的に指摘させる
• 各種indexの場合のデータ探索時の特性に関して、たとえばクラスタ索引と非クラスタ索引の場合、ページの読み込まれかたが違うから分析用のバッチ処理に使うデータの規模考えて効率的なのどっちですか

などなど、多分、自分と似たような「1~2年開発してみて、ある程度モデル同士の関係を考慮しつつ正規化されたテーブルを設計してn+1などの問題がないクエリは書け、問題のあるテーブルの修正も提案できてrailsの上でSQLをいじって怒られることは減ってきたが、次はなにをやってみたらいいのか具体的によくわからないwebエンジニア」にとって、格好の目標となるのではないでしょうか。いや、いまはあっぷあっぷでこれ解いてるけど、いつかスラスラ説明できるようになりたいと思ったのでなったというか。。

正直時間的にも午後1は制限時間の45分で解くのがしんどいのですが、その分、一問解いてわからなかったことを調べるたびに、わからなかったことに関する用語はこれか、こういう観点があるのかって探検するための地図をもらっているような気持ちでした。鍵本も初めて机上ではあるかもしれませんが、具体的な問題のために取り出せたので満足です。

さて、午後2なんですけど、データベーススペシャリストの試験が受けやすいと言われる同時に国語の試験と揶揄される原因でして、だいたい論理設計１本勝負か、物理設計そのほかを絡めた論理設計から一題選ぶ方式となっています。そして、この論理設計一本勝負の方が問題形式としては大胆で、

• まず、業務について書かれた長文10ページを読みます
• 次にそれをふまえて答案用紙にありったけの時間をかけてカラム名とテーブル名を書きなぐります

というワイルドな問題構成であることが多いです。図の記入欄の余白、足りないんですけど？？

これよりもっと少ないページ数に収まる要件の一部をなんだかんだ一週間、少なくとも数日は議論して決める自分の知ってる実務からすると、これ120分で読ませて書かせちゃうかーって感じなんですが。。

喉元過ぎた今眺めると「ドメインロジックとデータベースの知識の両方があって初めて正しい設計ができる。知識を生かすために、後々困らないように必要な知識をくまなく汲み取ってこそのプロである。それも、急に人が相談しにきて今日中にって言われた、みたいな場合でもある程度の方向性を示せる上級エンジニアたれ」みたいな、強い圧力を感じます。痺れる(腕が)。

なお、この設定、実際にそのままrailsでアプリケーションがかけちゃいそうな勢いで細かいので、設計の演習や練習用のアプリの設定に困っている人も、無料で公開されていますし一回みてみるといいのではないでしょうか。リレーショナルモデルに沿ったある一派の設計に浴びるように触れる、という体験としても非常に楽しいです。時々でもなく文章量にうんざりしますが、いろんな職場や業界で使われるシステムについて書かれた文章を読むのは社会見学みたいで不謹慎ながら面白かったです。

まとめ

午後1はサーバサイドに戻ることになったら一通り解き直したいレベルでよかったです。午後2で問われている領域には知識以上にビジネスロジックに噛んでいくコミュ力とか信頼とかを築く力といった部分が先立つんだろうな、ということでちょいと虚しさもありましたが。。

やっぱりめっちゃ怖い人からこんなもんって言われそうであれなんですが、闇雲にやるよりこの試験問題で知らないことを教えてもらってよかったよ！っていうのを言いたかったので、現場からは以上です。