データベース基礎

データベースとは何か

データベースとは、データを効率的に保存・管理・検索するための仕組みのこと。

身近な例で考えてみよう。図書館を想像してほしい。

図書館 = データベース

+---------------------------------------------------+
|                   図書館（データベース）              |
|                                                     |
|  書棚（テーブル）                                    |
|  +-----------------------------------------------+ |
|  | 小説棚   | 技術書棚  | 雑誌棚   | 漫画棚     | |
|  | (novels) | (tech)   | (mags)   | (comics)   | |
|  +-----------------------------------------------+ |
|                                                     |
|  カード目録（インデックス）                          |
|  +-----------------------------------------------+ |
|  | タイトル順 | 著者順  | 出版年順 | ジャンル順  | |
|  +-----------------------------------------------+ |
|                                                     |
|  図書カード（レコード/行）                           |
|  +-----------------------------------------------+ |
|  | ID: 001                                        | |
|  | タイトル: データベース入門                       | |
|  | 著者: 山田太郎                                  | |
|  | ISBN: 978-4-xxxx-xxxx-x                        | |
|  | 棚番号: B-3-12                                  | |
|  +-----------------------------------------------+ |
+---------------------------------------------------+

この対応関係を整理すると以下のようになる。

カード目録がなければ、本を探すたびに全ての書棚を端から順に見ていく必要がある。データベースのインデックスも同じで、検索を高速にするための仕組みだ。

なぜデータベースが必要か

「ファイル（CSVやJSON）にデータを保存すればいいのでは？」と思うかもしれない。小規模なデータならそれでも問題ないが、アプリケーションが成長すると以下の問題が発生する。

ファイル管理 vs データベースの比較

具体例: ユーザーデータの管理

CSVファイルでユーザーデータを管理する場合を考えてみよう。

users.csv:
id,name,email
1,田中太郎,taro@example.com
2,佐藤花子,hanako@example.com

orders.csv:
id,user_id,item,price
1,1,本,1500
2,1,ペン,200

この方式だと以下の問題が起きる。

• プログラムAがusers.csvを読み込んでいる最中に、プログラムBが書き込むとデータが壊れる
• user_id=999の注文データを入れてもエラーにならない（存在しないユーザー）
• 「田中太郎が買った商品の合計金額」を求めるには、2つのファイルを読み込んで自力で紐付ける必要がある
• users.csvが100万行になると検索が非常に遅い

データベースなら、これらの問題を全て解決できる。

ACID特性

ACID特性とは、データベースのトランザクション（一連の操作のまとまり）が満たすべき4つの性質のこと。信頼性のあるデータベースの基盤となる概念だ。

銀行振込の例で理解する

太郎の口座から花子の口座に1万円を送金する処理で考えてみよう。

操作1: 太郎の残高を1万円減らす（10万円 → 9万円）
操作2: 花子の残高を1万円増やす（5万円 → 6万円）

各特性の詳細

ACIDの図解

トランザクション（振込処理）
+------------------------------------------------------------------+
|                                                                    |
|  BEGIN                                                             |
|    |                                                               |
|    v                                                               |
|  操作1: 太郎の残高 -10,000円                                       |
|    |                                                               |
|    v                                                               |
|  操作2: 花子の残高 +10,000円                                       |
|    |                                                               |
|    +--- 成功 ---> COMMIT  ---> 変更が確定（永続性）                |
|    |                                                               |
|    +--- 失敗 ---> ROLLBACK ---> 全ての変更を取り消し（原子性）     |
|                                                                    |
+------------------------------------------------------------------+

独立性: 他のトランザクションからは、この処理の途中経過が見えない
一貫性: 処理前後で合計金額は変わらない

データベースの種類一覧と比較

データベースにはさまざまな種類があり、用途に応じて使い分ける。

リレーショナルデータベース（RDB）

データを**テーブル（表）として管理し、テーブル同士をリレーション（関連）**で結びつける。最も広く使われているタイプ。

ドキュメントデータベース

データをJSON形式のドキュメントとして保存する。スキーマが柔軟で、アジャイル開発に向いている。

