データベース設計の基礎｜正規化からインデックスまで実践的に解説

「テーブル設計を適当にしたら、後からクエリが遅すぎて全面改修に…」こんな失敗、エンジニアなら一度は経験があるのではないでしょうか。データベース設計は、アプリケーション開発で最も手戻りコストが高い工程の一つです。

筆者は10年以上のバックエンド開発経験の中で、数十のプロジェクトでDB設計に携わってきました。この記事では、正規化の考え方からインデックス戦略、現場で頻出するアンチパターンまで、実務で即使える知識を体系的に解説します。初心者エンジニアから中級者まで、設計力を確実にレベルアップできる内容です。

データベース設計が重要な理由｜コスト削減と保守性向上
ER図で全体像を設計する｜ツールと書き方
正規化の基本｜第1〜第3正規形を具体例で理解する
テーブル設計の実践的なコツ5選
インデックス戦略｜検索パフォーマンスを最適化する方法
避けるべきアンチパターン4選
よくある質問（FAQ）
まとめ：良い設計が良いシステムを作る
1. あわせて読みたい

データベース設計が重要な理由｜コスト削減と保守性向上

データベース設計は、家を建てるときの設計図に相当します。設計図なしに建てた家は後から間取りを変えるのが困難であるように、運用開始後のスキーマ変更は開発コストの3〜5倍に膨らむケースも珍しくありません。

適切な設計によって得られるメリットは多岐にわたります。データの整合性が保たれ、クエリのパフォーマンスが向上し、将来の機能追加が容易になります。逆に設計が不適切だと、データの重複・更新時の不整合・検索の遅延が頻発し、開発チーム全体の生産性が大幅に低下します。

ER図で全体像を設計する｜ツールと書き方

データベース設計の第一歩は、ER図（Entity-Relationship Diagram）の作成です。ER図ではエンティティ（テーブルになるもの）とリレーションシップ（テーブル間の関係）を視覚化し、設計の全体像を俯瞰します。

リレーションシップには3種類あります。1対1（ユーザーとプロフィール）、1対多（ユーザーと投稿）、多対多（学生と講座）です。多対多の関係は中間テーブルを使って表現するのが定石です。

ER図の作成ツールとしては、dbdiagram.io（コードベースで高速に作成可能）、MySQL Workbench（リバースエンジニアリング対応）、Mermaid（Markdownに埋め込み可能）がおすすめです。チームでの共有を重視するならdraw.ioやNotionのER図テンプレートも選択肢に入ります。

正規化の基本｜第1〜第3正規形を具体例で理解する

正規化とは、データの重複を排除し、更新時の不整合を防ぐための設計手法です。段階的に第1〜第3正規形まで適用するのが一般的です。

第1正規形（1NF）：繰り返しグループの排除

第1正規形の条件は「各カラムが原子的な値（それ以上分割できない値）を持つこと」です。例えば、1つのカラムに「東京,大阪,名古屋」とカンマ区切りで複数の値を入れるのはNGです。別テーブルに分離して1対多の関係にします。

悪い例：ordersテーブルに「items」カラムで「りんご,みかん,バナナ」と格納
良い例：ordersテーブルとorder_itemsテーブルに分離し、外部キーで紐付け

第2正規形（2NF）：部分関数従属の排除

第2正規形は「複合主キーの一部にだけ依存するカラムを排除する」ことです。例えば、受注明細テーブルで（注文ID, 商品ID）が複合主キーの場合、「商品名」は商品IDだけに依存するため、別テーブル（商品マスタ）に分離すべきです。

第3正規形（3NF）：推移的関数従属の排除

第3正規形は「非キーカラムが他の非キーカラムに依存する関係を排除する」ことです。例えば、社員テーブルに「部署ID」「部署名」「部署所在地」がある場合、「部署名」「部署所在地」は「部署ID」に依存しているため、部署テーブルに分離します。

実務のポイント：多くのWebアプリケーションでは第3正規形まで適用すれば十分です。ただし、パフォーマンスを重視する集計テーブルや読み取り専用のレポート用テーブルでは、あえて非正規化（デノーマライゼーション）を行うこともあります。正規化と非正規化のバランスが設計の腕の見せ所です。

