Excelデータベースの正規化とは？表/テーブルの分割手順と実務解説
- 「Excelテーブルでデータ管理しているが、
重複が多くて修正するときが大変…」 - 「Excelでリレーショナルデータベースを再現したいが、
テーブル設計の考え方がわからない…」 - 「表をマスタとトランザクションに分割する方法が知りたい…」
このような問題は、
本記事では、
「Excelデータベース」
Excelで「データベース」
Excelによるデータベースの基本については、
目次
テーブルを分割せずに1つの表に情報を詰め込み続けると、
重複データの発生
同じ顧客が複数回購入するたびに、
更新時異状（アノマリー）
データを追加・修正・削除するたびに、
| 異状の種類 | 具体的な問題 |
|---|---|
| 修正異状 | 1社の住所変更に伴い、 |
| 挿入異状 | 売上が発生していない段階では、 |
| 削除異状 | 特定の売上レコードを削除すると、 |
正規化前（非正規化状態）
取引履歴（イベント情報）
| 受注番号 | 受注日 | 顧客ID | 顧客名 | 顧客住所 | 商品ID | 商品名 | 単価 | 数量 |
|---|---|---|---|---|---|---|---|---|
| 1001 | 2026/06/01 | C01 | 株式会社A | 東京都... | P01 | ノートPC | 100,000 | 2 |
| 1002 | P02 | マウス | 5,000 | 5 |
「株式会社A」
正規化後（リレーショナル状態）
「イベント（売上の事実）
T_売上（トランザクション）
| 受注番号 | 受注日 | 顧客ID | 商品ID | 数量 |
|---|---|---|---|---|
| 1001 | 2026/06/01 | C01 | P01 | 2 |
| 1002 | P02 | 5 |
M_顧客（マスタ）
| 顧客ID | 顧客名 | 顧客住所 |
|---|---|---|
| C01 | 株式会社A | 東京都... |
M_商品（マスタ）
| 商品ID | 商品名 | 単価 |
|---|---|---|
| P01 | ノートPC | 100,000 |
| P02 | マウス | 5,000 |
「株式会社A」
2種類のテーブル：マスタとトランザクション
データベース設計では、
| 格納データ | テーブルの種類 | テーブル名のプレフィックス（接頭語） | 例 |
|---|---|---|---|
| 属性 | マスタ（ディメンション） | M_（Master） | 商品リスト、 |
| イベント | トランザクション（ファクト） | T_（Transaction / Table） | 売上明細、 |
テーブルの種類の通称はさまざま
テーブルの呼び方は文脈によって異なります。
- テーブル設計での呼び方：「マスタ」
と「トランザクション」 - Power Queryでの呼び方：「ディメンション」
と「ファクト」 - Excelでのプレフィックス（接頭語）
：M_（Master） と T_（Transaction / Table） - ※ T_ は "Transaction" ではなく "Table" を指し、
マスタテーブル以外のテーブルに付けることが一般的です。
- ※ T_ は "Transaction" ではなく "Table" を指し、
テーブル名の設定方法など、
正規化は「多対多の関係をなくし、
ステップ1：第一正規化による「1セル1値」
第一正規化は、
. - 第1正規形の定義：1つのセルに1つの値のみを格納し、
以下のような入力は、
- 1つのセルにカンマやセル内改行で複数の値を記入している
- セルを結合して複数のセルに1つの値を表示している
- 「1月売上」
「2月売上」 「3月売上」 のように、 同一項目を複数列に並べている（クロス集計表）
ステップ2：第2・第3正規化によるマスタの切り出し
第2・第3正規化は、
- 第2正規形の定義：複合主キーの一部のキーにしか依存しない属性を、
別テーブルに分離した状態（部分関数従属の排除） 。 - ※ 部分関数従属 とは、
主キーが2つ以上の列（複合キー） でできているとき、 その「一部のキー」 だけでデータが決まる関係のこと
- ※ 部分関数従属 とは、
- 第3正規形の定義：主キー以外の列に依存する属性を、
別テーブルに分離した状態（推移的関数従属の排除） 。 - ※ 推移的関数従属 とは、
「主キー以外の列」 が決まるとデータが決まる関係のこと。 主キーから見ると、 別の列を挟んで（推移して） データが決まる状態。
- ※ 推移的関数従属 とは、
推移的関数従属 とは、
実務では「どの列が、
| キー（決定項目） | キーに直接従属する属性 | 分離先テーブル |
|---|---|---|
| 商品ID | 商品名、 | M_商品 |
| 顧客ID | 顧客名、 | M_顧客 |
| 受注番号 | 受注日、 | T_売上 |
正規化には第4正規形・第5正規形なども理論上は存在しますが、
ステップ3：スタースキーマで過度な正規化を防ぐ
専用のDBMSと違い、
スタースキーマの構造
「ファクトテーブル（トランザクション）
| テーブルの形 | 特徴 | デメリット |
|---|---|---|
| スタースキーマ（非正規化） | テーブルの数が少なく、 | 同じデータが何度も重複して保存されるため、 |
| スノーフレークスキーマ（第3正規形まで分解） | データの重複が一切なく、 | 使用する際に大量のテーブルを「結合（JOIN） |
データベース理論どおりに正規化を徹底すると（例：住所から都道府県・市区町村を別々のマスタに分割するなど）
基本的には、
- マスタとトランザクションに分離する
- マスタからさらにマスタを分離するのは特定の条件の場合（後述）
とする。
マスタからさらにマスタを分離する判断基準
Excelデータベースでは、
- データ量が膨大で、
重複によるサイズ増大が問題になる場合 ：大量行のトランザクションテーブルに、 選択肢の少ない属性（長い文字列など） が全行で重複して入っているケース。
- 粒度が異なるデータが混在する場合 ：トランザクションテーブルに「日単位の列」
と「月単位の列」 が混在しているケース（1対多の関係が崩れている場合） 。
RDBでは、
| 方法 | 用途 | 特徴 |
|---|---|---|
| XLOOKUP / VLOOKUP / INDEX+MATCH 関数 | 単一の値を参照する場合 | リアルタイムで更新される。 |
| Power Query マージ | 2つのテーブルを結合する場合 | 大量データの結合に向く。 |
| Power Pivot リレーションシップ | 複数テーブルを結合する場合 | 大量データを高速に処理できる。 |
Excelは表計算ソフトであり、
- 容量と速度の限界 ：データ量が増えると動作が極端に重くなり、
強制終了のリスクが高まる。 シートには104万行の上限があり、 ビッグデータの格納には向かない。 - 同時編集が困難 ： 複数人による同時更新ができず 、
データの消失や不整合が起きやすい。 - 参照整合性の欠陥 ：一方のテーブルを修正しても、
関連する他方のテーブルは自動更新されない。 矛盾が生じたままになるリスクがある。 - 人的ミスの発生 ：セル値の誤消去や、
不適切なデータ型の入力を防ぐ仕組みが弱い。 - セキュリティの脆弱性 ：ファイル全体の流出リスクが常に存在する。
以下の状況に当てはまる場合は、
- ファイルを開く操作や計算処理に数分以上かかる。
- 「誰かがファイルを開いていて更新できない」
という状況が頻繁に起きている。 - 参照数式が複雑化しており、
メンテナンスが困難になっている。 - データの不整合を修正する作業に、
膨大な時間を費やしている。
本記事では、
- テーブル分割のメリット ： データの重複による容量肥大化と、
修正・挿入・削除時のデータ不整合（アノマリー） を防ぐ。 - Excelテーブルの設計方針 ： 第1~3正規化によりテーブルをマスタとトランザクションに分離するが、
「スタースキーマ」 を採用してテーブル階層を深くしない。 - 第1正規化 ： 1セルに1値のみを格納し、
セルの結合や繰り返し列を完全に排除する。 - 第2・第3正規化 ： 主キーや他の項目に依存する属性（商品名や顧客住所など）
を別テーブルに分離する。
- 第1正規化 ： 1セルに1値のみを格納し、
Excelデータベースの注意点・限界や、