RDBのデータ構造:
users テーブル
+----+--------+------------------+
| id | name   | email            |
+----+--------+------------------+
| 1  | 太郎   | taro@example.com |
+----+--------+------------------+

ドキュメントDBのデータ構造:
{
  "_id": "user001",
  "name": "太郎",
  "email": "taro@example.com",
  "address": {
    "city": "東京",
    "zip": "100-0001"
  },
  "hobbies": ["読書", "プログラミング"]
}

キーバリュー型データベース

**キー（名前）とバリュー（値）**のペアでデータを保存する。極めて高速で、キャッシュやセッション管理に使われる。

キーバリューのイメージ:
+------------------------+-------------------+
| キー                   | バリュー          |
+------------------------+-------------------+
| "user:1:name"          | "太郎"            |
| "session:abc123"       | "{...セッション}" |
| "cache:top_products"   | "[{...}, {...}]"  |
+------------------------+-------------------+

グラフデータベース

データを**ノード（点）とエッジ（辺）**で表現する。関係性の分析に特化。

グラフDBのイメージ:
    (太郎) ---[友人]--> (花子)
       |                  |
    [購入]             [購入]
       |                  |
       v                  v
    (商品A)            (商品B)
       |
    [類似]
       |
       v
    (商品C)

→「太郎の友人が買った商品」「商品Aに似ている商品」を高速に検索できる

時系列データベース

時間順に並んだデータの保存と分析に特化。IoTセンサーデータやメトリクス収集に最適。

全文検索エンジン

テキストの全文検索に特化したデータベース。形態素解析やあいまい検索が可能。

CAP定理

分散データベースを設計する際の重要な理論。3つの性質のうち、同時に2つまでしか満たせないという定理。

3つの性質

CAP定理の図解

                  一貫性 (C)
                    /\
                   /  \
                  /    \
                 / CA   \
                /  領域  \
               /----------\
              /            \
             / CP    AP     \
            /   領域   領域  \
           /                  \
          +--------------------+
    可用性 (A)           分断耐性 (P)

CA: PostgreSQL, MySQL（単一ノード）
   → ネットワーク分断が起きないことを前提とする
CP: MongoDB, Redis Cluster, HBase
   → 一貫性を優先し、分断時はリクエストを拒否する可能性がある
AP: DynamoDB, Cassandra, CouchDB
   → 可用性を優先し、一時的にデータが古い可能性がある

実務での考え方

インターネットを介した分散システムでは、ネットワーク分断は必ず起こる。そのため、実質的にはCPかAPのどちらかを選ぶことになる。

RDB vs NoSQL

使い分けフローチャート

データの構造は決まっているか?
├── はい → データ間に複雑な関連があるか?
│           ├── はい → RDB（PostgreSQL, MySQL）
│           └── いいえ → データ量は非常に大きいか?
│                        ├── はい → NoSQL（DynamoDB, Cassandra）
│                        └── いいえ → RDB（シンプルで十分）
│
└── いいえ → どんな検索が必要か?
             ├── キーで1件取得 → キーバリュー（Redis, DynamoDB）
             ├── 全文検索 → Elasticsearch
             ├── 関係性の探索 → グラフDB（Neo4j）
             ├── 時系列の集計 → 時系列DB（InfluxDB）
             └── 柔軟な構造 → ドキュメントDB（MongoDB, Firestore）

比較表

スキーマとスキーマレスの違い

スキーマあり（RDB）

スキーマとは、データの構造を事前に定義したもの。テーブルのカラム名、データ型、制約などを決めてからデータを投入する。

-- スキーマの定義（テーブル構造を先に決める）
CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    age INTEGER CHECK (age >= 0)
);

-- スキーマに合わないデータは拒否される
INSERT INTO users (id, name, email, age) VALUES (1, '太郎', 'taro@example.com', 25);  -- 成功
INSERT INTO users (id, name, email, age) VALUES (2, NULL, 'test@example.com', 25);     -- 失敗（nameがNULL）
INSERT INTO users (id, name, email, age) VALUES (3, '花子', 'taro@example.com', 28);   -- 失敗（emailが重複）

メリット: データの品質が保証される。型の不一致や必須項目の欠落を防げる。 デメリット: スキーマの変更（ALTER TABLE）が必要で、大規模テーブルでは時間がかかる場合がある。

