リレーショナルDB（RDB / SQL）とは — 表・関係・トランザクション

📖 このページのゴール：データの置き場所の第一候補であるリレーショナルDB（RDB）が「何者か」を、たとえと表で腹落ちさせる。表・行・列、表どうしを結ぶ関係（リレーション）、共通言語SQL、設計図のスキーマ、そして「ぜんぶ成功か、ぜんぶ取り消し」のトランザクションまで。むずかしい言葉は全部その場でほどきます。 ← 目次・はじめにへもどる

リレーショナルDB（relational database＝関係データベース。略してRDB）とは、データをかっちりした表（テーブル）の形でしまっておき、表どうしを「関係」で結びつけて使うデータベースです。世の中のアプリのデータの置き場所として、いちばん長く・いちばん広く使われてきた王道です。「DB」と言ったらまずこれ、と思って大丈夫。

🗄 ひとことのたとえ

きっちりした表計算（エクセル）＋伝票。

RDBは、ルールがしっかり決まった表計算ソフトだと思ってください。「この列は数字しか入れちゃダメ」「この欄は空っぽ禁止」「同じ会員番号を二重に作るの禁止」——そんなかっちりしたルールが最初から効いていて、変なデータが紛れ込みにくい。だから正確で、信頼できる。

そして、表が1枚だけではありません。「会員の表」「注文の表」「商品の表」…と複数の表に分けて持ち、伝票のように番号でつなぎます。注文の伝票に「お客様番号: 12」と書いてあれば、会員の表の12番（＝田中さん）を見にいける。この「番号でつなぐ」が“関係（リレーション）”で、RDBの名前の由来です。

🟢 「ルールが厳しいエクセルを、何枚も、番号でつなげて持っている」——これがRDBのイメージです。厳しいぶん、データが散らからず、信用できるのが最大の強み。

🧩 何者？（しくみ）

RDBを理解するのに必要な部品は、たった5つです。順番に、たとえつきで見ていきます。

① テーブル（表）＝行（レコード）＋列（カラム）

データはテーブル（表）にしまいます。表は 行（レコード） と 列（カラム） でできています。

列（カラム） … 表のタテ。「項目の種類」。例：id・名前・メール・年齢。
行（レコード） … 表のヨコ1本。「1件ぶんのデータ」。例：田中さん1人ぶん。

会員テーブルの例：

id	名前	メール	年齢
1	田中	tanaka@example.com	28
2	佐藤	sato@example.com	35
3	鈴木	suzuki@example.com	22

🟢 列＝項目（タテ）／行＝1件（ヨコ）。エクセルそのままの感覚でOKです。いちばん左の id（番号）は、行を1件ずつ見分けるための通し番号で、ほぼ必ず付けます。

② 表どうしを「関係（リレーション）」で結ぶ

ここがRDBの本体です。1枚の巨大な表に全部詰め込まず、意味ごとに表を分けて、番号でつなぎます。

たとえば「誰が何を注文したか」。会員の情報を注文のたびに丸ごとコピーしていたら、田中さんがメールを変えたとき、全部の注文を直す羽目になります。そこで——

会員テーブル（上の表）とは別に、注文テーブルを持ち、会員id で会員テーブルを指す（＝伝票に「お客様番号」を書く）。

注文id	会員id	商品	金額
101	1	本	1500
102	1	ペン	200
103	3	ノート	400

注文101の 会員id=1 をたどれば、会員テーブルの1番＝田中さんだとわかります。この「番号で別の表を指す」つなぎ方が関係（リレーション）。指すための番号（ここでは 会員id）を、専門用語で外部キー（がいぶキー＝よその表を指す鍵）と呼びます。

  会員テーブル                      注文テーブル
 ┌────┬──────┐              ┌──────┬───────┬──────┐
 │ id │ 名前 │              │注文id│会員id │ 商品 │
 ├────┼──────┤              ├──────┼───────┼──────┤
 │ 1  │ 田中 │◀───────────┤ 101  │  1    │ 本   │
 │ 2  │ 佐藤 │     │      │ 102  │  1    │ ペン │
 │ 3  │ 鈴木 │◀────┼──────┤ 103  │  3    │ノート│
 └────┴──────┘     └─ 「会員id」で会員テーブルを指す（＝関係）

🟢 同じことを何度も書かず、番号でつなぐ。 これで「田中さんのメール変更」は会員テーブルの1か所を直すだけ。データのダブりが消え、矛盾が起きにくくなります。これがRDBが「正確」と言われる正体です。

③ 共通言語＝ SQL（エスキューエル）

RDBにお願いをするときの共通の言葉が SQL（Structured Query Language＝問い合わせの言語）です。だから「RDB」と「SQL」はほぼセットで語られます。

「会員テーブルから、年齢が30以上の人の名前をちょうだい」——これをSQLで書くと、ほぼ英語のままです。

SELECT 名前 FROM 会員 WHERE 年齢 >= 30;
   （取り出して  会員から   条件は 年齢が30以上）

