LASSIC Media らしくメディア
正規化と非正規化の違い｜DB設計の基準
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 正規化はデータの重複をなくし、更新のときの値の食い違いを防ぐ手法で、非正規化はあえて重複を持たせて読み取りを速くする考え方です。
- 正規化を進めるほど整合性は保ちやすくなりますが、複数のテーブルを突き合わせる処理が増えて読み取りが遅くなりやすく、進めるほどよいわけではありません。
- 更新が多く整合性を重視するデータは正規化、参照が多く速さを重視する集計・分析データは非正規化と使い分けます。
※ 本記事は2026年9月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
テーブル（データを入れる表）の設計の説明で「ここは正規化しています」と聞いたのに、別の箇所では「あえて非正規化しています」と言われた。どちらが正しい設計なのか、発注する側として判断がつかない——。データベースの設計を開発会社に任せる現場では、こうした戸惑いが起こりがちです。正規化とはデータの重複をできるだけなくして整合性を保つための設計手法で、非正規化とはあえて重複を持たせてでも読み取りの性能を高めようとする考え方です。
どちらも「テーブルをどう分けるか、分けないか」という設計上の選択で、目指す方向は正反対です。ただし一方が常に正しいわけではなく、扱うデータの性質によって向いている設計が変わります。本記事では、発注担当者やPM（プロジェクトマネージャー）、設計者に向けて、正規形の段階、正規化で防げる更新異常、両者の違いと使い分け、そして外部に委託するときに確認したい点を整理します。特定の製品の機能やSQL（データベースを操作する言語）の書き方には触れません。
目次
正規化とは
正規化の目的は、同じ情報を1か所にだけ記録する状態に近づけることです。同じ情報があちこちに重複していると、更新のたびにすべての箇所を漏れなく直さなければならず、直し忘れた箇所からデータの矛盾が生まれます。正規化は、こうした重複や矛盾が生まれる余地を、設計の段階で先に減らしておくための考え方です。
たとえば顧客の住所を注文のたびに書き写すのではなく、顧客マスタ（顧客の情報をまとめた基本のテーブル）に一度だけ記録し、注文テーブルからはその顧客を参照する形にします。住所が変わったときは顧客マスタの1か所を更新するだけで済むので、データ全体の整合性を保ちやすくなります。
正規化は、繰り返し項目を分ける、ほかの項目によって決まる項目を別のテーブルへ移すといった手順を、段階を追って進めます。この段階を「正規形」と呼び、どこまで正規化を進めたかを表す目安として使います。
正規形の段階
正規形にはいくつかの段階がありますが、実務の設計でまず押さえておきたいのは第1正規形から第3正規形までの3つです。段階が進むほど重複や矛盾の余地は減る一方で、テーブルの数は増え、参照するときの結合（複数のテーブルを突き合わせて一つの結果にする処理）も増えていきます。
第1正規形は、一つの欄に複数の値をまとめて入れたり、「商品1・商品2」のように同じ性質の項目を何列も並べたりする状態をなくし、一つの欄に一つの値だけが入る形に整えた状態です。一件の注文に複数の商品がある場合なら、商品名を横に並べず、注文明細として商品ごとに行を分けて記録します。
第2正規形は、主キー（1行を特定するための項目）が複数の項目の組み合わせでできているときに、主キーの一部だけで決まる項目を別のテーブルへ切り出した状態です。注文番号と商品番号の組み合わせを主キーとする注文明細テーブルで、商品名が商品番号だけで決まるなら、商品名は商品マスタへ移します。
第3正規形は、主キーではない項目によって決まる項目を、さらに別のテーブルへ分けた状態です。顧客テーブルに、顧客が所属する営業所の住所まで入れると、営業所コードが分かれば住所も分かるため、同じ営業所の住所が、所属する顧客の数だけ重複して記録されます。この場合は営業所マスタを独立させ、顧客テーブルには営業所コードだけを残して参照するのが基本です。
第3正規形まで整理した状態は、一般的な業務システムの設計で一つの目安とされることの多い段階です。ただし、正規形をどこまで厳密に追求するかは、システムの性質や運用の体制によって判断が分かれます。
正規化で防げる更新異常
正規化が重視される背景には、重複したデータを持つテーブルで起こりやすい「更新異常」という問題があります。更新異常には、データを登録するとき、変更するとき、削除するときのそれぞれに代表的な形があり、挿入時異常・更新時異常・削除時異常と呼ばれます。
挿入時異常は、本来は別々に記録すべき情報が一つの表にまとまっているために、片方の情報だけを登録できない問題です。営業所の情報を顧客テーブルに含めていると、まだ顧客のいない新しい営業所だけを先に登録しにくくなります。
更新時異常は、同じ情報が複数の行に重複しているために、変更のたびに該当するすべての行を直さなければならない問題です。一部の行を直し忘れると、同じはずの情報が行ごとに食い違い、どの値が正しいのか分からなくなります。
削除時異常は、ある行を削除したときに、残しておきたかった別の情報まで一緒に消えてしまう問題です。注文明細の最後の1件を削除したら、そこにしか記録されていなかった商品名まで消えてしまった、という例が考えられます。
非正規化とは
非正規化で行うのは、正規化で分けたテーブルをあえて一つにまとめ直したり、参照先の情報をあらかじめ重複して持たせたりすることです。正規化と逆の操作に見えますが、読み取りの処理を速くするために行う設計上の判断です。
正規化された状態では、一覧画面や集計処理に必要な情報を得るために、複数のテーブルを結合して参照する場面が増えます。結合は、扱う件数が多くなるほど処理の負荷が大きくなりやすい操作です。非正規化では、よく参照する情報を一つのテーブルにまとめておくことで結合の回数を減らし、読み取りにかかる時間を縮めます。
非正規化がよく採用されるのは、大量のデータを集計・分析するレポート用のテーブルや、アクセスが集中する一覧画面の表示用のテーブルです。更新の頻度が低く参照の頻度が高いデータほど、読み取りが速くなる効果は大きくなる傾向があります。
その代わり、同じ情報が複数の場所に重複する状態に戻るため、更新のときにはすべての重複箇所をそろえる仕組みが必要です。
正規化と非正規化の違い
正規化と非正規化は、目指すものと、その代わりに生じる負担の種類が違います。主な観点を表に整理しました。
| 観点 | 正規化 | 非正規化 |
|---|---|---|
| データの重複 | 重複をなくす方向に整理する | あえて重複を持たせる |
| 更新のしやすさ・整合性 | 1か所の更新で済み、整合性を保ちやすい | 重複箇所すべてをそろえる仕組みが必要 |
| 読み取りの性能 | テーブルの結合が増え、負荷が高まりやすい | 結合が減り、読み取りが速くなりやすい |
| テーブルの数 | 分割が進み、数が増える | まとめられ、数が絞られる |
| 向いている処理 | 更新が多い業務処理 | 参照が多い集計・分析処理 |
| 設計・運用の負荷 | 更新異常を防ぎやすいが、結合の設計が必要 | 参照は簡潔だが、整合性を保つ仕組みが必要 |
表のとおり、どちらか一方が常に優れているわけではありません。整合性を保つことを優先するか、読み取りの速さを優先するかという、設計上のトレードオフ（一方を取ると他方を譲る関係）です。次の図は、正規化を段階的に進める流れと、非正規化がその逆の方向にある関係を示したものです。
どう使い分けるのか
正規化と非正規化のどちらを採るかは、次の5つの点を確かめると整理しやすくなります。
- 更新の頻度：データが頻繁に書き換わる業務データか、書き換えの少ない参照用のデータか
- 整合性の要件：重複を持たせた場合に、矛盾なく値をそろえ続ける仕組みを用意できるか
- 読み取りの頻度と件数：一覧表示や集計処理で、大量の行を頻繁に参照する必要があるか
- 処理の性質：日々の取引を扱う処理か、蓄積したデータを分析する処理か
- 運用の体制：非正規化した箇所の整合性の確認や再集計を続けられる体制があるか
日々の受発注や会員登録のように、取引を正確に記録し続ける処理はOLTP（オンライントランザクション処理）と呼ばれます。この領域では、更新異常を防ぎやすい正規化された設計が向く場面が多くなります。一方、蓄積したデータを集計・分析するOLAP（オンライン分析処理）の領域では、更新が少なく参照が中心になるため、あらかじめ非正規化しておいたほうが集計の処理を軽くできる場合があります。
一つのシステムの中で両方を組み合わせる構成もよく見られます。日々の取引を記録する部分は正規化した設計を保ち、集計・分析やレポート表示に使うテーブルだけを非正規化して別に用意する形です。正規化したデータをもとに、必要な箇所だけ非正規化したテーブルを作れば、整合性の土台を保ちながら読み取りの性能も確保しやすくなります。
外部に委託するときに確認しておきたい点
データベースの設計は、いったん運用を始めると、後からテーブルの構造を大きく変えにくい部分です。設計を開発会社に委託するときは、次の点を先に確かめておくと、後の手戻りを抑えやすくなります。
- どのテーブルをどこまで正規化するかが、業務の要件に沿って整理されているか
- 非正規化する箇所がある場合、その理由と整合性を保つ仕組みが説明されているか
- 更新の頻度が高いデータと参照の頻度が高いデータを、区別して設計しているか
- 正規化・非正規化の判断が、将来のデータ量の増加を見込んで検討されているか
- 設計の変更が生じたときに、テーブルの構造を見直す工数が見積もりに入っているか
とくに非正規化する箇所は、なぜそこだけ重複を持たせるのか、重複した値をどの処理でそろえるのかを、設計書や打ち合わせで説明してもらうとよいでしょう。発注の段階でこうした確認点を共有しておけば、期待とのずれを防ぎやすくなります。
まとめ：正規化と非正規化で確かめておきたい3つの点
正規化と非正規化を使い分けるうえで、確かめておきたい点は3つに整理できます。第一に、そのデータが頻繁に更新される業務データなのか、参照が中心の集計・分析データなのかを分けること。第二に、非正規化する箇所では、重複した値をそろえる仕組みと、それを続ける運用の体制を用意できるかを確かめること。第三に、テーブルの構造は後から変えにくいので、どこまで正規化し、どこを非正規化するかの方針を発注の段階で共有しておくことです。この3点を踏まえておけば、「整合性を優先して分けたら一覧画面が遅くなった」「速さを優先してまとめたら値が食い違った」という事態を避けやすくなります。テーブル設計の方針に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
どこまで正規化すればよいですか
実務では第3正規形まで整理しておくことが多く、それより先の正規形まで追求しなければならないわけではありません。どこまで進めるかは、データの更新頻度や整合性の要件、参照するときの性能への影響を踏まえ、業務の要件に沿って個別に決めます。
非正規化は、どの段階で検討すればよいですか
正規化した設計のままでは結合が増え、一覧表示や集計処理の速さが業務で許容できない水準まで落ちてきたときが、検討を始める一つの目安です。まずは正規化した設計を基本にし、遅くなった処理に関わる箇所から検討する形になります。
正規化・非正規化は、SQLかNoSQLかの選定と同じ話ですか
別の観点の話です。SQLを使うデータベースか、NoSQL（表の形に限らずデータを扱うデータベース）かの選定は、データベースの方式そのものを選ぶ判断です。正規化・非正規化は、リレーショナルデータベース（表の形でデータを管理するデータベース）の中でテーブルをどう組み立てるかという設計上の選択で、方式を選んだあとに検討します。
正規化の方針は、発注のどの時点で決めればよいですか
要件定義や基本設計の段階で、業務データの更新頻度や参照頻度を整理したうえで固めておくのが望ましいです。早いうちに発注先と方針をすり合わせておくと、後の手戻りを抑えやすくなります。
システム開発・データ設計のご相談はLASSICへ
元請（プライムベンダー）として、テーブル設計の方針整理から、基盤構築を含むシステム開発までご提案します。まずはお気軽にご相談ください。
Remoguとリラシクなら、データベースの設計やシステム開発に加わるITエンジニアも探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：IPA（独立行政法人情報処理推進機構）「情報処理技術者試験」（https://www.ipa.go.jp/shiken/）。試験のシラバスにおけるデータベース設計・正規化に関する情報を参照（2026年9月確認）
