🔖 キーワード索引

「rdb」は統計データ分析の文脈で扱う重要概念のひとつ。 本ページでは「rdb」を取り巻く中核キーワードを以下にチップで一覧化する。 各キーワードは関連する概念・手法・道具立てを含み、 文献検索や学習計画の起点になる。

これらのキーワードは「rdb の理解 → 適用 → 検証」のプロセスを構成する。 各章で詳しく解説する。

🎨 直感で掴む

「Excelシートの複数枚＋関係」が直感的：

• 「顧客」シート、 「注文」シート、 「商品」シート、 とテーマ別に分ける
• シート間は「顧客ID」「商品ID」で関係付け
• 「ある顧客の月別売上」を出すには3表を JOIN

🎨 リレーショナルデータベースの可視化・実装パターン（拡張）

RDB を運用・分析する場面では、 単に SQL を書けるだけでなく 「テーブル間の関係を図で示す」「集計結果を統計図で示す」「クエリ性能を時系列で示す」 という三つの可視化が同時に求められます。 ここでは SSDSE-B-2026 を 47 都道府県 × 12 年 × 約 112 指標のリレーショナル構造として扱うことを前提に、 RDB の理論を補強する 3 種類の可視化と、 6 種類の実務テーブルを提示します。

📷 図1: 都道府県 × 指標の相関ヒートマップ（RDB から JOIN+集計で生成）

図1 は、 SSDSE-B-2026 の家計支出系の列（消費支出 L3221、 食料費 L322101 など）を都道府県マスタと Code で結合し、 相関係数を corr() で求めた結果である。 食料費 × 教育費（r = 0.728）、 消費支出 × 食料費（r = 0.679）が有意な正の相関を示す一方、 住居費はどの変数とも有意な相関を持たない。 RDB を採用すると、 同じデータを「人口分析」「家計分析」など複数の文脈で再利用できる利点が、 このような任意の列の組み合わせ集計から読み取れる。

📷 図2: SQL 集計 1 文で得られる時系列（全国死亡率）

図2 は、 SSDSE-B-2026 を格納した DB に対し、 SELECT 年度, SUM(死亡数)*1000.0/SUM(総人口) FROM ssdse_b GROUP BY 年度 という集計クエリ 1 文で得られる時系列である（実測値：2012 年度 9.84 → 2023 年度 12.67）。 移動平均のような窓計算もウィンドウ関数 AVG(...) OVER (ORDER BY 年度 ROWS 2 PRECEDING) で SQL 側に寄せられる。 RDB の理論を学んだ後は、 こうした実データでの集計まで踏み込むと理解が深まる。

📷 図3: 主成分分析によるテーブル列の構造把握

図3 のように、 RDB の列をすべて主成分分析にかけると、 「どの列とどの列が冗長か」「正規化を進めるべき境界はどこか」 を統計的に判断できる。 列の数が増えるほどテーブル設計は難しくなるが、 統計手法と組み合わせれば客観的な根拠を持って設計判断ができるようになる。

📋 表1: RDB の正規化レベルと SSDSE-B-2026 への適用

📋 表2: 主要 RDBMS の特徴比較（SSDSE-B-2026 配置に向けて）

📋 表3: SSDSE-B-2026 を JOIN するときの注意点

🐍 追加 Python 実装: SSDSE-B-2026 を SQLite に格納し JOIN 集計

① 目的：SSDSE-B-2026（2023 年度）を SQLite に取り込み、 別に用意した「地方ブロック対応表」と JOIN して、 ブロック別の総人口（A1101）合計を SQL 一文で求める。 pandas の merge + groupby に相当する処理を、 RDB では宣言的な 1 クエリで書ける点を体感する。

② 橋渡し：読み込みは cp932・skiprows=[1]（先頭行の Code 名を列名に採用）とし、 先頭列 SSDSE-B-2026（＝年度）が 2023 の 47 行だけを残す。 その観測テーブル ssdse_b と、 都道府県→ブロックの対応表 region を Prefecture をキーに INNER JOIN する。

📥 入力データ (SSDSE-B-2026 抜粋):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

import sqlite3
import pandas as pd

# SSDSE-B-2026 を読み込み（先頭列名は Code 行 = A1101 等を採用）
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
df = df[df['SSDSE-B-2026'] == 2023]          # 2023 年度だけ抽出（47 行）

# SQLite に格納
conn = sqlite3.connect(':memory:')
df.to_sql('ssdse_b', conn, index=False)

# 地方ブロックの対応表（別テーブル）
region = pd.DataFrame({
    'Prefecture': ['東京都', '神奈川県', '埼玉県', '大阪府', '愛知県'],
    'block':      ['関東', '関東', '関東', '近畿', '中部'],
})
region.to_sql('region', conn, index=False)

# JOIN 集計：ブロック別の総人口(A1101)合計
query = """
SELECT r.block, SUM(s.A1101) AS pop_sum
FROM ssdse_b s JOIN region r ON s.Prefecture = r.Prefecture
GROUP BY r.block
ORDER BY pop_sum DESC
"""
print(pd.read_sql_query(query, conn))
conn.close()

📤 実行すると次の出力が得られる:

④ 実行結果の読み取り：INNER JOIN により対応表 region に載せた 5 県だけが集計対象となり、 関東 3 県（東京・神奈川・埼玉）の合計 30,646,000 人が近畿・中部を大きく上回る。 対応表に無い県は自動的に除外されるため、 全 47 県を集計したい場合はマスタを 47 行に完備するか LEFT JOIN に切り替える。 RDB では「どの表を主に、 どのキーで結合するか」を宣言するだけで、 結合と集計が一度に片付く点が pandas との違いである。

以上のように、 RDB は単なる「データの入れ物」ではなく、 「分析の土台」として機能する。 SSDSE-B-2026 を RDB に格納し、 SQL と Python（pandas）を組み合わせるだけで、 47 都道府県の経済・社会構造を多角的に分析できる。 本ページの理論と組み合わせて、 ぜひ実データで手を動かしてみてほしい。

🎯 理解度チェック（RDB 編）

以下の問いは、 RDB の基礎—正規化、 主キーと外部キー、 SQL 結合、 トランザクション、 そして SSDSE-B-2026 のような実データを格納したときの使い方—を一度に確かめるためのものである。 各設問は前のセクションで触れた概念に直接対応している。

Q1. 主キーの目的を 1 行で説明せよ。

Q2. 外部キーが指す先の値が存在しないとき、 INSERT は成功するか。

Q3. 第1正規形 (1NF)、 第2正規形 (2NF)、 第3正規形 (3NF) を 1 行ずつでまとめよ。

Q4. 内部結合 (INNER JOIN) と左外部結合 (LEFT JOIN) の違いを SSDSE-B-2026 で説明せよ。

Q5. ACID 特性のうち「Atomicity（原子性）」が崩れる具体例を挙げよ。

💬 補足：5 問のうち 4 問以上即答できれば実務最低限の RDB リテラシーは備わっている。 不安な問題は 主キー、 外部キー、 SQL、 データベースのページに戻って確認するとよい。

📝 補足: RDB を選ぶか NoSQL を選ぶかは「データの構造性」「クエリの複雑さ」「整合性要件」の 3 軸で判断する。 SSDSE-B-2026 のような構造化された統計データは、 RDB が圧倒的に有利。 一方、 ログデータ・センサーデータ・ソーシャルメディアデータのような半構造化・非構造化データは NoSQL が向く。 ハイブリッド構成（RDB + NoSQL）も一般的で、 トランザクションは RDB、 ログは NoSQL、 検索は Elasticsearch、 分析は DuckDB、 のように使い分ける。 用途に応じた選択眼を養うことが、 データエンジニアリングの中核スキルである。

📎 関連リソース

• データベース — RDB を含む上位概念
• NoSQL — RDB と対をなすデータストア
• DataFrame — Python 側で SQL 結果を扱う型
• データ結合 — JOIN を pandas で行う方法
• 構造化データ — RDB が扱う代表的なデータ形式

📖 SSDSE-B-2026 を RDB で扱うときの実務メモ

SSDSE-B-2026 は 47 都道府県 × 12 年（2012〜2023 年度）× 約 110 指標（564 行 × 112 列）で構成される。 これを RDB に格納する典型設計は次の通り。 まず 都道府県マスタ prefectures(pref_code PK, pref_name, region) を作る。 47 行の小テーブルだが、 すべての分析テーブルの外部キー先になる。 次に 指標マスタ indicators(indicator_code PK, indicator_name, category, unit) を作る。 ここに A1101（総人口）、 A1303（65 歳以上人口）、 A4101（出生数）などの定義を入れる。 最後に 事実テーブル facts(pref_code FK, year, indicator_code FK, value, PRIMARY KEY(pref_code, year, indicator_code)) を作る。 この 3 テーブル構成は、 1NF・2NF・3NF を満たし、 かつ追加指標の挿入が破壊的変更を伴わない。

この設計の利点は次の 4 点である。 第一に、 新指標の追加が ALTER TABLE 不要になる。 ワイド形式 (564 行 × 112 列) では新指標を追加するたびにカラム追加が必要だが、 ロング形式（事実テーブル）では INSERT だけで済む。 第二に、 欠損が自然に表現できる。 ある年・ある県・ある指標が観測されなかった場合、 行が存在しないだけ。 NULL カラムが氾濫しない。 第三に、 SQL の集計が直感的になる。 「2020 年代の各県の人口成長率」は WHERE indicator_code='A1101' GROUP BY pref_code で出る。 第四に、 外部キー制約で参照整合性が保証される。 誤った県コードを INSERT すると即座にエラーになり、 データ品質が自動で守られる。

一方で、 ロング形式のままだと分析時に毎回ピボット（PIVOT/CROSSTAB）が必要になり、 SQL 初学者にとっては敷居が高い。 そこで実務では マテリアライズドビューとして、 よく使うワイド形式（年×指標）を事前計算する。 例えば CREATE MATERIALIZED VIEW pref_panel AS SELECT pref_code, year, MAX(CASE WHEN indicator_code='A1101' THEN value END) AS pop, MAX(CASE WHEN indicator_code='A1303' THEN value END) AS aged ... のような形で、 ロングをワイドに事前変換する。 これにより「分析時はワイド、 格納時はロング」という二刀流を成立させられる。 PostgreSQL なら crosstab 関数、 SQLite なら GROUP BY ... CASE WHEN パターンが定番。

インデックス設計も重要である。 SSDSE-B-2026 規模（47×12×約 110 ≒ 約 6 万行のロング形式）なら全表スキャンでも秒以下で完了するが、 30 年分・1700 市区町村に拡張する SSDSE-A（市区町村版）になると行数が 200 万を超え、 インデックス無しでは性能が落ちる。 典型的には (pref_code, year) の複合インデックス、 (indicator_code) の単一インデックス、 そして「最新年の値だけ取り出す」用途には 部分インデックス（WHERE year = (SELECT MAX(year) FROM facts)）を併用する。 PostgreSQL の EXPLAIN ANALYZE でクエリプランを確認しながらインデックス戦略を組むのが実務の流儀である。