スキーマレス（NoSQL）

データの構造を事前に定義しない。各ドキュメントが異なる構造を持てる。

// ドキュメント1
{
  "name": "太郎",
  "email": "taro@example.com",
  "age": 25
}

// ドキュメント2（フィールドが異なる）
{
  "name": "花子",
  "email": "hanako@example.com",
  "phone": "090-xxxx-xxxx",
  "address": {
    "city": "大阪",
    "zip": "530-0001"
  }
}

メリット: 柔軟にデータ構造を変更できる。開発初期の試行錯誤がしやすい。 デメリット: データの品質はアプリケーション側で保証する必要がある。

どちらを選ぶか

正規化 vs 非正規化

正規化とは

正規化とは、データの重複を排除してテーブルを効率的に設計する手法。データの一貫性を保ちやすくなる。

正規化前（非正規形）:
+--------+--------+----------+--------+------+------+
| 注文ID | 顧客名 | 顧客住所 | 商品名 | 単価 | 数量 |
+--------+--------+----------+--------+------+------+
| 1      | 太郎   | 東京都   | 本A    | 1500 | 2    |
| 1      | 太郎   | 東京都   | ペンB  | 200  | 3    |
| 2      | 花子   | 大阪府   | 本A    | 1500 | 1    |
+--------+--------+----------+--------+------+------+

問題: 「太郎」「東京都」が重複。太郎が引っ越したら全行を更新する必要がある。

正規化後:
顧客テーブル           商品テーブル           注文テーブル
+----+------+------+   +----+------+------+   +----+------+
| id | 名前 | 住所 |   | id | 名前 | 単価 |   | id | 顧客 |
+----+------+------+   +----+------+------+   +----+------+
| 1  | 太郎 | 東京 |   | 1  | 本A  | 1500 |   | 1  | 1    |
| 2  | 花子 | 大阪 |   | 2  | ペンB| 200  |   | 2  | 2    |
+----+------+------+   +----+------+------+   +----+------+

注文明細テーブル
+------+------+------+
| 注文 | 商品 | 数量 |
+------+------+------+
| 1    | 1    | 2    |
| 1    | 2    | 3    |
| 2    | 1    | 1    |
+------+------+------+

非正規化とは

意図的にデータの重複を許容して、読み取り性能を向上させる手法。

非正規化の例（注文履歴テーブル）:
+--------+--------+--------+------+------+
| 注文ID | 顧客名 | 商品名 | 単価 | 数量 |
+--------+--------+--------+------+------+
| 1      | 太郎   | 本A    | 1500 | 2    |
| 1      | 太郎   | ペンB  | 200  | 3    |
+--------+--------+--------+------+------+

→ JOINなしで注文内容を一発で取得できる（読み取りが速い）
→ ただし「太郎」が重複しているので、更新が面倒

いつどちらを選ぶか

実務での基本方針: まず正規化で設計し、パフォーマンスが問題になった箇所だけ非正規化を検討する。

トランザクション分離レベル

複数のトランザクションが同時に実行されるとき、他のトランザクションの変更がどこまで見えるかを決める設定。

発生しうる問題

分離レベルの比較表

各レベルの解説

READ UNCOMMITTED（未コミット読み取り）

他のトランザクションがCOMMITしていないデータも読める。最も緩い分離レベル。

トランザクションA                トランザクションB
BEGIN;
UPDATE users SET age=30          BEGIN;
  WHERE id=1;
                                 SELECT age FROM users WHERE id=1;
                                 → 30が見える（まだCOMMITしていない！）
ROLLBACK;
                                 → 30を使って処理を進めてしまう
                                    （実際にはROLLBACKされて元の値に戻った）

READ COMMITTED（コミット済み読み取り）

PostgreSQLのデフォルト。COMMITされたデータのみ読める。

トランザクションA                トランザクションB
BEGIN;                           BEGIN;
UPDATE users SET age=30          SELECT age FROM users WHERE id=1;
  WHERE id=1;                    → 25（COMMIT前なので古い値）
COMMIT;
                                 SELECT age FROM users WHERE id=1;
                                 → 30（COMMITされたので新しい値）
                                 ※同じクエリなのに結果が変わる！

