初級ではDBを「整理された台帳」と捉えました。中級では、リレーショナルの基本・速さ・正しさを見ます。
中級の解説は準備中のため、中級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
これは何をする係？
多くのWebサービスの中心にあるのはリレーショナルDB（RDB）。データを表（テーブル）に持ち、表どうしをキーで関連づけます。
- 主キー — 各行を一意に識別する項目（例：ユーザーID）
- 外部キー — 別の表の主キーを指して関連づける（例：注文の「ユーザーID」）
- 正規化 — 同じデータの重複を減らし、矛盾が起きにくい形に整理する
登場人物メモ:
- ※1 インデックス（B-tree） — 木構造で範囲・一致を素早く探す索引。書き込みは少し重くなる
- ※2 トランザクション（ACID） — 原子性・一貫性・独立性・永続性を満たす処理のまとまり
仕事の流れ
- バックから SQL を受ける（
SELECT／INSERTなど） - 実行計画を立て、インデックスが使えるかを判断する
- 使えれば索引で該当行へ、使えなければフルスキャン（遅い）
アニメーション『インデックスと全表走査』を開く
- 更新系はトランザクションでまとめ、確定（コミット）で永続化する
トランザクションの核が原子性（Atomicity）。「全部成功か、全部なかったことに」で、送金のように「引く」だけ成功して「足す」が失敗、という中途半端を防ぎます。
アニメーション『トランザクション（全部か、なしか）』を開く
速さと正しさ
- インデックス設計 — よく使う検索条件に合わせて張る。多すぎると書き込みが重い
- ロック／独立性 — 同時更新の衝突を防ぐが、待ち合わせがデッドロックを生むことも
- レプリケーション — 同じDBの複製を用意し、読み取りを分散／障害に備える
- シャーディング — データを複数に分割して1台の限界を超える（運用は複雑）
- NoSQLとの使い分け — 表に馴染まないデータ（大量ログ・柔軟な構造）には別種のDBも
⚠️ うまくいかないとき
- フルスキャンで遅い — インデックス不足／条件の書き方でインデックスが効かない
- デッドロック — 複数トランザクションが互いのロックを待って止まる
- N+1問題 — アプリ側が行ごとにクエリを乱発（JOINやまとめ取得で回避）
- 整合性の乱れ — キャッシュやレプリカとの時間差（stale）を考慮していない
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. トランザクションの「ACID」のうち、「途中で失敗したら全部なかったことにする（中途半端に残さない）」性質はどれ？
問2. インデックスが効かず、全行を順に調べてしまう状態を何と呼ぶ？
問3. 別の表の主キーを指して、2つの表を関連づける項目を何という？
問4. ACIDのうち「確定（コミット）した変更は障害が起きても失われない」という性質はどれ？
問5. 「デッドロック」とはどんな状態か？
問6. 「N+1問題」の説明として正しいのは？
問7. データの重複を減らし、更新時の矛盾が起きにくい形に表を整理することを何と呼ぶか。
問8. 1台のDBの容量・性能の限界を超えるため、データをキーで複数のサーバに分割して持たせる手法をカタカナで答えてください。