永続化

• 日程: Day 3 / セッション7
• 時間: [13:30-14:00]
• 形式: 座学
• ゴール: ACID（原子性・一貫性・独立性・永続性）を説明し、RDB（正規化）とKey-Valueストアの使い分けを説明できる
• 学習形式: 対話型解説

🗣️ 要約

• データを消えない形で保存する仕組みを「永続化」と呼ぶ
• 永続化には「安全に保存する」視点（ACID）と「どこに保存するか」視点（RDB・Key-Valueストア）がある
• 銀行の振込システムが1件も間違えない仕組みは、この2つの視点で説明できる

前のセッションでは、開発テーマの機能をMVCで分解しました。Model・View・Controllerのうち、Modelが担っているのは「データを保持し続けること」でしたね。

では質問です。あなたが今使っているスマホの家計簿アプリ、アプリを閉じてもう一度開いたとき、入力したデータはどうなっていますか？消えていたら困りますよね。

データを「消えない形」で保存しておく仕組みのことを「永続化」と呼びます。今回はこの永続化について、特に「安全に保存する」という視点（ACID）と「どこに保存するか」という視点（RDBとKey-Valueストア）の2つを学びます。このセッションが終わる頃には、なぜ銀行の振込システムが1件も間違えられないのか、その裏側の仕組みを説明できるようになっています。

🗣️ 要約

• ACIDはデータベースが守るべき4つの約束（原子性・一貫性・独立性・永続性）
• 永続化の方法にはRDB（正規化）とKey-Valueストアがあり、目的によって使い分ける
• オブジェクト（情報モデル）とテーブルの形の違いが「インピーダンス・ミスマッチ」で、O/Rマッピングが橋渡しする

🗣️ 要約

• ACIDは原子性・一貫性・独立性・永続性という4つの約束
• 原子性は「全部成功か、全部失敗（なかったことにする）」のどちらかしか許さないこと
• 4つすべてが同時に満たされて初めて意味がある

たとえば、あなたが銀行アプリでAさんからBさんへ1万円を振り込んだとします。このとき裏側では、

• Aさんの残高から1万円を引く
• Bさんの残高に1万円を足す

という2つの処理が行われます。ここでもし、1つ目の処理が終わった直後にシステムが停止してしまったらどうなるでしょうか？少し考えてみてください。Aさんの1万円は消えたのに、Bさんには振り込まれていない——そんな事故が起きてしまいます。

このような事故を防ぐために、データベースには「ACID」という4つの約束があります。

• 原子性（Atomicity）：複数の処理をひとまとまりとして扱い、「全部成功」か「全部失敗（なかったことにする）」のどちらかしか許さない。振込の例で言えば、引く処理と足す処理は必ずセットで成功する
• 一貫性（Consistency）：処理の前後でデータのルール（残高がマイナスにならない、など）が破られない
• 独立性（Isolation）：複数の処理が同時に走っても、互いに干渉しない。AさんとCさんが同時に振込操作をしても、結果が混ざらない
• 永続性（Durability）：一度「成功した」と認められた処理は、たとえ直後に停電しても消えない

これは、いわば「銀行の窓口係が持つ職業倫理」のようなものです。窓口係は「途中でやめる」ということをせず、必ず最後までやり切るか、最初からやらなかったことにするか、どちらかしか選びません。だからこそ私たちは安心してお金を預けられるのです。

ここまでで、ACIDが「なぜ必要か」についてイメージできましたか？

特に注意してほしいのは、ACIDは「4つとも同時に満たされて初めて意味がある」という点です。原子性だけ満たしていても、独立性がなければ同時アクセスで結果が壊れます。よくある誤解として「ACIDはデータベース製品の機能の名前」だと思われがちですが、正しくは「データベースが満たすべき性質・約束事」の名前です。RDB（リレーショナルデータベース）の多くはこのACIDを重視して設計されています。

🗣️ 要約

• 永続化の方法は「ファイル保存」と「データベース利用」に大別され、実務ではRDBかKey-Valueストアが使われる
• RDBは正規化してテーブル形式に整理し、複雑な関連の集計に向く
• Key-Valueストアはキーと値のペアで保存し、単純な出し入れの速さに向く

永続化の方法にはいくつか種類がありますが、大きく分けると「ファイルに直接保存する」方法と「データベースを使う」方法があります。実務では後者、特にRDBかKey-Valueストア（KVS）を使うことがほとんどです。

RDBは、Day1で学んだ「情報の整理・分類」に似た作業である「正規化」を行い、データを表（テーブル）の形に整理して保存します。たとえば家計簿アプリなら「支出テーブル」「カテゴリテーブル」のように、情報を重複なく整理してから保存します。一方Key-Valueストアは、「キー」と「値」のペアだけで保存する、もっとシンプルな仕組みです。たとえば「ユーザーID123のセッション情報」のように、1つのキーに1つのかたまりのデータを紐づけて保存します。