ありがたいのは、この言葉がほぼ共通なこと。PostgreSQL でも MySQL でも、SQLの基本はだいたい同じ。一度SQLを覚えれば、いろんなRDBで使い回せる——ここが、後で出てくる「移行しやすい」「まず間違いない」につながります。

🔧 表をまたいだ取り出し（注文と会員をくっつけて「誰が何を買ったか」を一覧する）も、SQLの JOIN（ジョイン＝結合） という命令一発でできます。この「複雑な突き合わせが得意」が、後で出てくるNoSQL（第7章）との大きな違いです。今は「SQLは表どうしの突き合わせが強い」とだけ覚えれば十分。

④ スキーマ（設計図）＝型をかっちり決める

スキーマ（schema＝表の設計図）とは、「この表にはどんな列があり、各列にはどんな種類（型）のデータが入るか」を前もって決めたルールのことです。

列	型（入れていいもの）	例
id	整数（数字だけ）	1, 2, 3
名前	文字（テキスト）	田中
メール	文字（テキスト・重複禁止）	tanaka@example.com
年齢	整数（数字だけ）	28

設計図を先に決めておくので、ルール違反のデータはそもそも入りません。年齢の欄に「りんご」と書こうとすればはじかれる。メールを二重登録しようとすれば止められる。

🟢 スキーマ＝「先に表のルールを決めておく方式」。最初にかっちり決めるぶん最初は少し手間ですが、変なデータが入らないので、あとでずっと安心。これが「形がかっちり（軸①）」の意味です。（逆に、形を先に決めずゆるく入れるのがNoSQL。第7章で対比します。）

⑤ トランザクション／ ACID ＝「ぜんぶ成功か、ぜんぶ取り消し」

最後がRDBの信頼性の心臓部、トランザクション（transaction＝ひとまとまりの処理）です。

たとえば銀行の振込。「Aさんから1万円引く」と「Bさんに1万円足す」は、両方そろって初めて正しい。もし途中で停電して「Aから引いたのにBに足されてない」が起きたら、1万円が宇宙に消えます。

トランザクションは、この一連の処理を“1個のかたまり”として扱い、「ぜんぶ成功」か「ぜんぶ無かったことにする（取り消し）」のどちらかしか許さない仕組み。途中半端で終わることを防ぎます。

  ┌─ トランザクション（ひとかたまり） ─┐
  │  Aから1万円ひく                  │
  │  Bに1万円たす                    │   ← 両方OK  → 確定（コミット）
  └────────────────────────────────┘   ← 片方失敗 → 全部取消（ロールバック）

この「全か無か」をはじめ、データを壊さないための4つの約束をまとめて ACID（エー・シー・アイ・ディー）と呼びます。

文字	約束	かんたんに言うと
A 原子性	全か無か	途中半端で終わらない（上の振込の話）
C 一貫性	ルールを守る	スキーマ等のルールを破る状態にしない
I 独立性	混ざらない	同時にたくさん来ても、互いに邪魔しない
D 永続性	消えない	「成功」と言ったら、停電しても残る

🟢 トランザクション＝「ぜんぶ成功か、ぜんぶ取り消し」。 お金・在庫・予約など「1円・1個もズレちゃダメ」なデータを、RDBが安心して任される理由がこれです。NoSQLはここが弱め（第7章）。正確さが命のデータは、まずRDB——この一文だけは覚えて帰ってください。

🛠 代表サービス（実名）

RDBには「いろんな種類（製品）」があります。中でも、いま新しく作るならまずこの2つを知っておけば十分です。

名前	読み	ひとこと
PostgreSQL	ポストグレス	高機能で何でもこなす優等生。いま最も人気の第一候補。本ガイドも基本これを推します
MySQL	マイエスキューエル	歴史が長く実績豊富。Web系で広く使われてきた定番

🔧 ほかにも SQL Server（マイクロソフト）・Oracle（オラクル）などがありますが、初心者がまず触るのは上の2つ。迷ったら PostgreSQL でOKです。

📄 「SQLite（エスキューライト）」も実はRDBの一種ですが、これは「サーバーを立てず、ファイル1個で動かす」という特別な存在なので、次の章（03-sqlite.md）でじっくり扱います。本ページは「RDBという考え方そのもの」に集中します。

なお、ここで挙げた製品を「どこで・どうやって動かすか」（自分のサーバーに立てる？クラウドに任せる？）は、まさに運用のはしご（軸②）の話。それを姉妹編とつないで一段ずつ見ていくのが、続く第3〜6章です。（運用のはしごの全体像は ../compute_options/README.md と地続きです。）

👍 向いている / 👎 向かない

