データベーススペシャリスト試験とは？傾向は？過去問は役に立つ？AIに予想問題を作らせてみた
データベーススペシャリスト（通称：DB）は、企業や組織の膨大な情報を管理する「データベース」に関する高度な知識と技能を証明する、情報処理技術者試験の中でも特に難易度が高い「高度試験」の一つです。
データベースは、私たちが日々利用するWebサービスや、企業の顧客情報管理、ECサイトの商品情報など、あらゆるデジタル情報の根幹を支える存在です。この資格を持つ人は、単にデータベースを操作するだけでなく、データが持つ意味を深く理解し、効率的で安全、かつ信頼性の高いデータベースシステムを企画、要件定義、設計、開発、運用、そして保守することが求められます。
データベースの構造を設計する「論理設計」や「物理設計」、複雑なデータを効率よく取り出すための「SQL」という言語のスキル、そして障害が発生した際のバックアップや復旧、性能改善など、多岐にわたる専門的な知識が問われます。
試験の難易度と合格率について
データベーススペシャリスト試験は、情報処理技術者試験の中でも、特に専門性が高い「スペシャリスト系」の高度試験に位置づけられています。合格率は毎回変動しますが、一般的に15%から20%前後で推移しており、非常に難易度が高い試験として知られています。この合格率からも、合格するためには、表面的な知識だけでなく、深い理解と実践的な応用力が不可欠であることがお分かりいただけるかと思います。
試験の出題傾向はどのように変わってきていますか？
データベーススペシャリスト試験の出題傾向は、近年のデータ管理技術の進化や、新しいデータベースの登場に合わせて、常に変化しています。単に過去の知識を問うのではなく、現代のデータ活用における課題を解決するための思考力や判断力を試す問題が増えているのが特徴です。
午前問題の傾向
午前問題は、選択式の四肢択一形式で、データベースに関する広範な知識が問われます。
- 午前Ⅰ： 応用情報技術者試験の午前問題とほぼ同じレベルの内容が出題されます。マネジメント、テクノロジ、ストラテジの分野から幅広く出題され、基礎的な知識が問われます。
- 午前Ⅱ： データベースに特化した専門的な知識が中心となります。データベースの概念、論理設計、物理設計、SQL、トランザクション処理、セキュリティなど、データベーススペシャリストに特化した内容が出題されます。近年では、NoSQLデータベース（リレーショナルデータベース以外のデータベース）やビッグデータ、データ分析といった、新しい技術トレンドに関する問題も増えています。
これらの問題は、単に用語を覚えるだけでなく、その技術がどのような仕組みで動いているのか、どのような場面で使われるのかといった深い理解が求められます。
午後問題の傾向
午後問題は、記述式で、長文の事例問題を読み解き、論理的に回答する形式です。これがこの試験の最大の難関と言えるでしょう。
- 午後Ⅰ： 業務システムの要件を読み解き、データベースの論理設計や物理設計を行う能力が問われます。例えば、新しい業務システムの仕様書を読み解き、最適なテーブル構造やインデックスを設計する問題、あるいはSQL文を適切に作成する問題などが出題されます。
- 午後Ⅱ： より高度な視点から、データベースシステムの運用管理や性能改善、障害対応に関する問題が出題されることが多いです。データベースの性能が低下している原因を分析し、改善策を提案する問題や、セキュリティ対策、バックアップ・リカバリ計画に関する問題などがあります。
午後問題の傾向として、単一の技術知識だけでなく、複数の技術要素やマネジメントの観点を組み合わせて回答させる問題が増えています。また、ビッグデータやクラウドデータベースなど、新しい技術を前提とした問題も増えており、日頃からデータベース関連の新しい動向にアンテナを張っておくことが非常に大切です。
過去問は試験対策に役立ちますか？
過去問はデータベーススペシャリスト試験の対策において、非常に重要な役割を果たします。過去問を解くことは、単に問題の答えを覚えるためだけではなく、以下のような、より深い学習効果をもたらします。
- 出題傾向と形式の把握: 過去問を解くことで、どのような分野からどのような形式で問題が出題されるのか、その傾向を肌で感じることができます。特に午後問題では、長文の読み方、設問の意図の汲み取り方、記述の仕方など、独特のコツが必要になります。
- 時間配分の練習: 試験本番では、限られた時間内に膨大な量の問題を解き進める必要があります。特に午後問題は時間が足りなくなることが多いので、過去問を解くことで、どのくらいのペースで進めればよいのか、時間配分の感覚を養うことができます。
- 知識の定着と応用力の強化: 過去問を解いて間違えた問題は、ご自身の弱点を知る良い機会になります。解説をしっかり読み込むことで、なぜその答えになるのかを深く理解し、知識を定着させることができます。また、似たような問題でも少し視点を変えて出題されることが多いため、過去問を通して、学んだ知識を応用する力を鍛えることができます。
ただ、過去問をただ漫然と解くだけでは、十分な効果は得られません。大切なのは、「なぜその答えになるのか」を深く考察し、解説をしっかり読み込むことです。特に午後問題では、解答の根拠が本文のどこにあるのか、なぜその記述が求められているのかを丁寧に分析することが、合格への近道になります。
効果的な学習対策はありますか？
データベーススペシャリスト試験に合格するためには、計画的で効率的な学習が不可欠です。以下に、おすすめの学習方法をいくつかご紹介しますね。
1. 午前問題対策の進め方
- 基礎知識の定着: まずは、午前Ⅰで問われる応用情報技術者試験レベルの基礎知識をしっかりと固めましょう。もし応用情報技術者試験に合格済みであれば、午前Ⅰは免除される場合がありますので、ご自身の状況を確認してみてください。
- 専門知識のインプット: 午前Ⅱ対策としては、データベースに関する専門書や参考書を使って、体系的に知識をインプットすることが大切です。特に、正規化、トランザクション、排他制御といったデータベースの根幹となる概念は、重点的に学習しましょう。
- 繰り返し問題を解く: 過去問や予想問題集を繰り返し解くことで、知識を定着させます。間違えた問題は、解説を読み、なぜ間違えたのかを理解することが重要です。
2. 午後問題対策の進め方
午後問題は、単なる知識問題ではないため、特別な対策が必要です。
- 過去問を徹底的に分析: 午後問題の対策は、何よりも過去問が最も重要です。過去5年分程度の過去問を、時間を測って実際に解いてみましょう。
- 解答の思考プロセスを学ぶ: 過去問を解いた後は、解説を丁寧に読み込み、正解に至るまでの思考プロセスを理解することが大切です。解説書によっては、解答の根拠が本文のどこにあるのか、どのような知識を組み合わせて解答を導き出すのかが詳しく書かれています。
- SQLの練習: 午後問題ではSQL文の作成や読解がよく問われます。実際にデータベースソフトをインストールし、SQL文を書いてみることで、より実践的なスキルを身につけることができます。
- 業務要件の読み取り練習: 午後問題は、実際の業務を想定したシナリオ形式で出題されます。設問の意図を正確に読み取り、業務要件とデータベース設計の関係性を理解する練習を重ねることが重要です。
3. 専門用語を分かりやすく理解する
この試験には多くの専門用語が出てきます。例えば、「正規化」や「トランザクション」、「インデックス」、「排他制御」などです。これらの用語をただ覚えるだけでなく、どのような仕組みで、何のために使われているのかを、身近な例え話などを交えて理解すると、記憶に残りやすくなります。
例えば、「正規化」は、整理整頓された本棚のようなものだと考えてみましょう。同じ本が複数の場所に散らばっていると、どこに何があるか分からなくなり、探すのに時間がかかります。正規化は、この散らばったデータを一つの場所にまとめ、無駄なく整理することで、データの整合性を保ち、効率よく取り出せるようにするための作業です。このように、専門用語を自分の言葉で説明できるようになることが、深い理解につながります。
どのような仕事に役立ちますか？
データベーススペシャリストの資格は、幅広い職種や業務であなたの専門性を証明し、キャリアアップに繋がります。
1. データベースエンジニア/データベース管理者（DBA）
最も直接的に役立つのがこの職種です。データベースの設計、構築、運用、そして性能チューニングや障害対応など、専門的なデータベース業務を行う上で、国が認めた専門家として大きな信頼を得ることができます。
2. システムコンサルタント
お客様の課題をヒアリングし、情報システム全体をデータの観点から最適化する提案を行う仕事です。この資格を持つことで、お客様は「この人に任せれば安心だ」と感じ、信頼関係を築きやすくなります。
3. データサイエンティスト/データアナリスト
膨大なデータから価値ある情報を引き出す仕事です。この資格を持つことで、データの構造を深く理解し、効率的なデータ収集・分析基盤を構築する能力を証明できます。
4. システム開発者/プログラマー
Webサービスや業務システムを開発する上で、データベースは切っても切れない関係です。この資格を持つことで、性能や保守性を考慮したデータベース設計ができるようになり、開発者としての市場価値を高めることができます。
5. IT監査/リスクマネジメント
企業のITシステムが、適切にデータを管理し、セキュリティ対策を取っているかを評価・監査する仕事です。データベーススペシャリストは、データ管理に関する深い知識を持っているため、監査人として客観的で専門的な評価を行うことができます。
転職時には有利になりますか？
データベーススペシャリストの資格は、転職活動において非常に有利に働きます。特に、IT業界や、データ駆動型のビジネスを展開する企業への転職を考えている方にとっては、大きな武器となります。
1. 専門性の証明
履歴書にこの資格を記載することで、あなたがデータベースに関する専門的な知識と実践的な能力を持っていることを、明確にアピールできます。これは、採用担当者にとって、あなたのスキルレベルを判断する上で非常に分かりやすい指標となります。
2. 企業からの高い需要
近年、企業のDX（デジタルトランスフォーメーション）が進む中で、データの重要性はますます高まっています。そのため、データベースの専門家に対する需要は非常に高く、データベーススペシャリストの資格を持つ人材は、多くの企業で求められています。
3. 信頼性の向上
国が認定する国家資格であるため、その信頼性は非常に高いです。お客様や取引先に対しても、あなたの専門家としての信頼性をアピールすることができ、ビジネスの場で有利に働くことがあります。
4. キャリアチェンジのきっかけに
今とは少し違う分野、例えば、プログラマーからデータ管理の専門家へのキャリアチェンジを考えている場合、この資格は、その第一歩を踏み出すための強力な後押しとなります。
ただし、資格を持っているだけでは十分ではありません。資格に加えて、これまでの実務経験や、ご自身がどのようにデータベースの知識を活かしてきたのかを、具体的なエピソードを交えて説明できるよう準備しておくことが大切です。
AIに奪われる可能性は？これからも必要とされますか？
「AIが発展したら、データベースの仕事もAIに取って代わられるのでは？」というご不安は、多くの方がお持ちだと思います。結論から申し上げますと、データベーススペシャリストのような専門家は、これからも必要とされ続ける可能性が非常に高いです。むしろ、AIの進化によって、その役割はより重要になっていくと私は考えています。
AIとデータベースの関係
たしかに、AIは膨大なデータを高速で分析し、最適なSQL文を生成したり、データベースの性能を自動でチューニングしたりする可能性があります。すでに多くのデータベース製品にAIが活用されており、定型的な運用業務の一部はAIが担うようになっていくでしょう。
しかし、データベーススペシャリストが担う仕事は、単にSQLを書いたり、チューニングをしたりするだけではありません。
- 業務要件の理解と設計: AIは、業務の背景や目的、データの持つ意味、そしてユーザーのニーズを深く理解した上で、最適なデータベース構造をゼロから設計することは難しいです。
- 複雑な問題解決と戦略: データベースの運用では、予期せぬ障害や、複数のシステムにまたがる複雑な問題に直面することがよくあります。その際に、既存の知識を組み合わせ、創造的な解決策を導き出す能力は、人間にしかできない仕事です。
- データ活用の提案とガバナンス: データベーススペシャリストは、単に技術的な専門家であるだけでなく、ビジネスの観点から「データをどう活用すれば価値を生み出せるか」を提案する役割も担います。また、データの品質やセキュリティを管理する「データガバナンス」の策定も、人間が主導すべき重要な業務です。
これからのデータベーススペシャリストの役割
AIの進化は、データベーススペシャリストの仕事を奪うのではなく、むしろ、より高度で戦略的な業務に集中できる環境を整えてくれるものと捉えるべきです。
これからのデータベーススペシャリストは、AIを「ツール」として使いこなしながら、以下のような役割を担っていくことになります。
- AIを活用したデータ分析基盤の設計者: AIが効率的に学習・分析できるよう、最適なデータ収集・管理基盤を設計する専門家が求められます。
- AIが生成したSQLや設計の検証者: AIが生成したコードや設計が、セキュリティや性能、業務要件といった厳しい要件を満たしているかを、専門家として評価・検証する役割です。
- データ戦略の立案者: 企業のデータ資産を最大化するため、どのようなデータを収集し、どのように活用していくかという、より大きな視点でのデータ戦略を立案する役割です。
このように、AIが進化すればするほど、その技術を深く理解し、適切に活用し、そしてデータが持つ価値を最大化できる、データベーススペシャリストのような専門家の価値は、ますます高まっていくと私は考えています。
情報のまとめと次に進むためのアドバイス
データベーススペシャリスト試験について、幅広くご説明してまいりました。最後に、これまでの内容を整理し、あなたがこれからの一歩を踏み出すためのアドバイスをお伝えしますね。
この記事の主要なポイント
- データベーススペシャリストとは: 膨大なデータを管理・活用する専門家として、国が認める国家資格です。
- 試験の傾向: 近年のビッグデータやNoSQLの普及を反映した、より実践的な知識や思考力が問われる問題が増加しています。
- 過去問の活用: 単に問題を解くのではなく、なぜその答えになるのか、思考プロセスを理解することが非常に重要です。
- キャリアへのメリット: 専門性の証明、転職での優位性、そして幅広い職種での活躍が期待できます。
- AIとの未来: AIはツールであり、データベーススペシャリストはAIを使いこなし、より高度で戦略的な役割を担うことで、これからも必要とされる存在であり続けます。
もし、あなたがこの資格に少しでも興味を持たれたのでしたら、まずは情報処理推進機構（IPA）の公式サイトで、過去の試験問題やシラバス（出題範囲）をご覧になってみてください。特に午後問題の事例に目を通すだけでも、「このような問題が問われるのだな」という具体的なイメージが掴めるかと思います。
データベーススペシャリスト 予想問題（AI作成）
- 正規化の判定（3NF）
問題: 関係R(A,B,C)、関数従属性が A→B、B→C。主キー候補はA。Rはどの正規形を満たすか。
A 1NFのみ B 2NFまで C 3NFまで D BCNF
正解: B
解説: Aが主キーなので部分従属はないため2NFは満たすが、非キー属性BがCを決める推移従属があり3NF違反。 - 3NFへの分解
問題: 問1のRを3NFに分解する適切な組合せはどれか。
A R1(A,B), R2(A,C) B R1(A,B), R2(B,C) C R1(A,C), R2(B,C) D R1(A,B,C)のまま
正解: B
解説: 推移従属B→Cを切るためBを軸に分解する。 - BCNFの判定
問題: 関係S(X,Y,Z)、関数従属性 X→Y、Y→X、X→Z。SはBCNFか。
A 常にBCNF B 常に3NFだがBCNFでない C 条件次第 D 常に1NFのみ
正解: A
解説: XとYが相互に決定し合うため両方スーパーキー。すべての決定項がスーパーキーでBCNF。 - 候補キーの導出
問題: R(A,B,C,D)、FD: A→B、C→D、(A,C)→B,D。候補キーはどれか。
A A B C C C D C (A,C)
正解: D
解説: A単独ではC,Dを決められず、C単独でもA,Bを決められない。AとCで全属性が決まる。 - 多値従属性
問題: 4NFを要するのはどのケースか。
A 推移従属がある B 部分従属がある C 多値従属性がある D 関係が巨大
正解: C
解説: 多値従属性の排除が4NFの目的。 - 主キー設計（自然 vs 代理）
問題: 顧客テーブルの主キーとして妥当性が高いのは。
A メールアドレス B 電話番号 C 自動採番ID D 氏名
正解: C
解説: 変更可能性・重複可能性を避けるため安定な代理キーが適切。 - ERモデル（1対多）
問題: 部門と社員。1部門に多数社員、社員は1部門。実装として適切なのは。
A 交差テーブル B 社員に部門ID外部キー C 部門に社員ID外部キー D どちらも不要
正解: B
解説: 1対多は「多」側に外部キー。 - ERモデル（多対多）
問題: 商品と注文は多対多。適切な実装は。
A 注文に商品ID列を追加 B 商品に注文ID列を追加 C 中間表(注文明細) D どちらでも良い
正解: C
解説: 多対多は中間表で表現。 - 弱実体
問題: 注文と注文明細。明細の主キー設計で適切なのは。
A 明細ID単独 B (注文ID, 行番号) C 商品ID単独 D (商品ID, 数量)
正解: B
解説: 弱実体は親キー＋識別子（行番号）を含む。 - 正規化と性能
問題: 読み取り主体の分析系で結合回数を減らしたい。適切な方針は。
A 過度に正規化 B スキーマをスター型にデノーマライズ C すべて1NFまで戻す D インデックスを全削除
正解: B
解説: DWHはディメンションを非正規化したスター型が一般的。 - 参照整合性（ON DELETE）
問題: 親の削除時に子も自動削除したい。適切な制約は。
A ON DELETE RESTRICT B ON DELETE SET NULL C ON DELETE NO ACTION D ON DELETE CASCADE
正解: D
解説: 連鎖削除はCASCADE。 - 一意制約とNULL
問題: 一意インデックスとNULLの扱いで一般的に正しいのは。
A NULLは常に同値で重複不可 B DBMSによりNULLの複数許容がある C 常に複数NULL許容 D 一意制約と無関係
正解: B
解説: 実装差がある（例: Oracleは複数NULL可、SQL Serverは不可の設定もある）。 - 集合演算
問題: 2つの問合せの集合差を求める標準SQLは。
A INTERSECT B UNION C EXCEPT D MINUS
正解: C
解説: 標準はEXCEPT（製品によりMINUS）。 - GROUP BYとHAVING
問題: 集計後の条件を課す句は。
A WHERE B HAVING C QUALIFY D OVER
正解: B
解説: HAVINGはグループに対する条件。 - ウィンドウ関数
問題: 部門内で給与が高い順の連番を振る関数は。
A RANK() OVER(PARTITION BY 部門 ORDER BY 給与 DESC)
B SUM() OVER(…)
C DENSE_AGG()
D ROWCOUNT()
正解: A
解説: RANK/DENSE_RANK/ROW_NUMBERが代表。設問はRANKの例。 - 上位N取得（部門ごと上位1人）
問題: 部門ごとに給与トップのみ取得する一般的解法は。
A DISTINCT ON(部門) B サブクエリ＋MAX(給与)結合 C PARTITION BYでRANK=1を抽出 D すべて同等
正解: C
解説: ウィンドウ関数でRANK=1を抽出するのが汎用的。 - NULLと集計
問題: COUNT(列)とCOUNT()の違いは。
A 同じ B 前者はNULLを数えない C 後者はNULLのみ数える D 前者は行数、後者は非NULL
正解: B
解説: COUNT(列)は非NULLの数、COUNT()は行数。 - 相関サブクエリとパフォーマンス
問題: 相関サブクエリが遅い時の一般的対策は。
A DISTINCT追加 B JOINやウィンドウ関数に置換 C インデックス削除 D ORDER BY追加
正解: B
解説: 相関の繰返し評価を集合指向に置換。 - SARGable
問題: インデックス利用を妨げやすい条件は。
A 列 = ? B 列 BETWEEN ? AND ? C 関数(列) = ? D 列 IN (…)
正解: C
解説: 列に関数をかけると検索条件が非SARG化しやすい。 - LIKE検索
問題: 前方一致を効かせたい。最も有利なパターンは。
A ‘%abc’ B ‘abc%’ C ‘%abc%’ D ‘a%c’
正解: B
解説: 先頭固定でB-treeの範囲走査が可能。 - 結合アルゴリズム
問題: 大きな二表の等値結合（結合キーにインデックスなし）で有利なのは。
A ネステッドループ B マージ結合（事前ソート含む） C ハッシュ結合 D カルテジアン
正解: C
解説: ハッシュ結合が一般に効率的。 - マージ結合の前提
問題: マージ結合に必要な前提は。
A 両表がハッシュ化済 B 両表が結合キー順にソート済 C 片方にクラスタインデックス D 外部キーが必須
正解: B
解説: 並び順が一致していること。 - カバリングインデックス
問題: クエリがインデックスのみで完結する状況を指す用語は。
A ヒープアクセス B テーブルルックアップ C カバリング D ルーズインデックス
正解: C
解説: 取得列がすべてインデックス内にある。 - 複合インデックス順序
問題: WHERE a = ? AND b BETWEEN ? AND ?。最適な複合インデックス順序は。
A (b,a) B (a,b) C (a)のみ D (b)のみ
正解: B
解説: 等価条件→範囲条件の順に並べるのが基本。 - 統計情報
問題: 実行計画の精度に最も影響するのは。
A ページサイズ B 統計情報の鮮度 C バックアップの頻度 D ユーザー数
正解: B
解説: カーディナリティ推定の基礎。 - クラスタ化インデックス
問題: 主にデータの物理順序に影響するインデックスは。
A 非クラスタB-tree B ハッシュ C ビットマップ D クラスタ化インデックス
正解: D
解説: クラスタ化は行の物理順序を規定。 - ビットマップインデックス
問題: ビットマップインデックスが適するのは。
A 高更新OLTP B 低更新・低基数OLAP C 文字列LIKE検索 D トランザクションログ
正解: B
解説: 低更新・低基数で効果的。 - パーティションプリuning
問題: 日付列でレンジ・パーティション。効果を得るため必要なのは。
A 暗黙型変換を多用 B パーティションキーに対する直接比較 C 列に関数を適用 D 文字列比較に変換
正解: B
解説: キーに直接SARGableな述語が必要。 - フィルファクタ
問題: ランダム挿入が多いB-treeのページ分割を抑える設定は。
A 低いフィルファクタ B 高いフィルファクタ C 無関係 D 自動調整のみ
正解: A
解説: 余白を残すほど分割頻度が下がる。 - トランザクションのACID
問題: “耐久性”に該当するのは。
A 同時実行制御 B クラッシュ後もコミット結果が保持 C 一貫性制約を満たす D 原子性を保つ
正解: B
解説: コミット後の永続保持が耐久性。 - 分離レベル
問題: ダーティリードは禁止、非再読込は許容。該当する分離レベルは。
A READ UNCOMMITTED B READ COMMITTED C REPEATABLE READ D SERIALIZABLE
正解: B
解説: 読込コミット済の保証のみ。 - ファントム読込の防止
問題: ファントムを防ぐ分離レベルは。
A READ COMMITTED B REPEATABLE READ（DB依存で可の場合も） C SERIALIZABLE D いずれも不可
正解: C
解説: 理論上はSERIALIZABLEで防止。 - MVCCの長所
問題: MVCCの主目的は。
A ロックを完全不要にする B 読み取りの待ちを減らす C 書き込みを高速化 D ストレージ節約
正解: B
解説: 読み取りがスナップショット参照でブロックされにくい。 - ロックの粒度
問題: ロック競合を減らす基本戦略は。
A テーブルロックへ昇格 B 行ロックを活用 C ページロック固定 D 排他レベルを上げる
正解: B
解説: 粒度を細かくして競合を局所化。 - デッドロックの検知
問題: 一般的な対処は。
A すべて待たせ続ける B 検知後、犠牲トランザクションをロールバック C サーバ再起動 D タイムスタンプを表示
正解: B
解説: 検知・解消が実装定石。 - 更新順序のルール
問題: デッドロック回避の設計指針として有効なのは。
A 任意順序 B 大きいテーブルから更新 C 常に同じ資源取得順序 D ロックを避ける
正解: C
解説: 一貫した取得順序で循環待ちを回避。 - 2相コミット(2PC)
問題: 異種DB間の分散トランザクションで原子性を確保する方式は。
A 2PC B 3PC必須 C MVCC D 楽観ロック
正解: A
解説: 調整者と参加者の2段階でコミットを保証。 - 楽観的同時実行制御
問題: 楽観ロックで一般的な衝突検出手段は。
A 行レベル排他ロック B バージョン番号/タイムスタンプ比較 C テーブルロック D OSミューテックス
正解: B
解説: 更新時に変化を検出して失敗させる。 - 監査要件
問題: 更新履歴を改ざん困難に保つ設計として適切なのは。
A 物理削除のみ B 論理削除＋監査表に追記 C トリガ無効 D ログ無効
正解: B
解説: 監査表に時系列で追記し証跡を保持。 - バックアップ完全性
問題: PITR（時点復旧）に最低限必要な組合せは。
A フルだけ B 差分だけ C フル＋アーカイブログ/トランザクションログ連続 D ログだけ
正解: C
解説: ベースバックアップと連続ログ適用で復旧。 - バックアップ方式
問題: フル毎日・差分毎時・ログ常時。復旧時間を最短化しやすいのは。
A 毎回フルのみ B フル＋差分＋ログ C 差分のみ D ログのみ
正解: B
解説: 直近の差分から開始でき復旧が速い。 - RAIDの選択
問題: 書き込み性能と冗長性のバランスが良い構成は。
A RAID0 B RAID1 C RAID5 D RAID10
正解: D
解説: ミラー＋ストライピングで性能と耐障害性。 - 可用性: 同期レプリケーション
問題: ゼロRPO（データ損失0）を狙うなら。
A 非同期レプリケーション B 同期レプリケーション C バックアップのみ D キャッシュ拡大
正解: B
解説: 同期でコミットを遠隔にも反映。 - フェイルオーバ
問題: 自動フェイルオーバ要件として重要なのは。
A 手動手順書 B ハートビートと投票（クォーラム） C バッチジョブ増設 D バックアップ停止
正解: B
解説: スプリットブレイン回避のためクォーラムが重要。 - リードレプリカの用途
問題: リードレプリカの主用途は。
A 書込拡張 B 読取分散 C トランザクション整合性強化 D バックアップ不要化
正解: B
解説: 読取負荷のオフロード。 - スナップショットとコピーオンライト
問題: 急速なポイントコピーと省容量に寄与する技術は。
A フルコピー B コピーオンライト(COW) C 圧縮不可 D 同期ミラーのみ
正解: B
解説: 変更差分のみ保持で迅速に作成。 - シャーディングキー
問題: 均等分散を狙うキー選択で望ましいのは。
A 連番ID B 作成日 C 高カーディナリティのハッシュ D フラグ列
正解: C
解説: 偏りを避けるためハッシュ化が有効。 - 分散とCAP
問題: ネットワーク分断時に整合性を優先すると犠牲になるのは。
A 可用性 B パフォーマンス C 一貫性 D 耐久性
正解: A
解説: CAPにより分断(P)下ではCとAの両立不可。 - 参照整合性と分散
問題: 分散シャードにまたがる外部キーを厳密に保つと何が増えるか。
A スループット B 跨りトランザクション C キャッシュ命中 D スキーマ単純化
正解: B
解説: 跨り制約は分散トランザクションを誘発。 - ETLとDWH
問題: 緩やかに変化するディメンションを履歴保持したい。一般的な方式は。
A SCD Type 1 B SCD Type 2 C SCD Type 0 D 物理削除
正解: B
解説: 新行追加＋有効期間で履歴を保持。 - スターとスノーフレーク
問題: クエリ単純さ・結合数低減を優先するモデリングは。
A スノーフレーク B スター C 3NF完全正規化 D ガレージモデル
正解: B
解説: ディメンションを非正規化する。 - マテビュー（集約表）
問題: 夜間に集計し日中は即時参照したい。適切なのは。
A 生クエリのみ B マテリアライズドビュー/集約テーブル C インデックス削除 D フルスキャン固定
正解: B
解説: 事前集計で応答を短縮。 - データ型選択
問題: 金額列に適切なのは。
A FLOAT B DOUBLE C DECIMAL(精度指定) D VARCHAR
正解: C
解説: 浮動小数点は誤差が出るため固定小数点。 - タイムゾーン管理
問題: 国際サービスの時刻格納で推奨は。
A ローカル時刻 B 文字列 C UTCで格納し表示時に変換 D UNIX秒を文字列
正解: C
解説: 変換一貫性と比較容易性。 - 事例: キャンペーン検索が遅い
問題: 条件はWHERE 開始日<=:t AND 終了日>=:t。改善の第一歩は。
A (開始日,終了日)複合インデックス B LIKE検索に変更 C 列を文字列化 D フルテーブルヒント
正解: A
解説: 範囲条件に適した複合インデックスで走査縮小。 - 事例: 月次レポートの重いJOIN
問題: 巨大明細と小さなマスタの等値結合。改善策としてまず有効なのは。
A 明細にマスタの参照列でハッシュ分散 B マスタ側に結合キーのインデックス C 明細側をソートのみ D DISTINCTを付与
正解: B
解説: 小表のインデックスでNL/ハッシュ結合効率化。 - 事例: オンライン注文、二重決済の懸念
問題: 同一ユーザ同一注文の重複挿入を防ぐ最適策は。
A アプリでif文 B 一意制約(ユーザ, 注文番号)＋適切な再試行設計 C 定期バッチで重複削除 D ビューで隠す
正解: B
解説: 一意制約で同時実行下でも正しく防止。 - 事例: 在庫引当の整合性
問題: 同時減算で過剰引当が起きる。対策として適切なのは。
A 可視性読込 B 行ロックで在庫レコードを更新し原子性確保 C 楽観ロック無効化 D テーブルロック固定
正解: B
解説: 対象行の更新ロックで競合制御。 - 事例: 監査証跡の改ざん防止
問題: 更新時に旧・新値を保存し、後で否認されないようにしたい。
A 監査表にINSERTのみ、署名/ハッシュ付与 B UPDATEで上書き C 物理削除 D 外部キーなし
正解: A
解説: 追記型＋ハッシュ等で改ざん検知性向上。 - 事例: 複合インデックスの列順が効かない
問題: インデックス(a,b)があるが、WHERE b=?のみの検索が遅い。適切な対策は。
A インデックス(b,a)を追加 B 既存を削除 C (a)単独に変更 D 統計削除
正解: A
解説: 先頭列が利用されないため、b先頭の索引を別途用意する。 - 外部キーの更新連鎖
問題: 親テーブルの主キー値が変更されたとき、子テーブルの外部キーも自動で追随させたい。適切な指定はどれか。
A ON UPDATE RESTRICT B ON UPDATE SET NULL C ON UPDATE NO ACTION D ON UPDATE CASCADE
正解: D
解説: 親キー更新に応じて子の外部キーを自動更新するにはON UPDATE CASCADEを用いる。 - 遅延可能制約
問題: トランザクション終了時まで一時的に参照整合性違反を許し、最後にまとめて検査したい。適切なのはどれか。
A NOT DEFERRABLE B DEFERRABLE INITIALLY IMMEDIATE C DEFERRABLE INITIALLY DEFERRED D CHECK制約追加
正解: C
解説: DEFERREDはコミット時に検査。INITIALLY DEFERREDで開始時から遅延。 - CHECK制約の限界
問題: CHECK制約で他テーブルの値を参照したい。正しい方針はどれか。
A 可能、自由に参照できる B 基本不可、必要ならトリガやアプリで担保 C ビューにすればOK D 外部キーで代替必須
正解: B
解説: CHECKは同一行内の検査が原則。他表参照は不可の実装が一般的。 - 主キーと一意キー
問題: 主キーと一意制約の一般的な違いとして正しいのはどれか。
A 主キーはNULL可 B 一意制約は複数設定不可 C 主キーは表に一つ・NULL不可 D どちらも複数設定可能
正解: C
解説: 主キーは表に1つ・NULL不可。一意制約は複数可でNULL扱いはDB実装依存。 - 採番値の安全取得
問題: 同時実行下で新規行のIDを安全に取得する方法として最も適切なのはどれか。
A SELECT MAX(id)+1 を使う B アプリでカウンタ変数を増やす C DBのIDENTITY/SEQUENCEとRETURNING等で取得 D 直後にSELECTで検索
正解: C
解説: 競合を避けるにはDBの採番機構と生成値返却APIを用いる。 - 選択度と索引効果
問題: インデックス効果が出やすい列はどれか。
A 性別(男/女) B 削除フラグ(0/1) C 金額(0〜数千万) D 真偽値
正解: C
解説: 値の種類が多い高カーディナリティ列は選択度が高く、索引効果が出やすい。 - カバリングインデックス
問題: SELECT name, created_at FROM users WHERE email=? を高速化したい。適切なのはどれか。
A (email)のみ B (name, created_at)のみ C (email, name, created_at)の複合索引 D フルテーブルスキャン
正解: C
解説: 取得列を含む複合索引によりテーブルアクセス不要（カバリング）。 - 並び替え最適化
問題: WHERE status=’OPEN’ ORDER BY created_at DESC を最適化したい。索引の列順として適切なのはどれか。
A (created_at, status) B (status, created_at DESC) C (created_at DESC) D (status)
正解: B
解説: 先頭に等価条件の列、次に並び替え列（降順指定対応）でソート省略が狙える。 - ページングの設計
問題: OFFSET/LIMITで深いページへ進むほど遅い。改善策として有効なのはどれか。
A ORDER BYを外す B キーセット方式（最後のキー未満を条件）に書き換え C LIMITを増やす D インデックスを削除
正解: B
解説: キーセット方式はスキップせずに続きから取り、効率が良い。 - 累計のウィンドウ枠
問題: 顧客ごとの購入金額累計を日付順に計算する正しい式はどれか。
A SUM(amount) OVER()
B SUM(amount) OVER(PARTITION BY customer)
C SUM(amount) OVER(PARTITION BY customer ORDER BY date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
D SUM(amount) GROUP BY customer
正解: C
解説: 顧客単位に並べ、枠を先頭〜現在行に限定して累計にする。 - NULLの代替
問題: 標準SQLでNULLを別値に置き換える関数はどれか。
A NVL B IFNULL C COALESCE D ISNULL
正解: C
解説: COALESCEは標準。NVL/IFNULL/ISNULLは実装依存。 - NULL比較の注意
問題: 列xがNULLの行を取得する正しい条件はどれか。
A WHERE x = NULL B WHERE x <> NULL C WHERE x IS NULL D WHERE COALESCE(x,”)=”
正解: C
解説: NULLは三値論理。IS NULL/IS NOT NULLを使う。 - 日付範囲の上端
問題: 2025-08-01の1日分を取りたい。適切な条件はどれか。
A date BETWEEN ‘2025-08-01 00:00’ AND ‘2025-08-01 23:59:59’
B date >= ‘2025-08-01’ AND date < ‘2025-08-02’
C date LIKE ‘2025-08-01%’
D date = ‘2025-08-01’
正解: B
解説: 上端は次日未満で表すと小数秒を含む時刻でも漏れない。 - OR条件と索引
問題: WHERE a=? OR b=? が遅い。一般的な改善として有効なのはどれか。
A UNION ALLで2本のSARGable条件に分解 B 結果にDISTINCTを追加 C ヒントでフルスキャン固定 D 関数で包む
正解: A
解説: 各条件に索引を効かせて結果を結合する方が速い場合が多い。 - INとEXISTS
問題: 重複が多いサブクエリに対し、会員が購入を「少なくとも1件」しているかの判定。効率的なのはどれか。
A WHERE user_id IN (SELECT user_id FROM purchases)
B WHERE EXISTS (SELECT 1 FROM purchases p WHERE p.user_id = u.id)
C LEFT JOINでNULL判定
D CROSS JOIN
正解: B
解説: 存在判定はEXISTSが適切。重複の影響を受けにくい。 - 重複検出
問題: emailが重複しているレコードを抽出したい。正しい方針はどれか。
A DISTINCTで除外 B GROUP BY email HAVING COUNT(*)>1 C ORDER BY email D 逐次ループで比較
正解: B
解説: 集計して件数>1のキーを抽出する。 - 5NFの目的
問題: 5NFで主に解消されるのはどれか。
A 部分従属 B 推移従属 C 多値従属性 D 結合従属性
正解: D
解説: 5NFは結合従属性（情報の分解・再結合での冗長発生）を扱う。 - 分解の無損失性
問題: 関係RをR1とR2へ分解するとき無損失結合の十分条件として正しいのはどれか。
A R1∩R2が空である B 共通属性がR1またはR2のキーである C 共通属性が1列だけ D 行数が同じ
正解: B
解説: 共通属性が片方のキーであれば無損失。 - アームストロングの公理
問題: アームストロングの公理に含まれないのはどれか。
A 反射性 B 推移性 C 擴張性（増強） D 交差性
正解: D
解説: 代表は反射性・推移性・増強。他は派生規則。 - 非正規化の典型的副作用
問題: 非正規化で生じやすい問題はどれか。
A 読取遅延 B 更新異常 C 参照整合性の強化 D データ圧縮
正解: B
解説: 冗長な重複により更新忘れ・不整合が起こる。 - JSONの活用
問題: 半構造データを取り込み、柔軟に属性が増える。一般的な方針として最も適切なのはどれか。
A すべてVARCHARで保持 B JSON型やパス索引を活用 C 行を縦持ちEAVに統一 D 列追加を都度実施
正解: B
解説: JSON型＋パスインデックスで柔軟性と検索性の両立を図る。 - EAVモデルの注意
問題: 属性を縦持ちするEAVの欠点として正しいのはどれか。
A 参照整合性が強化される B 制約・型保証が難しくクエリも複雑化 C 正規化が自動で進む D 性能が常に向上
正解: B
解説: 一般に検証が難しく、集計や結合が複雑化しやすい。 - 最小権限の原則
問題: データベース権限設計の基本原則として適切なのはどれか。
A すべてのユーザにDBAを付与 B 必要最小限の権限のみ付与 C 一律読み書き許可 D 監査を無効化
正解: B
解説: 誤操作・侵害時の被害を最小化する。 - SQLインジェクション対策
問題: 最も有効な基本対策はどれか。
A 文字列連結を最小化 B パラメータ化クエリ（プリペアド）を使う C 画面で注意喚起 D ログを削除
正解: B
解説: バインドにより解釈の境界を固定できる。 - 行レベルセキュリティ
問題: ユーザごとに参照できる行を制御したい。一般的な実装はどれか。
A 行ロック B 行レベルセキュリティポリシー/ビューでのフィルタ C テーブル分割 D 外部キー
正解: B
解説: ポリシーやビューで条件付与して行可視性を制御。 - マスキング
問題: 本番の顧客データを開発者に渡す際の一般的な配慮はどれか。
A 生データのまま共有 B ダイナミック/静的マスキングで秘匿化 C 暗号化鍵を公開 D 参照制御を外す
正解: B
解説: 個人情報は匿名化・マスキングして共有する。 - パスワード保護
問題: パスワードの保管として適切なのはどれか。
A 平文保存 B 単純なMD5 C ソルト付きの遅延KDF（bcrypt/Argon2等） D 対称鍵で暗号化し平文復号可能にする
正解: C
解説: 一方向・計算コスト高のKDFとソルトで総当たり耐性を高める。 - 透過的暗号化
問題: ディスク紛失時のデータ漏えい対策に効果が高いのはどれか。
A 透過的データ暗号化(TDE) B 圧縮 C キャッシュ拡大 D MVCC
正解: A
解説: ストレージ上のデータを暗号化して媒体盗難対策に有効。 - 統計情報の更新
問題: カーディナリティ推定が外れて遅くなった。まず実施すべき対策として妥当なのはどれか。
A 統計情報の更新 B バックアップ C フルスキャン固定ヒント D テーブル削除
正解: A
解説: 最適化の根拠となる統計を新鮮に保つ。 - バインド変数の効果
問題: バインド変数（準備済み文）の主な利点として誤っているのはどれか。
A パース/最適化コスト低減 B プランキャッシュ再利用 C SQLインジェクション耐性向上 D 常に最速の実行計画になる
正解: D
解説: 常に最速とは限らない。ほかの利点は一般に正しい。 - 相関列の推定
問題: 列Aと列Bが強く相関（例: 郵便番号と都道府県）。誤推定を減らす一般的手段はどれか。
A 列を文字列化 B 拡張統計（複合分布）やヒストグラムの活用 C 索引をすべて削除 D ORDER BYを外す
正解: B
解説: 相関を反映する拡張統計・ヒストグラムで推定精度を上げる。 - ロックエスカレーション
問題: 非常に多くの行ロックを取得した結果、上位粒度に自動昇格される現象を何というか。
A デッドロック B スターベーション C ロックエスカレーション D ラッチ競合
正解: C
解説: 行→ページ/テーブルに昇格し競合が増えることがある。 - シリアライザブルの実装
問題: シリアライザブル分離を実現する代表的な内部手法はどれか。
A ページロックのみ B 述語ロック/範囲ロック C 共有ロック禁止 D MVCCを無効化
正解: B
解説: 条件にマッチし得る範囲へロックを拡張してファントムを防ぐ。 - スナップショット分離の特徴
問題: スナップショット分離で正しいのはどれか。
A ダーティリードを許す B 読取は一貫した過去像を参照する C 書込み競合が自動解決される D ロックは不要
正解: B
解説: 読み取りはスナップショットを参照し、書込み競合は失敗として検出される。 - パーティションの運用
問題: 日付レンジ・パーティションで古い月をアーカイブに移す効率的な手順はどれか。
A DELETEで全行削除 B ALTER TABLE … DROP PARTITION / EXCHANGE PARTITION を活用 C 全表再作成 D インデックス全削除
正解: B
解説: パーティション操作はメタデータ中心で高速。 - マテリアライズドビューの増分更新
問題: マテビューを高速にリフレッシュ（差分）したい前提として適切なのはどれか。
A 参照元に変更追跡情報（ログ）等がある B 参照元を毎回全削除 C ビューを通常ビューにする D 統計を削除
正解: A
解説: 差分計算には変更ログやキーが必要。 - CDC（変更データ取得）
問題: CDCの説明として正しいのはどれか。
A バックアップの別名 B 変更履歴をログ等から抽出して配信・連携する仕組み C 暗号化方式 D 圧縮アルゴリズム
正解: B
解説: ログから変更を取り出し下流（DWH等）へ伝える。 - PACELCの要点
問題: PACELCにおいて分断がない平常時に注目するトレードオフはどれか。
A 可用性 vs 一貫性 B 一貫性 vs レイテンシ C 耐久性 vs 費用 D セキュリティ vs 性能
正解: B
解説: PACELCは「分断時はCAのトレードオフ、平常時はCとLのトレードオフ」を示す。 - 計算列の索引
問題: WHERE DATE(created_at) = :d で遅い。一般的な改善はどれか。
A 列に関数を残す B 計算結果列（例: created_date）を用意しSARGableにして索引 C 文字列比較に変える D インデックスを外す
正解: B
解説: 列への関数適用は索引を阻害。計算列で直接比較する。 - 事例: 複数条件検索UI
問題: 検索フォームで多数の条件が任意指定。実行計画が不安定。一般的な対策として適切なのはどれか。
A 動的SQLで不要条件を削除し、主要列に適切な複合索引を用意 B すべてORでつなぐ固定SQL C 全件取得してアプリで絞る D 常にヒントでフルスキャン
正解: A
解説: 任意条件は動的に最小の述語集合にし、SARGableな索引を活かす設計が安定しやすい。