最後に、 RDB と pandas を組み合わせるときのアンチパターンを 3 つ紹介する。 第一に、 SELECT * FROM huge_table をして pandas にロードし、 そこから WHERE 句相当のフィルタリングをするパターン。 これはネットワーク帯域と RAM を浪費する。 SQL 側で WHERE をかけるのが鉄則。 第二に、 for ループで 47 回 SELECT を回すパターン。 1 回の集計クエリで終わるものを N+1 問題化させてしまう。 GROUP BY で一発取得する。 第三に、 外部キー無視で INSERT。 外部キー制約を一時的に切って大量 INSERT する手法もあるが、 切り戻しを忘れると参照整合性が壊れる。 一括ロード時は BEGIN; SET CONSTRAINTS ALL DEFERRED; ... COMMIT; でトランザクション内に閉じ込めるのが安全。 これらを踏まえれば、 RDB は「データの入れ物」から「分析の土台」へと一段格上げされる。

📜 RDB の歴史的背景と現代的位置づけ

RDB の理論的基礎は 1970 年に IBM 研究所のエドガー・F・コッドが発表した論文「A Relational Model of Data for Large Shared Data Banks」に始まる。 それ以前のデータベースは階層型（IMS）やネットワーク型（CODASYL）が主流で、 物理的なポインタ参照に依存していた。 コッドは「データを関係（リレーション）= 数学的な集合として扱う」という抽象を導入し、 物理構造とアプリケーションを分離した。 これにより、 同じデータを複数の視点から照会できるようになり、 SQL という宣言的問い合わせ言語が成立した。

1980 年代に Oracle・DB2・SQL Server などの商用 RDB が登場し、 90 年代に PostgreSQL・MySQL・SQLite といったオープンソース実装が広まった。 2000 年代に Web の大規模化で「スキーマレス」「水平分散」が求められると、 MongoDB・Cassandra などの NoSQL が台頭し、 一時は「RDB の時代は終わる」とまで言われた。 しかし 2010 年代後半から、 NoSQL が直面した「結果整合性の運用負荷」「複雑クエリの困難さ」が露呈し、 NewSQL（CockroachDB・Google Spanner）として RDB の利点が再評価された。 2020 年代の現在、 「分析用途は列指向 RDB（DuckDB・ClickHouse）、 トランザクション用途は古典的 RDB（PostgreSQL）」という棲み分けが定着している。

SSDSE-B-2026 のような統計データセットの保管・分析には、 軽量な SQLite または DuckDB が最適である。 SQLite はファイル 1 つで完結し、 学習用に最適。 DuckDB は SQLite と同じく組み込み型だが、 列指向で集計が高速。 「47 都道府県 × 12 年 × 約 110 指標を pandas に直接読み込む」のと「DuckDB に格納して SQL でクエリ」を比べると、 後者は SELECT/JOIN/GROUP BY が直感的で、 さらに pandas の DataFrame に duckdb.sql('...').df() でシームレスに変換できる。 教育現場でも「最初は CSV→pandas、 次に SQLite→pandas、 最後に DuckDB→pandas」と段階を踏むのが推奨。 RDB の概念は SQL を一度学べば NoSQL・グラフ DB の理解にも転用できるため、 データサイエンスの基礎として習得する価値が高い。

🧰 SSDSE-B-2026 を SQLite で扱う具体例

SQLite を使った最小ワークフローは次の通り。 (1) sqlite3 ssdse.db で空のデータベースを作る。 (2) CREATE TABLE ssdse_b (year INTEGER, pref_code TEXT, pref_name TEXT, A1101 REAL, A4101 REAL, ...); でテーブル定義。 (3) .mode csv と .import data/raw/SSDSE-B-2026.csv ssdse_b で CSV を一括取り込み。 (4) CREATE INDEX idx_year_pref ON ssdse_b(year, pref_code); で複合インデックスを張る。 (5) クエリ実行。 例えば「2023 年の人口上位 5 都道府県」は SELECT pref_name, A1101 FROM ssdse_b WHERE year=2023 ORDER BY A1101 DESC LIMIT 5; で 1 ミリ秒以下で結果が返る。 Python からは import sqlite3; con = sqlite3.connect('ssdse.db'); df = pd.read_sql_query('...', con) でそのまま DataFrame 化できる。

複雑な分析の例として「高齢化率（65 歳以上人口÷総人口）を地方ブロック別に平均し、 全国平均との偏差をランキング」したい場合、 SQL は次のように書ける: WITH per_capita AS (SELECT pref_code, A1303*1.0/A1101 AS aging FROM ssdse_b WHERE year=2023), regional AS (SELECT region, AVG(aging) AS rgn_avg FROM per_capita JOIN prefectures USING(pref_code) GROUP BY region), national AS (SELECT AVG(aging) AS nat_avg FROM per_capita) SELECT region, rgn_avg, rgn_avg - (SELECT nat_avg FROM national) AS deviation FROM regional ORDER BY deviation DESC;。 これを pandas で書くと 5-6 ステップの method chain になるが、 SQL なら 1 つの宣言的クエリで完結する。 特に複雑な集計では SQL の優位性が際立つ。

RDB はトランザクション処理（OLTP）とオンライン分析処理（OLAP）の両方を担えるが、 アーキテクチャは異なる。 OLTP は短時間の書き込みを高頻度で処理するため行指向（PostgreSQL）が向く。 OLAP は大量データの集計クエリを処理するため列指向（DuckDB、 ClickHouse、 BigQuery）が向く。 SSDSE-B-2026 のような分析用途では OLAP に倒した DuckDB を選ぶ価値が高く、 同じ SQL クエリでも pandas 経由より 3-10 倍高速になる。 RDB を学んだ知識は、 NoSQL、 グラフ DB、 ベクトル DB（RAG 用途）に進む際の出発点になるため、 一度しっかり腰を据えて学習する価値がある。 SSDSE-B-2026 を題材に SQL を学べば、 統計学・データ分析・データベース工学の三領域を同時に習得できる。

本ページで扱った正規化・主キー・外部キー・ACID 特性・JOIN・インデックス・マテリアライズドビューといった概念は、 半世紀近く前にコッドが示した枠組みが現代でも有効であることを物語る。 SQL を 1 度習得すれば、 PostgreSQL であろうと DuckDB であろうと BigQuery であろうと、 ほぼ同じクエリで動く。 これがリレーショナルモデルの普遍性であり、 データサイエンスの基盤として RDB を学ぶ価値である。 ぜひ手元の SQLite または DuckDB に SSDSE-B-2026 を取り込み、 実際にクエリを書きながら習熟してほしい。 慣れれば pandas より高速で、 表現力も高く、 何より「データの構造を考える」習慣が身に付く。 RDB はデータ工学・分析・統計の交差点に位置する核となる技術である。

📐 定義／数式

関係 (relation) の数学的定義: 関係 $R$ は属性集合 $A_1, A_2, \dots, A_n$ の直積の部分集合である。

$$ R \subseteq \mathrm{dom}(A_1) \times \mathrm{dom}(A_2) \times \dots \times \mathrm{dom}(A_n) $$

ここで $\mathrm{dom}(A_i)$ は属性 $A_i$ がとりうる値の集合 (例: 都道府県名なら 47 要素の集合、 人口なら $\mathbb{N}$)。 各要素 $(a_1, \dots, a_n) \in R$ を タプル (= 行) と呼ぶ。 行の順序・重複は意味を持たず、 RDB の「表」は実装上の見え方にすぎない。

主キー制約: 部分集合 $K \subseteq \{A_1, \dots, A_n\}$ が主キーであるとは、 次が成り立つこと。

$$ \forall t_1, t_2 \in R,\ \big(\pi_K(t_1) = \pi_K(t_2)\big) \Rightarrow t_1 = t_2 $$

ここで $\pi_K(t)$ はタプル $t$ の主キー属性への射影。 つまり「主キーが同じなら同じ行」。 SSDSE-B-2026 では (年度, 都道府県コード)（コードは R01000〜R47000）の組が自然な主キー候補。

関係代数の基本演算 5 つ: SQL は全てこれらの組合せに分解できる。

• 射影 $\pi_{A_i, A_j}(R)$ — 列の選択 (SQL の SELECT 列名)
• 選択 $\sigma_{\phi}(R)$ — 条件 $\phi$ を満たす行抽出 (SQL の WHERE)
• 和集合 $R \cup S$、 差 $R - S$、 直積 $R \times S$ — 集合演算
• 自然結合 $R \bowtie S$ — 共通属性で結合 (SQL の JOIN ... ON)
• 名前変更 $\rho_{A \to B}(R)$ — 列名の変更 (SQL の AS)

正規形の条件: 第 3 正規形 (3NF) とは、 任意の非キー属性 $A$ について「$A$ は主キーに完全関数従属し、 かつ他の非キー属性を経由しない」状態。 形式的には、 関数従属 $X \to A$ が成り立つなら $X$ は超キーか $A$ は主属性。

🔬 数式を言葉で読み解く

🔬 数式を言葉で読み解く（詳細版）

🏭 産業界での活用事例（6 件）

⚖️ 関連手法との比較表

💥 失敗例から学ぶ

📝 演習問題（5 問・解答付き）

1. 問題：SSDSE-B-2026 を SQLite にロードし、 「2023 年の総人口上位 10 都道府県」を SQL で取得せよ。
   ▼ 解答を見る

   import sqlite3, pandas as pd
df = pd.read_csv("data/raw/SSDSE-B-2026.csv", encoding="cp932", skiprows=[1])
df = df.rename(columns={"SSDSE-B-2026":"年度", "Code":"地域コード", "Prefecture":"都道府県", "A1101":"総人口"})
conn = sqlite3.connect(":memory:")
df.to_sql("ssdse_b", conn, index=False)
pd.read_sql("SELECT 都道府県, 総人口 FROM ssdse_b WHERE 年度=2023 ORDER BY 総人口 DESC LIMIT 10", conn)。 結果は東京・神奈川・大阪・愛知・埼玉・千葉・兵庫・福岡・北海道・静岡（実データで確認済み）。
2. 問題：SSDSE-B-2026 の主キーは何にすべきか？
   ▼ 解答を見る

   (年度, 地域コード) の複合主キー。 年度単独や地域単独では一意でない（47 県 × 12 年 = 564 行を識別するため両方必要）。
3. 問題：「2023 年度と 2012 年度の総人口の差」を都道府県別に SQL で計算せよ（自己結合の練習）。
   ▼ 解答を見る

   SELECT a.都道府県, a.総人口 - b.総人口 AS 増減 FROM ssdse_b a JOIN ssdse_b b ON a.地域コード=b.地域コード WHERE a.年度=2023 AND b.年度=2012 ORDER BY 増減 DESC;。 増加 1 位は東京都（+852,000 人）、 減少 1 位は北海道（−373,000 人）。
4. 問題：正規化を進めると、 SSDSE-B はどう分割できるか？
   ▼ 解答を見る

   都道府県マスタ（地域コード, 都道府県名）と 統計事実テーブル（年度, 地域コード, 各指標）に分割すると 3NF。 さらに指標カタログ（指標ID, 名称, 単位, 出典）を作ると 4NF。
5. 問題：インデックスを (年度) に張ると、 「2023 年フィルタ」のクエリはどう変わるか？
   ▼ 解答を見る

   B-tree インデックスを CREATE INDEX idx_year ON ssdse_b(年度); で作成。 全件スキャン O(n)→ O(log n + k) に高速化。 564 行では差が感じにくいが、 100 万行クラスで明確に効く。

📖 関連用語辞典（10 語）

RDB

Relational Database。 表（行・列）でデータを管理する DB の方式。 Codd 1970 年の論文が起源。

