「このテーブル設計で問題はありますか？」と聞かれて、すぐにボトルネックを指摘できるでしょうか。
データベース設計はシステムのパフォーマンスと信頼性の根幹を担う領域であり、技術面接でも重点的に問われるテーマです。特にバックエンドエンジニアやデータエンジニアのポジションでは、スキーマ設計の判断力やクエリ最適化の知識が直接的に評価対象となります。実は、データベース設計の面接で出題されるパターンにはある程度の規則性があり、事前に準備しておくことで回答の質を大きく向上させることができます。
この記事では、データベース設計面接で実際に聞かれる質問を体系的に整理し、面接官が期待する模範回答の構成を紹介します。正規化の基礎からインデックス戦略、NoSQLの選定まで、幅広いテーマをカバーしていますので、面接直前の総仕上げとしてぜひ活用してください。
データベース設計面接で評価される3つの能力
データベース設計面接では、単にSQLを書ける能力だけが求められるわけではありません。面接官が本当に見ているのは、ビジネス要件をデータモデルに変換する設計力、パフォーマンスを考慮した最適化の判断力、そしてトレードオフを理解した上での意思決定能力です。
設計力というのは、業務フローを理解した上で適切なテーブル構造を導き出せる能力のことです。たとえばECサイトの注文管理システムを設計する場合、注文と商品の多対多の関係をどう表現するか、注文履歴の変更をどう追跡するかなど、実務的な判断が求められます。面接では「なぜこのテーブル構造にしたのか」という理由を論理的に説明できることが、高評価につながるポイントです。
最適化の判断力は、実際にシステムが動き始めた後に必要になるスキルです。スロークエリの原因をインデックスの有無から推定したり、テーブルのパーティショニングが必要なタイミングを見極めたりする能力が問われます。そういえば、面接で「このクエリを高速化するにはどうしますか」と聞かれた際に、闇雲にインデックスを追加するのではなく、EXPLAINの結果を分析してから判断するという姿勢を見せることが重要です。
RDBとNoSQLの選定を語るコツ
面接でデータベースの選定について問われるケースは非常に多いです。「なぜRDBを選びましたか」「NoSQLの方が良い場面はどんな時ですか」といった質問に対して、安易に「とりあえずRDB」と答えるのではなく、要件に基づいた判断理由を説明できることが求められます。
RDB（リレーショナルデータベース）が適しているのは、データ間の関係性が複雑で、ACIDトランザクションが必要な場面です。金融系のシステムや在庫管理のように、データの一貫性が最優先される場面では、PostgreSQLやMySQLのようなRDBが最適です。一方、NoSQLが適しているのは、スキーマの柔軟性が求められたり、膨大なデータを高速に読み書きする必要がある場面です。
面接で効果的なのは、同じシステムの中でもRDBとNoSQLを使い分ける設計を提案することです。ECサイトを例にすると、注文や決済のデータはRDBで管理しつつ、商品レビューやユーザーの行動ログはMongoDBやDynamoDBで管理するという設計が考えられます。このように、一つの技術に固執せず、適材適所の判断ができることを示すと、面接官に柔軟な思考を持っている印象を与えられます。
正規化に関する質問と回答のポイント
正規化はデータベース設計の基礎でありながら、面接で最も深掘りされやすいテーマの一つです。「第三正規形まで説明してください」という基本的な質問から、「あえて正規化を崩す場面はありますか」という応用的な質問まで、幅広い出題パターンがあります。
第一正規形から第三正規形までの基本的な説明は、面接の前提知識として確実に押さえておきましょう。ただし、単に定義を暗唱するのではなく、各正規形が解決する具体的な問題（更新異常、削除異常、挿入異常）をセットで説明すると、理解の深さが伝わります。「第二正規形に違反していると、部分関数従属性によって更新時にデータの不整合が発生する可能性がある」というように、実際のリスクと結びつけて語りましょう。
ところが、実務では完全な正規化が常に最善とは限りません。面接で差がつくのは、意図的に非正規化を行う判断ができるかどうかです。読み取り性能を向上させるために、集計値をあらかじめ計算して保持する「非正規化テーブル」の活用や、頻繁にJOINされるテーブルを一つに統合する判断は、パフォーマンスチューニングの観点で正当化されます。面接では「原則として正規化を行い、パフォーマンス要件を満たせない場合に限り、計測結果に基づいて非正規化を検討する」という段階的なアプローチを示すのが効果的です。
正規化と非正規化のトレードオフ回答例
面接で「正規化と非正規化のトレードオフについて説明してください」と聞かれた場合の回答例を紹介します。この質問は、データベース設計の本質的な理解を測るために出題されることが多いです。
正規化の最大の利点は、データの冗長性を排除してデータの整合性を保つことです。あるユーザーの住所情報が複数のテーブルに散在していた場合、住所変更時にすべてのテーブルを更新する必要があり、一つでも更新漏れがあるとデータの不整合が発生します。正規化によって住所情報を一箇所にまとめれば、更新は一度で済み、整合性が担保されます。
一方で、正規化を進めるとテーブル数が増え、データの取得時にJOINが必要になります。JOINの数が増えると、クエリの実行計画が複雑になり、パフォーマンスが低下する可能性があります。レポート画面のように大量のデータを結合して表示する場面では、非正規化されたサマリーテーブルを用意することで、クエリの実行時間を大幅に短縮できます。面接では、この正規化と非正規化のバランスを取る判断が「設計力」として評価されるのです。
回答を締めくくる際は、CQRSパターン（Command Query Responsibility Segregation）にも触れると好印象です。書き込み用のデータモデルは正規化して整合性を保ち、読み取り用のデータモデルは非正規化してパフォーマンスを最適化するという分離のアプローチは、実務でも広く活用されている設計パターンです。
インデックス設計に関する頻出質問
インデックスに関する質問は、データベース設計面接では必ずと言っていいほど出題されます。「どのカラムにインデックスを貼りますか」という基本的な質問から、「複合インデックスのカラム順序はどう決めますか」という実践的な質問まで、出題パターンは多岐にわたります。
インデックスの基本原理を説明する際は、B-Tree構造のイメージを使うと面接官に伝わりやすいです。B-Treeインデックスは、本の索引のような仕組みで、データを素早く検索できるようにする仕組みです。索引なしで特定のキーワードを探す場合はすべてのページをめくる必要がありますが、索引があれば該当ページに直接アクセスできます。テーブルスキャンとインデックススキャンの違いを、この例え話で説明すると、技術的な内容を分かりやすく伝えるコミュニケーション力もアピールできます。
インデックスの選定で面接官が注目するのは、インデックスにはコストがあるという認識を持っているかどうかです。インデックスを追加すれば検索は高速になりますが、データの挿入・更新・削除時にはインデックスの更新コストが発生します。書き込みが多いテーブルに過剰なインデックスを設定すると、書き込み性能が著しく低下する可能性があります。面接では、読み取りと書き込みのバランスを考慮してインデックスを設計する姿勢を見せましょう。
複合インデックスの設計判断
複合インデックスの設計は、面接でも実務でも頻繁に議論されるテーマです。「WHERE句に複数のカラムが含まれるクエリに対して、どのようにインデックスを設計しますか」という質問に対して、カラムの選択順序を論理的に説明できることが求められます。
複合インデックスのカラム順序を決める際の基本原則は、選択性（カーディナリティ）の高いカラムを先頭に置くことです。ただし、これは一般的な指針であり、実際にはクエリのWHERE句の条件と一致する順序にすることが最も重要です。たとえばユーザーの注文履歴を検索する場合、WHERE user_id = ? AND status = ? AND created_at > ? というクエリに対しては、(user_id, status, created_at)の順で複合インデックスを作成するのが効果的です。
面接で複合インデックスについて説明する際は、「最左接頭辞ルール」についても触れましょう。(A, B, C)の複合インデックスがある場合、(A)や(A, B)の条件でもインデックスが活用されますが、(B, C)や(C)だけの条件ではインデックスが使われないという制約です。この知識を持っていることで、不要なインデックスの追加を防ぎ、効率的なインデックス設計ができるエンジニアだという印象を与えられます。
テーブル設計の実践的な質問パターン
面接では、具体的なシナリオに基づいてテーブル設計を求められるケースも多いです。「SNSのフォロー機能のテーブルを設計してください」「通知システムのデータモデルを考えてください」など、実務に近い課題が出題されます。このような質問に対しては、要件の確認から始めて段階的に設計を組み立てていくアプローチが効果的です。
テーブル設計の質問で評価されるのは、エンティティ間の関係を正確にモデル化できる能力です。一対一、一対多、多対多の関係を適切に表現し、中間テーブルの必要性を判断できることが基本スキルとして求められます。ECサイトの商品とカテゴリの関係であれば、一つの商品が複数のカテゴリに属する可能性があるため、多対多の関係を中間テーブルで表現する設計が自然です。
設計を進める中で、将来の拡張性についても言及できると好印象です。「現時点では必要ないが、将来的にこの機能が追加された場合にもスキーマ変更が最小限で済む」という視点を持っていることは、経験豊富なエンジニアの証です。ただし、過度な汎用化は逆効果なので、YAGNI（You Aren't Gonna Need It）の原則とのバランスを意識することも大切です。
履歴データの管理方法
データベース設計面接で意外と頻出なのが、履歴データの管理に関する質問です。「商品の価格変更履歴をどう管理しますか」「ユーザーのプロフィール変更を追跡するにはどう設計しますか」といった質問は、実務での経験を問うものでもあります。
履歴データを管理する方法として一般的なのは、現在のデータと履歴データを別テーブルに分ける方法です。商品テーブルには現在の価格情報を保持し、価格変更履歴テーブルに過去の価格と変更日時を記録します。この設計の利点は、現在のデータへのクエリがシンプルに保たれることです。一方、変更のたびに履歴テーブルへの挿入が必要になるため、書き込みコストが若干増加します。
もう一つのアプローチとして、Temporal Table（時制テーブル）があります。有効期間の開始日と終了日をカラムとして持たせることで、任意の時点でのデータの状態を再現できます。PostgreSQLの場合はrange型を活用すると、期間の重複を防ぐ制約も設定できます。面接でこのアプローチを提案できると、データベースの機能を深く理解しているエンジニアとして評価されるでしょう。
パフォーマンスチューニングに関する質問
データベースのパフォーマンスチューニングは、面接で技術力が最も直接的に問われるテーマです。「このクエリが遅い原因を特定して改善策を提案してください」という実践的な問いかけに対して、体系的なアプローチで回答できることが求められます。
パフォーマンス問題の調査で最初に行うべきは、EXPLAINコマンドの実行です。クエリの実行計画を分析することで、テーブルスキャンが発生しているか、インデックスが適切に使われているか、JOINのアルゴリズムは最適かを確認できます。面接では「まずEXPLAINで実行計画を確認し、ボトルネックを特定してから改善策を検討します」という段階的なアプローチを示すことが高評価につながります。
チューニングの手法は、クエリレベルの最適化とスキーマレベルの最適化に分けて考えましょう。クエリレベルでは、不要なSELECT * の排除、サブクエリのJOINへの書き換え、適切なインデックスの追加などが基本的な対策です。スキーマレベルでは、テーブルのパーティショニング、マテリアライズドビューの活用、非正規化テーブルの導入などが検討されます。面接では両方のレベルの対策を提案できると、幅広い知識をアピールできます。
スロークエリの分析と改善の回答例
面接で具体的なスロークエリの改善を求められた場合、以下のような段階的なアプローチで回答しましょう。この手順に沿って説明することで、論理的で漏れのない回答ができます。
最初のステップとして、クエリの実行計画を確認します。EXPLAIN ANALYZEの結果から、どのテーブルでフルスキャンが発生しているか、推定行数と実際の行数に大きな乖離がないかを確認します。推定行数と実際の行数に差がある場合は、統計情報が古くなっている可能性があるため、ANALYZEコマンドで統計情報を更新することが効果的な場合があります。
インデックスの追加やクエリの書き換えで改善できない場合は、アーキテクチャレベルの対策を検討します。読み取り頻度の高いクエリに対してはキャッシュの導入が有効ですし、大量のデータを集計するクエリに対してはマテリアライズドビューの利用が効果的です。面接では「すぐに実行できる対策から順に検討し、コストが高い対策は最後の手段とする」という優先順位の考え方を示すことが大切です。
最終手段として、データベースのスケーリング（リードレプリカの追加やシャーディング）も選択肢に含まれます。ただし、これらは運用コストが大幅に増加するため、他の手段で解決できないかを十分に検討してから判断すべきです。面接でこの優先順位を意識した回答ができると、コスト意識の高いエンジニアとして評価されます。
まとめ
データベース設計面接では、RDBとNoSQLの選定、正規化と非正規化のトレードオフ、インデックス設計、テーブル設計、パフォーマンスチューニングなど、幅広いテーマが出題されます。これらの個々の知識を身につけることはもちろん大切ですが、面接で本当に評価されるのは、要件に基づいて適切な設計判断ができる能力です。
面接で差がつくのは、テクニカルな正しさだけでなく、設計のトレードオフを理解した上で判断理由を説明できるかどうかです。「正規化は常に正しい」のような教科書的な回答ではなく、「この要件であれば、読み取り性能を優先して非正規化を選択する」という実践的な判断ができることが、シニアレベルのエンジニアに求められるスキルです。
面接対策としては、実際のサービスを想定したテーブル設計の練習が最も効果的です。身近なWebサービスのデータモデルを自分で設計し、なぜその構造にしたのかを言語化する練習を繰り返すことで、本番でも自信を持って回答できるようになるはずです。