3.3データベース（関係モデル・正規化・SQL・トランザクション・排他制御・障害回復）

データベースは基本情報技術者試験の科目Aで安定して出題される重要領域です。正規化の理由と手順、SQLの基本構文、複数人が同時にアクセスしたときの整合性維持、障害からの復旧手順という4つの柱を、単なる用語の暗記ではなく「なぜそうするのか」という設計判断として理解することが得点への近道です。

3.3.1関係モデルと正規化

• 関係モデル＝データを行と列からなる表（リレーション）として扱うモデル。各行は1件のデータ、各列は属性を表す。表同士は共通の列（キー）を介して関連付けられる。
• 正規化＝データの重複と更新時の不整合（更新異常）を防ぐために表を分割する設計手法。第1正規形（1NF）＝繰り返し項目（1つのセルに複数値）を排除し、各セルを単一値にする。第2正規形（2NF）＝1NFに加え、主キーの一部だけに従属する列（部分関数従属）を別表に分離する（複合主キーの表で問題になる）。
• 第3正規形（3NF）＝2NFに加え、主キー以外の列に従属する列（推移的関数従属）を別表に分離する（例：注文表に「顧客ID」だけでなく「顧客名」まで持たせると、顧客名は主キーでなく顧客IDに従属する推移的従属となり分離対象）。正規化を進めるほど更新時の不整合は減るが、JOINが増え検索性能は低下しうるというトレードオフがある。

3.3.2SQLの基本と主キー/外部キー

• SELECT文＝表からデータを取得する（SELECT name FROM employees WHERE dept = 'sales'）。JOIN＝複数の表を結合する（一致する行のみの内部結合や、一致しない側もNULLで残す外部結合がある）。GROUP BY＝指定列の値ごとに行をグループ化し、集約関数（count/sum等）と組み合わせて使う。
• 主キー（PRIMARY KEY）＝表の中で行を一意に識別する列（重複禁止・NULL禁止）。外部キー（FOREIGN KEY）＝他の表の主キーを参照する列で、参照先に存在しない値の登録を防ぐ参照整合性を保証する（例：注文表の「顧客ID」が顧客表に実在する値のみ許可）。

3.3.3トランザクションと排他制御・障害回復

• トランザクション＝「すべて実行されるか、すべて実行されないか」という単位で扱う一連の処理（例：口座振替＝出金と入金は両方成功するか両方失敗するかのいずれか）。ACID特性＝原子性（Atomicity）全て成功/失敗の二択・一貫性（Consistency）実行後もデータの整合性を保つ・独立性（Isolation）同時実行される他のトランザクションから干渉されない・耐久性（Durability）正常終了した結果は障害が起きても失われない。
• 排他制御＝複数のトランザクションが同じデータへ同時にアクセスした際の不整合を防ぐ仕組み。ロックでデータへの一時的な独占権を確保する（読み取り用の共有ロックと更新用の専有ロックがある）。デッドロック＝互いに相手が確保したロックの解放を待ち続け、双方とも先に進めなくなる状態（一方を強制的にロールバックさせて解消する）。
• 障害からの復旧はログ（更新前ログ・更新後ログ）を用いて行う。ロールバック＝異常終了したトランザクションの更新を更新前ログで巻き戻し、実行前の状態に戻す（トランザクション障害時）。ロールフォワード＝バックアップ以降の更新後ログを再適用し、障害直前の状態まで復元する（ディスク障害等でバックアップからの復旧が必要な場合）。「戻す=ロールバック・進める=ロールフォワード」という方向の違いが最頻出。
• NoSQL＝関係モデル（表形式）に縛られないデータベースの総称。キーバリュー型（単純なキーと値の対）・ドキュメント型（JSON等の半構造データ）・グラフ型（ノードと関係を表現）などがあり、大量データの分散処理や柔軟なスキーマが必要な場面でリレーショナルDBの代替・併用として選ばれる。

受注管理システムを設計する場面で正規化からトランザクションまでの流れを追いましょう。最初に用意した「注文表」に注文ID・顧客ID・顧客名・商品名・数量・単価をすべて1つの表に詰め込んだとします。この表では同じ顧客が複数回注文するたびに顧客名が重複して記録され、顧客名を変更したい場合に全注文行を漏れなく更新しないと不整合が生じます（更新異常）。顧客名は主キー（注文ID）ではなく顧客IDに従属する情報なので、これは第3正規形違反であり、顧客表（顧客ID・顧客名）を分離し、注文表には顧客IDを外部キーとして持たせることで解消します。同様に、1注文に複数商品が含まれる場合に商品名・数量・単価を注文表の1行に繰り返し項目として詰め込むのは第1正規形違反であり、注文明細表として分離する必要があります。正規化後、実際に注文を検索する際はSELECT o.id, c.name, sum(d.quantity * d.unit_price) FROM orders o JOIN customers c ON o.customer_id = c.id JOIN order_details d ON o.id = d.order_id GROUP BY o.id, c.name;のようにJOINとGROUP BYを組み合わせて元の1表構成のときと同じ情報を再構築します。次に「注文確定」の処理を考えると、在庫数を減らす更新と注文レコードを作成する挿入は、どちらか一方だけ成功すると在庫と注文の整合性が崩れるため、1つのトランザクションとして原子性を保証する必要があります。ここで2人の担当者が同じ商品の在庫行を同時に更新しようとすると、片方が排他制御のロックを確保し、もう片方は解放を待ちます。もし2つのトランザクションが互いに相手の確保したロックを待つ関係になればデッドロックが発生し、DBMSは一方を強制的にロールバックして解消します。最後に、システムが処理の途中で異常終了した場合、中断したトランザクションの更新は更新前ログでロールバックされ、一方でハードディスク自体が壊れてバックアップから復旧する場合は、バックアップ取得以降の更新後ログをロールフォワードで再適用して障害直前の状態まで戻します。

3.3.4この節のまとめ

• 正規化(1NF→2NF→3NF)は重複・更新異常を減らすがJOIN増加とのトレードオフ。主キー=一意識別・外部キー=参照整合性
• ACID(原子性/一貫性/独立性/耐久性)でトランザクションを保証。排他制御のロックが行き詰まるとデッドロック
• ロールバック=更新前ログで戻す(Tx障害)・ロールフォワード=更新後ログで進める(バックアップ復旧)。NoSQLは表形式に縛られない代替