RDBMS

RDB を管理するソフトウェア。 PostgreSQL／MySQL／Oracle／SQL Server／SQLite。

スキーマ

テーブル・列・型・制約の構造定義。 デプロイ時に DDL（CREATE TABLE）で確定。

主キー（PK）

行を一意に識別する属性または属性の組。 NULL 不可、 一意。

外部キー（FK）

別表の主キーを参照する属性。 参照整合性を保証。

正規化

関数従属を解消する設計手法。 1NF → 2NF → 3NF → BCNF → 4NF → 5NF。

トランザクション

不可分な一連の操作。 BEGIN〜COMMIT/ROLLBACK で括る。

ACID 特性

原子性・整合性・隔離性・永続性。 トランザクションの 4 性質。

SQL

Structured Query Language。 RDB の標準問い合わせ言語。 ISO/IEC 9075。

インデックス

クエリ高速化のためのデータ構造。 B-tree／ハッシュ／GiST／GIN など。

🧮 実値で計算してみる

SSDSE-B の都道府県データをSQL風に集計するなら（高齢化率は列として存在しないため、 高齢人口 A1303 ÷ 総人口 A1101 で計算する）：

1
2
3
4
5

SELECT 都道府県, 高齢人口*1.0/総人口 AS 高齢化率
FROM ssdse_b
WHERE 年度 = 2023
GROUP BY 都道府県
ORDER BY 高齢化率 DESC;

pandas なら d23 = df[df["年度"]==2023]; (d23["高齢人口"]/d23["総人口"]).sort_values(ascending=False) 相当。

🧮 数式に値を入れて手で計算する: SSDSE-B-2026 を 3NF 設計したときのストレージ削減

SSDSE-B-2026 (47 都道府県 × 12 年 × 112 列 = 63,168 セル) を非正規形 (Excel 形式) と第 3 正規形 (3NF) で比較します。

Step 1: 非正規形 (1 テーブル)

Step 2: 第 3 正規形 (4 テーブル)

Step 3: 比較・効果

🐍 Python で再現

1
2
3

tables = {'非正規': 1, '1NF': 2, '2NF': 3, '3NF': 4}
for k, v in tables.items():
    print(f"{k}: {v} 表")

📤 実行結果

💬 手計算 (Step 2) と Python 出力が完全一致。

🐍 Python 実装

最小限のスニペットで動作確認できる例。 公的データ（SSDSE 等）を想定しています。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

import sqlite3
import pandas as pd

# SSDSE-B-2026 を読み込み、主要列を日本語名にリネーム（本ページ共通の前提）
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
df = df.rename(columns={'SSDSE-B-2026': '年度', 'Code': '地域コード',
                        'Prefecture': '都道府県', 'A1101': '総人口',
                        'A4101': '出生数', 'A4200': '死亡数',
                        'A1303': '高齢人口', 'A1302': '生産年齢人口'})
conn = sqlite3.connect(':memory:')
df.to_sql('ssdse', conn, index=False)

# SQL クエリで抽出
query = "SELECT 年度, 都道府県, 総人口, 出生数, 死亡数 FROM ssdse WHERE 都道府県='秋田県' AND 年度=2023"
result = pd.read_sql(query, conn)
print(result)

📤 実行すると次の出力が得られる:

💬 結果の読み方: SSDSE-B-2026 (564 行 × 112 列) を SQLite テーブルに変換した上で SQL の WHERE 都道府県='秋田県' AND 年度=2023 で 1 行抽出している。 本ページの以降の SQL 例は、 すべてこのリネーム済みテーブルを前提とする。 同じことを pandas で書くと df[(df['都道府県']=='秋田県') & (df['年度']==2023)] だが、 RDB を介すと (1) インデックス自動利用 (2) JOIN で他テーブルと結合可能 (3) ストレージとアプリの分離、 という運用上の利点が得られる。 :memory: をファイルパス (例: 'ssdse.db') に変えれば永続化可能。

📥 JOIN 集計例: SSDSE-B-2026 と地方区分マスタを結合し、 ブロック別人口合計を出す。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 地方ブロックマスタを作って INNER JOIN
block = pd.DataFrame({
    '都道府県': ['北海道', '東京都', '大阪府', '福岡県', '沖縄県'],
    'ブロック': ['北海道', '関東', '近畿', '九州', '九州'],
})
block.to_sql('block', conn, index=False, if_exists='replace')
q = """
SELECT b.ブロック, COUNT(*) AS 件数, SUM(s.総人口) AS 人口計
FROM ssdse s JOIN block b ON s.都道府県 = b.都道府県 WHERE s.年度 = 2023
GROUP BY b.ブロック
"""
print(pd.read_sql(q, conn))

📤 実行結果:

💬 結果の読み方: INNER JOIN で「都道府県」をキーに 2 表を突き合わせ、 GROUP BY ブロック で集計値を返している。 マスタ側 (block) に存在しない都道府県は結果から除外されるため、 全 47 件を集計したい場合は地方区分マスタを完備するか LEFT JOIN + NULL 検出に変更する。

🎮 触って理解する ── 正規化と JOIN を動かして体感

下の図は「顧客名・住所が注文ごとに重複コピーされた 1 枚のフラット表」です。 「⚡ 正規化」ボタンを押す（またはスライダーをドラッグする）と、 表が顧客表＋注文表の 2 枚に分割され、 氏名・住所のセルが顧客表へ飛んでいき、 主キー（顧客表の 顧客ID）↔ 外部キー（注文表の 顧客ID）が線で結ばれる様子がアニメーションで見られます。 「🔗 JOIN」で元の 1 枚表に戻ります。 さらに「🏠 引っ越し」で更新異常、 「⚠️ 迷子の注文」で参照整合性違反を体感してください。 右下の数値（セル数・冗長数・整合性）は操作に合わせてリアルタイムに更新されます。

💡 直感 ── 「重複を無くし、 表を分けて、 鍵で繋ぐ」

正規化の本質は 3 ステップに尽きる。 (1) 同じ事実は 1 か所にだけ書く（佐藤さんの住所はこの世界に 1 つしかないのに、 フラット表では注文の数だけコピーされる）。 (2) テーマごとに表を分ける（「顧客という実体」と「注文という出来事」は変化の頻度も主語も違う）。 (3) 主キーと外部キーで繋ぎ直す（分けた表は JOIN でいつでも元に戻せる＝無損失結合）。 上のデモの数値がそのまま証拠になっている：フラット表は 6 行 × 6 列 = 36 セルのうち氏名・住所 6 セルが重複だが、 正規化後は注文 6 行 × 4 列 + 顧客 3 行 × 3 列 = 33 セルで冗長ゼロ。 引っ越し 1 件の反映が「3 セル書き換え（1 つでも漏れると同一人物の住所が食い違う更新異常）」から「顧客表の 1 セル」に減ることこそ、 正規化が守ってくれる整合性である。

⚠️ よくある落とし穴 ── 過正規化と JOIN コスト

• 過正規化：理論的純度を追って表を細分しすぎると、 画面 1 つ出すのに 5〜10 表の JOIN が必要になり、 SQL も実行計画も複雑化する。 分析（OLAP）用途では、 デモとは逆方向の非正規化（JOIN 済みワイド表を事前に作る）が定石。 「書き込みが多い業務系は正規化、 読み取り中心の分析系は非正規化」が使い分けの軸。
• JOIN コスト：結合キーにインデックスが無いと、 素朴には N × M 回の突き合わせ（ネステッドループ）になる。 デモの 6 行 × 3 行なら一瞬でも、 数百万行同士では致命的。 結合キーへの CREATE INDEX と EXPLAIN での実行計画確認が実務の基本動作。
• 迷子の行（ダングリング）：デモの O7 (C99) のように参照先の無い行は、 INNER JOIN で黙って消える。 「JOIN したら行数が減った／増えた」ときは、 まず参照整合性とキーの重複を疑う。 FOREIGN KEY 制約を張っておけば、 そもそも INSERT の時点で拒否される。

🚀 発展 ── 正規形・インデックス・トランザクション

デモで行った分割は、 実は「非キー列（氏名・住所）が主キー（注文ID）ではなく顧客IDに従属している」状態＝推移的従属の解消であり、 第 3 正規形 (3NF) への変換に相当する。 正規形には 1NF（1 セル 1 値）→ 2NF（部分従属の排除）→ 3NF（推移従属の排除）→ BCNF という段階があり、 実務は 3NF が事実上の標準。 分割で増える JOIN の代償はインデックス（B-tree）が支払う：外部キー照合が全表走査から対数時間の探索に変わる。 そして「顧客表と注文表を同時に更新する」ような複数表更新はトランザクション（ACID）で原子化し、 途中失敗による中途半端な状態を防ぐ。 SSDSE-B-2026 も本文で見たように「都道府県マスタ＋指標マスタ＋事実テーブル」の 3NF 構成に正規化でき、 このデモの顧客・注文の関係は 都道府県マスタ・観測値の関係にそのまま対応する。

🔗 さらに手を動かす：SQL（クエリビルダーのデモあり）／主キー／外部キー／データ結合／データベース／NoSQL。 正規形理論・トランザクション分離レベルの専用ページは未収録のため、 教科書では「関数従属」「ACID」「直列化可能性」をキーワードに調べるとよい。

⚠️ よくある落とし穴

🌐 関連手法・派生

• PostgreSQL — 機能豊富な高性能OSS
• SQLite — ファイルベースの軽量DB
• MySQL — Web系で広く採用
• SQLAlchemy — PythonのORM
• BigQuery — クラウド分析向けカラム型

RDB (リレーショナルデータベース) は、 SSDSE-B-2026 のような正規化済みテーブル (都道府県マスタ + 観測ファクト) を SQL で結合・集計する基盤。 「テーブル + 主キー + 外部キー + JOIN + 集計関数」 という関係モデルが核心で、 CSV や JSON とは「整合性制約 + トランザクション」の有無で区別される。

• 上位概念: データベース管理システム (DBMS)、 関係モデル (E.F.Codd) — RDB はその実装。
• 並列手法: NoSQL (KVS/ドキュメント/グラフ)、 カラムストア (BigQuery/Redshift) — スキーマレス or 列指向の選択肢。
• 前段処理: ER 図設計 → 第 3 正規形までの正規化 → CREATE TABLE & 主キー/外部キー定義 → INSERT で SSDSE データ投入。
• 後段処理: SELECT + GROUP BY で集計 → pandas に read_sql で取り込み → 可視化・モデル学習へ。
• 派生・拡張: ビュー / マテリアライズドビュー / ストアドプロシージャ / ウィンドウ関数 (LAG/LEAD) で時系列パネル分析。
• 競合・代替: DuckDB (組込列指向、 CSV 直接 SQL) — 47 都道府県級ならば pandas 直接でも十分。

SSDSE-B-2026 を SQLite に投入し、 都道府県マスタと観測テーブルを JOIN して集計、 という流れが RDB 学習の入口。

🔗 関連用語（前提・並列・発展）

役割で色分け：前提／上位／並列／発展／応用

RDB (Relational Database) を学ぶ際に併読すると理解が深まる関連用語を「前提・並列・発展」の 3 区分で整理する。