REPEATABLE READ（反復読み取り）

トランザクション開始時のスナップショットを使う。同じクエリは常に同じ結果を返す。

トランザクションA                トランザクションB
                                 BEGIN;
                                 SELECT age FROM users WHERE id=1;
                                 → 25
BEGIN;
UPDATE users SET age=30
  WHERE id=1;
COMMIT;
                                 SELECT age FROM users WHERE id=1;
                                 → 25（スナップショットなので変わらない）
                                 COMMIT;

SERIALIZABLE（直列化可能）

最も厳格。トランザクションを1つずつ順番に実行したのと同じ結果を保証する。

実務での選び方

インデックスの基本

インデックスとは

インデックスとは、データベースの検索を高速化するための仕組み。本の巻末にある「索引」と同じ考え方だ。

本の索引の例:
+------------------+--------+
| キーワード       | ページ |
+------------------+--------+
| ACID             | 45     |
| インデックス     | 78     |
| カーソル         | 112    |
| トランザクション | 45, 93 |
+------------------+--------+

→ 「トランザクション」を調べたいとき
   索引なし: 1ページ目から順に読む（遅い）
   索引あり: 索引を見て45ページと93ページに直行（速い）

B-treeインデックス

最も一般的なインデックスの種類。ほとんどのRDBでデフォルトで使われる。

B-tree（バランスツリー）の構造:

                    [50]
                   /    \
              [20,35]    [70,85]
             /  |  \    /  |  \
          [10] [25] [40] [60] [75] [90]
           |    |    |    |    |    |
          行   行   行   行   行   行

検索例: id=60 を探す場合
1. ルート [50] → 60 > 50 なので右へ
2. [70,85] → 60 < 70 なので左の子へ
3. [60] → 見つかった！

→ 100万行あっても、20回程度の比較で見つかる（log2(1000000) ≒ 20）

なぜ検索が速くなるか

注意点: インデックスは検索を速くするが、データの挿入・更新・削除のたびにインデックスも更新する必要があるため、書き込みは遅くなる。

インデックスを作るべき場面

インデックスを作らない方がよい場面

データベース選定の判断基準

新しいプロジェクトでデータベースを選ぶ際のチェックリスト。

チェックリスト

よくある構成パターン

パターン1: 一般的なWebアプリケーション
+-----------------+     +--------+
| アプリケーション | --> | PostgreSQL |
+-----------------+     +--------+

パターン2: キャッシュ層あり
+-----------------+     +-------+     +------------+
| アプリケーション | --> | Redis | --> | PostgreSQL |
+-----------------+     +-------+     +------------+
                     (キャッシュ)      (メインDB)

パターン3: 検索機能あり
+-----------------+     +------------+     +---------------+
| アプリケーション | --> | PostgreSQL | --> | Elasticsearch |
+-----------------+     +------------+     +---------------+
                       (メインDB)        (全文検索)

パターン4: マイクロサービス
+-----------+     +-------+
| サービスA | --> | PostgreSQL |
+-----------+     +-------+
+-----------+     +---------+
| サービスB | --> | MongoDB |
+-----------+     +---------+
+-----------+     +-------+
| サービスC | --> | Redis |
+-----------+     +-------+

主要データベース比較表

以下は、現在よく使われている主要なデータベースの比較表。

選定の目安

まとめ

データベースの基礎知識を振り返ろう。

データベースの選定に「正解」はない。プロジェクトの要件、チームのスキル、将来の成長を考慮して、最適なものを選ぶことが重要だ。迷ったらPostgreSQLから始めるのがよい。RDBの機能が充実しており、JSONBでドキュメントDBのような使い方もでき、無料で利用できる。

参考リンク

• PostgreSQL公式ドキュメント
• MySQL公式ドキュメント
• MongoDB公式ドキュメント
• Redis公式ドキュメント
• DynamoDB公式ドキュメント
• Supabase公式ドキュメント
• Firebase公式ドキュメント
• DB-Engines Ranking（データベース人気ランキング）
• CAP定理の解説（Martin Kleppmann）
• Use The Index, Luke（インデックスの解説）