前回の危険を、仕組みで防ぐ
前回のL-08では、WHEREを忘れたUPDATEやDELETEが全行を書き換える危険を見ました。あれは人が気をつけて防ぐ話でしたが、人はいつか間違えますし、AIも書き間違えます。この講義では、間違えても壊れないように、データベース自身に守らせる仕組みへ進みます。制約は不正な値の保存そのものを拒み、トランザクションは処理が途中で失敗しても中途半端な状態を残しません。
このスライドのポイント
- L-08: WHEREを忘れたUPDATE・DELETEは全行に作用する（人の注意で防ぐ話だった）
- 人はいつか間違える。AIも書き間違える
- この講義: 間違えても壊れないよう、データベース自身に守らせる
- 制約＝不正な値の保存を拒む／トランザクション＝中途半端な状態を残さない
制約とトランザクションの定義
制約とは、テーブルの定義に書いておく守るべき規則のことです。代表的なものは4つあります。NOT NULLは空の値を許さない規則、UNIQUEは重複を許さない規則、外部キー制約はL-04で見た参照先が存在しない値を許さない規則、そしてCHECKはamountが0より大きいなど条件を満たす値だけを許す規則です。トランザクションとは、複数の変更をひとまとまりとして扱い、途中で失敗したら全部を無かったことに戻す、ロールバックという仕組みです。
このスライドのポイント
- 制約: テーブルの定義に書く「守るべき規則」。代表4つ
なぜ必要か——最後の砦と、中途半端の防止
よくある誤解に、アプリ側で入力を検査しているから制約はいらない、というものがあります。これはJ-06で学んだ信頼境界のデータベース版です。アプリにバグがあったり、別の経路から直接書き込まれたりすると、アプリの検査はすり抜けられます。その最後の砦になるのが制約です。またトランザクションが無いと、振込元から引いたのに振込先へ足す前に失敗する、といった中途半端な状態がそのまま残ってしまいます。
このスライドのポイント
- よくある誤解:「アプリ側で検査しているから制約はいらない」
- これはJ-06の信頼境界のデータベース版
- アプリのバグや別経路からの書き込みは、アプリの検査をすり抜ける → 最後の砦が制約
- トランザクションが無いと:「振込元から引いたのに、振込先へ足す前に失敗」型の中途半端が残る
データを守る防衛線は3段
データを守る防衛線は3段で考えると整理できます。1段目はH-05で見た画面の親切な入力補助、2段目はJ-06のサーバー側の検査、3段目が今回のデータベースの制約です。手前の段はすり抜けられることがあり、どの経路から来ても効く最後の砦が制約になります。トランザクションはこれとは別の観点で、BEGINからCOMMITまでを運命共同体とみなし、全部成功か全部なしのどちらかしか残さない、と押さえてください。
このスライドのポイント
- 防衛線3段（手前ほどすり抜けやすい／制約はどの経路でも効く最後の砦）
承認処理を1トランザクションにする
経費アプリの承認処理を例にします。承認では、expensesテーブルの承認フラグを更新する文と、承認履歴を1行追加する文の、2つの変更が必要です。この2つを1つのトランザクションで囲むと、片方だけ成功した状態をデータベースが作らせません。もし履歴の追加に失敗すれば、承認フラグの更新もまとめて取り消され、処理前の状態に戻ります。2つの変更が運命を共にする、というのがトランザクションの効き目です。
このスライドのポイント
- 経費アプリの承認処理には2つの変更が必要
技術サンプルカード
サンプルはトランザクションの骨子です。BEGINで開始し、UPDATEで経費を承認し、INSERTで履歴を追加し、COMMITで確定します。読み方の要点は、BEGINからCOMMITまでが一蓮托生で、途中で問題が起きたときはROLLBACKで全部を取り消せることです。L-08で学んだ、先にSELECTで対象を確かめる安全手順も、このBEGINで包んでおけばやり直しがきくようになります。
アプリの検査 vs DBの制約
混同しやすいのが、アプリの検査とデータベースの制約です。アプリの検査は親切で分かりやすい一方、J-06で見たとおり別経路から迂回される可能性があります。データベースの制約は、どの経路から来ても必ず効きますが、利用者への丁寧な案内はできません。どちらが優れているかではなく、両方そろえて初めてデータが守られる、と理解してください。
バイブコーディングでの確認点
バイブコーディングでの確認点です。複数のテーブルをまたぐ更新をAIに作らせたら、トランザクションで囲まれているかを必ず確認しましょう。特に金額や在庫、履歴が絡む処理では必須です。テーブルを設計するときは、空を許さない列や重複を許さない列に、制約が付いているかも確かめてください。AIへの質問例としては、この一連の更新はトランザクションで囲まれていますか、途中で失敗したらどうなりますか、と聞くとよいでしょう。
このスライドのポイント
- 複数テーブルをまたぐ更新をAIに作らせたら、トランザクションで囲まれているか確認
まとめと次回
一問一答です。複数の変更を、全部成功か全部無しにする仕組みは何でしょうか。（間）答えはトランザクションです。30秒まとめとして、制約は不正な値を入り口で拒む規則、トランザクションは複数の変更をひとまとまりで扱う仕組みで、どちらもデータを壊さないための守りです。次回はカテゴリL最終回、検索の速さと構造変更と復旧の3点を扱います。関連資料は「DB設計チェックリスト50」と「監査ログと変更履歴入門」です。
このスライドのポイント
- 一問一答: 複数の変更を、全部成功か全部無しにする仕組みは？ → トランザクション
- 30秒まとめ: 制約＝不正な値を入り口で拒む規則／トランザクション＝複数の変更をひとまとまりで扱う仕組み。どちらもデータを壊さない守り
- 次回: カテゴリL最終回。検索の速さ・構造変更・復旧の3点へ
- 関連資料: 「DB設計チェックリスト50」「監査ログと変更履歴入門」