• 前提概念: テーブル / 行 / 列 / 主キー / 外部キー / 正規化 (第 1-第 3 正規形) / SQL 基本構文 (SELECT / JOIN / WHERE)。 SSDSE-B-2026 の都道府県データも 47 行 × 多列の構造で RDB に格納可能。
• 並列概念: NoSQL (ドキュメント DB / KVS / グラフ DB) / NewSQL / OLAP 専用 DWH / DataFrame (pandas) — スキーマと整合性のトレードオフが異なる並列ストレージ。 統計分析では DataFrame が手軽だが、 大規模運用では RDB が必須。
• 発展概念: インデックス設計 / トランザクション (ACID) / マテリアライズドビュー / レプリケーション / シャーディング / データウェアハウス (DWH) — 性能と可用性の発展技法。 ビッグデータ 化への対応として重要。

RDB は「表とその関係を整合性を保って管理する」基盤。 SSDSE-B-2026 のような統計データを長期保管・共有する場合、 CSV ファイル直置きより RDB + SQL で管理する方が更新ログ・型保証・JOIN 検索の点で圧倒的に有利。

📚 関連グループ教材

この用語の全体像を学ぶには、 横断的な教材で文脈を掴むのが効率的です。

• 📚 データエンジニアリング
• 📚 データベース概論

🔎 深掘り解説

正規化の段階

• 第1正規形（1NF）：1セルに1値（繰返し列を排除）
• 第2正規形（2NF）：部分関数従属の排除（複合キーがある場合）
• 第3正規形（3NF）：推移関数従属の排除
• BCNF：あらゆる関数従属でPKに依存
• 非正規化（Denormalization）：パフォーマンスのため意図的に冗長化

インデックスの種類

✅ 使う前のチェックリスト

• ☐ リレーショナルデータベース が今のタスクに本当に適切か再確認した
• ☐ 前提条件（独立性、 正規性、 サンプル数等）を満たしているか確認した
• ☐ データの尺度・分布・欠損・外れ値を確認した
• ☐ 結果だけでなく「不確実性」（CI、 標準誤差）も把握した
• ☐ 解釈と限界を区別して文書化した
• ☐ 関連する別の手法と比較したうえでRDBを選んだ
• ☐ 落とし穴（このページの ⚠️ セクション）に該当しないか確認した
• ☐ 関連グループ教材で全体像と位置付けを把握した

📖 さらに学ぶには

本サイト内

• 論文一覧に戻る — リレーショナルデータベース を実際に使った再現論文をハンズオン形式で読む
• このページ上部の「🔗 関連用語」から派生概念へ
• 「📚 関連グループ教材」で横断的な学習教材へ

外部リソース

• scikit-learn 公式ドキュメント — 標準実装と例
• StatQuest with Josh Starmer (YouTube) — 直感的な統計／ML 解説
• Cross Validated (Stack Exchange) — 統計／ML の質問サイト
• arXiv — 最新の手法論文プレプリント

困ったときは

1. データの可視化（散布図、 ヒストグラム、 箱ひげ図）で異常を確認
2. サンプルサイズ・欠損・外れ値を確認
3. 仮定が満たされているか診断（正規性検定、 等分散性検定など）
4. 類似研究での標準的な手法を確認
5. 結果を複数手法でクロスチェック（頑健性確認）

🔗 同カテゴリの他用語

📚 参考文献・出典

• Codd, E. F. (1970). A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, 13(6).
• Date, C. J. (2003). An Introduction to Database Systems (8th ed.). Addison-Wesley.
• Garcia-Molina, H., Ullman, J. D., Widom, J. (2008). Database Systems: The Complete Book. Pearson.
• PostgreSQL Documentation. https://www.postgresql.org/docs/
• SQLite Documentation. https://www.sqlite.org/docs.html
• 独立行政法人統計センター. SSDSE-B-2026. https://www.nstac.go.jp/use/literacy/ssdse/
• ISO/IEC 9075:2023 SQL 標準仕様.

🌟 拡張ハンドブック

📜 RDB の歴史と Codd の 12 原則

RDB は Edgar F. Codd（IBM 研究員）が 1970 年に Communications of the ACM に発表した論文「A Relational Model of Data for Large Shared Data Banks」が起源です。 当時主流だった階層型・ネットワーク型 DB の「データと処理の密結合」という欠点を解消すべく、 集合論と関係代数に基づく抽象モデルを提唱しました。 1979 年に Oracle が商用 RDBMS をリリースし、 1980 年代に DB2、 SQL Server、 PostgreSQL、 MySQL が登場、 現在に至るまで 50 年以上 RDB は基幹 DB の標準として君臨しています。

Codd の 12 原則（要約）

1. 情報原則：データは表の中の値だけで表現される
2. 保証アクセス：表名・列名・主キーで全データにアクセス可能
3. NULL の系統的扱い：欠損は NULL で一貫表現
4. 能動的カタログ：メタデータも表で管理
5. 包括的サブ言語：データ定義・操作・整合性・権限が 1 言語（=SQL）で記述
6. ビュー更新：ビュー経由でも更新可能
7. 高水準の挿入・更新・削除：集合演算で複数行を一括処理
8. 物理データ独立性：ストレージ実装変更がアプリに影響しない
9. 論理データ独立性：論理スキーマ変更がアプリに影響しない
10. 整合性独立性：制約はスキーマで管理
11. 分散独立性：DB が分散しても透明
12. 非破壊規則：低水準 API で 12 原則を回避できない

🔑 主キー・外部キー・候補キーの違い

📐 正規化の段階詳細

第 1 正規形（1NF）

「各セルは原子値のみ」「繰り返し列なし」を満たす。 SSDSE-B-2026 はもともとリレーショナル形式で配布されているので 1NF を満たしている。 逆に Excel で「2010, 2011, ..., 2023」と各年度を列にしている場合は非 1NFで、 pd.melt で Long 形式に変換すると 1NF 化できる。

第 2 正規形（2NF）

1NF を満たし、 かつ「非キー属性が候補キー全体に関数従属」する。 たとえば SSDSE-B の (年度, 地域コード) を主キーにした場合、 都道府県名は「地域コード」のみに依存（年度に依存しない）ので 2NF 違反。 解消するには「都道府県マスタ（地域コード, 都道府県名）」と「統計事実テーブル」に分割。

第 3 正規形（3NF）

2NF を満たし、 かつ「非キー属性間の関数従属」がない。 推移的関数従属（A→B→C で A→C）を排除。 SSDSE-B-2026 を分割した後の「都道府県マスタ（地域コード→都道府県→地方区分）」では、 地方区分は地域コード→都道府県→地方区分の推移依存なので 3NF 違反。 「都道府県マスタ」と「地方区分マスタ」に分割するのが 3NF。

BCNF・4NF・5NF

BCNF（Boyce-Codd 正規形）：3NF を強化、 非自明な関数従属の左辺が必ずスーパーキー。 4NF：多値従属を排除。 5NF：結合従属を排除。 実務では 3NF か BCNF で十分なケースがほとんど。

🔄 ACID と トランザクション

A: Atomicity（原子性）

「複数の操作をまとめて、 全成功か全失敗のどちらか」。 銀行送金で「A 口座から引いて B 口座に入れる」途中で停電しても、 両方が完了するか両方が元に戻る。 SQL では BEGIN; ... COMMIT; または ROLLBACK;。

C: Consistency（整合性）

「トランザクション後も DB 制約を満たす」。 NOT NULL、 UNIQUE、 CHECK、 FK の各制約が常に成立。

I: Isolation（隔離性）

「並行する複数トランザクションが互いに干渉しない」。 ANSI 標準で 4 レベル：READ UNCOMMITTED < READ COMMITTED < REPEATABLE READ < SERIALIZABLE。 高いほど安全だが遅い。

D: Durability（永続性）

「COMMIT したデータは障害があっても消えない」。 WAL（Write-Ahead Logging）と fsync で保証。

⚡ インデックスの種類と選び方

💻 PostgreSQL vs MySQL vs SQLite

❓ FAQ・20 問

🏭 産業界の事例詳細（6 件・各 200 字超）

📚 50 連発レシピ集

🧪 50 連発の SQL レシピ（SSDSE-B-2026 を SQLite で）

1. SELECT * FROM ssdse_b WHERE 年度=2023; — フィルタ
2. SELECT 都道府県, 総人口 FROM ssdse_b WHERE 年度=2023 ORDER BY 総人口 DESC LIMIT 10; — TOP 10
3. SELECT 都道府県, AVG(総人口) FROM ssdse_b GROUP BY 都道府県; — 集計
4. SELECT COUNT(*) FROM ssdse_b; — 行数
5. SELECT MIN(総人口), MAX(総人口), AVG(総人口) FROM ssdse_b WHERE 年度=2023; — 統計
6. SELECT 年度, SUM(総人口) FROM ssdse_b GROUP BY 年度 ORDER BY 年度; — 年別合計
7. SELECT * FROM ssdse_b WHERE 都道府県 IN ('東京都','大阪府','愛知県'); — IN
8. SELECT * FROM ssdse_b WHERE 都道府県 LIKE '%県' AND 年度=2023; — LIKE
9. SELECT 都道府県 FROM ssdse_b WHERE 総人口 BETWEEN 1000000 AND 5000000; — BETWEEN
10. SELECT DISTINCT 年度 FROM ssdse_b; — ユニーク
11. SELECT 都道府県, 総人口, RANK() OVER (PARTITION BY 年度 ORDER BY 総人口 DESC) FROM ssdse_b; — ウィンドウ
12. SELECT 都道府県, LAG(総人口, 1) OVER (PARTITION BY 都道府県 ORDER BY 年度) AS 前年 FROM ssdse_b;
13. SELECT 都道府県, 総人口 - LAG(総人口) OVER (PARTITION BY 都道府県 ORDER BY 年度) AS 増減 FROM ssdse_b;
14. SELECT 都道府県, SUM(総人口) OVER (PARTITION BY 都道府県 ORDER BY 年度) AS 累計 FROM ssdse_b;
15. SELECT 年度, AVG(総人口) OVER (ORDER BY 年度 ROWS 2 PRECEDING) AS 移動平均 FROM ssdse_b;
16. WITH 集計 AS (SELECT 都道府県, AVG(総人口) AS 平均 FROM ssdse_b GROUP BY 都道府県) SELECT * FROM 集計 WHERE 平均 > 1000000; — CTE
17. SELECT a.都道府県, a.総人口 - b.総人口 AS 増減 FROM ssdse_b a JOIN ssdse_b b ON a.地域コード=b.地域コード WHERE a.年度=2023 AND b.年度=2012; — 自己結合
18. SELECT 都道府県, 総人口, CASE WHEN 総人口 > 5000000 THEN '大' ELSE '小' END FROM ssdse_b; — CASE
19. SELECT 都道府県 FROM ssdse_b WHERE 年度=2023 AND 総人口 > (SELECT AVG(総人口) FROM ssdse_b WHERE 年度=2023); — サブクエリ
20. SELECT 都道府県, COUNT(*) FROM ssdse_b GROUP BY 都道府県 HAVING COUNT(*) > 10; — HAVING
21. CREATE INDEX idx_year ON ssdse_b(年度); — インデックス
22. CREATE INDEX idx_pref ON ssdse_b(都道府県);
23. EXPLAIN QUERY PLAN SELECT * FROM ssdse_b WHERE 年度=2023; — 実行計画
24. CREATE VIEW v_2023 AS SELECT * FROM ssdse_b WHERE 年度=2023; — ビュー
25. BEGIN; UPDATE ssdse_b SET 総人口=総人口+1; ROLLBACK; — トランザクション
26. SELECT 都道府県, 出生数*1000.0/総人口 AS 出生率 FROM ssdse_b WHERE 年度=2023 ORDER BY 出生率 DESC;
27. SELECT 都道府県, SUM(出生数) - SUM(死亡数) AS 自然増減 FROM ssdse_b GROUP BY 都道府県;
28. SELECT 都道府県, NTILE(4) OVER (ORDER BY 総人口) AS 4分位 FROM ssdse_b WHERE 年度=2023;
29. SELECT 都道府県, ROW_NUMBER() OVER (ORDER BY 総人口 DESC) FROM ssdse_b WHERE 年度=2023;
30. SELECT * FROM ssdse_b WHERE 都道府県 IS NOT NULL; — NULL 除外
31. SELECT 都道府県, COALESCE(出生数, 0) FROM ssdse_b; — COALESCE
32. SELECT printf('%d人', 総人口) FROM ssdse_b LIMIT 5; — フォーマット
33. SELECT date('now') AS today; — 日付
34. SELECT julianday('2024-01-01') - julianday('2023-01-01'); — 日数差
35. SELECT length(都道府県) FROM ssdse_b LIMIT 3; — 長さ
36. SELECT upper(都道府県), lower(都道府県) FROM ssdse_b LIMIT 3; — 大小
37. SELECT substr(都道府県, 1, 2) FROM ssdse_b LIMIT 5; — 部分文字列
38. SELECT trim(' hello '); — トリム
39. SELECT replace(都道府県, '県', '') FROM ssdse_b; — 置換
40. SELECT cast(総人口 AS REAL) / 10000 FROM ssdse_b; — キャスト
41. SELECT abs(-5), round(3.14159, 2), random() % 100; — 数値関数
42. ATTACH DATABASE 'other.db' AS o; — DB アタッチ
43. SELECT * FROM main.ssdse_b UNION ALL SELECT * FROM o.ssdse_b;
44. CREATE TABLE 都道府県マスタ (地域コード TEXT PRIMARY KEY, 名前 TEXT);
45. INSERT INTO 都道府県マスタ VALUES ('R01000', '北海道');
46. SELECT a.*, m.名前 FROM ssdse_b a JOIN 都道府県マスタ m ON a.地域コード=m.地域コード;
47. UPDATE ssdse_b SET 都道府県='東京' WHERE 都道府県='東京都';
48. DELETE FROM ssdse_b WHERE 年度 < 2015;
49. VACUUM; — 領域整理
50. PRAGMA table_info(ssdse_b); — スキーマ確認

