もしもこの世界に
RDBがなかったらあなたには、この Excel の何が壊れているかわかりますか？
下に、架空 EC サイトの受注管理 Excel があります。仕込まれているのは7 つの明らかにおかしい箇所。
「Excel でどうにかなる」で止まっていた業務データ管理の限界を、RDB が黙って守ってくれている5 つの根本価値で1 つずつ言語化していきましょう。
リレーショナルデータベース管理システム (RDBMS) とは、リレーショナルモデルに基づいてデータを表形式で管理し、トランザクションによる ACID 特性と一意性・参照整合性などの宣言的制約を通じて、複数ユーザー環境でのデータ整合性を構造的に保証するデータ管理システムである。
| 商品ID | 商品名 | 在庫 |
|---|---|---|
| P-042 | プレミアム座布団 | 12 |
| P-018 | 竹製箸 | 42 |
| 顧客ID | 名前 | メール |
|---|---|---|
| C-001 | 山田太郎 | yamada@example.com |
| C-002 | 佐藤花子 | sato@example.com |
| C-999 | 山田太郎 | taro@example.com |
- P-042 座布団の受注 5 件 (各 qty 1、合計 5 units)
- P-018 竹製箸の受注 2 件 (qty 2 + 3 = 5 units)
- C-999 の退会処理 (削除)
- 新規顧客登録 3 件 (C-011 / C-012 / C-013、 いずれも「山田太郎」を名乗る)
| 注文ID | 顧客ID | 顧客名 | 商品ID | 数量 | 金額 | 日時 | |
|---|---|---|---|---|---|---|---|
| 2 | ORD-001 | C-001 | 山田太郎 | P-042 | 1 | ¥9,800 | 2026-03-15 10:22 |
| 3 | ORD-001 | C-002 | 佐藤花子 | P-042 | 1 | ¥10,800 | 2026-03-15 10:23 |
| 4 | ORD-002 | C-999 | #N/A | P-018 | 2 | ¥7,600 | 2026-03-15 11:05 |
| 5 | ORD-003 | C-011 | 山田太郎 | P-042 | 1 | ¥9,800 | 2026-03-15 11:47 |
| 6 | ORD-004 | C-012 | 山田太郎 | P-042 | 1 | ¥9,800 | 2026-03-15 12:10 |
| 7 | ORD-005 | C-013 | 山田太郎 | P-042 | 1 | ¥9,800 | 2026-03-15 12:33 |
| 8 | ORD-006 | C-001 | 山田太郎 | P-018 | 3 | ¥30.00 ($9.99×3) | 2026-03-15 13:15 |
| 9 | (削除済み?) | — | — | — | 0 | — | 2024-03-15 (最終保存不整合) |
| 顧客ID | 名前 | メール |
|---|---|---|
| C-001 | 山田太郎 | yamada@example.com |
| C-011 | 山田太郎 | n/a |
| C-012 | 山田太郎 | unknown |
| C-013 | 山田太郎 | - |
| C-002 | 佐藤花子 | sato@example.com |
| 商品ID | 商品名 | 在庫 |
|---|---|---|
| P-042 | プレミアム座布団 | 12 |
| P-018 | 竹製箸 | 37 |
RDB の 5 つの根本価値を体系的に学ぶ
事故インパクトの大きい順に並べています。7 つの違和感の解説から辿ってきた場合は、 該当ページだけ拾い読みしても構いません。
- 基礎01原子性注文だけが残った夜 (原子性)
受注時に「注文追加 → 在庫減算」の 2 段階マクロを実行する Excel で、途中で止まって注文は記録されたが在庫が減らないままの中途半端な状態が積み重なった。この事故から、RDB のトランザクションが提供する「原子性 (atomicity)」を体系的に理解する。
- 基礎02同時実行制御2 人が同時に書いて修正が消えた (同時実行制御)
経理担当 A と担当 B が同じ売上シートを開いて別々の修正を保存した結果、後に保存した側が先の修正を上書きして消してしまった (Lost Update)。RDB のロックと分離レベルによる同時実行制御を、この事故から学ぶ。
- 基礎03一意性「山田太郎」の行が 4 つある (一意性)
顧客管理シートに「山田太郎」の行が 4 つできてしまい、しかもそれぞれ違う連絡先。同一人物の再登録なのか、同姓同名の別人なのかシステム的に判定できない。この事故から、RDB の主キーと UNIQUE 制約による一意性の保証を理解する。
- 基礎04参照整合性顧客 ID が消えた注文シート (参照整合性)
顧客シートで顧客 ID「C-999」の行を削除したのに、注文シートには「C-999」の注文が残ったまま。宛先が不明になった。この事故から、RDB の外部キー制約と CASCADE / RESTRICT / SET NULL の挙動を学ぶ。
- 基礎05永続性停電で全部消えた (永続性)
深夜の停電から復電後、Excel を開くと当日の受注データがまるごと消えていた (最終保存は朝、以降 8 時間分が全滅)。この事故から、RDB の Write-Ahead Logging (WAL) と COMMIT 時のディスク同期による永続性を理解する。
- 基礎06RDB の 5 つの根本価値RDB が黙って守ってくれている 5 つの根本価値 (総括)
5 つの事故から見えた「Excel には無くて RDB には有る」5 つの根本価値 (原子性 / 同時実行制御 / 一意性 / 参照整合性 / 永続性) を横断的にまとめる。ACID と宣言的制約が「なぜ RDB なのか」の答えである。
RDB を選んだあと、次に学ぶこと
「なぜ RDB か」を掴んだら、次は「どう動くか (性能)」と「どう設計するか (スキーマ)」の 2 面へ。
よくある疑問
もっと学びたい方へ（おすすめ書籍）
テーブル設計と正規化、パフォーマンス考慮のインデックス設計まで実務レベルで学べる定番書。第2版ではクラウド対応も強化。
実務でやりがちなSQL・DB設計のアンチパターンとその回避策を体系的に学べる。
IPAデータベーススペシャリスト試験の総合対策書。インデックス関連は本サイトと合わせて学ぶと理解が深まる。
リレーショナルモデルの理論から、インデックス設計を含む実務で使えるSQLまで解説。
ER 図をどう「使える設計」に落とすか、実務の判断まで踏み込んだ入門書。エンティティの切り出しから多対多の扱いまで具体例が豊富。
SQLの本質的な使い方と、インデックスが効くクエリの書き方を学べる。ウィンドウ関数など現代SQLも網羅。
PostgreSQLの内部構造・ストレージ・インデックス機構を丁寧に解説。設計と運用計画の鉄則が学べる。
本セクションはAmazonアソシエイトのリンクを含みます。
もっと深くDBを学びたい方へ。
たいてっくが、SQL・データベース設計・パフォーマンスチューニング・ IPAデータベーススペシャリスト対策まで、1対1で学習をサポートします。まずは無料相談から。
「教え方も上手で、お人柄も良いメンターです。DB周りの知識はもちろん、何より、しっかり教えてあげようという姿勢がとてもありがたかったです。データベース、SQLの学習を考えている方にはおススメです。」
— H 様（DB・SQL コース受講）「体系的に知識を教えてくださり、実際の業務でも大変役立っております。特に短い時間で効率よく知識の習得や、練習をできているのは期待以上でした。」
— M 様（DB・SQL コース受講）「大変充実したコンテンツでわかりやすいご説明をありがとうございました。基本的な質問にも丁寧にご説明いただき、また業務のご相談にも乗って頂き大変有意義な時間でした。」
— K 様（DB・SQL コース受講）