本記事は
情報処理試験ウィーク
1日目の記事です。
✨📓 告知記事
▶▶ 本記事 ▶▶
2日目
📓✨
こんにちは、上村です。
私は2年前、データベースに関する知識を深めたいと思い、情報処理技術者試験である「データベーススペシャリスト試験」を受験し、無事合格することができました。 過去にもいくつか資格試験を受験しましたが、特にデータベーススペシャリストの知識は業務でも役に立っていると感じています。 そこで、どう役に立っているかを本記事で説明します。 読み物として、軽い気持ちで読んでいただければと思います。
1.テーブル設計がしやすくなった
テーブル設計を検討する際、いきなりテーブルと詳細な属性から考えるよりもまずE-R図を書くほうが整理して考えやすいと感じています。 データベーススペシャリスト試験では、午後試験でE-R図を書く問題が出てくるので、その試験対策をすることでE-R図が書きやすくなりました。
例えば、以下キャプチャのように、欠落しているいくつかのリレーションシップをすべて補う問題がよく出ます。
試験対策を行った際、全体の5割～8割程度のリレーションシップが欠落している問題が多いと感じました。 そのため、試験勉強でも1からE-R図を設計する気持ちで問題演習をしていました。 E-R図の書き方を知るだけというよりは、実際にE-R図を書いてみるほうが理解が深まるので、この試験対策を通してE-R図の書き方はかなりイメージが深まったかと思っています。
2.DB調査を行いやすくなった
私の担当業務では、不具合の発生状況調査などの一環でDB調査を行うことがあります。 不具合発生条件（例えば、特定の文字を含むデータが仕様通り処理できないなど）を整理したうえで、その条件を満たすデータ一覧が取得可能なSQLを実行して調査します。 試験対策したことにより、そういったSQLが書きやすくなったと感じています。
データベーススペシャリスト試験では、SQLの一部を書く問題が出てきます。
SQL全文を書く問題は自分が過去問を解いた限りでは出てこなかったのですが、問題文に出てくるSQL文の中には挙動イメージが湧かないものもありました。 なので、自分のローカル環境でDBコンテナを立てて、イメージが湧かなかったSQLの表現を抜粋して実行してみたりもしました。 上記のE-R図の内容と重複しますが、SQLを読むだけより実際に書いてみるほうが、理解も格段に深まって結果的に業務にも役立ちやすくなったと考えています。
3.より幅広いDB調査手段を知ることができた
DB調査では、複雑なデータ状況を調べたいこともあります。
例えば、下記のように生徒の試験スコアがstudentテーブルで管理されているとします。
ここから、クラスごとに試験スコアが2位以上の生徒一覧をリストアップしたいとします。 私が知っていたようなWHERE句やORDER BY句などの知識だけではスコアの順位付けをすることができません。
※上記例はデータ数も少ないので目視で順位を見ることもできますが、データ数が膨大になると難しくなります。
このリストアップは、ウインドウ関数のRANK()を使うと可能になります。 dev.mysql.com
SQLは以下です。
SELECT * FROM (
SELECT *,
RANK() OVER(PARTITION BY class_id ORDER BY score DESC) AS rankings_by_class
FROM db.student
) rankings_by_class_table
WHERE rankings_by_class <= 2;
データベーススペシャリスト試験では幅広いSQLが出てきます。 例えば、上述したウインドウ関数(以下キャプチャの例ではLAG())も出てきました。
ウインドウ関数も試験対策で初めて知ったので、この関数も含めた複雑なSQLの知識を習得することで、調査可能なデータ状況の幅が広がったと感じています。
実際のDB調査では、WHERE句などを知っていれば十分なこともあります。 ただ、いざ複雑なDB調査が必要になった場合、データベーススペシャリスト試験で初めて知ったSQLが使えそうと感じることもありました。 もしそのようなSQLを知らなくても、インターネット検索して知ることができるケースも多いかと思います。 それでも最初から知っているとそうでないとで取っ掛かりやすさも大きく違うのかなと感じました。 特に、DB調査が必要になったときはすぐにデータ状況を知りたいこともあると思うので、その場合は今ある知識の範囲でSQLを作成しがちになるためです。
4.DBの非機能要件をより意識できるようになった
システム設計時、まず機能要件（商品検索といった、システムが何をできるかという要件）を満たしているかを意識することが多いかと思います。 ユーザーの目に見える部分となるためです。
一方、非機能要件（システムの応答速度といった、機能以外の品質要件）を満たしているかも重要です。 ユーザー満足度やシステムの信頼性に繋がるためです。
DBに関連した非機能要件だと、下記あたりはよく議論としてあがるのではないでしょうか。
- トランザクションが適切に設定されているか
- デッドロックが起きないか
いずれも業務で頻出ですが、試験対策で理解を深めることで、業務のシステム設計でも強く意識できるようになりました。
トランザクション
トランザクションとは、一連のデータ処理をまとめて管理する仕組みです。
例えば、Confluenceといったウィキサービスでは、ページ保存時に履歴情報も追加され、過去ページも見ることができるものが多いかと思います。 つまり、このような例では現行データと履歴データの2種類が保存されます。 もし現行データ→履歴データという順でDBに保存されるとすると、1つのトランザクションで現行データと履歴データを保存されるのが一般的には適切かと思います。 もし現行データ保存と履歴データ保存が別々のトランザクションでなされると、履歴データ保存が失敗したときは履歴データがロールバックされますが、現行データはロールバックされません。 この場合、現行データと履歴データの状態が合わず、不自然になります。
このように、データの品質を高めるため、機能に応じて適切にトランザクションを設定する必要があります。
デッドロック
デッドロックとは、複数の処理がお互いの処理終了を待ち続け、結果的にどの処理も進まなくなる事象です。
システムの設計が適切でないことが原因で起きますが、中でもデータ処理順が不定なことが原因となることが多いです。 この場合、例えばデータのID順に処理する設計へと見直すことで、デッドロックが起きなくなります。
なお参考までですが、例えば下記にてデッドロックの問題が出てきています。
まとめ
ここまでで、データベーススペシャリスト試験を受験して業務でも役に立っていることを書いてきました。 DBに関する一般的な知見が身につく試験なので、DBを扱う現場であればどこでも役に立つのではないかと考えています。 本記事がどなたかの受験モチベーションアップ寄与に繋がれば幸いです。
執筆者：上村 真弘
Webアプリケーションの開発管理をしています。
過去記事：https://tech.nri-net.com/archive/author/m2-kamimura