📘 体系的解説（拡張版）

📜 RDB の歴史的展開

前史：階層型 DB とネットワーク型 DB（1960 年代）

RDB 登場以前は IBM の IMS（階層型、 1968）や CODASYL DBTG モデル（ネットワーク型）が主流。 これらは「ポインタで構造を表現」するため、 データ構造とアプリケーションコードが密結合。 構造変更のたびにアプリ全体を書き直す必要があり、 保守コストが膨大でした。

RDB の誕生：Codd 1970

Edgar F. Codd（IBM サンノゼ研究所）が 1970 年 6 月、 Communications of the ACM に「A Relational Model of Data for Large Shared Data Banks」を発表。 集合論と関係代数に基づき、 「データを論理的に表現し、 物理的実装と切り離す」設計を提唱。 これにより、 ストレージ実装やデータ構造を変えてもアプリは無修正、 という革命的な独立性が実現しました。

商用化：1979-1989

1979 年：Larry Ellison が Oracle V2 をリリース（実は内部バージョン 1 は未完成）。 IBM の SQL/DS（1981）、 DB2（1983）、 Sybase（1984）と続く。 1986 年：SQL が ANSI 標準（X3.135-1986）として制定。 1989 年：PostgreSQL のオリジナル「POSTGRES」が UC Berkeley でリリース。

OSS RDB の勃興：1990 年代

MySQL（1995、 Monty Widenius）、 PostgreSQL（1996、 Berkeley から派生）、 SQLite（2000、 D. Richard Hipp）が登場。 LAMP スタック（Linux + Apache + MySQL + PHP）がインターネット黎明期の Web 開発の主流に。 「商用 RDB を買わずに済む」時代の到来。

NoSQL の挑戦：2009 年〜

2009 年に「NoSQL」という言葉が流行し、 MongoDB、 Cassandra、 Redis、 Neo4j など多様な DB が登場。 「RDB の終焉」が叫ばれましたが、 結局は用途別に使い分ける「polyglot persistence」が定着。 RDB は依然として基幹系・帳簿系の中核。

NewSQL とクラウド DB：2015 年〜

Google Spanner（2012 発表、 2017 公開）、 CockroachDB、 TiDB など、 「ACID + 水平スケール」を両立する NewSQL が登場。 また Snowflake、 BigQuery など分析特化のクラウド DWH も普及。 オンプレ DBA からクラウド DBA への業務シフトが進行中。

📐 関係代数演算の完全ガイド

基本演算（5 個）

派生演算（4 個）

拡張演算（集合・集約）

⚙️ SQL 標準の歴史

🔧 SSDSE-B-2026 を題材にした完全 SQL 演習

演習 1：データロード

1
2
3
4
5
6
7
8

import sqlite3, pandas as pd
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
df = df.rename(columns={'SSDSE-B-2026': '年度', 'Code': '地域コード',
                        'Prefecture': '都道府県', 'A1101': '総人口',
                        'A4101': '出生数', 'A4200': '死亡数',
                        'A1303': '高齢人口', 'A1302': '生産年齢人口'})
conn = sqlite3.connect('ssdse.db')
df.to_sql('ssdse_b', conn, if_exists='replace', index=False)

演習 2：基本クエリ 10 連発

-- 1. 全件数
SELECT COUNT(*) FROM ssdse_b;
-- 2. 年度のユニーク
SELECT DISTINCT 年度 FROM ssdse_b ORDER BY 年度;
-- 3. 都道府県のユニーク
SELECT DISTINCT 都道府県 FROM ssdse_b ORDER BY 都道府県;
-- 4. 2023 年の総人口上位 10
SELECT 都道府県, 総人口 FROM ssdse_b
WHERE 年度=2023 ORDER BY 総人口 DESC LIMIT 10;
-- 5. 2023 年の平均人口
SELECT AVG(総人口) FROM ssdse_b WHERE 年度=2023;
-- 6. 出生率 上位 5
SELECT 都道府県, 出生数*1000.0/総人口 AS 出生率
FROM ssdse_b WHERE 年度=2023
ORDER BY 出生率 DESC LIMIT 5;
-- 7. 高齢化率 上位 5
SELECT 都道府県, 高齢人口*1.0/総人口 AS 高齢化率
FROM ssdse_b WHERE 年度=2023
ORDER BY 高齢化率 DESC LIMIT 5;
-- 8. 自然増減（出生数-死亡数）
SELECT 都道府県, 出生数 - 死亡数 AS 自然増減
FROM ssdse_b WHERE 年度=2023
ORDER BY 自然増減 DESC;
-- 9. 都道府県別の総人口平均
SELECT 都道府県, AVG(総人口) FROM ssdse_b GROUP BY 都道府県;
-- 10. 年度別の全国合計
SELECT 年度, SUM(総人口) FROM ssdse_b GROUP BY 年度;

演習 3：ウィンドウ関数

-- 都道府県内での前年差
SELECT 年度, 都道府県, 総人口,
  総人口 - LAG(総人口) OVER (PARTITION BY 都道府県 ORDER BY 年度) AS 前年差
FROM ssdse_b;

-- 各年度のランキング
SELECT 年度, 都道府県, 総人口,
  RANK() OVER (PARTITION BY 年度 ORDER BY 総人口 DESC) AS 順位
FROM ssdse_b;

-- 3 年移動平均
SELECT 年度, 都道府県, 総人口,
  AVG(総人口) OVER (PARTITION BY 都道府県 ORDER BY 年度 ROWS 2 PRECEDING) AS 移動平均
FROM ssdse_b;

演習 4：自己結合

-- 2012 年度と 2023 年度の比較
SELECT a.都道府県,
  a.総人口 AS 人口_2023,
  b.総人口 AS 人口_2012,
  a.総人口 - b.総人口 AS 増減,
  ROUND((a.総人口 - b.総人口) * 100.0 / b.総人口, 2) AS 増減率
FROM ssdse_b a
JOIN ssdse_b b ON a.地域コード=b.地域コード
WHERE a.年度=2023 AND b.年度=2012
ORDER BY 増減率 DESC;

🎯 RDB 設計のベストプラクティス

1. 主キーは必ず付ける：行を一意に識別する手段がないと、 後でデータ整合性が破綻。
2. 命名規則を統一：snake_case か camelCase。 表は単数形（user）か複数形（users）。 1 つの規約を貫く。
3. NULL 許可は最小に：NULL は「未知」「未入力」「適用外」など曖昧。 デフォルト値を入れるか、 NOT NULL 制約を。
4. 外部キーは必ず張る：参照整合性の DB レベル保証。 「実装時に厄介」と言って外すと後悔する。
5. インデックスは慎重に：読込みは速くなるが書込みは遅くなる。 EXPLAIN で実効性を確認。
6. 3NF を基本に：4NF・5NF は実務では稀。 ただし分析系では適度な非正規化（スター/スノーフレークスキーマ）。
7. マイグレーション管理：Flyway、 Liquibase、 Alembic などでスキーマ変更を履歴管理。
8. バックアップ自動化：日次フル + 1 時間ごとの差分が標準。
9. 監視：スロークエリログ、 接続数、 ロック状態を Prometheus + Grafana で可視化。
10. テスト DB：本番と同じスキーマ・サイズのテスト環境を用意。

🎯 実践演習・チェックリスト

🎓 RDB 100 ステップ学習プラン

第 1 段階：基本（ステップ 1-20）

1. SQLite のインストール（Python に標準同梱）
2. SSDSE-B-2026 を pandas で読込
3. SQLite DB ファイル作成
4. to_sql でテーブル作成
5. SELECT * FROM ssdse_b LIMIT 5
6. SELECT COUNT(*) FROM ssdse_b
7. SELECT DISTINCT 都道府県 FROM ssdse_b
8. WHERE 年度=2023
9. WHERE 都道府県='東京都'
10. WHERE 総人口 > 5000000
11. ORDER BY 総人口 DESC
12. LIMIT 10
13. GROUP BY 年度
14. SUM、 AVG、 MIN、 MAX、 COUNT
15. HAVING COUNT(*) > 10
16. WHERE 都道府県 LIKE '%県'
17. WHERE 都道府県 IN ('東京都', '大阪府')
18. WHERE 総人口 BETWEEN 1000000 AND 5000000
19. WHERE 都道府県 IS NOT NULL
20. SELECT 都道府県, 総人口/10000 AS 万人 FROM ssdse_b

第 2 段階：結合（ステップ 21-40）

21. 都道府県マスタテーブル作成
22. INSERT INTO で行追加
23. INNER JOIN の基本
24. LEFT JOIN
25. RIGHT JOIN
26. FULL OUTER JOIN（SQLite では UNION で代替）
27. CROSS JOIN
28. 自己結合（前年比較）
29. サブクエリ（WHERE 句内）
30. サブクエリ（FROM 句内）
31. サブクエリ（SELECT 句内）
32. EXISTS / NOT EXISTS
33. IN / NOT IN サブクエリ
34. UNION
35. UNION ALL
36. INTERSECT
37. EXCEPT（SQLite では EXCEPT）
38. CASE 式
39. COALESCE で NULL 処理
40. NULLIF