テーブル設計の実践的なコツ5選

正規化の理論を押さえたら、次は実務で役立つ設計テクニックを身につけましょう。筆者が現場で実践しているコツを5つ紹介します。

1. 主キーにはサロゲートキー（AUTO INCREMENT）を使う：ビジネスロジックに依存しないIDを主キーにすることで、将来の仕様変更に強い設計になります。UUIDはマイクロサービス環境で特に有効です。

2. created_at / updated_atカラムは必ず追加する：デバッグやデータ分析で必ず役立ちます。DEFAULT CURRENT_TIMESTAMPとON UPDATE CURRENT_TIMESTAMPを設定しておくと管理が楽です。

3. 論理削除（soft delete）を採用する：deleted_atカラムを用意し、DELETE文の代わりにUPDATEで削除フラグを立てます。誤削除からのリカバリが容易になり、データの監査証跡にもなります。

4. ENUM型の使用は慎重に：ステータス値などにENUM型を使うと、値の追加時にALTER TABLEが必要です。代わりにTINYINTやVARCHARを使い、アプリケーション側でバリデーションする方が拡張性が高いです。

5. 命名規約を統一する：テーブル名は複数形（users, orders）、カラム名はsnake_case（first_name, created_at）で統一すると、チーム開発での可読性が大幅に向上します。

インデックス戦略｜検索パフォーマンスを最適化する方法

インデックスは、データベースのパフォーマンスチューニングで最も効果的な手段です。適切に設定すれば、クエリの実行時間を100倍以上改善できるケースもあります。

WHERE句やJOIN条件で頻繁に使われるカラムにインデックスを作成するのが基本です。ただし、インデックスの貼りすぎには注意が必要です。INSERT・UPDATEの速度が低下し、ストレージも消費するため、よく使うクエリパターンを分析し、必要なインデックスだけを作成するのが鉄則です。

複合インデックスのコツ：複数カラムを組み合わせたインデックスを作成する際は、カーディナリティ（値の種類）が高いカラムを先頭に配置します。また、インデックスは左端から順にしか効かない（レフトモストプレフィックス）という特性を理解しておくことが重要です。

EXPLAINで実行計画を確認：クエリの前にEXPLAINを付けて実行すると、インデックスが使われているかどうかを確認できます。typeがALLになっている場合はフルテーブルスキャンが発生しているため、インデックスの追加を検討しましょう。

避けるべきアンチパターン4選

データベース設計で避けるべき代表的なアンチパターンを紹介します。

1. EAVパターン（Entity-Attribute-Value）：柔軟性は高いものの、クエリが複雑になり型安全性が失われます。PostgreSQLのJSONBカラムやMySQLのJSON型で代替できるケースが多いため、そちらを検討しましょう。

2. ポリモーフィック関連：1つの外部キーで複数テーブルを参照する設計は、参照整合性が保てずJOINが複雑になります。STI（Single Table Inheritance）やCTI（Class Table Inheritance）への移行を検討してください。

3. マジックナンバー：ステータスを「1=有効、2=無効、3=保留」のように意味不明な数字で管理すると、可読性が激減します。定数定義やマスタテーブルで管理しましょう。

4. 神テーブル（God Table）：1つのテーブルにあらゆる情報を詰め込むパターン。カラム数が50を超えたら設計を見直すサインです。責務に応じてテーブルを分割しましょう。

よくある質問（FAQ）

Q. 正規化はどこまでやるべきですか？

実務では第3正規形まで適用すれば十分なケースがほとんどです。第4・第5正規形は理論としては重要ですが、過度な正規化はJOINの増加によるパフォーマンス低下を招きます。読み取り頻度の高いテーブルでは、あえて非正規化してパフォーマンスを優先することもあります。

Q. NoSQLとRDBはどう使い分けますか？

データ間の関係性が複雑で、トランザクションの整合性が重要な場合はRDB（MySQL, PostgreSQL）が適しています。一方、スキーマが頻繁に変わるデータや、大量の読み書きが発生するリアルタイムアプリケーションにはNoSQL（MongoDB, DynamoDB）が向いています。最近は両者を組み合わせるポリグロットパーシステンスが主流です。