👍 向いている（RDBの出番）	👎 向かない（別の置き場所が向く）
データに関係がある（会員と注文、商品と在庫…ほとんどのアプリ）	中身の形がバラバラで、表にきれいに収まらない
正確さ・整合性が命（お金・在庫・予約・ポイント）	スキーマ（設計図）を先に決めるとかえって窮屈
複雑な検索・突き合わせをしたい（条件で絞る、表をまたぐ集計）	単純な読み書きを、超大量・超高速でさばきたい
「とりあえず手堅く始めたい」多くのアプリの第一候補	1台に収まらない桁違いの規模を最初から前提にする

🟢 ざっくり：「関係があって、正確さが要って、いろんな条件で検索したい」なら、ほぼRDBで正解。 逆に「形がそろわない」「単純だけど超大量」のときだけ、NoSQL（第7・8章）を検討します。世の中のアプリの多くは、まず前者です。

🔧 運用・メンテ（ひとことだけ）

RDBは便利ですが、ただ置けば勝手に動き続けるわけではありません。バックアップ（控えを取る）／パッチ（修正の当て直し）／壊れたときの切り替えといった世話が要ります。

ここで効いてくるのが軸②（運用のはしご）。この世話を自分で全部やるのか、クラウドに任せるのかで、手触りがまるで変わります。自前なら自分の責任、マネージドなら自動でも「復元できるか」は要確認——詳しくは第4〜6章で。

🔧 いまの結論：世話の重さは「どこで動かすか」で決まる。 RDBという中身は同じでも、はしごのどの段で動かすかで、ラクさが大きく変わります。

🏢 誰が使う？（ペルソナひとこと）

ペルソナ	RDBとの基本線
個人 / スタートアップ	まずマネージドPostgres（Supabase / Neon / RDS）。「とりあえずRDBで素直に」が王道
中堅ベンチャー	RDS / Aurora を主軸に、用途によってNoSQLやキャッシュを足していく
大企業	Aurora や自前RDBを核に、監査・コンプラ・データ所在地まで作り込む

🟢 立場が変わっても、「中心にRDBを置く」のは共通。違うのは“どこで動かすか”と“何を足すか”だけです。

🌱 なぜ「まずRDB」なのか

この章でいちばん持ち帰ってほしい結論です。データの置き場所に迷ったら、特別な理由がない限り、まずRDB（できればPostgreSQL系）。理由は3つ。

普遍（どこでも通じる） … 何十年も使われ、表とSQLという考え方は業界の共通語。情報も人材も道具もそろっていて、ハマっても抜け出しやすい。
移行しやすい … SQLはほぼ共通なので、SQLite → マネージド → 大規模と、必要になってから段階的に引っ越せる（まさに軸②のはしご）。最初に正解を引き当てなくても大丈夫。
情報が多い … 困ったときに調べれば先人の答えがほぼ必ず見つかる。初心者にとって、これは何より心強い。

そして実は、姉妹教材の Twitterクローン／ChatGPTクローンも、データの土台は Supabase（中身は PostgreSQL）＝RDBです。「誰がどのツイートを投稿したか」「誰の会話履歴か」——まさに本章で見た関係（リレーション）と持ち主（user_id）そのもの。そこで効く RLS（行レベルのアクセス制御＝データを持ち主ごとに分ける仕組み） も、RDBの上で動きます。学びがそのまま実物につながるわけです。

🟢 「とりあえず PostgreSQL（系のマネージド）で素直に」。これが本ガイド全体の“迷ったときの初期設定”。NoSQLは、後の章で見る特定の理由があるときに選びます。

📝 ことばメモ

RDB（リレーショナルDB）：データを表で持ち、表どうしを「関係」で結ぶデータベース。データの置き場所の第一候補。
テーブル（表）／行（レコード）／列（カラム）：表＝データのしまい場所。行＝1件ぶん（ヨコ）。列＝項目の種類（タテ）。
関係（リレーション）／外部キー：表どうしを「番号」でつなぐこと／そのためによその表を指す番号。
SQL（エスキューエル）：RDBにお願いするための共通言語。製品が違ってもだいたい同じ。
スキーマ：表の設計図。どの列にどんな型を入れるか、先に決めたルール。
トランザクション：ひとまとまりの処理を「ぜんぶ成功か、ぜんぶ取り消し」にする仕組み。
ACID（エー・シー・アイ・ディー）：データを壊さないための4つの約束（原子性・一貫性・独立性・永続性）。

🟢 ひとことで言うと

RDBは「ルールが厳しいエクセルを、何枚も、番号でつないで持つ」データの置き場所。表（行と列）×関係（リレーション）×SQL×スキーマ×トランザクション（ぜんぶ成功か取り消し＝ACID）で、正確で・検索が強く・信頼できるのが持ち味。代表は PostgreSQL / MySQL。普遍で・移行しやすく・情報も多いので、迷ったらまずRDB（PostgreSQL系）——姉妹教材の Twitter/ChatGPTクローンも Supabase（Postgres）です。

➡️ 次へ

次のページ：SQLite — サーバー不要、ファイル1個のDB（＋Turso / Cloudflare D1） → ← 目次・はじめにへもどる