第 3 段階：ウィンドウ関数（ステップ 41-60）

41. ROW_NUMBER() OVER
42. RANK() OVER
43. DENSE_RANK() OVER
44. PARTITION BY
45. ORDER BY 内
46. LAG（前期参照）
47. LEAD（後期参照）
48. FIRST_VALUE / LAST_VALUE
49. SUM() OVER（累積）
50. AVG() OVER ROWS BETWEEN（移動平均）
51. NTILE（パーセンタイル）
52. PERCENT_RANK
53. CUME_DIST
54. RANGE 指定
55. ROWS BETWEEN UNBOUNDED PRECEDING
56. 名前付きウィンドウ（WINDOW 句）
57. 複数ウィンドウの組合せ
58. ウィンドウとサブクエリの比較
59. ウィンドウのパフォーマンス
60. EXPLAIN で実行計画確認

第 4 段階：DDL と制約（ステップ 61-80）

61. CREATE TABLE
62. データ型（INT、 REAL、 TEXT、 BLOB）
63. PRIMARY KEY
64. FOREIGN KEY
65. UNIQUE 制約
66. NOT NULL 制約
67. CHECK 制約
68. DEFAULT 値
69. AUTO_INCREMENT（SQLite では INTEGER PRIMARY KEY）
70. CREATE INDEX
71. DROP INDEX
72. ALTER TABLE ADD COLUMN
73. ALTER TABLE RENAME
74. DROP TABLE
75. CREATE VIEW
76. DROP VIEW
77. CREATE TRIGGER
78. BEGIN / COMMIT / ROLLBACK
79. SAVEPOINT
80. VACUUM（領域整理）

第 5 段階：高度な操作（ステップ 81-100）

81. CTE（WITH 句）
82. WITH RECURSIVE
83. 階層クエリ（祖先・子孫）
84. ピボット（SUM + CASE）
85. アンピボット（UNION ALL）
86. JSON 関数（json_extract）
87. 正規表現（REGEXP）
88. FTS（全文検索）
89. R-tree（地理空間）
90. ATTACH DATABASE（複数 DB）
91. pragma の調整
92. WAL モード
93. バックアップ（BACKUP コマンド）
94. レプリケーション（litestream）
95. EXPLAIN QUERY PLAN
96. ANALYZE で統計情報
97. 仮想テーブル
98. カスタム関数（Python から）
99. セッション/エクステンション拡張
100. 本番運用ベストプラクティス

📊 SSDSE-B-2026 を題材にした実用 SQL レシピ 30 連発

1. SELECT 都道府県, 総人口 FROM ssdse_b WHERE 年度=2023 ORDER BY 総人口 DESC LIMIT 10;

2. SELECT 都道府県, AVG(総人口) FROM ssdse_b GROUP BY 都道府県;

3. SELECT 年度, SUM(総人口) FROM ssdse_b GROUP BY 年度;

4. SELECT 都道府県, 出生数*1000.0/総人口 AS 出生率 FROM ssdse_b WHERE 年度=2023;

5. SELECT 都道府県, 高齢人口*1.0/総人口 AS 高齢化率 FROM ssdse_b WHERE 年度=2023 ORDER BY 高齢化率 DESC;

6. SELECT 都道府県, RANK() OVER (ORDER BY 総人口 DESC) FROM ssdse_b WHERE 年度=2023;

7. SELECT 年度, 都道府県, 総人口 - LAG(総人口) OVER (PARTITION BY 都道府県 ORDER BY 年度) AS 増減 FROM ssdse_b;

8. SELECT 都道府県, MIN(総人口) AS 最小, MAX(総人口) AS 最大 FROM ssdse_b GROUP BY 都道府県;

9. SELECT a.都道府県, a.総人口, b.総人口 AS 前年 FROM ssdse_b a JOIN ssdse_b b ON a.地域コード=b.地域コード AND a.年度=b.年度+1;

10. WITH 増減 AS (SELECT 都道府県, 年度, 総人口, 総人口 - LAG(総人口) OVER (PARTITION BY 都道府県 ORDER BY 年度) AS d FROM ssdse_b) SELECT * FROM 増減 WHERE d < 0;

11. SELECT 都道府県, AVG(総人口) OVER (PARTITION BY 都道府県 ORDER BY 年度 ROWS 2 PRECEDING) AS 3年平均 FROM ssdse_b;

12. SELECT 都道府県 FROM ssdse_b WHERE 年度=2023 AND 総人口 > (SELECT AVG(総人口) FROM ssdse_b WHERE 年度=2023);

13. SELECT 都道府県, COUNT(*) FROM ssdse_b GROUP BY 都道府県 HAVING COUNT(*) = 12;

14. CREATE INDEX idx_year_pref ON ssdse_b(年度, 都道府県);

15. EXPLAIN QUERY PLAN SELECT * FROM ssdse_b WHERE 年度=2023 AND 都道府県='東京都';

16. CREATE VIEW v_2023_summary AS SELECT 都道府県, 総人口, 出生数, 死亡数 FROM ssdse_b WHERE 年度=2023;

17. SELECT 都道府県, CASE WHEN 総人口 > 5000000 THEN '大' WHEN 総人口 > 1500000 THEN '中' ELSE '小' END AS 規模 FROM ssdse_b WHERE 年度=2023;

18. SELECT 都道府県, NTILE(4) OVER (ORDER BY 総人口) AS 4分位 FROM ssdse_b WHERE 年度=2023;

19. SELECT 都道府県, ROUND(出生数*1000.0/総人口, 2) AS 出生率_per1000 FROM ssdse_b WHERE 年度=2023;

20. SELECT 都道府県, COALESCE(死亡数, 0) FROM ssdse_b WHERE 年度=2023;

21. SELECT 都道府県, SUM(出生数) OVER (PARTITION BY 都道府県 ORDER BY 年度) AS 累計出生数 FROM ssdse_b;

22. CREATE TABLE 地方区分 (地域コード TEXT PRIMARY KEY, 地方名 TEXT);

23. INSERT INTO 地方区分 VALUES ('R01000', '北海道'), ('R02000', '東北'), ...;

24. SELECT g.地方名, AVG(s.総人口) FROM ssdse_b s JOIN 地方区分 g ON s.地域コード=g.地域コード GROUP BY g.地方名;

25. BEGIN; UPDATE ssdse_b SET 都道府県='東京都' WHERE 都道府県='東京'; COMMIT;

26. -- PostgreSQL のみ（SQLite に CORR は無い）: SELECT ROUND(CORR(総人口, 出生数)::numeric, 3) FROM ssdse_b WHERE 年度=2023;

27. SELECT json_object('都道府県', 都道府県, '人口', 総人口) FROM ssdse_b WHERE 年度=2023;

28. PRAGMA table_info(ssdse_b);

29. PRAGMA index_list(ssdse_b);

30. VACUUM;

📚 包括的付録

📖 包括的付録：RDBの完全ガイド

本付録は、 RDBを初めて学ぶ人から、 実務でフル活用する人まで、 段階的に深掘りできるよう構成されています。 すべての例は SSDSE-B-2026 を使った実コードで、 そのままコピペで動作確認できます。

D.1 SQL 関数 完全リファレンス

D.1.1 集約関数

D.1.2 ウィンドウ関数

D.1.3 文字列関数

D.1.4 日付関数（SQLite）

date('now')                       -- 今日
datetime('now')                   -- 現在日時
strftime('%Y', date)              -- 年抽出
strftime('%m', date)              -- 月抽出
date('now', '-1 year')            -- 1 年前
date('2023-01-01', '+30 days')    -- 30 日後
julianday(date1) - julianday(date2)  -- 日数差

D.2 索引設計のガイドライン

• 主キーには自動でインデックスが張られる（B-tree）
• 外部キー列もインデックスを推奨（結合性能向上）
• WHERE 句で頻繁に使う列にインデックス
• ORDER BY、 GROUP BY で使う列にもインデックス検討
• カーディナリティが低い列（例：性別）はインデックスより効果が薄い
• 複合インデックスは「前方一致」で効く：(年度, 都道府県) なら 年度 検索は OK、 都道府県単独はインデックス効かず
• 関数インデックス：CREATE INDEX ON ssdse_b(LOWER(都道府県))
• 部分インデックス：CREATE INDEX ON ssdse_b(総人口) WHERE 年度=2023
• カバリングインデックス：SELECT に使う列すべてを含むインデックス（テーブル参照不要）
• EXPLAIN で確認：本当にインデックスが使われているか

🎁 追加リファレンス

📚 主要 RDBMS の比較とライセンス

🔧 SSDSE-B-2026 を使った 30 個のクエリパターン

1. 2023 年の全データ：SELECT * FROM ssdse_b WHERE 年度=2023
2. 都道府県数：SELECT COUNT(DISTINCT 都道府県) FROM ssdse_b
3. 年度数：SELECT COUNT(DISTINCT 年度) FROM ssdse_b
4. 東京の総人口推移：SELECT 年度, 総人口 FROM ssdse_b WHERE 都道府県='東京都' ORDER BY 年度
5. 各年度の最大人口県：SELECT 年度, 都道府県, MAX(総人口) FROM ssdse_b GROUP BY 年度
6. 2023 年の高齢化率トップ 5：SELECT 都道府県, 高齢人口*1.0/総人口 r FROM ssdse_b WHERE 年度=2023 ORDER BY r DESC LIMIT 5
7. 2012-2023 の総人口変化率：WITH t1 AS (SELECT 地域コード, 総人口 FROM ssdse_b WHERE 年度=2012), t2 AS (SELECT 地域コード, 総人口 FROM ssdse_b WHERE 年度=2023) SELECT t1.地域コード, (t2.総人口-t1.総人口)*100.0/t1.総人口 AS 変化率 FROM t1 JOIN t2 USING(地域コード)
8. 北海道・東京・沖縄の比較：SELECT 年度, 都道府県, 総人口, 出生数, 死亡数 FROM ssdse_b WHERE 都道府県 IN ('北海道','東京都','沖縄県') ORDER BY 都道府県, 年度
9. 全国合計人口（年度別）：SELECT 年度, SUM(総人口) FROM ssdse_b GROUP BY 年度 ORDER BY 年度
10. 都道府県別 12 年平均人口：SELECT 都道府県, AVG(総人口) FROM ssdse_b GROUP BY 都道府県 ORDER BY 2 DESC
11. 各都道府県のピーク年：SELECT s1.都道府県, s1.年度 FROM ssdse_b s1 WHERE s1.総人口 = (SELECT MAX(総人口) FROM ssdse_b s2 WHERE s2.都道府県=s1.都道府県)
12. 2023 年に減少した都道府県：SELECT a.都道府県 FROM ssdse_b a JOIN ssdse_b b ON a.地域コード=b.地域コード WHERE a.年度=2023 AND b.年度=2022 AND a.総人口 < b.総人口
13. 2023 年に増加した都道府県：上記の不等号を逆に
14. 出生率トップ：SELECT 都道府県, 出生数/総人口*1000.0 r FROM ssdse_b WHERE 年度=2023 ORDER BY r DESC
15. 死亡率トップ：SELECT 都道府県, 死亡数/総人口*1000.0 r FROM ssdse_b WHERE 年度=2023 ORDER BY r DESC
16. 自然増減：SELECT 都道府県, 出生数-死亡数 FROM ssdse_b WHERE 年度=2023 ORDER BY 2 DESC
17. 生産年齢人口（15〜64 歳、 A1302）：SELECT 都道府県, 生産年齢人口 FROM ssdse_b WHERE 年度=2023
18. 従属人口指数：SELECT 都道府県, (総人口-生産年齢人口)*100.0/生産年齢人口 FROM ssdse_b WHERE 年度=2023
19. 2023 年の粗死亡率：SELECT 都道府県, 死亡数*1000.0/総人口 FROM ssdse_b WHERE 年度=2023
20. 都市圏 vs 地方の比較：地方区分マスタを使って集計
21. 気候別の家計消費：年平均気温 (B4101) で分類してから消費支出 (L3221) を集計
22. 4 分位での分類：NTILE(4) OVER (ORDER BY 総人口)
23. 百分位ランク：PERCENT_RANK()
24. 移動平均：3 年・5 年
25. 累積：SUM() OVER (PARTITION BY 都道府県 ORDER BY 年度)
26. 差分：LAG で取得
27. 成長率：(現在 − 前年) / 前年
28. CAGR（年平均成長率）：POW(末期/初期, 1.0/(年数))-1
29. 相関：Pearson 相関係数の計算
30. カバリングインデックスの確認：EXPLAIN QUERY PLAN