たとえば、複雑な関連（誰が・いつ・何を買ったか、を横断的に集計したい）を扱いたいなら正規化されたRDBが向いていますが、単純に「このIDのデータをとにかく速く出し入れしたい」（ログイン状態の保持など）という場合はKey-Valueストアの方が向いています。どちらが優れているという話ではなく、目的によって使い分けるものだと考えてください。

🗣️ 要約

• オブジェクト（情報モデル）の形とテーブルの形が一致しない問題を「インピーダンス・ミスマッチ」と呼ぶ
• 「1人のペルソナが複数の支出を持つ」ような関係は、テーブルではペルソナIDの列を持たせる形に変換する必要がある
• O/Rマッピングは、オブジェクトとRDBの間を自動で橋渡しする仕組み

Day2で、みなさんは「情報モデル」を抽出しましたね。情報モデルはオブジェクト（もの）として、属性や振る舞いをひとまとまりに持っています。ところが、RDBはデータを「表」の形でしか保存できません。

このオブジェクトの形と、テーブルの形がぴったり一致しない、という問題を「インピーダンス・ミスマッチ」と呼びます。もとは電気工学の用語で、回路のインピーダンス（電気的な性質）が合わないと信号がうまく伝わらないことから来ています。オブジェクトとテーブルという、形の違う2つの世界をつなごうとすると、同じように「うまく伝わらない」摩擦が起きるわけです。

たとえば、「1人のペルソナが複数の支出を持つ」という情報モデルをテーブルで表現しようとすると、ペルソナのオブジェクトの中に支出のリストをそのまま入れることはできず、「支出テーブルにペルソナIDの列を持たせる」といった、テーブルならではの表現に変換する必要があります。

この変換を自動でやってくれる仕組みが「O/Rマッピング（Object-Relational Mapping）」です。オブジェクトとリレーショナル（RDB）の間を橋渡ししてくれる、いわば通訳のような存在だと考えてください。

🗣️ 要約

• Isolation（独立性）の分かりにくさや、自分たちの開発テーマにRDB・KVSどちらが向くか、インピーダンス・ミスマッチが招く実務上のバグなどをAIに質問できる

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「ACIDの中で一番わかりにくいIsolation（独立性）を、身近な例でもう一度説明して」
• 「自分たちの開発テーマ（〇〇システム）は、RDBとKey-Valueストアのどちらが向いている？」
• 「インピーダンス・ミスマッチは実務でどういうバグにつながるの？」

🗣️ 要約

• 永続化とは、データを安全に（ACID）、目的に合った形で（RDB or KVS）残すこと
• 情報モデル（オブジェクト）とテーブルの形の違いがインピーダンス・ミスマッチであり、O/Rマッピングがそれを橋渡しする
• 次回はRDBの正規化とDay1の情報アーキテクチャの整理・分類を見比べる演習を行う

今回学んだことを一言でまとめると、「データを安全に（ACID）、目的に合った形で（RDB or KVS）残す」のが永続化です。そして、情報モデル（オブジェクト）とテーブルの形の違いが「インピーダンス・ミスマッチ」であり、O/Rマッピングがそれを橋渡しする、という3点を押さえておいてください。

次回は、この「RDBの正規化」と、Day1で学んだ「情報アーキテクチャによる整理・分類」を見比べる演習に挑戦します。今回の正規化・ACIDの知識が土台になるので、しっかり復習しておきましょう。

🗣️ 要約

• ACIDの4つの要素をそれぞれ一言で説明できるか
• RDBとKey-Valueストアをどんな基準で使い分ければよいか
• インピーダンス・ミスマッチが起きる理由を説明できるか

以下の問いに答えられるか確認してみましょう：

• ACIDの4つの要素を、それぞれ一言で説明できますか？
• RDBとKey-Valueストアを、どんな基準で使い分ければよいか説明できますか？
• インピーダンス・ミスマッチが起きる理由を説明できますか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

🗣️ 要約

• 参考リンクは特になく、各自が使うRDB製品・O/Rマッパーの公式ドキュメントを参照する
• 発展課題は、開発テーマをRDB設計とKey-Valueストア設計の両方で書き出して比較すること

• 参考リンク: なし（社内・外部の特定ツールに依存しないため、各自が使うRDB製品・O/Rマッパーの公式ドキュメントを参照してください）
• 発展課題: 自分たちの開発テーマについて、RDBで設計した場合とKey-Valueストアで設計した場合のテーブル／データ構造をそれぞれ書き出し、比較してみましょう

🗣️ 要約

• 受講者からよく出る質問への回答例と、つまずきやすいポイントへの対処法をまとめている

このセクションは、受講者が理解を深めることをサポートする参考情報です。

🗣️ 要約

• Key-Valueストアは、NoSQL（非RDB）の一種の1つ
• ACIDを完全に満たさないデータベースも存在するが、多くのRDBはACIDを重視する
• O/Rマッピングを使っても、複雑な関連を扱う際にはインピーダンス・ミスマッチへの意識が依然として必要

🗣️ 要約

• ACIDの4つの用語（原子性・一貫性・独立性・永続性）は覚えにくい
• 正規化とKey-Valueストアの違いがイメージしにくい
• 「インピーダンス・ミスマッチ」という言葉自体が難しく感じられる