第3章：高度なデータベース設計と管理

3-1. 非正規化の判断基準

スタンダードでは「重複をなくす（正規化）」を学びましたが、アドバンストではあえて重複を許容する**「非正規化（崩し）」**を学びます。

• なぜ非正規化するか:

  • テーブル結合（JOIN）があまりに多くなると、検索速度が著しく低下するため。

• 主な手法:

  • サマリーテーブルの作成: 大量のトランザクションデータの合計値をあらかじめ計算して別テーブルに持っておく。

  • 冗長な列の追加: 頻繁に参照される名称などを、結合しなくて済むように元のテーブルにも持たせる。

• 注意点: データの更新時に、コピー元の値と不整合が起きないようアプリケーション側やトリガーでの厳密な管理が求められます。

3-2. ストアドプロシージャとトリガー

データベース内部にロジックを持たせる仕組みです。

• ストアドプロシージャ:

  • 複雑な一連の処理をSQLとしてDBサーバー側に保存したもの。

  • メリット: ネットワークトラフィックの削減（1回の呼び出しで済む）や、処理の共通化。

• トリガー:

  • 「データの挿入・更新・削除」などのイベントに反応して、自動で実行される処理。

  • 用途: 更新ログの自動記録、非正規化テーブルへの同期、複雑な制約チェック。

3-3. ロック制御と排他制御

複数のユーザーが同時に同じデータを書き換えようとした際、データの整合性を守る仕組みです。

• ロックの種類:

  • 共有ロック (Shared Lock): 読み取り時にかける。他の人の読み取りは許可するが、書き換えは待たせる。

  • 排他ロック (Exclusive Lock): 書き換え時にかける。他の人の読み取りも書き換えも一切禁止する。

• デッドロック (Deadlock):

  • 2人のユーザーがお互いに相手の持っているロックが解除されるのを待ってしまい、処理が止まる現象。

  • 対策: テーブルにアクセスする順番をシステム全体で統一する、トランザクションを短く保つといった工夫が必要です。

3-4. 楽観的ロックと悲観的ロック

• 悲観的ロック: 「誰かが更新するかもしれない」と考え、あらかじめDBの機能でロックをかける（SELECT FOR UPDATE など）。

• 楽観的ロック: 「競合は滅多に起きない」と考え、ロックはかけない。更新時に「自分が読み取った時からデータが変わっていないか」を確認する（バージョン番号や更新日時を使用）。

第3章のまとめ

• 非正規化は、読み取り速度を稼ぐための「諸刃の剣」である。

• ストアドプロシージャ等を活用し、DBに近い場所で処理を完結させる。

• デッドロックを防ぐための設計ルールを徹底する。

• 業務要件に合わせて楽観的/悲観的ロックを使い分ける。