ITエンジニアとしてこの先生きのこるために

テーブル設計の基礎

作成: 2026.03.24更新: 2026.03.24

テーブル設計の基礎とは

テーブル設計は、業務で扱うデータをリレーショナルデータベース（RDB）のテーブル構造として定義する作業である。どのデータをどのテーブルに格納し、テーブル間をどのように関連づけるかを決定する。

テーブル設計の品質はシステム全体の品質に直結する。不適切なテーブル設計は、データの不整合、パフォーマンスの低下、保守性の悪化を引き起こす。逆に、適切に設計されたテーブルは長期間にわたって安定したシステム運用を支える基盤となる。

なぜ SIer で重要か

SIer のプロジェクトにおいて、テーブル設計は 基本設計（外部設計）の中核的な成果物 である。テーブル定義書と ER 図は、設計レビューで必ず確認される重要なドキュメントであり、顧客にも提出する正式な設計書となる。

テーブル設計は一度決定すると後から変更するコストが非常に高い。テーブル構造の変更は、アプリケーションの SQL、画面、帳票、バッチ処理など広範囲に影響するためだ。そのため、SIer の現場では基本設計の段階で十分な時間をかけてテーブル設計のレビューが行われる。

基本概念

ER 図（Entity-Relationship Diagram）

ER 図は、テーブル（エンティティ）間のリレーション（関連）を視覚的に表現した図である。テーブル設計の全体像を把握するために使用される。

┌──────────────┐       ┌──────────────┐
│ departments  │       │ users        │
├──────────────┤       ├──────────────┤
│ PK id        │──┐    │ PK id        │
│    name      │  │    │    name      │
│    location  │  └───→│ FK dept_id   │
└──────────────┘       │    email     │
                       └──────────────┘

PK = Primary Key（主キー）
FK = Foreign Key（外部キー）

ER 図の記法にはいくつかの種類がある。SIer の現場では IE 記法（Information Engineering 記法） が多く使われる。IE 記法では、リレーションの多重度（1 対 1、1 対多、多対多）を線の端の記号で表現する。

正規化

正規化は、データの冗長性を排除し、更新時の不整合を防ぐためにテーブル構造を整理する手法である。段階的に正規化を進めていく。

第 1 正規形（1NF）

繰り返し項目を排除し、すべてのカラムが原子的な値（これ以上分割できない値）を持つ状態。

非正規形（NG）:
┌─────┬──────┬──────────────────────┐
│ id  │ name │ phones               │
├─────┼──────┼──────────────────────┤
│ 1   │ 田中 │ 090-1234, 03-5678   │ ← 1 つのセルに複数の値
└─────┴──────┴──────────────────────┘

第 1 正規形（OK）:
┌─────┬──────┬──────────┐
│ id  │ name │ phone    │
├─────┼──────┼──────────┤
│ 1   │ 田中 │ 090-1234 │
│ 1   │ 田中 │ 03-5678  │
└─────┴──────┴──────────┘

第 2 正規形（2NF）

第 1 正規形を満たした上で、主キーの一部にのみ依存する項目（部分関数従属）を別テーブルに分離した状態。

第 1 正規形（部分関数従属あり）:
注文明細テーブル
┌──────────┬─────────┬───────────┬───────────┐
│ order_id │ item_id │ item_name │ quantity  │
├──────────┼─────────┼───────────┼───────────┤
│ 主キー   │ 主キー  │ item_idに │ 主キー全体│
│          │         │ のみ依存  │ に依存    │
└──────────┴─────────┴───────────┴───────────┘

第 2 正規形（テーブルを分離）:
注文明細: order_id, item_id, quantity
商品:     item_id, item_name

第 3 正規形（3NF）

第 2 正規形を満たした上で、主キー以外の項目間の依存（推移的関数従属）を別テーブルに分離した状態。

第 2 正規形（推移的関数従属あり）:
┌─────┬──────┬─────────┬───────────┐
│ id  │ name │ dept_id │ dept_name │
├─────┼──────┼─────────┼───────────┤
│     │      │         │ dept_idに │
│     │      │         │ 依存      │
└─────┴──────┴─────────┴───────────┘

第 3 正規形（テーブルを分離）:
users:       id, name, dept_id
departments: dept_id, dept_name

実務では 第 3 正規形 までの正規化が基本となる。ただし、パフォーマンスの観点から意図的に非正規化（冗長なデータを持たせる）を行うこともある。

インデックス

インデックスは、テーブル内のデータを高速に検索するための仕組みである。本の索引と同じ役割で、全行を順番に調べる（フルテーブルスキャン）代わりに、インデックスを使って目的のデータに直接アクセスできる。

-- インデックスの作成
CREATE INDEX idx_users_email ON users (email);

-- インデックスが使われる検索
SELECT * FROM users WHERE email = 'tanaka@example.com';

インデックスを付けるべきカラム

  • WHERE 句で頻繁に検索条件に使われるカラム
  • JOIN の結合条件に使われるカラム
  • ORDER BY で並び替えに使われるカラム

インデックスの注意点

  • インデックスが多すぎると INSERT / UPDATE のパフォーマンスが低下する
  • データ量が少ないテーブルではインデックスの効果が小さい
  • カーディナリティ（値の種類の多さ）が低いカラムにはインデックスの効果が薄い

SIer での使われ方

テーブル定義書

SIer のプロジェクトでは、テーブルごとに テーブル定義書 を作成する。テーブル定義書には以下の項目が記載される。

項目説明
テーブル物理名t_users
テーブル論理名ユーザーマスタ
カラム物理名・論理名user_id / ユーザーID
データ型VARCHAR(50), INTEGER 等
NOT NULL 制約NULL を許容するかどうか
主キー・外部キーPK / FK の指定
デフォルト値初期値の設定
備考カラムの説明や業務上の意味

命名規則

SIer のプロジェクトでは、テーブルやカラムの命名規則が定められていることが多い。

テーブル名: t_ + 英語名（例: t_users, t_orders）
マスタ系:   m_ + 英語名（例: m_departments, m_products）
カラム名:   スネークケース（例: user_id, created_at）

設計レビューのポイント

テーブル設計のレビューでは以下の点が確認される。

  • 正規化が適切に行われているか
  • 主キーと外部キーの設定が正しいか
  • 必要なインデックスが設計されているか
  • NOT NULL 制約が適切に設定されているか
  • 将来の拡張を考慮した設計になっているか

まとめ

  • テーブル設計は業務データを RDB のテーブル構造として定義する作業であり、基本設計の中核である
  • ER 図でテーブル間のリレーションを可視化し、設計の全体像を把握する
  • 正規化（第 1〜第 3 正規形）によりデータの冗長性を排除し、整合性を保つ
  • インデックスにより検索パフォーマンスを向上させるが、付けすぎには注意が必要
  • SIer ではテーブル定義書が設計書の主要成果物の一つであり、設計レビューの重要な対象となる