業務改善を支えるリレーショナルDB設計：第3正規化とSQLクエリの基礎

はじめに

スプレッドシート等を用いた個別管理からリレーショナルデータベース（RDB）へ移行する際、最も基本かつ重要となるのが**「テーブル設計（正規化）」**です。

本記事では、AccessDBを用いた業務改善実習の中で取り組んだデータベース正規化の手順と、ドキュメント作成の際に意識したポイントについて解説します。

1. なぜ正規化が必要なのか？

非正規形のテーブルでは、以下のような「更新不整合」や「データの重複」が発生しやすくなります：

登録時異状: 注文データが存在しないと、新規商品のマスタ情報を登録できない。
削除時異状: 過去の注文履歴を削除した際に、商品マスタの情報まで誤って失われる。
修正時異状: 顧客の住所や社名変更が発生した際、関連する全レコードを手作業で更新しなければ不整合が生じる。

graph LR
    subgraph "非正規形 (単一テーブル)"
        A["受注・顧客・商品が混在"]
    end
    subgraph "第3正規形 (テーブル分離と参照)"
        C["顧客マスタ"]
        P["商品マスタ"]
        O["受注伝票テーブル"]
        D["受注明細テーブル"]
    end
    A -->|正規化の適用| C
    A -->|正規化の適用| P
    A -->|正規化の適用| O
    A -->|正規化の適用| D

2. 第3正規化へのステップ

第1正規形: 繰り返し項目（1セル内の複数データ）を排除し、単一値（アトミック）化。
第2正規形: 主キーの一部に依存する項目（部分関数従属）を別テーブルへ分離。
第3正規形: 主キー以外の項目に依存する項目（推移的関数従属）を分離。

この手順を順を追って適用することで、データの整合性と更新の安全性を高めることができます。

3. Webフロントエンド開発への応用

リレーショナルデータベースの構造や正規化の考え方を学んだことで、Webフロントエンド開発におけるAPIレスポンスのデータ構造の把握や、状態管理（State）のモデリングにおいても、データの重複を避けた一貫性のある設計を意識できるようになりました。