非正規化（逆正規化）の適用基準と整合性担保パターン

非正規化は、重複列や事前集計などで読取りの負担を減らす代わりに、容量と更新処理、整合性の管理を増やす設計です。先に正規化した論理モデルと守る業務制約を明らかにし、実測したボトルネック、更新頻度、許容する鮮度から適用を判断します。結合を使う設計が必ず遅いわけではありません。

何を重複させるか、何を省けるか

大きく低頻度な列を別表へ分ける垂直分割は、アクセスする行の幅を減らす物理設計です。必ずしも冗長性を増やす非正規化ではありません。同じ種類の設計として一括せず、正規形を変えるのか、配置を変えるだけなのかを確認します。

履歴の値と、現在値の複写は別の事実

注文に保存する顧客名が「現在の顧客名のコピー」なら、顧客の変更と同期する必要があります。一方「注文時の請求先名」や「成立時の単価」は、当時の事実を保存する属性です。現在のマスタ変更で過去の注文を書き換えると、むしろ履歴を壊します。

似た列名でも、意味と有効時点を先に決めます。正規化の従属も、その業務上の意味を前提として判定します。過去の全注文を必ず更新する、という一律の説明はできません。履歴の固定値と再計算可能な現在のサマリを区別すると、更新責任が明確になります。

サマリは同一トランザクションと並行制御で守る

受注の合計金額を明細から事前保存するなら、明細の追加・数量変更・単価変更・削除・取消をすべて対象にします。明細更新と合計更新を同一トランザクションにすると途中の一方だけが確定することを防げます。ただし同一トランザクションにしただけで、並行する再計算の上書きが常に防がれるわけではありません。

たとえば別明細を同時に変更し、各処理が古い状態から合計を計算すると、親への書込みが直列でも後の合計が先の変更を含まない可能性があります。親行を共通の順序でロックしてから明細を変更・再計算する、または整合する差分を親へ原子的に加えるなど、全経路で同じ規則を守ります。複数受注を扱う場合は受注番号順などで取得し、循環待ちを減らします。

トリガー・実体化結果・突合せの役割

トリガーは更新規則をDB側へ集約できますが、大量更新の負担やロック取得順序、循環更新、取消時の動作を確認します。トリガーを付けたから並行競合をすべて解決できるわけではありません。業務操作が複数表へ与える影響を図にして、どの経路が値を更新するかを点検します。

マテリアライズドビューの更新は製品によって異なります。PostgreSQLでは通常REFRESH MATERIALIZED VIEWで内容を更新するため、元表が変われば即時に自動更新されるものではありません。取得時に鮮度を示す、同期更新が必要な用途と分けるなどの判断が必要です。

定期的な突合せや再計算は、誤差を発見して修復する方法です。突合せまでの不一致を許容できない請求・在庫などでは、即時の整合性維持の代わりにはなりません。元データが正しいこと、再計算処理が実行できること、差分発見後の対応も設計します。

演習1：合計の差分更新

条件：明細は2個×100円と1個×300円。前者を3個へ変更し、他の条件は不変。

問い：元の合計、新合計、差分を求めよう。

解答例：元500円、新600円、差分+100円。

根拠：明細と親の合計を同じ確定単位で更新し、並行変更が上書きされない処理にする。

演習2：現在値と履歴値

条件：顧客が社名変更した。注文には当時の請求先名を確定時の事実として保存している。

問い：過去の請求先名を現在名に同期しない理由を説明しよう。（35字以内）

解答例：注文時点の事実を保存する属性だから。（18字）

根拠：現在名のコピーではなく、別の時点の事実である。

復習で確かめること

例の数値や業務条件を変えて同じ結論になるか確認してください。用語の定義だけでなく、問題文のどの条件から、どの制約・SQL・対策を選んだのかを自分の言葉で説明できれば、次の過去問に進みます。

出典と仕様を確認する

IPA：DBシラバス Ver.4.1

PostgreSQL 18：マテリアライズドビュー

PostgreSQL 18：ロック

関連するテーマ

関係モデルと正規化理論（第1〜第3正規形・BCNFと関数従属の導出）

トランザクションACID特性とロック機構・デッドロック回避の設計