2025年度 データベーススペシャリスト試験に合格しました
2025年度（令和7年度）のデータベーススペシャリスト試験に合格しました。
高度試験の中でも午後問題で特殊な対策が必要だと感じたため、これから受験される方向けに、私が行った勉強方法や対策メモを記載します。
自己紹介
- 大学院 工学系研究科を2022年3月に卒業
- 研究は深層学習を使ったデータ分析でした
- 現在はIT企業でソフトウェアエンジニアとして勤務中
- バックエンドを中心としたWebアプリが多いです
- テーブル設計やSQLチューニングの経験は一定あるものの体系立てて学んでいない状態でした
- 保持資格は以下の通りです。高度試験は初の合格でした
- AWS/Google Cloud資格 いくつか
- 応用情報技術者
- 基本情報技術者
データベーススペシャリストについて
試験は 午前I・午前II・午後I・午後II の4区分から構成されます。
合計4-5時間のため体力や精神力も必要です。
2026年度CBT移行後も出題数や時間は同じとされています。
午前I（50分／四肢択一30問）
広い範囲の基礎知識チェックで、DBに限らずネットワーク、セキュリティ、開発、マネジメントなども含みます。
午前Iは共通問題で、応用情報の午前問題から出題される形です。
高度試験では午前I免除制度があるため、ぜひ活用したいです（後述）。
午前II（40分／四肢択一25問）
ここからDB寄りになります。
SQL、正規化、トランザクション、排他制御、障害回復、性能、分散／レプリケーションなど、午後問題の基礎となる知識が混ざってきます。
試験時間が短いので注意が必要です。
午後I（90分／記述式：3問中2問解答）
午後Iから記述式になります。
長文＋図表＋SQL断片のような実務寄りの状況が与えられ、設問に沿って解答していく形式です。
正規化の根拠を書かせる問題や、概念データモデル設計、SQLの穴埋めなどが頻出です。
午後II（120分／記述式：2問中1問解答）
ラスボスです。
問題文が長く、設計の整合性を最後まで崩さずに120分間を走り切る体力が要ります。
例年、物理設計／論理設計の2題から1題選択という形で出る年が多いです（後述）。
合格基準
各区分で100点中60点以上が必要です。
また「多段階選抜方式」が採用されており、午前Iが基準未達なら午前II以降は採点されない、午前IIが未達なら午後以降は採点されない……という仕組みです。
受験結果
2025年度の得点は次の通りでした。
- 午前I 免除
- 午前II 76点
- 午後I 80点
- 午後II 75点
結果的にはバランスよく得点できた形となります。個人的には午前IIの手応えがなく、当日に自己採点して一安心した記憶があります。
2024年にも受験したのですが、午後IIで4点足りず不合格でした。
不合格とはいえ、このおかげで午前Iが免除となり、2025年度は午後対策に集中することができました。午前Iは他の3区分と出題範囲が全く異なるため、午前Iの免除は非常に大きいです。
これから受験される方も、まずは午前Iの免除を目指すことを強く推奨します。
受験のきっかけ
シンプルに「データベースに詳しくなりたい」という動機から受験しました。
業務でバックエンド開発をしていると、テーブル設計、インデックス設計、トランザクション設計など、DBの判断が品質を左右する場面に必ず当たります。業務中に都度キャッチアップしたり技術書を読んだりもしていましたが、断片的な知識が増えるだけで、芯が通っていない感覚がありました。一度しっかりと腰を据えて体系的に勉強すべきだと感じて受験を決めました。
クラウドのデータベース系の資格も検討したのですが、各サービスやソリューションの機能や特徴を問われる問題が多く、今回の目的にはノイズだったためデータベーススペシャリストにしました。
DBの知識を身につけるという目的自体は2024年度の受験で概ね果たせたのですが……やはり合格したいと感じてしまい、2025年も受験しました。
試験対策
勉強法
データベーススペシャリストに合格するには過去問演習が最も重要です。
前述の通り、データベーススペシャリスト試験は午前I、午前II、午後I、午後IIの4区分に分かれています。
特に難しいのは午後IIです。例年、物理設計・論理設計の2題が出題され、そのうち1題を選択して回答します。
私は「何があっても論理設計を選ぶ」と決めていました。主な理由は次の2つです。
- 出題形式が毎年ある程度似ており大事故が起こりにくそうなこと
- 論理設計を選ぶ人が多いため参考書やネット上の解説などの知見が豊富そうなこと
この選択方針の固定は結果的に有効でした。本番で問題を見てから迷う時間が発生しないので解答作成に集中できました。
最終的なスケジュールは以下の通りでした。
- 6-7月：試験範囲の座学 + 午前IIの過去問演習
- 正規化、キー設計、SQL、排他制御、障害回復、性能、バックアップ… などを参考書で広く確認する
- 完璧を目指すより午後問題で見たときに思い出せるフックを作る意識
- 簡単にSQLを書いてみる程度はしたものの、基本は参考書の熟読と午前IIの演習がメイン
- 8-10月：午後I＋午後IIの論理設計の過去問演習
- 解く → 複数媒体の解説を読む → もう一度解く、を繰り返す
- 最終的には約5年分の論理設計を解きました
「5年分は少ないのでは？」と思われるかもしれませんが、私は逆に、古い年度を広く浅く回すより、直近の問題を完全に理解する方が効果が高いと感じました。データベーススペシャリストは年ごとに題材やクセが変わるので、最新傾向に近い問題の理解密度を上げる方針にしました。これは正しかったと思います。
ただ、論理設計は解説を読んでもよく分からないことが多いんですよね…。
勉強の後半になっても自分の考え方の何が間違っているのか全く分からない、理解しきれないことがありました。今も普通にあります。
- 「なぜこの関係は1対多ではなく1対1なのか」
- 「なぜこの属性は複合主キーに含めなくてよいのか」
- 「なぜこのサブタイプは共存的サブタイプではなく排他的サブタイプなのか」
- 「なぜこの属性に外部キーを持たせる必要がないのか」
など挙げるとキリがありませんが、それくらい常識だと考えられてしまうのか、とにかく解答解説に納得できない場面が多かったです。
対策として私が意識していたのは、複数媒体の解説に当たることでした。
特に、後述するYouTube解説は、問題文をどの順番でどう読んで何を判断するかを追体験できるため非常におすすめです。
勉強法とは少しズレますがネット上の受験体験記を読むのもおすすめです。
他の受験者の方がどこで苦戦して、何を捨てて、何を拾ったのかが分かるので、戦略を固める助けになります。
使用した教材
[参考書] 情報処理教科書 データベーススペシャリスト 2025年版
データベースの実務経験がある方はこれ一冊でよいです。
20年以上分の過去問と解説が付いており、解説も非常に丁寧です。
座学パートもデータベース自体というよりはデータベーススペシャリスト試験に特化した内容となっています。
[参考書] 徹底攻略 データベーススペシャリスト教科書 令和7年度
名前の通り、座学用の辞書兼教科書として使っていました。
情報処理教科書だけだと理解が薄いテーマが出てきたときに、ここへ戻って補強する、という使い分けです。電子版が付いているのが最高です。
[YouTube] SE歴20年の人
午後I・午後IIの論理設計を中心に解説されているYouTubeチャンネルです。
ゆっくり実況スタイルで頭に入ってきやすく、どこで悩むのかという人間的な感覚・コメントが非常にタメになります。
私はこのチャンネルのおかげで論理設計が解けるようになりました。論理設計を解く方は必見のチャンネルです。
[YouTube] IT技術の寺子屋
こちらは論理設計の解き方も参考にさせてもらいましたが、より基礎の整理（午前II〜午後I寄り）に効きました。
図解や言い換えが入る回が多く、参考書の文章を読んでいて頭に入らない場合に助かりました。
[Webサイト] 情報処理試験まとめwiki
午後I、午後IIの論理設計の攻略に使いました。
勉強法から具体的な解答テクニックまで載っているため、一度目を通すことを強く推奨します。特に論理設計の解答テクニックは必見です。
[Webサイト] データベーススペシャリスト ドットコム
午前IIの対策で、回転数を上げる用途に使いました。まとまった時間が取れない日でも、スマホで数問だけ解いて弱点を可視化できるのが便利です。
また、掲示板機能もあります。私は使いませんでしたが、不明点の質問をしている方が多いようです。
余談ですが、2025年度のデータベーススペシャリスト試験は午後IIの論理設計問題が難解で掲示板が大荒れしていました。
問1(物理設計)のコメント42件に対して問2(論理設計)は247件…。
試験対策メモ
私が勉強中に作成したメモの抜粋を記載します。
記述問題と論理設計の解答テクニックが中心です。
あくまでメモなので雑な内容ですが、参考にできる部分があれば幸いです。
記述問題の常套句
- 20 字以内の場合
- 設問の表現をそのまま使う
- 空白マスの字数によって文章のまとめ方を決める
- 50 字以上の場合
- 結論から先に書く
- キーワードを書く
正規化の根拠を説明させるもの
第一正規形でない理由（正規化されていない理由）
- 属性 ○○ は属性 △△ の集合であり単一値ではないため
- 属性 ○○ が繰り返し項目であり単一値ではないため
第一正規形の理由
- すべての属性が単一値で、候補キーＡ、Ｂの一部であるＢに非キー属性のＣが部分関数従属するため
- 非キー属性であるＣが候補キーの一部であるＢに関数従属し、候補キーに完全関数従属していないから
- 非キー属性であるＣが候補キーの部分集合｛Ａ、Ｂ｝に関数従属し、候補キーに完全関数従属していないから
第二正規形の理由
- すべての属性が単一値で、候補キーからの部分関数従属がなく、推移的関数従属性Ａ → Ｂ → Ｃがあるため
第三正規形の理由
- すべての属性が単一値で、候補キーからの部分関数従属がなく、候補キーからの推移的関数従属性もないため
更新時異常の具体的状況を説明させるもの
- 正規化していないことで発生する問題についても定型文が存在する
- 例えば第二正規形で終わっているテーブルは
- 「属性 ○○ が重複して登録される」
- 「事前に属性 ○○ を登録しておくことができない」
- 「属性 ○○ の更新時に整合性がとれなくなる」
- などだ。これも午後 1 では頻出ワードになるので覚えておくこと。
論理設計 解答テクニック
-
設問の構成を最初に調べる
- 問題の構成は、おおむね最初に企業の業種や組織、業務プロセス、システムのテーブル構造を文章で説明し、その後に業務の改善要望が記述されているパターンが多い
- ほとんどの問題で「現状の業務やシステムの説明 → 新しい要望の説明」となっていて区切りがつけられている
- 設問も現状の業務の解説と改善要望は分けられているので、「現状の業務」の説明まで読んだらその部分をまず解答して現状のテーブル構造を確定してしまう
- それから新しい要望に取りかかったほうが効率がいい
-
問題文を読みながら会社の仕組み、ビジネスロジックなどを簡単な図でまとめる
- 午後 1 にも午後 2 にも言えることだが、その会社の組織やビジネスロジックを理解することはとても重要
- そのため問題文を読みながらその組織の組織図、伝票の作られ方、商品の配送方法などを簡単にメモしながら問題文を読んでいくようにすると、すんなり組織を覚えることができる
- 例えば、「本社があり、商圏をいくつかの地域に分け、そこに複数の支社がある。配送センターは地域に一つだけある。営業担当は同じ地域の複数の支社に所属することがある。」みたいな記述がある場合には、以下のように簡単な図を作ってまとめる
- こうすると頭の中で簡単に整理できる
本社 - 地域 - 配送センター - 支社 - 営業担当 - 支社 x 営業担当 - 支社 - 営業担当 - 地域 - 配送センター - 支社 - 営業担当 -
問題文と ER 図、関係スキーマなどの図表を見比べて確認する
- データベーススペシャリストの午後 2 問題は業務プロセスを文章で説明し、そしてテーブル構造を答えさせようとしている
- 逆に言えばテーブル構造を文章で説明していることになる
- 説明はおおむねテーブルごとに、それぞれのテーブルについて解説している
- なので、もし問題文に関係スキーマ（テーブル）、概念データモデル（ER 図）が図や表として記述されているようなら、問題文とそれらの図や表をページをめくり行き来し、問題文中のテーブルの説明と図や表中に記述されているテーブルを比較し記述内容を確認するようにする
- 例えば「企業には複数の支社があり支社コードで識別される」などという説明があれば、おそらく支社テーブルが存在し、支社コードが主キーとなっているであろうことがわかる
- そしたら関係スキーマや ER 図を調べて支社テーブルを探して、テーブルがあることの確認と、支社コードが候補キーまたは主キーとして存在していることを確認する
- もし支社テーブルに該当するテーブルがなかったり、そのテーブルに支社コード属性がない場合、そのテーブルや属性を答えさせる設問が出る可能性が高い
-
問題文へのマーキング
- 上記のように問題文と関係スキーマや ER 図を行き来し、一つ一つ確認していくとおかしな記述があったり、該当するテーブルがなかったりする場合がある
- テーブルがない場合：ひょっとしたら虫食い問題になっている可能性があるので、その部分は非常に重要
- とりあえず疑問に思いながらも問題文を読み進むわけだが、読み進めるうちに忘れてしまう可能性があるので疑問を感じた部分に下線を引いて欄外に「はてなマーク」を書いておこう
- 可能なら欄外に「支社テーブルがあるはず？」「主キーとして支社コードがない？」などとメモしておく。こうすると、あとで簡単に見直すことができる
- また、読み進めるとロジック的におかしいなと思われる部分を見つけることもある
- 例えば将来的に商品の値段を変更する可能性があるのに、その商品の値段の履歴を残すようなテーブル構造になっていないような場合である
- これだと商品の値段を変更すると過去の売上げの値段すべてが変更されて金額がおかしくなってしまう
- こういうものを見かけたときも下線を引いて「価格変更履歴テーブルは？」などと記述しておく
- 例えば将来的に商品の値段を変更する可能性があるのに、その商品の値段の履歴を残すようなテーブル構造になっていないような場合である
-
キーとリレーションシップについて
- 矢印 (→) は主キーから外部キーへ
- 主キーが全く同じなら 1 対 1、明細など追加のキーがあれば 1 対多の関係
- 主キーにユニークなキーが含まれていたら、それ以上の付属品は付けるべきではない
- 1 つのテーブルに複数のリレーションが来ている場合、共通の情報を持ってはいけない
- テーブル A からテーブル B、テーブル B からテーブル C へとつながるリレーションシップがあるにも関わらず、A と C が同じ情報を持つのはご法度
- 高々 1 名＝ 0 名もありうる。高々一つのリレーションは 1 対 1
- リレーションシップが 1 対 1 の場合，意味的に後からインスタンスが発生する側のエンティティタイプに外部キー属性を配置する
- カラム名に意味を持たせないといけない場合がある（× 会員コード 〇代表会員コード）
- 対応表は多対多の関係なので連関エンティティを設ける可能性が高い
- 在庫の倉庫間移動では入出庫に関連を持つ可能性を疑う
- 「～を記録している」という表現は必要な属性になる
-
サブタイプについて
- スーパータイプとサブタイプの主キーは一致する
- サブタイプの主キーを外部キーとして区別する必要があるときは、主キーそのままではなく、どのサブタイプの主キーを外部キーとして使うか明示する
- 「サブタイプが複数のスーパータイプを持つパターン」の場合
- 概念データモデルにはそのまま記述すればいい
- 一方、関係スキーマでは，片方のスーパータイプの主キーをサブタイプの主キーに設定し，それ以外のスーパータイプの主キーは外部キーとして持たせる必要がある
- 共存型(切口 2 つ)かそれ以外(切口 1 つ)か判別
- あるサブタイプに複数のスーパータイプがある場合、各スーパータイプの主キーを外部キーとして持つ
- 区分が出たらサブタイプ化が基本であるが区分がなくてもサブタイプ化が必要な場合もある
-
反応すべきキーワード
- 「A ごとの B コードで識別している」 = A と B が主キー
- 「A ごと B ごとに」 = A と B が主キー
- 「A からの B は」 = A を特定できる外部キーが必要
- 「A を B に対応させて」 = 1 対 1
- 「A は、B と C に分類される」= B と C がサブタイプ
- 「A には、B と C がある」 = B と C がサブタイプ
- 「A は、B と C からなる」 = B と C がサブタイプ
- 「A ごとに B, C が決める」 = A が主キー、B, C は属性
- 「～で識別し」という表現は“主キー”になる
- 「～をもつ」という表現は，必要な属性になる
- 「フラグで分類し」という表現は，共存的サブタイプをもつことになる
- 「〜で区分し」という表現は、排他的サブタイプをもつことになる
- 「階層構造」「下位・上位の部門」という表現は「自己参照」だと判断できる
- 「複数をまとめる」とか「一つを分解する」という表現がない場合、1 対 1 の可能性がある
- 「A は B の上位の分類で」という表現は，A と B が 1 対多の関係にあることを示す
おわりに
初の高度試験合格だったため素直に達成感がありました。2024年度は午後IIであと一歩届かず不合格だったこともあり、翌年にリベンジできたのは嬉しかったです。
合格そのもの以上に良かったのは、データベース設計の知識が体系化できたことでした。特に正規化とキー設計は効果が大きく、テーブル設計で迷ったときに「なぜそうするのか」を説明できるようになりました。実務でそのまま効いています。
資格勉強は、今後も実務に活かせるものであれば細々と続けたいです。次はIPAだとセキスペ（情報処理安全確保支援士）、クラウド系だとネットワーク周りの資格を考えています。
読んでいただきありがとうございました。
Discussion