🔧 補足リソース

🔒 RDB セキュリティのベストプラクティス

• SQL インジェクション対策：パラメータ化クエリ必須
• 最小権限の原則：アプリ用ユーザは SELECT/INSERT/UPDATE のみ
• 暗号化：保存時（at rest）と通信時（in transit）両方
• 監査ログ：すべての DDL/DML を記録
• バックアップ：日次フル + 1 時間ごと差分
• パスワード管理：環境変数、 シークレットマネージャ
• 接続プール：適切なサイズ設定
• ファイアウォール：DB サーバへの直接アクセスを制限
• VPC/プライベートネットワーク：パブリック IP を持たせない
• 定期的な脆弱性スキャン：CVE 情報の追跡

📈 RDB パフォーマンスチューニング体系

レベル 1：クエリ単位

• EXPLAIN で実行計画確認
• 適切なインデックス追加
• SELECT * 回避
• WHERE 条件で先頭から絞る
• JOIN の順序最適化
• サブクエリ vs JOIN の選択

レベル 2：スキーマ単位

• 正規化と非正規化のバランス
• パーティショニング（日付・地域）
• マテリアライズドビュー
• 列指向 vs 行指向
• シャーディング

レベル 3：インフラ単位

• メモリ・CPU・ディスクの増強
• SSD への移行
• レプリケーション（読込み負荷分散）
• キャッシュ層追加（Redis）
• CDN（Web 配信時）

💼 RDB 関連職種とキャリアパス

📚 RDB 関連の主要書籍

• C.J. Date『An Introduction to Database Systems』
• Hector Garcia-Molina et al.『Database Systems: The Complete Book』
• Stéphane Faroult『The Art of SQL』
• Markus Winand『SQL Performance Explained』
• Joe Celko『SQL for Smarties』
• Adam Tornhill『SQL Antipatterns』
• 『達人に学ぶ DB 設計徹底指南書』ミック
• 『SQL アンチパターン』Bill Karwin
• 『PostgreSQL 徹底入門』近藤雄太郎
• 『MySQL によるタフな運用の極意』奥野幹也

📖 完全マスター・ハンドブック

📋 RDB ハンドブック：100 のヒント

1. 主キーは必ず指定する
2. 外部キー制約は最初から設定
3. NOT NULL を可能な限り適用
4. DEFAULT 値で NULL を回避
5. CHECK 制約で値の範囲を保証
6. UNIQUE 制約で重複防止
7. 命名規則は snake_case を統一
8. テーブル名は複数形（users）か単数形（user）を統一
9. 列名に予約語を避ける
10. カラム数は 30 以内が望ましい
11. 1 トランザクション = 1 業務単位
12. BEGIN / COMMIT / ROLLBACK を明示
13. 長時間トランザクションを避ける
14. デッドロックを意識（同じ順序でロック）
15. 分離レベルは READ COMMITTED が基本
16. SELECT * を避ける
17. WHERE で必要な列だけを取得
18. JOIN の順序を意識（小テーブルから大テーブルへ）
19. EXISTS と IN の使い分け
20. サブクエリより CTE
21. UNION より UNION ALL（重複排除が不要なら）
22. HAVING より WHERE（集計前に絞り込み）
23. ORDER BY は最小限の列
24. LIMIT で行数制限
25. EXPLAIN で実行計画確認
26. インデックスは選択性が高い列
27. 複合インデックスは前方一致
28. カバリングインデックスで SELECT 高速化
29. 関数インデックスで WHERE 句の関数
30. 部分インデックスで特定条件
31. テーブル統計を定期更新（ANALYZE）
32. VACUUM で領域整理
33. パーティショニングで巨大表を分割
34. シャーディングで水平スケール
35. レプリケーションで読込み負荷分散
36. マスター/スレーブ構成
37. マスター/マスター構成は要注意
38. バックアップは日次フル + 1 時間差分
39. WAL（Write-Ahead Logging）有効化
40. ロールバック可能な範囲を確保
41. パスワードは環境変数で管理
42. SQL インジェクション対策（パラメータ化クエリ）
43. 暗号化（at rest、 in transit）
44. 監査ログ（DDL、 DML 全件）
45. 最小権限の原則
46. マイグレーション管理（Flyway、 Liquibase）
47. テスト DB と本番 DB の同期
48. 本番への直接アクセスを制限
49. API 経由でのアクセスを推奨
50. 監視（Prometheus、 Grafana）
51. スロークエリログを定期的に確認
52. 接続数の上限を意識
53. 接続プールサイズ調整
54. クエリタイムアウト設定
55. アプリケーション側のリトライロジック
56. キャッシュ層（Redis）の併用
57. マテリアライズドビューで集計高速化
58. ストアドプロシージャは慎重に
59. トリガーは副作用に注意
60. ビューは可読性のために活用
61. 命名規則：テーブルは名詞
62. 命名規則：列は具体的に
63. 命名規則：インデックスは idx_ プレフィックス
64. 命名規則：制約は ck_, fk_, uq_ プレフィックス
65. 正規化は 3NF まで
66. 非正規化は読込み中心なら検討
67. 分析系は星型/雪型スキーマ
68. OLTP と OLAP を分離
69. ETL の頻度を業務に合わせる
70. データ品質チェック（DBT、 Great Expectations）
71. スキーマ進化は後方互換性を保つ
72. 追加カラムは末尾に
73. 列削除は段階的に
74. 型変更は注意（NUMBER → VARCHAR は不可逆）
75. 命名変更は別名 → 移行 → 削除
76. テーブル削除前にバックアップ
77. 本番デプロイは平日の業務時間外
78. 本番デプロイ前にステージング検証
79. ロールバックスクリプトを準備
80. ダウンタイム最小化（Blue/Green デプロイ）
81. SaaS DB（Supabase、 PlanetScale）の活用
82. クラウド DB（RDS、 Cloud SQL）でマネージド化
83. BigQuery、 Snowflake で分析特化
84. DuckDB でローカル分析
85. SQLite で組込み・テスト
86. PostgreSQL で OSS の標準
87. MySQL で Web の定番
88. Oracle で エンタープライズ最高峰
89. SQL Server で Microsoft 環境
90. NoSQL（MongoDB、 Cassandra）との使い分け
91. NewSQL（CockroachDB、 TiDB）の検討
92. グラフ DB（Neo4j）の利用
93. 時系列 DB（InfluxDB、 TimescaleDB）
94. ベクトル DB（Pinecone、 Weaviate）
95. 地理空間 DB（PostGIS）
96. JSON 対応（PostgreSQL、 MySQL 8）
97. 全文検索（PostgreSQL FTS、 Elasticsearch）
98. レプリケーションラグの監視
99. 障害復旧訓練（DR）の実施
100. キャパシティプランニング
101. クエリのパターン分析
102. n+1 問題を避ける（Eager Loading）
103. キャリア：DBA、 データエンジニア、 SRE

🌟 まとめと次のステップ

📚 RDB（リレーショナルデータベース）の総合チェックポイント

1. 基本理解

RDB（リレーショナルデータベース）を学ぶ上で、 最初に押さえるべき概念とその関係性。 SSDSE-B-2026 を題材に、 47 都道府県 × 12 年 × 112 指標のデータを使って実際に試すことで、 理論と実践のギャップを埋めることができます。 統計学・データサイエンスの教育では、 ハンズオン形式での学習が最も効果的とされており、 本ページもその設計思想に従って構成されています。

2. 応用力

基本を押さえたら、 実務での応用力を養います。 教科書通りの「綺麗なケース」ではなく、 SSDSE-B-2026 のような現実のデータには、 表記揺れ・欠損・外れ値・分布の偏りなど、 様々な「現実のノイズ」が含まれています。 これらに対処しながら意味のある分析結果を導く力こそが、 データサイエンティストとしての真価です。

3. 倫理と社会的責任

データ分析者には、 単なる技術的能力以上のものが求められます。 (1) プライバシー保護：個人情報の取扱、 (2) バイアスへの自覚：データに含まれる社会的偏見、 (3) 透明性：分析手法と前提の開示、 (4) 再現可能性：他者が同じ結論に到達できる文書化、 (5) 社会的影響：分析結果が引き起こす意思決定の影響範囲。

4. 継続的な学習

データサイエンスは急速に進化する分野です。 新しい手法・ツール・データソースが次々と登場するため、 継続的な学習が不可欠。 (1) 論文購読：arXiv の関連分野を週次でチェック、 (2) ライブラリ追跡：scipy、 sklearn、 PyTorch のリリースノート、 (3) カンファレンス：NeurIPS、 ICML、 KDD、 PyData、 (4) コミュニティ：Twitter／X、 LinkedIn、 国内の勉強会、 (5) ハンズオン：Kaggle、 SIGNATE、 SSDSE コンペ。

5. 本ページから次のステップへ

RDB（リレーショナルデータベース）を理解したら、 次は関連概念へ。 本サイトの「関連用語」セクションから派生概念へ進み、 「関連グループ教材」で全体像を把握。 さらに「論文一覧」では、 統計データ分析コンペティションで実際に提出された 159 件の論文を、 ハンズオン形式で再現することができます。 ぜひ自分のテーマで、 SSDSE-B-2026 を使った独自の研究にも挑戦してみてください。

🔬 用語固有の具体例（10 個）

1. SSDSE-B-2026.csv を SQLite にロード：df.to_sql('ssdse_b', sqlite3.connect('db'), index=False)
2. 主キー (年度, 地域コード) で複合キーを設定し、 一意性を保証
3. 都道府県マスタを別テーブル化し、 外部キー制約で参照整合性を維持
4. 2023 年の総人口上位 10 件を ORDER BY 総人口 DESC LIMIT 10 で取得
5. ウィンドウ関数 RANK() OVER (PARTITION BY 年度 ORDER BY 総人口 DESC) で各年の順位
6. 自己結合で 2012 年度と 2023 年度の人口比較、 増減率を計算
7. CTE で複雑なクエリを段階的に組み立てる（WITH … AS）
8. B-tree インデックスを (年度) に張り、 EXPLAIN で実行計画確認
9. VIEW で「2023 年サマリ」を定義し、 利用側のクエリを簡潔化
10. DuckDB で CSV を直接クエリ：SELECT * FROM 'SSDSE-B-2026.csv'

