正規化は、属性の依存関係を整理して不要な重複や更新時の矛盾を減らす設計です。非正規化は、読み取りなどの要件に合わせて、意図的に重複や統合した構造を持たせる設計です。どちらも名前だけで性能は決まりません。
同じ情報を何度も保存する問題
注文ごとに商品の現在の標準価格を保存していると、価格変更時に複数行の修正が必要になります。商品IDで決まる標準価格を商品表にまとめれば、同じ情報を一か所で管理しやすくなります。
| 表の例 | 持つ情報 |
|---|---|
| 商品 | 商品ID・商品名・現在の標準価格 |
| 注文明細 | 注文ID・明細番号・商品ID・数量・販売時単価 |
ただし、販売時単価は過去の取引事実として残す情報です。現在の標準価格とは意味が異なるため、価格という名前だけで重複と判断しません。正規化では、何が何を決定するかという業務規則を確認します。
正規化と非正規化を比較
| 観点 | 正規化 | 非正規化 |
|---|---|---|
| 狙い | 依存関係を整理して更新時異常を減らす | 特定の利用に合わせて読み取りなどを効率化 |
| 設計上の注意 | 必要な情報を結合で復元できる分割を考える | 重複や派生データの整合性を維持する |
| 性能 | データ量・索引・実行計画などに依存 | 高速化する保証はなく更新費用も増え得る |
非正規化では更新ルールまで設計する
例として集計済みの合計額を別に保存すれば、毎回全明細を集計しなくて済む場合があります。一方、明細の追加・変更・取消しと合計額をどう整合させるかが課題です。同期更新か定期更新か、古い値をどこまで許容するかを決めます。
JOINがあるだけで遅いとは限らない
JOINを減らすことだけで性能改善は判断できません。索引・問い合わせ・行数・読み書きの割合を確認し、実測した問題に対して設計を検討します。更新中心のシステムは正規化、分析は非正規化という傾向は参考になりますが、どのシステムも一律に決まるわけではありません。
非正規形と非正規化を区別
学習上の非正規形は、繰り返し項目などを含む出発点として説明されます。性能などを目的に行う意図的な非正規化と、同じ意味で扱わないようにします。また、表を細かく分けるだけでは正規化を進めたとは言えず、関数従属や情報を損なわない分割が重要です。
分けた表の識別と参照は、主キーと外部キーの違いでも確認できます。
確認問題
販売時単価と現在の商品標準価格は、数値が同じなら必ず片方を削除してよいでしょうか？
解答・解説を見る
いいえ。過去の取引時点の単価と現在の標準価格は意味が異なります。値だけで重複と判断せず、業務上の意味と依存関係を確認します。
キーと正規化をnoteで復習
関連noteには正規化の目的・主キー・関数従属・第1〜第3正規形の解説があります。設計の比較を理解した後は、具体的な表を分ける手順を復習できます。
ほかの教材は資格・目的別のnote教材ナビから選べます。
コメント