LASSIC Media らしくメディア
正規化と非正規化の違い｜DB設計の基準
LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・検証を受託
データベースのテーブル設計を検討する場面で、「正規化」と「非正規化」という言葉が並んで語られることは少なくありません。正規化はデータの重複をできるだけ排除し整合性を保つための設計手法であり、非正規化はあえて重複を許容してでも読み取りの性能を高めようとする考え方です。どちらも「テーブルをどう分けるか、あるいは分けないか」という設計上の選択肢である点は共通していますが、目指している方向は逆を向いているといえるでしょう。
本記事では、正規化と非正規化という二つの考え方の違いを整理したうえで、発注担当者・PM・設計者が押さえておきたい使い分けの判断軸を解説します。特定のデータベース製品の機能やSQL構文そのものには踏み込まず、あくまで「テーブル設計の考え方の違い」と「どちらに寄せるべきかの判断」に焦点を当てます。
この記事のポイント
- 正規化はデータの重複を排除し更新異常を防ぐための設計手法、非正規化はあえて重複を持たせて読み取り処理を速くする考え方という点で、目指す方向が異なります。
- 正規化を進めるほど整合性は保ちやすくなる一方、テーブルの結合が増えて読み取り時の処理が重くなりやすく、正規化すれば常に望ましい設計になるとは限りません。
- 更新頻度が高く整合性を重視する業務データは正規化、参照頻度が高く読み取り速度を重視する集計・分析データは非正規化というように、データの性質に応じた使い分けが求められます。
目次
正規化とは
正規化とは、一つの表にまとまっていたデータを整理し、重複する情報をできるだけ排除する形でテーブルを分割していく設計手法です。同じ情報があちこちに重複して存在すると、更新の際にすべての箇所を漏れなく修正する必要が生じ、修正漏れによってデータの矛盾が生まれる恐れがあります。正規化は、こうした重複や矛盾の芽をあらかじめ設計段階で摘み取っておくための考え方です。
目的：重複の排除と整合性の維持
正規化の目的は、一つの事実を一つの場所にだけ記録する状態に近づけることにあります。たとえば顧客の住所を注文のたびに書き写すのではなく、顧客マスタという一つのテーブルにまとめて記録し、注文テーブルからは顧客を参照する形にします。こうすることで、住所が変わった際にはマスタ側の一箇所を更新するだけで済み、データ全体の整合性を保ちやすくなるでしょう。
正規化の進め方の基本
正規化は、繰り返し項目の分離や、部分的にしか関係しない項目の分離といった手順を段階的に踏みながら進めます。この段階は「正規形」と呼ばれ、どこまで正規化を進めたかを表す指標として使われるものです。次の項で、実務上よく参照される第1正規形から第3正規形までの考え方を確認しましょう。
正規形の概要（第1〜第3正規形）
正規形にはいくつかの段階がありますが、実務の設計でまず押さえておきたいのは第1正規形から第3正規形までの三段階です。段階が進むほど重複や矛盾の余地は減っていく一方、テーブルの数は増え、参照時の結合も増えていきます。
第1正規形：繰り返し項目をなくす
一つのセルに複数の値をまとめて入れたり、同じ性質の項目を横に何列も並べたりする状態を解消し、一つのセルには一つの値だけを入れる形に整えた状態を指します。たとえば一件の注文に複数の商品を持たせる場合、商品名を横に並べるのではなく、注文明細として行を分けて記録する形に整理します。
第2正規形：主キーの一部にしか依存しない項目を分離する
主キーが複数の項目の組み合わせで構成されている場合に、主キーの一部だけに依存する項目を別のテーブルへ切り出した状態です。たとえば注文番号と商品番号の組み合わせを主キーとする注文明細テーブルにおいて、商品名が商品番号だけで決まる情報であれば、商品マスタとして分離します。
第3正規形：主キー以外の項目に依存する項目を分離する
主キーではない項目に依存して決まる項目を、さらに別のテーブルへ分離した状態です。たとえば顧客テーブルの中に、顧客の所属する営業所の住所まで含めてしまうと、営業所コードが決まれば住所も決まるという関係が生じます。この場合は営業所マスタを独立させ、顧客テーブルからは営業所コードだけを参照する形に整理するのが基本です。
第3正規形まで整理された状態は、一般的な業務システムの設計における一つの目安とされることが多い段階です。ただし、正規形をどこまで厳密に追求するかは、システムの性質や運用体制によって判断が分かれる部分でもあります。
正規化で防げる更新異常
正規化が重視される背景には、重複したデータを持つテーブルで起こりやすい「更新異常」と呼ばれる問題があります。更新異常には、挿入時・更新時・削除時のそれぞれで生じる代表的なパターンが存在します。
挿入時異常
本来であれば別々に記録すべき情報が一つの表にまとまっていると、一方の情報だけを登録したい場合でも、もう一方の情報がそろわないと登録できない状況が生じることがあります。たとえば営業所の情報を顧客テーブルに含めていると、まだ顧客のいない新設の営業所の情報を先に登録しづらくなる場合があるでしょう。
更新時異常
同じ情報が複数の行に重複して存在していると、その情報を変更する際にすべての該当行を漏れなく更新する必要が生じます。一部の行だけ更新し忘れると、同じはずの情報が行ごとに食い違ってしまい、どちらが正しいのか判断できない状態に陥る恐れがあります。
削除時異常
ある行を削除した際に、本来は残しておきたかった別の情報まで一緒に失われてしまう問題です。たとえば注文明細の最後の1件を削除した拍子に、そこにしか記録されていなかった商品名の情報までも消えてしまうといった状況が考えられます。
正規化は、これらの更新異常が発生する余地をテーブル構造の段階であらかじめ減らしておくための設計手法であり、データの整合性を長期にわたって保ちやすくする効果が期待できるでしょう。
非正規化とは
非正規化とは、正規化によって分割されたテーブルを、あえて結合した状態に近づけたり、参照先の情報をあらかじめ重複して持たせたりする設計上の判断です。正規化とは逆方向の操作に見えますが、目的なく重複を戻すのではなく、読み取り処理の性能を高めるという明確な狙いを持って行う点が特徴といえます。
目的：結合を減らして読み取りを速くする
正規化された状態では、一覧画面や集計処理で必要な情報を得るために複数のテーブルを結合して参照する場面が増えます。テーブルの結合は、扱う件数が多くなるほど処理の負荷が大きくなりやすい操作です。非正規化は、頻繁に参照する情報をあらかじめ一つのテーブルにまとめておくことで、結合の回数を減らし、読み取りにかかる時間を短縮しようとする考え方です。
代表的な適用場面
大量のデータを集計・分析するレポーティング用のテーブルや、アクセスが集中する一覧画面の表示用テーブルなどは、非正規化が採用されやすい代表例です。更新の頻度が低く、参照の頻度が高いデータほど、非正規化によって得られる読み取り速度の恩恵が大きくなる傾向にあります。
非正規化に伴うコスト
非正規化を行うと、同じ情報が複数の場所に重複して存在する状態に戻るため、更新の際にはすべての重複箇所を整合させる仕組みが必要になります。この整合性を保つための仕組みをどう用意するかが、非正規化を採用する際にあらかじめ検討しておくべき課題です。
両者の違い：対比表と分割イメージ図
正規化と非正規化は、どちらも「テーブルをどう構成するか」という設計上の選択である点は共通していますが、目指す方向と生じるコストの種類が異なります。次の表に主要な観点を整理します。
| 観点 | 正規化 | 非正規化 |
|---|---|---|
| データの重複 | 重複を排除する方向に整理する | あえて重複を持たせる |
| 更新のしやすさ・整合性 | 一箇所の更新で済み整合性を保ちやすい | 重複箇所すべての整合を保つ仕組みが必要 |
| 読み取り性能 | テーブルの結合が増え負荷が高まりやすい | 結合が減り読み取りが速くなりやすい |
| テーブルの数 | 分割が進み数が増える | 統合され数が絞られる |
| 向いている処理の性質 | 更新が多い業務処理（OLTP寄り） | 参照が多い集計・分析処理（OLAP寄り） |
| 設計・運用の負荷 | 更新異常を防ぎやすいが結合設計が必要 | 参照は簡潔だが整合性維持の仕組みが必要 |
対比表からわかるとおり、正規化と非正規化はどちらか一方が常に優れているという関係ではなく、整合性の維持を優先するか、読み取り性能を優先するかという設計上のトレードオフです。次の図で、正規化を段階的に進めていく流れと、非正規化がその逆方向に位置する関係のイメージを確認しておきましょう。
使い分けの判断軸（整合性重視 vs 読み取り性能重視）
設計にあたっては、次のような判断軸を確認しておくと、正規化と非正規化のどちらに寄せるべきかを整理しやすくなります。
- 更新の頻度――データが頻繁に書き換わる業務データか、書き換えの少ない参照用データか
- 整合性の要件――重複を持たせた場合に、矛盾なく維持できる仕組みを用意できるか
- 読み取りの頻度・件数――一覧表示や集計処理で大量の行を頻繁に参照する必要があるか
- 処理の性質――日々の取引を扱うOLTP寄りの処理か、蓄積したデータを分析するOLAP寄りの処理か
- 運用体制――非正規化した箇所の整合性チェックや再集計を運用できる体制があるか
OLTPとOLAPという視点
日々の受発注や会員登録のように、取引を正確に記録し続けるOLTP（オンライントランザクション処理）の領域では、更新異常を防ぎやすい正規化された設計が向く場面が多くなります。一方、蓄積したデータを集計・分析するOLAP（オンライン分析処理）の領域では、更新の頻度が低く参照が中心となるため、あらかじめ非正規化しておいたほうが集計処理を軽くできる場合があるでしょう。
同じシステムの中での使い分け
一つのシステムの中でも、日々の取引を記録する部分は正規化された設計を保ちつつ、集計・分析やレポート表示に使うテーブルだけを非正規化して別途用意するという組み合わせがよく見られます。正規化されたデータを基点として、必要な箇所だけ非正規化したテーブルを派生させる構成であれば、整合性の基盤を保ちながら読み取り性能も確保しやすくなります。
設計・発注時の確認点
データベース設計を発注する際は、次のような点をあらかじめ確認しておくと、後の手戻りを抑えやすくなります。
- どのテーブルをどこまで正規化するか、業務要件に沿って整理されているか
- 非正規化を採用する箇所がある場合、その理由と整合性を保つ仕組みが説明されているか
- 更新頻度の高いデータと参照頻度の高いデータが区別して設計されているか
- 正規化・非正規化の判断が、将来のデータ量の増加を見据えて検討されているか
- 設計変更が生じた際に、テーブル構造を見直す工数が見積もりに反映されているか
データベース設計は、一度運用を始めると後から構造を大きく変更しにくい部分でもあります。発注段階でこうした確認点を共有しておくことが、期待とのズレを防ぐことにつながるでしょう。
まとめ：整合性か読み取り性能かのトレードオフで設計する
本記事では、正規化と非正規化という二つの考え方の違いについて、データの重複・整合性・読み取り性能・テーブル数という観点から整理しました。正規化は重複を排除して更新異常を防ぎ整合性を保ちやすくする設計手法、非正規化はあえて重複を持たせることで読み取りの処理を速くする考え方であり、両者は逆方向を向いた設計上の選択といえます。
設計にあたっては、更新の頻度・整合性の要件・読み取りの頻度・処理の性質（OLTPかOLAPか）・運用体制といった判断軸を確認し、業務データの性質に応じて正規化と非正規化を使い分ける、あるいは同じシステムの中で組み合わせることが、無理のないデータベース設計につながるでしょう。
よくある質問
どこまで正規化すべきですか。
実務上の目安としては第3正規形まで整理しておくケースが多いですが、必ずしもそれ以上先の正規形まで追求する必要があるとは限りません。どこまで正規化を進めるかは、扱うデータの更新頻度や整合性の要件、参照時の性能への影響を踏まえたうえで、業務要件に沿って個別に判断する部分です。
非正規化はいつ検討すればよいですか。
正規化された設計のままではテーブルの結合が増え、一覧表示や集計処理の性能が業務上許容できない水準まで低下してきた段階が、非正規化を検討する一つの目安です。更新の頻度が低く参照の頻度が高いデータほど、非正規化による読み取り性能の恩恵が大きくなる傾向にあります。
正規化しすぎるとどうなりますか。
テーブルの分割が進むほど整合性は保ちやすくなりますが、一覧表示や集計のたびに結合するテーブルの数が増え、読み取り処理の負荷が高まりやすくなります。正規化は進めるほど望ましいわけではなく、参照時の性能とのバランスを踏まえて設計する必要があるでしょう。
正規化と非正規化はどちらが優れていますか。
どちらか一方が常に優れているという関係ではありません。正規化は整合性の維持に強く、非正規化は読み取り性能の確保に強いという、目的の異なる設計上の選択です。扱うデータの更新頻度や参照頻度、整合性の要件に応じて使い分けることが基本になります。
正規化・非正規化とSQL・NoSQLの選定は同じ話ですか。
別の観点の話です。SQL・NoSQLの選定はデータベースの方式そのものを選ぶ判断であるのに対し、正規化・非正規化は同じリレーショナルデータベースの中でテーブルをどう構成するかという設計上の選択です。方式を選んだうえで、さらにテーブル設計として検討する項目といえます。
正規化の方針は、発注時のどのタイミングで決めればよいですか。
要件定義や基本設計の段階で、業務データの更新頻度や参照頻度を整理したうえで方針を固めておくことが望ましいです。データベース設計は後から構造を大きく変更しにくいため、早い段階で正規化・非正規化の方針を発注先とすり合わせておくと、後の手戻りを抑えやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
システム開発・データ設計のご相談はLASSICへ
元請（プライムベンダー）として、テーブル設計の方針整理から、基盤構築を含むシステム開発までご提案します。まずはお気軽にご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：IPA（独立行政法人情報処理推進機構）「情報処理技術者試験」シラバスにおけるデータベース設計・正規化関連の情報（https://www.ipa.go.jp/shiken/）
