【2026年最新】データベースの正規化はどこまでやるか｜7項目

重複をなくす設計の考え方ですが、進めるほど参照する手間が増えます。実務ではどこで止めるかの判断が必要になります。この記事では、段階と判断の基準を整理します。

目的

【結論】矛盾を防ぐことです。

重複の問題

同じ情報が複数の場所にあると、片方だけ更新される事態が起きます。

更新の異常

一部だけ変わって、内容が食い違う状態です。

削除の異常

ある行を消すと、別の情報まで失われる状態です。

挿入の異常

関係のない情報がそろわないと、登録できない状態です。

段階の7項目

【結論】順に進めます。

1. 繰り返しをなくす

1つの欄に複数の値を入れないでください。

2. 行を特定できるようにする

どの行かを一意に示せる列を決めます。

3. 部分的な依存をなくす

複数の列で特定する場合、その一部だけで決まる項目を分けます。

4. 間接的な依存をなくす

他の列を経由して決まる項目を、別の表へ分けます。

5. ここまでが基本

実務では、多くの場合この段階で足ります。

6. さらに進める段階

特殊な構造で必要になる場合があります。

7. あえて戻す判断

参照の速さのために、重複を残す選択があります。

段階	やること
第1	1つの欄に複数の値を入れない
第2	一部の列だけで決まる項目を分ける
第3	他の列を経由して決まる項目を分ける
それ以上	必要になってから検討

1つの欄に複数の値

【結論】分けてください。

よくある例

区切り文字でつないだ値を、1つの欄に入れる形です。

問題

検索も集計もできません。

対応

別の表に分け、行として持たせます。

例外

検索も集計もしない付加的な情報なら、まとめて持つ判断もあります。

他の列を経由する依存

【結論】分けてください。

例

注文の表に、顧客の名前や住所を持たせる形です。

問題

顧客の住所が変わると、すべての行を更新することになります。

対応

顧客の表を分け、注文には識別する値だけを持たせます。

参照の手間

結合が必要になりますが、矛盾は防げます。

あえて重複させる場合

【結論】理由があるときだけです。

参照が遅い

結合が多いと、処理に時間がかかる場合があります。

当時の値を残す

注文時の価格など、後から変わっても記録として残したい項目があります。

集計した値を持つ

毎回計算せず、あらかじめ保持する方法があります。

更新の責任

重複させるなら、どう同期するかを決めておいてください。

当時の値を残す設計

【結論】重複とは意味が違います。

価格の例

商品の価格は変わります。注文の記録には、その時点の価格を残す必要があります。

参照ではなく複製

商品の表を参照するだけでは、後から変わってしまいます。

設計の意図

これは冗長ではなく、必要な複製です。

記録に残す

なぜそうしたかを、設計の記録に残してください。

進めすぎた場合

【結論】扱いにくくなります。

表の数が増える

1つの情報を得るのに、多くの結合が必要になります。

処理の負荷

結合が増えると、時間がかかります。

理解の難しさ

構造が複雑になり、後から関わる人が把握しにくくなります。

判断の目安

実際に問題が起きているかを基準にしてください。

設計の記録

【結論】意図を残してください。

なぜその構造か

判断の理由を書き残します。

あえて重複させた箇所

意図を記録しないと、後から誤って統合される可能性があります。

制約の設定

矛盾を防ぐ仕組みを、データベース側にも設定してください。

図で残す

表の関係を図にすると、伝わりやすくなります。

後から変える場合

【結論】段階的に進めてください。

一度に変えない

既存のデータを移す作業が伴います。

移行の手順

新しい構造を用意し、データを移し、切り替える順序が一般的です。

戻せる状態

問題が起きたときに戻せるよう、元のデータを残してください。

参照する側

構造が変われば、参照している処理も変更が必要です。

識別する値の選び方

【結論】変わらない値にしてください。

意味を持つ値

電話番号やメールを識別に使うと、変更のたびに影響が及びます。

意味を持たない値

連番や生成した値を使うと、変更の影響を受けません。

複数の列で特定する

組み合わせで一意になる場合もありますが、参照する側が複雑になります。

外部からの参照

公開される場面では、連番だと推測されます。別の値を用意する方法があります。

制約の設定

【結論】仕組みで守ってください。

一意の制約

重複を防ぎます。

参照の制約

存在しない値を指す状態を防ぎます。

空を許さない設定

必須の項目に設定します。

処理側だけに頼らない

データベース側にも設定すると、想定外の経路からの登録を防げます。

よくある質問（FAQ）

Q1. どこまで進めますか

第3の段階までを基本としてください。それ以上は必要になってから検討します。

Q2. 重複を残してもよいですか

理由があるなら構いません。ただし、どう同期するかを決めておいてください。

Q3. 注文時の価格はどう持ちますか

その時点の値を複製して残してください。参照するだけでは、後から変わってしまいます。

Q4. 結合が多くて遅いのですが

実際に問題が起きているなら、集計した値を持つといった対応を検討してください。

Q5. 1つの欄にまとめてもよいですか

検索も集計もしない付加的な情報なら、判断の余地があります。

Q6. 後から変えられますか

変えられますが、データの移行と参照側の変更が伴います。段階的に進めてください。

まとめ

目的は、同じ情報が複数の場所にあることで生じる矛盾を防ぐことです。片方だけ更新されて内容が食い違う事態を避けます。

実務では第3の段階までを基本としてください。1つの欄に複数の値を入れない、一部の列だけで決まる項目を分ける、他の列を経由して決まる項目を分ける、の3つです。

参照の速さのために、あえて重複を残す判断もあります。ただしその場合、どう同期するかを決め、なぜそうしたかを設計の記録に残してください。

注文時の価格のように、後から変わっても記録として残したい項目は、複製して持つ必要があります。これは冗長ではなく、意図した設計です。誤って統合されないよう、記録に残しておいてください。

📱 運営の裏側・最新情報はXで発信中 → @ore_chusotsu