🎯 SSDSE-B-2026 で学べること

SSDSE-B-2026 は単なるデータセットではなく、 「日本のデータサイエンス教育のための共通言語」として設計されています。 47 都道府県という馴染みのある単位、 12 年間という適切な期間、 112 個という網羅的な指標。 すべての受講生が同じデータを扱うことで、 結果を比較・議論・批判できるという、 教育的価値を持っています。

本ページで紹介した RDB（リレーショナルデータベース）の理論と実装は、 SSDSE-B-2026 という共通の素材を介して、 全国の学習者・研究者・実務家が共有できる知識基盤となります。 学習を通じて、 ぜひ「自分の県」「自分の地域」「自分の興味」を切り口に、 オリジナルの分析にチャレンジしてみてください。

📞 困ったときのサポート

• 本サイト内：用語集トップ → 概念マップ → 論文一覧
• 関連書籍：本ページの参考文献セクションを参照
• オンラインフォーラム：Stack Overflow、 Cross Validated、 teratail
• 公的サポート：統計センター、 e-Stat ヘルプデスク
• 勉強会：PyData Tokyo、 R-bloggers、 JapanTUG

本ページの内容は、 統計・データサイエンスを学ぶすべての方の参考となれば幸いです。 RDB（リレーショナルデータベース）を深く理解し、 実務・研究・教育の様々な場面で活用してください。 ご質問・ご指摘がある場合は、 本リポジトリの GitHub Issues にお寄せください。

🗺 概念マップ

RDB（リレーショナルデータベース）と SQL・正規化・トランザクション（ACID）・主キー/外部キー・インデックス・NoSQL との対比を俯瞰する概念マップ。 構造化データ管理の基盤としての位置づけを示す。

SSDSE-B-2026 を SQLite に取り込み、 都道府県マスタテーブル (prefecture_code, name) と観測テーブル (year, prefecture_code, population, births) を JOIN すると、 「ある年の人口上位 10 県」 のような分析を SQL 1 文で書ける。

SELECT name, population FROM obs JOIN pref USING(prefecture_code) WHERE year=2022 ORDER BY population DESC LIMIT 10; — RDB が CSV や JSON に対して持つ「インデックス + JOIN + 制約」の優位性が、 47 都道府県 × 複数年のパネルで明確になる。

🔗 隣接手法への橋渡し

「リレーショナルデータベース」は単独で完結する手法ではなく、 隣接領域と連携することで真価を発揮する。

• 上流: データモデリング・正規化の理解が前提
• 並列: NoSQL・KVSと比較し、 表とリレーションが主か Document/Graph が主かで分かれる
• 下流: SQL・BI ツール・DWH で利活用

SSDSE-B-2026 を題材にした リレーショナルデータベース の活用は、 上流 (取得・整形) と下流 (解釈・可視化) を含めて初めて完結する。

🌳 手法選択フロー

「リレーショナルデータベース」を実際の課題に当てはめるとき、 状況別に何を選ぶかを 3 段階で判定する。

1. データ構造は表形式か? Yes → RDB、 No (階層・グラフ) → NoSQL を検討
2. 関係 (JOIN) を多用するか? Yes → RDB が得意、 No → KVS / Document でも可
3. 整合性が最重要か? Yes → RDB の ACID、 No → BASE で高可用性を取る

SSDSE-B-2026 は CSV 1 枚で完結するが、 「県マスタ」「年マスタ」「指標マスタ」に分けて RDB に格納すると、 年代別比較や指標横断検索が SQL 1 行で書ける。

🎨 直感で掴む（追補）── 「表の集合＋関係」で世界を写す

RDB の直感を一言でいえば 「事実を、 重複なく、 表に切り分けて置く」 ことである。 現実世界のデータには必ず「何が」「いつ」「どこで」「どれだけ」という軸がある。 RDB はこれを 1 つの巨大な表に押し込めず、 テーマ別の表（テーブル）に分け、 表と表を キーでつなぐ。 SSDSE-B-2026 でいえば「都道府県という不変の属性」と「年ごとに変わる観測値」は別の性質を持つので、 別の表に置くのが自然である。

用語の対応表（直感 → RDB 用語）

キーが「関係」を作る：主キーは「この行はこれだ」と一意に指し示す背番号、 外部キーは「あの表のあの行を指す」矢印である。 この矢印が張られていれば、 存在しない相手を指す矢印（迷子の参照）を DB が拒否できる。 これが 参照整合性 であり、 表計算ソフトには無い RDB の核心的な安心感を生む（本ページ上部の 🎮 ウィジェットで、 C99 という存在しない顧客を指す注文がどう扱われるかを実際に動かせる）。

なぜ分けるのか＝正規化の直感：もし県名・地方区分・年ごとの観測値を全部 1 枚の表に並べると、 「北海道」という県名が観測のたびに何度も書かれる。 北海道の表記を「北海道地方」に直したくなったら 全行を書き換えねばならず、 1 か所でも漏れれば「同じ県なのに名前が 2 種類」という矛盾（更新異常）が生まれる。 正規化とは、 この 「同じ事実は 1 か所にだけ」 を徹底し、 必要なときに JOIN で貼り合わせる考え方である。 SQL はこの貼り合わせと集計を 手続きではなく宣言で書ける（「どう取るか」ではなく「何が欲しいか」を書く）点が、 for ループで組み立てる発想との決定的な違いになる。

⚠️ 落とし穴（重要・追補）── 設計と運用でつまずく 8 点

RDB は「正しく設計すれば強い」が、 裏を返せば 設計を誤ると矛盾や遅さが固定化する。 以下は SSDSE-B-2026 を題材に、 初学者〜実務で踏みやすい落とし穴を整理したものである。

落とし穴の具体例：NULL と平均の罠（SSDSE-B-2026）

ある年のある県の指標が「行として存在しない（ロング形式で欠損）」場合、 AVG(value) はその欠損を 分母から自動で外す。 これは便利だが、 「47 都道府県すべてで割った全国平均」を期待していると、 実際は「観測のあった県だけの平均」になり値が上振れする。 「NULL は 0 ではない」「NULL は欠測であって『無い＝ゼロ』ではない」 を常に意識する。 全県で割りたいなら SUM(value) / 47.0 のように分母を明示するか、 CROSS JOIN で 47×年の骨組みを先に作り LEFT JOIN で埋めて欠損を可視化する（本ページ「表3」参照）。

落とし穴の具体例：多対多と中間表（架空の対応を含む）

「都道府県」と「指標」は多対多の関係にある（1 県は多数の指標を持ち、 1 指標は多数の県で観測される）。 これを 2 表だけで表そうとすると破綻する。 正解は 中間表（連関エンティティ） を挟むこと：prefectures（県マスタ）× indicators（指標マスタ）× facts（中間表＝県コード・年・指標コードで一意）。 facts の主キーは (pref_code, year, indicator_code) の複合キーになり、 これが 2 本の外部キーで両マスタを参照する。 なお indicators に入れる「カテゴリ区分（人口系／家計系…）」の細分は SSDSE 本体に列が無いため、 補助的に付ける場合は 架空の分類である旨を明記して用いること。

🚀 発展（追補）── 正規化理論から OLTP/OLAP まで

1. 正規形の階段（1NF → BCNF）

正規化は「関数従属（ある列が決まれば別の列が決まる関係）」を手がかりに冗長を段階的に排除する。 1NF：各セルは原子値（コンマ区切りで複数値を詰めない）。 2NF：1NF かつ、 非キー列が主キー全体に従属（複合キーの一部にだけ従う部分従属を排除）。 3NF：2NF かつ、 非キー列同士の 推移的従属を排除（例：県コード→地方区分→…を別表へ）。 BCNF：あらゆる関数従属の決定項が候補キーであること（3NF で残る稀な異常を封じる、 より厳密な形）。 教育・分析用途では 3NF を基準に、 集計性能のため意図的に非正規化する、 という往復が現実的である。

2. インデックスと JOIN 最適化

インデックスは「本の索引」に相当し、 検索対象列に B-Tree を張ることで全表スキャン（O(n)）を対数時間（O(log n)）に落とす。 反面、 書き込みが遅くなり容量も食うため万能ではない。 JOIN 最適化では、 結合キー両側にインデックスがあると ハッシュ結合／マージ結合／ネステッドループ結合のうち最適な戦略をオプティマイザが選べる。 実務では EXPLAIN／EXPLAIN ANALYZE でクエリプランを読み、 「想定した索引が使われているか」「全表スキャンに落ちていないか」を確認するのが定石である（本ページ「実務メモ」の複合・部分インデックスも参照）。

3. ACID とトランザクション

Atomicity（原子性）：一連の操作は全て成功か全て失敗か。 Consistency（一貫性）：制約を破らない状態から状態へ遷移。 Isolation（分離性）：並行トランザクションが互いに干渉しない（分離レベルで ダーティリード・ノンリピータブルリード・ファントムリードのどこまで防ぐかを選ぶ）。 Durability（永続性）：コミット済みは障害後も残る。 対比として NoSQL 系の BASE（Basically Available, Soft state, Eventually consistent）は整合性を緩めて可用性・分散性を取る思想であり、 用途で選び分ける。

4. OLTP / OLAP とスタースキーマ

OLTP（オンライントランザクション処理）は小さな読み書きを高頻度で捌く用途で、 行指向ストレージ（PostgreSQL 等）が向く。 OLAP（オンライン分析処理）は大量行を集計する用途で、 列指向（DuckDB・ClickHouse 等）が桁違いに速い。 分析向けの定番設計が スタースキーマ：中央に数値の ファクト表（SSDSE でいう facts：値・キーだけ）、 周囲に ディメンション表（prefectures／年／indicators のような「切り口」）を放射状に配置する。 SSDSE-B-2026 の 3 表構成（県マスタ・指標マスタ・事実表）は、 そのまま小さなスタースキーマになっている。

5. RDB と NoSQL の使い分け

構造が安定し、 結合が多く、 整合性が命なら RDB。 スキーマが流動的で、 水平分散と高スループットを優先し、 結果整合性を許せるなら NoSQL（ドキュメント／KVS／列指向ワイド／グラフ）。 近年は両者の中間として NewSQL（分散でも ACID を保つ）や、 分析特化の列指向 RDB が定着した。 SSDSE-B-2026 のような構造化統計データは、 迷わず RDB（学習は SQLite、 分析高速化は DuckDB）が第一選択である。

📎 関連ページ（このサイト内）

• データベース — RDB を含む上位概念
• リレーショナルデータベース（詳細） — 本ページの発展・詳細版
• 主キー — 行を一意に識別するキー
• 外部キー — 参照整合性を担う矢印
• SQL — RDB を操作する宣言型言語
• ER 図 — テーブル間の関係を図示する
• 内部結合／外部結合／テーブル結合／データ結合 — JOIN の各種と pandas 対応
• NoSQL — RDB と対をなすデータストア

※ 正規化理論・ACID／トランザクション・インデックス・OLTP/OLAP・スタースキーマの各項目は、 現時点で単独ページが無いため本ページ内で解説している（テキストのみ）。