🔖 キーワード索引

「主キー」を取り巻く中核キーワード群です。 検索やインデックス作成で参照する際の手がかりにしてください。 各キーワードは関連する概念・手法・道具立てを含み、 文献検索や学習計画の起点になります。

🎨 直感で掴む

クラスの出席簿に喩えると：

• 名前（山田太郎）＝同姓同名の可能性あり → 不適
• 学籍番号（2024001）＝必ず一意 → 適切な主キー

主キーは「絶対に重複しない」 「必ず値がある」 「後から変わらない」 ものを選ぶのが鉄則。

🎨 SSDSE-B-2026 の主キー構造

SSDSE-B-2026 の各レコードは「年 × 都道府県」で一意に決まる。 つまり (SSDSE 年, Code, Prefecture) の組合せが「複合主キー」になっている。 単独の Code 列 (R01000 = 北海道, R13000 = 東京都, ...) は 都道府県表のみでは主キーだが、 SSDSE-B-2026 では 12 年分 × 47 県 = 564 行あるため Code 単独では重複する。

これを SQL で表現するなら PRIMARY KEY (year, code)。 pandas なら df.set_index(['SSDSE', 'Code'])。 主キーが定義されていれば、 重複削除も「年次集計のための GROUP BY」も「他テーブルとの JOIN」も安全に行える。 例えば、 同じ複合主キーを持つ別表 (A1101 だけの抜粋 vs A1303 だけの抜粋) を merge(on=['SSDSE','Code']) で結合すれば、 行ズレなく統合できる。

✅ 理解度チェック

1. 主キーが満たすべき 3 条件（一意性・非 NULL・不変性）を説明できるか。
2. 自然キーと代理キー（サロゲートキー）の違いと使い分けを 1 例で挙げられるか。
3. 複合主キーが必要になる典型シナリオ（売上明細など）を 1 つ示せるか。
4. 主キーと一意制約・インデックスの関係を区別できるか。

📐 数式または定義

主キーは「関係（テーブル）$R$ の各行を一意に識別する属性集合 $K$」として、 集合論的に定義される。 記号の意味は次節で言葉に翻訳する。

属性集合 $K \subseteq \mathrm{attr}(R)$ が主キーであるとは、 次の 3 条件をすべて満たすことをいう。

$$\forall\, t_1, t_2 \in R:\quad t_1 \neq t_2 \;\Longrightarrow\; t_1[K] \neq t_2[K]$$

（一意性：異なる 2 行は $K$ の値も必ず異なる。 対偶を取れば「$t_1[K]=t_2[K] \Rightarrow t_1=t_2$」、 すなわち $K$ の値だけで行を完全に特定できる。）

$$\forall\, t \in R,\; \forall\, a \in K:\quad t[a] \neq \mathrm{NULL} \qquad (\text{非 NULL 性})$$

$$\forall\, K' \subsetneq K:\quad K' \text{ は一意性を満たさない} \qquad (\text{極小性})$$

ここで $t_1, t_2$ は $R$ の任意の行（タプル）、 $t_1[K]$ は行 $t_1$ における属性集合 $K$ の値を表す。 一意性のみを満たす集合はスーパーキー、 極小性も満たせば候補キー、 その候補キーの中から 1 つ選んだものが主キー（primary key）である。 具体的な値での計算例は後続セクションを参照。

🔬 数式を言葉で読み解く

🔬 概念を言葉で読み解く（詳細版）

主キー（Primary Key, PK）は、 リレーショナルデータベースのテーブルの「各行を一意に識別する属性または属性の組」。 SSDSE-B-2026.csv の場合、 (年度, 地域コード) の複合主キーが各レコードを一意に決めます。 PK は単なる「行番号」ではなく、 NULL 不可・一意性保証・自動インデックスといった3 つの絶対要件を満たします。

① 主キーの形式的定義

② 候補キー・代理キー・自然キー

③ SSDSE-B-2026 の主キー設計

SSDSE-B-2026 は 47 都道府県 × 12 年（2012-2023） = 564 行。 主キー候補：

• (年度, 地域コード)：47 × 12 = 564、 一意。 ✅ 推奨
• (年度, 都道府県)：47 × 12 = 564、 一意だが文字列で重い
• 地域コード単独：47 種類しかないので 12 年分で重複 → NG
• 年度単独：13 種類しかないので NG

地域コード（例：R13000=東京都）は ISO 3166-2:JP 規格に対応し、 国際標準との互換性も高い。 これが「(年度, 地域コード)」を主キーに選ぶ実務的根拠。

④ B-tree インデックスとパフォーマンス

SSDSE-B-2026 を SQLite で主キー付きロード

SSDSE-B-2026 を SQLite にロードする際、 (年度, 地域コード) を主キーに指定することで、 「2023 年の東京都を取得」というクエリが O(log n) に高速化。 564 行では体感差は小さいが、 主キー設計の練習として最適。 また主キーがあれば INSERT OR REPLACE で冪等更新も可能。

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

⚖️ 主キー設計の比較表

💥 失敗例から学ぶ

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

1. 問題：SSDSE-B-2026 を SQLite にロードし、 (年度, 地域コード) を主キーに指定せよ。
   ▼ 解答

   📥 入力例（skiprows=1 で日本語見出しのまま読み、全 564 行＝47 都道府県 × 12 年度から 4 列を使う） 年度 地域コード 都道府県 総人口 2023 R01000 北海道 5092000 2022 R01000 北海道 5140000 2023 R13000 東京都 14086000 …（全 564 行）

   📋 コピー

   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) # 日本語の列名で読む（2 行目を見出しにする） conn = sqlite3.connect(':memory:') conn.execute('''CREATE TABLE ssdse_b ( 年度 INTEGER, 地域コード TEXT, 都道府県 TEXT, 総人口 INTEGER, PRIMARY KEY (年度, 地域コード))''') df[['年度','地域コード','都道府県','総人口']].to_sql('ssdse_b', conn, if_exists='append', index=False) print(conn.execute("SELECT COUNT(*) FROM ssdse_b").fetchone()) # (564,)

   📤 実行例（実測） (564,)

   💬 (564,) が返り、主キー (年度, 地域コード) の組み合わせで 564 行すべてが重複なく入った。地域コードは 47 種類、各県が 12 年度ずつなので 47×12=564 で、どちらか一方だけを主キーにすると 2 行目以降が一意制約違反で挿入に失敗する。複合主キーは「この表の 1 行は何を表すか（県×年度）」をそのまま宣言したものと読める。

2. 問題：SSDSE-B-2026 で「都道府県」を単独 PK にしようとするとなぜ失敗する？
   ▼ 解答

   47 都道府県 × 12 年 = 564 行。 都道府県名は 12 回ずつ重複するため一意性違反。 (年度, 都道府県) の複合キーが必要。
3. 問題：(年度, 地域コード) と (年度, 都道府県) のどちらを PK にするか、 理由とともに述べよ。
   ▼ 解答

   (年度, 地域コード) を推奨。 理由：(1) 統計センターが振ったコードで、 表記揺れがなく他の統計表と突き合わせやすい、 (2) 整数/短文字列でインデックスが軽量、 (3) 都道府県名は表記揺れリスク（東京都 vs 東京）。
4. 問題：SSDSE-B-2026 の主キーに重複値を INSERT したらどうなるか、 また対策は？
   ▼ 解答

   UNIQUE constraint failed エラー。 対策：(1) INSERT OR IGNORE（既存を無視）、 (2) INSERT OR REPLACE（上書き）、 (3) ON CONFLICT (年度, 地域コード) DO UPDATE（PostgreSQL 互換）。
5. 問題：SSDSE-B-2026 から「都道府県マスタ」と「統計事実テーブル」に正規化する場合、 それぞれの PK は？
   ▼ 解答

   都道府県マスタ：PK = 地域コード（47 行、 例 R13000=東京都）。 統計事実テーブル：PK = (年度, 地域コード)、 FK = 地域コード → 都道府県マスタ。 これで 3NF を満たす。

📖 関連用語辞典（10 語）

主キー（PK）

行を一意に識別する属性集合。 NULL 不可、 一意。

外部キー（FK）

他表の PK を参照する属性。 参照整合性を保証。

候補キー

最小性を満たすスーパーキー。 PK の選択肢。

代理キー（surrogate）

人工的に振った ID（AUTO_INCREMENT）。 業務上意味なし。

自然キー（natural）

業務的意味を持つキー（マイナンバー、 ISBN）。

複合キー

2 つ以上の属性の組による PK。 SSDSE-B の (年度, 地域コード) が典型。

参照整合性

FK が参照する PK が必ず存在する状態。

UNIQUE 制約

一意性のみ要求（NULL 可）。 PK の弱い版。

B-tree インデックス

PK に自動で張られる検索構造。 計算量 O(log n)。

UUID / ULID

分散システム向けユニーク ID。 UUID は 128 ビット。

🔬 SSDSE-B-2026 で主キー設計の総合実習

実習：3NF 正規化 + FK 整合性 + UPSERT パターンの統合

🎯 やること：SSDSE-B-2026 を「都道府県マスタ」「地方区分マスタ」「統計事実」の 3 テーブルに正規化、 主キーと外部キーで参照整合性を確立、 UPSERT で冪等更新を実装する。

📥 入力：SSDSE-B-2026.csv 全 564 行。

 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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

import sqlite3, pandas as pd

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=1)

# 地方区分マッピング
BLOCKS = {
    '北海道': '北海道',
    '青森県':'東北','岩手県':'東北','宮城県':'東北','秋田県':'東北','山形県':'東北','福島県':'東北',
    '茨城県':'関東','栃木県':'関東','群馬県':'関東','埼玉県':'関東','千葉県':'関東','東京都':'関東','神奈川県':'関東',
    '新潟県':'中部','富山県':'中部','石川県':'中部','福井県':'中部','山梨県':'中部','長野県':'中部','岐阜県':'中部','静岡県':'中部','愛知県':'中部',
    '三重県':'近畿','滋賀県':'近畿','京都府':'近畿','大阪府':'近畿','兵庫県':'近畿','奈良県':'近畿','和歌山県':'近畿',
    '鳥取県':'中国','島根県':'中国','岡山県':'中国','広島県':'中国','山口県':'中国',
    '徳島県':'四国','香川県':'四国','愛媛県':'四国','高知県':'四国',
    '福岡県':'九州','佐賀県':'九州','長崎県':'九州','熊本県':'九州','大分県':'九州','宮崎県':'九州','鹿児島県':'九州','沖縄県':'九州',
}

conn = sqlite3.connect(':memory:')
conn.execute('PRAGMA foreign_keys = ON')

# 1. 地方区分マスタ
conn.execute('''CREATE TABLE 地方区分 (
    名称 TEXT PRIMARY KEY
)''')
conn.executemany('INSERT INTO 地方区分 VALUES (?)',
    [(b,) for b in sorted(set(BLOCKS.values()))])

# 2. 都道府県マスタ
conn.execute('''CREATE TABLE 都道府県マスタ (
    地域コード TEXT PRIMARY KEY,
    都道府県 TEXT NOT NULL UNIQUE,
    地方区分 TEXT NOT NULL,
    FOREIGN KEY (地方区分) REFERENCES 地方区分(名称)
)''')
master = df[['地域コード','都道府県']].drop_duplicates().copy()
master['地方区分'] = master['都道府県'].map(BLOCKS)
master.to_sql('都道府県マスタ', conn, if_exists='append', index=False)

# 3. 統計事実
conn.execute('''CREATE TABLE 統計事実 (
    年度 INTEGER NOT NULL,
    地域コード TEXT NOT NULL,
    総人口 INTEGER,
    出生数 INTEGER,
    PRIMARY KEY (年度, 地域コード),
    FOREIGN KEY (地域コード) REFERENCES 都道府県マスタ(地域コード)
)''')
df[['年度','地域コード','総人口','出生数']].to_sql(
    '統計事実', conn, if_exists='append', index=False)

# 集計クエリ：地方区分別人口（3 表 JOIN）
result = conn.execute('''
    SELECT 区.名称 AS 地方, COUNT(*) AS 件数, SUM(s.総人口) AS 合計人口
    FROM 統計事実 s
    JOIN 都道府県マスタ m USING (地域コード)
    JOIN 地方区分 区 ON m.地方区分 = 区.名称
    WHERE s.年度 = 2023
    GROUP BY 区.名称
    ORDER BY 合計人口 DESC
''').fetchall()

print(f"{'地方':4s} {'県数':>4s} {'合計人口':>12s}")
print('-' * 30)
for region, n, total in result:
    print(f"{region:4s} {n:>4d} {total:>12,}")

📤 実行結果：

💬 結果の読み方：3 表構造（地方区分マスタ → 都道府県マスタ → 統計事実）で 3NF を満たし、 FK で参照整合性を保証。 「地方区分・地域コード」が他表に存在しない値の挿入は DB レベルで拒否される。 集計クエリは 3 表 JOIN で実現し、 関東 4,352.7 万人（全国 1 億 2,435.3 万人の 35.0%）、 近畿 2,199.0 万人、 中部 2,074.9 万人の上位 3 ブロックで全国の 69.4% を占める。 県数の欄が 7・7・9・8・6・5・1・4 で合計 47 になっているのは、 2023 年に絞った 47 行が都道府県マスタとの JOIN で 1 行も落ちなかったことの確認にもなる。 主キーと外部キーの組合せが、 業務要件と性能の両立を可能にする。

🧮 実値で計算してみる

都道府県統計テーブルの主キー設計：

🧮 数式に値を入れて手で計算する: 主キー衝突確率 (誕生日)

合成データで UUID と数値 ID の衝突確率を比較する。

Step 1: 公式

Step 2: ID 別衝突

🐍 Python で再現

1
2
3
4
5
6
7
8
9
10

import numpy as np
n = 1e6
N_32 = 2**32
N_uuid = 2**122
x32 = n**2 / (2 * N_32)            # 期待衝突ペア数 n²/(2N)
xuuid = n**2 / (2 * N_uuid)
p32 = -np.expm1(-x32)              # 衝突確率 1 - exp(-n²/(2N))
puuid = -np.expm1(-xuuid)          # expm1 で極小値も桁落ちせずに計算
print(f"32bit: n²/(2N) = {x32:.1f} → 衝突確率 {p32:.4f}")
print(f"UUID : n²/(2N) = {xuuid:.2e} → 衝突確率 {puuid:.2e}")

📤 実行結果

💬 32bit 整数の空間 約 43 億に 100 万件を入れると n²/(2N) は 116.4 で、 衝突する組が平均 116 組ある計算になる。 近似式 n²/(2N) をそのまま確率と読むと 1 を超えてしまうので、 1 − e^(−116.4) で見ると衝突確率は事実上 1。 UUID v4 では 9.40e-26 で、 n²/(2N) が小さいこの領域では近似と厳密式が一致する。 32bit のランダム ID は 10 万件（n²/(2N) ≈ 1.16、 衝突確率 約 69%）でもすでに危ない。

🧮 結合の行数を主キーから予言する

2 つの表をキー列 $k$ で結合したときの行数は、 キーの値ごとの行数の積の和で決まる。

$$\text{結合後の行数} = \sum_{k} n_L(k)\, n_R(k)$$

$n_L(k)$ は左の表でキーが $k$ の行数、 $n_R(k)$ は右の表での行数。 結合に使う列が「主キー」なら $n_L(k)=1$ なので、 結合後の行数は右の表の行数を超えない。 主キーでない列で結合すると、 積の分だけ行が増える。

青森県・岩手県・宮城県で確かめる。 左は 2023 年度の総人口（1 県 1 行）、 右は 2022・2023 年度の出生数（1 県 2 行）。

• Step 1：キーごとの行数を数える。 左は地域コードが主キーなので 3 県とも $n_L=1$、 右は 2 年度分あるので $n_R=2$。
• Step 2：県ごとに積を取る。 $1\times2=2$ が 3 県。
• Step 3：和を取る。 $2+2+2=6$ 行。 左の 3 行が 2 倍に増えて見えるのは、 右が「県 × 年度」の粒度だから。
• Step 4：右と同じ 2 年度分の表どうしを地域コードだけで結合すると $n_L=n_R=2$ なので $3\times(2\times2)=12$ 行。 (年度, 地域コード) で結合すれば各組が 1 行ずつなので $6\times(1\times1)=6$ 行。
• Step 5：全 47 県・12 年度どうしを地域コードだけで結合すると $47\times12\times12=6{,}768$ 行、 主キー (年度, 地域コード) で結合すれば 564 行。

🎯 このコードでやること：手計算の Step 1〜5 を pandas の value_counts と merge で再現し、 予言した行数と実際の行数が一致するか確かめる。

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

import 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': '地域コード', 'A1101': '総人口'})
tohoku = ['R02000', 'R03000', 'R04000']            # 青森・岩手・宮城
L = df[(df['年度'] == 2023) & df['地域コード'].isin(tohoku)][['地域コード', '総人口']]
R = df[df['年度'].isin([2022, 2023]) & df['地域コード'].isin(tohoku)][['年度', '地域コード', 'A4101']]

# Step 1: キーごとの行数 n_L(k), n_R(k)
nL = L['地域コード'].value_counts().sort_index()
nR = R['地域コード'].value_counts().sort_index()
print(pd.DataFrame({'n_L': nL, 'n_R': nR, 'n_L×n_R': nL * nR}))
# Step 2: 予言 = Σ n_L(k)·n_R(k)
print('予言した行数:', int((nL * nR).sum()))
# Step 3: 実際に結合して確かめる
print('地域コードだけで結合:', len(L.merge(R, on='地域コード')))
# 右側を 2 年度とも持つ表どうしを地域コードだけで結合すると
L2 = R[['年度', '地域コード']].copy()
print('両側 2 年度・地域コードだけ:', len(L2.merge(R, on='地域コード')), '行')
print('両側 2 年度・(年度, 地域コード):', len(L2.merge(R, on=['年度', '地域コード'])), '行')
# 全 47 県・12 年度どうしで同じことをすると
full = df[['年度', '地域コード']]
print('全体・地域コードだけ:', len(full.merge(full, on='地域コード')), '行 = 47 × 12 × 12')
print('全体・(年度, 地域コード):', len(full.merge(full, on=['年度', '地域コード'])), '行')

💬 予言した 6 行と実際の結合結果 6 行が一致し、 手計算の Step 4・5 の 12 行・6,768 行・564 行もそのまま出た。 結合の前に「結合に使う列が片側で主キーになっているか」を確かめておけば、 結合後の行数を先に言い当てられる。 地域コードだけで全体どうしを結合した 6,768 行は、 同じ県の 12 年度 × 12 年度の組み合わせがすべて作られた結果で、 どの行も分析には使えない。

🧠 理解度チェック（実測値で解く）

1. 2023 年度の 47 行だけの表で主キーになる列は何か。 564 行の表ではなぜそれが主キーにならないか。
   解答：地域コード（都道府県名でもよい）。 564 行の表では各県が 12 年度分あり、 地域コードの異なり値は 47 しかないため。
2. 564 行の表どうしを (年度, 地域コード) ではなく年度だけで結合すると何行になるか。
   解答：各年度に 47 行ずつなので $12\times47\times47=26{,}508$ 行。
3. 2023 年度の表に東京都の行が 2 回入ると、 総人口の合計はいくつずれるか。
   解答：東京都 14,086,000 人の分だけ多くなり、 124,353,000 人が 138,439,000 人になる（下の ⚠️ の例では 2 行目の値を変えているので 138,453,000 人）。
4. 主キー (年度, 地域コード) を持つ横長の表を、 指標を縦に並べた縦長の表に変えたとき、 主キーはどう変わるか。
   解答：指標の列が加わり (年度, 地域コード, 指標) になる。 下の 🐍 の例では 61,476 行で重複 0。

🐍 Python での扱い

最小再現コード。 SSDSE-B のような実データを前提に、 4〜8 行で動く例です：

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

import sqlite3
conn = sqlite3.connect(':memory:')
cur = conn.cursor()
cur.execute('''CREATE TABLE prefecture_stats (
    code CHAR(2),
    year INT,
    tfr REAL,
    PRIMARY KEY (code, year)
)''')
cur.execute("INSERT INTO prefecture_stats VALUES ('13', 2023, 0.99)")  # 東京都 2023 年度の合計特殊出生率
# 重複は拒否される
try:
    cur.execute("INSERT INTO prefecture_stats VALUES ('13', 2023, 9.99)")
except sqlite3.IntegrityError as e:
    print('拒否:', e)

💬 同じ ('13', 2023) の組をもう一度入れようとすると IntegrityError になり、エラー文に code と year の 2 列が並んでいるので、複合主キーの組が衝突したことが分かる。2 回目の tfr=9.99 のように値が違っても拒否されるので、主キーは「中身の重複」ではなく「同じ県・同じ年度の行が 2 つある」ことを防いでいる。値を更新したいときは INSERT ではなく UPDATE か INSERT OR REPLACE を使う。

🐍 Python 完全コード（4 要素ナレーション付き）

コード 1：SSDSE-B-2026 を複合主キー付きで SQLite にロード

🎯 このコードでやること：SSDSE-B-2026.csv の 564 行を SQLite に格納、 (年度, 地域コード) を PRIMARY KEY に指定し、 一意性が保たれることを確認する。

📥 入力データ：

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

import pandas as pd, sqlite3

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=1)
cols = ['年度','地域コード','都道府県','総人口','出生数']

conn = sqlite3.connect(':memory:')
conn.execute('''CREATE TABLE ssdse_b (
    年度        INTEGER NOT NULL,
    地域コード  TEXT    NOT NULL,
    都道府県    TEXT    NOT NULL,
    総人口      INTEGER,
    出生数      INTEGER,
    PRIMARY KEY (年度, 地域コード)
)''')
df[cols].to_sql('ssdse_b', conn, if_exists='append', index=False)

n = conn.execute('SELECT COUNT(*) FROM ssdse_b').fetchone()[0]
print(f"ロード行数: {n}（期待値 47 × 12 = 564）")
print(f"PK 列: {[r[1] for r in conn.execute('PRAGMA table_info(ssdse_b)') if r[5]]}")

📤 実行結果：

💬 結果の読み方：564 行が一切重複なくロードされた＝(年度, 地域コード) が確かに一意である証拠。 SQLite は PK 列に自動で B-tree インデックスを構築、 以降の「2023 年東京都」検索は O(log n) で 1〜2 ノード参照のみ。 NOT NULL 制約も同時に課されているため、 欠損値混入も防げる。

コード 2：主キー違反をハンドリング（INSERT OR REPLACE）

🎯 このコードでやること：既存の (2023, R13000) レコードに新値を INSERT すると PK 違反エラー。 INSERT OR REPLACE で冪等更新できることを確認。

📥 入力データ：上記 ssdse_b テーブル。

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

import sqlite3, pandas as pd

# 上記コード 1 と同じセットアップ
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=1)
conn = sqlite3.connect(':memory:')
conn.execute('''CREATE TABLE ssdse_b (
    年度 INTEGER NOT NULL, 地域コード TEXT NOT NULL,
    都道府県 TEXT, 総人口 INTEGER, 出生数 INTEGER,
    PRIMARY KEY (年度, 地域コード))''')
df[['年度','地域コード','都道府県','総人口','出生数']].to_sql(
    'ssdse_b', conn, if_exists='append', index=False)

# 通常 INSERT は失敗
try:
    conn.execute("INSERT INTO ssdse_b VALUES (2023, 'R13000', '東京都', 14100000, 86000)")
except sqlite3.IntegrityError as e:
    print(f"❌ 普通の INSERT: {e}")

# INSERT OR REPLACE は成功
conn.execute("INSERT OR REPLACE INTO ssdse_b VALUES (2023, 'R13000', '東京都', 14100000, 86000)")
row = conn.execute("SELECT 総人口 FROM ssdse_b WHERE 年度=2023 AND 地域コード='R13000'").fetchone()
print(f"✅ INSERT OR REPLACE 後の総人口: {row[0]:,}")

📤 実行結果：

💬 結果の読み方：PK 違反は UNIQUE constraint failed として明示される。 INSERT OR REPLACE（PostgreSQL では ON CONFLICT ... DO UPDATE）で冪等な upsertが可能。 これがバッチ更新の鉄板パターン。 既存値（14,086,000）が新値（14,100,000）に置換された。

コード 3：複合 PK での JOIN と FK 整合性確認

🎯 このコードでやること：SSDSE-B-2026 を「都道府県マスタ」と「統計事実テーブル」に分割（3NF）、 FK で参照整合性を保証、 JOIN で元の形を復元できることを確認。

📥 入力データ：

 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, pandas as pd

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=1)

conn = sqlite3.connect(':memory:')
conn.execute('PRAGMA foreign_keys = ON')

# マスタテーブル（PK = 地域コード）
conn.execute('CREATE TABLE 都道府県マスタ (地域コード TEXT PRIMARY KEY, 都道府県 TEXT NOT NULL)')
master = df[['地域コード','都道府県']].drop_duplicates()
master.to_sql('都道府県マスタ', conn, if_exists='append', index=False)

# 事実テーブル（PK = (年度, 地域コード), FK = 地域コード）
conn.execute('''CREATE TABLE 統計事実 (
    年度 INTEGER, 地域コード TEXT, 総人口 INTEGER,
    PRIMARY KEY (年度, 地域コード),
    FOREIGN KEY (地域コード) REFERENCES 都道府県マスタ(地域コード))''')
df[['年度','地域コード','総人口']].to_sql('統計事実', conn, if_exists='append', index=False)

# 元の形を JOIN で復元
top3 = conn.execute('''
    SELECT s.年度, m.都道府県, s.総人口
    FROM 統計事実 s JOIN 都道府県マスタ m USING(地域コード)
    WHERE s.年度=2023 ORDER BY s.総人口 DESC LIMIT 3
''').fetchall()
for r in top3:
    print(r)

📤 実行結果：

💬 結果の読み方：3NF への正規化が成功。 都道府県マスタ（47 行）と統計事実（564 行）に分かれ、 FK 制約で「存在しない地域コードの統計レコード挿入」を DB レベルで拒否。 JOIN で元の形が完全復元され、 2023 年人口 TOP3 は東京・神奈川・大阪。 主キーと外部キーの組合せが「整合性」と「柔軟性」を両立する仕組み。

❓ FAQ 20 問

📖 主キーの包括ガイド（追補編）

📜 主キー概念の進化年表

📐 関係モデルにおける主キーの形式定義

関係 $R$ の主キー $K \subseteq \text{attr}(R)$ は以下を満たす：

1. 一意性：$\forall t_1, t_2 \in R: t_1[K] = t_2[K] \Rightarrow t_1 = t_2$
2. 最小性：$\forall K' \subsetneq K: \exists t_1, t_2 \in R: t_1 \ne t_2 \wedge t_1[K'] = t_2[K']$
3. 非 NULL 性：$\forall t \in R, \forall a \in K: t[a] \ne \text{NULL}$

一意性のみだとスーパーキー、 最小性も満たせば候補キー、 そこから DBA が選んだ 1 つが主キー。

⚙️ 主要 RDBMS の主キー実装

🎯 SSDSE-B-2026 の主キー戦略 4 種比較

戦略 1：自然複合 PK (年度, 地域コード)

CREATE TABLE ssdse_b (
    年度 INTEGER NOT NULL,
    地域コード TEXT NOT NULL,
    総人口 INTEGER,
    PRIMARY KEY (年度, 地域コード)
);

長所：業務的意味あり、 重複自然に防止、 e-Stat と整合。 短所：JOIN 時に列が増える、 値変更困難。

戦略 2：代理キー（連番）

CREATE TABLE ssdse_b (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    年度 INTEGER NOT NULL,
    地域コード TEXT NOT NULL,
    総人口 INTEGER,
    UNIQUE (年度, 地域コード)
);

長所：単一列で軽量、 JOIN シンプル、 PK 値が業務に左右されない。 短所：人工的、 業務的意味なし、 BigQuery 等で AUTOINCREMENT 不対応。

戦略 3：UUID

CREATE TABLE ssdse_b (
    id TEXT PRIMARY KEY,  -- UUID
    年度 INTEGER NOT NULL,
    地域コード TEXT NOT NULL,
    総人口 INTEGER,
    UNIQUE (年度, 地域コード)
);

長所：分散システム対応、 衝突しない、 シャーディング容易。 短所：16 バイトで重い、 ランダム UUID では INSERT 性能低下、 人間が読めない。

戦略 4：ハッシュ PK

-- 年度 + 地域コードのハッシュを PK に
CREATE TABLE ssdse_b (
    pk_hash TEXT PRIMARY KEY,  -- SHA-256(年度||地域コード)[:16]
    年度 INTEGER NOT NULL,
    地域コード TEXT NOT NULL,
    総人口 INTEGER
);

用途：データウェアハウス（dbt 等）でステージング層から事実テーブルへの変換に。

🔍 主キーと B-tree インデックスの内部

PK には自動で B-tree インデックスが構築される。 B-tree の特性：

• 平衡多分木：高さが揃う
• ブランチング係数：1 ノードあたり通常 100〜400 子
• 葉ノード：実データへのポインタ（またはクラスタ化インデックスではデータ本体）
• 計算量：検索・挿入・削除すべて $O(\log_b n)$
• SSDSE-B-2026 の 564 行：$\log_{200} 564 \approx 1.2$、 つまり 1〜2 ノード参照で目的行に到達
• 1 億行でも $\log_{200} 10^8 \approx 3.6$、 4 ノード参照

📊 主キーと参照整合性（FK）

SSDSE-B-2026 を 3NF 正規化した場合：

-- 都道府県マスタ
CREATE TABLE 都道府県マスタ (
    地域コード TEXT PRIMARY KEY,
    都道府県 TEXT NOT NULL UNIQUE,
    地方区分 TEXT NOT NULL
);

-- 統計事実
CREATE TABLE 統計事実 (
    年度 INTEGER NOT NULL,
    地域コード TEXT NOT NULL,
    総人口 INTEGER,
    出生数 INTEGER,
    PRIMARY KEY (年度, 地域コード),
    FOREIGN KEY (地域コード) REFERENCES 都道府県マスタ(地域コード)
        ON UPDATE CASCADE
        ON DELETE RESTRICT
);

これで：

• 「存在しない地域コードの統計レコード」は INSERT で拒否
• 地域コード変更時は CASCADE で統計事実も自動更新
• 都道府県マスタ削除時は RESTRICT で阻止（統計事実が参照中なら）

⚡ 主キー設計が性能に与える影響

🛡️ 主キーとセキュリティ

• 連番 ID の問題：「id=1 から順に推測」されると情報漏洩。 URL に id を露出するなら UUID 推奨
• 自然キーの個人情報：マイナンバーを PK にすると DB 漏洩で大規模情報漏洩。 ハッシュ化や代理キー分離が安全
• SSDSE-B-2026 の場合：都道府県レベル集計なので PII 問題なし、 自然キー（地域コード）で OK

🎓 主キー学習の段階的目標

1. 初級：1 表に PK 1 つ、 一意性・NULL 不可を理解、 SQLite で CREATE TABLE ... PRIMARY KEY
2. 中級：複合 PK、 候補キーから PK を選ぶ判断、 SSDSE-B-2026 で (年度, 地域コード) 設計
3. 上級：FK と参照整合性、 ON CASCADE / ON RESTRICT、 3NF 正規化
4. 実務：性能最適化、 シャーディング、 ULID 採用、 分散システムでの PK 戦略
5. 専門：DDD のエンティティ ID、 イベントソーシング、 CQRS パターン

🐍 表の形を変えると主キーも変わる（横長 → 縦長）

主キーは列の名前ではなく「1 行が何を表すか」で決まる。 SSDSE-B-2026 は 1 行 = 県 × 年度 の横長の表だが、 指標を縦に並べ直すと 1 行 = 県 × 年度 × 指標 になり、 主キーに指標の列が加わる。

🎯 このコードでやること：横長の表を melt で縦長に変え、 (年度, 地域コード) と (年度, 地域コード, 指標) の重複数を比べる。 pivot で元の形に戻せることも確かめる。

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

import 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': '都道府県'})
key = ['年度', '地域コード']
print('横長の表:', df.shape, '/ (年度, 地域コード) の重複', int(df.duplicated(subset=key).sum()))

# 縦長（1 行 = 県 × 年度 × 指標）に変換する
long = df.melt(id_vars=['年度', '地域コード', '都道府県'], var_name='指標', value_name='値')
print('縦長の表:', long.shape)
print('(年度, 地域コード) の重複:', int(long.duplicated(subset=key).sum()))
print('(年度, 地域コード, 指標) の重複:', int(long.duplicated(subset=key + ['指標']).sum()))
print(long[(long['地域コード'] == 'R13000') & (long['年度'] == 2023)].head(3).to_string(index=False))
# 縦長のまま「地域コード × 年度」で横に戻すと、キーが正しければ元の形に戻る
back = long.pivot(index=key, columns='指標', values='値')
print('pivot で戻した形:', back.shape)

💬 縦長にすると 564 × 109 = 61,476 行になり、 (年度, 地域コード) の重複は 60,912 件（= 61,476 − 564）に跳ね上がる。 指標を加えた 3 列の組では重複が 0 なので、 これが縦長の表の主キー。 pivot で (564, 109) に戻せたのも、 3 列の組が一意だからで、 重複があると pivot は ValueError で止まる。

⚠️ よくある落とし穴

主キー を実務で扱うとき、 多くの分析者が同じところでつまずきます。 代表的な失敗パターンを先回りで押さえておくと、 後工程のトラブルを大幅に減らせます。

※ 上記は文献調査・現場経験で報告される頻度の高い注意点。 ドメインや手法のバージョンによって追加の落とし穴がある場合があります。

⚠️ 実データで確かめる: 二重取り込みは drop_duplicates() では消えない

主キー制約の無い pandas の DataFrame では、 同じ県・同じ年度の行が 2 回入っても何も起きない。 値が訂正されて少し違っていると、 全列一致を見る drop_duplicates() ではすり抜ける。

🎯 このコードでやること：2023 年度の 47 行に、 東京都の行を「訂正版」として値を変えてもう 1 行足し、 全列での重複削除と主キーでの重複検出を比べる。

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

import 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': '総人口'})
t = df[df['年度'] == 2023][['年度', '地域コード', '都道府県', '総人口']]
print('正しい全国合計:', f"{t['総人口'].sum():,}")

# 東京都 2023 年度の行が「訂正版」として二重に取り込まれた状況を再現（14,100,000 は説明用の仮の値）
fix = t[t['地域コード'] == 'R13000'].assign(総人口=14_100_000)
t2 = pd.concat([t, fix], ignore_index=True)
print('行数:', len(t2))
print('drop_duplicates() 後の行数:', len(t2.drop_duplicates()))   # 値が違うので消えない
print('二重のまま合計:', f"{t2['総人口'].sum():,}")

# 主キーで重複を検出する
key = ['年度', '地域コード']
print('キーの重複:', int(t2.duplicated(subset=key).sum()), '件')
try:
    t2.set_index(key, verify_integrity=True)
except ValueError as e:
    print('verify_integrity:', str(e).splitlines()[0])
# 「後から来た訂正版を正とする」と決めて 1 行に絞る
t3 = t2.drop_duplicates(subset=key, keep='last')
print('keep=last 後:', len(t3), '行, 合計', f"{t3['総人口'].sum():,}")

💬 48 行のうち東京都の 2 行は総人口が違うので、 drop_duplicates() を通しても 48 行のまま。 合計は 138,453,000 人で、 正しい 124,353,000 人より 1,410 万人多い。 主キー (年度, 地域コード) で見れば重複 1 件として見つかり、 verify_integrity=True はその組 (2023, R13000) を名指しで止める。 どちらを残すかは「後から来た訂正版を正とする」のような約束で決め、 keep='last' で 47 行・124,367,000 人に戻る。

⚠️ 実データで確かめる: キーの「型」がずれると同じ値でも結合できない

主キーの値が同じに見えても、 片方が整数 2023、 もう片方が文字列 "2023" だと別の値として扱われる。 地域コードから県番号を切り出して整数にすると、 先頭の 0 が消えて "01" と 1 が一致しなくなる。

🎯 このコードでやること：年度の型が違う 2 つの表を結合したときのエラーと、 県番号の先頭の 0 が消えたときに何行が結合から漏れるかを確かめる。

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

import 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': '都道府県'})
pop = df[df['年度'] == 2023][['年度', '地域コード', 'A1101']]
# 別の表を文字列のまま読んだ状況（CSV を dtype=str で読むとこうなる）
birth = df[df['年度'] == 2023][['年度', '地域コード', 'A4101']].astype({'年度': str})
print(pop['年度'].dtype, birth['年度'].dtype)
try:
    pop.merge(birth, on=['年度', '地域コード'])
except ValueError as e:
    print('ValueError:', str(e)[:70])
# 型をそろえれば 47 行で 1 対 1 に結合できる
m = pop.merge(birth.astype({'年度': int}), on=['年度', '地域コード'], validate='one_to_one')
print('型をそろえた結合:', len(m), '行')

# 地域コードから 2 桁の県番号を作るとき、整数にすると先頭の 0 が消える
pop['県番号_int'] = pop['地域コード'].str[1:3].astype(int)
pop['県番号_str'] = pop['地域コード'].str[1:3]
print(pop[['地域コード', '県番号_int', '県番号_str']].head(3).to_string(index=False))
master = pd.DataFrame({'県番号': ['01', '02', '13'], '名称': ['北海道', '青森県', '東京都']})
print('文字列どうし:', len(pop.merge(master, left_on='県番号_str', right_on='県番号')), '行')
print('整数を文字列にしただけ:', len(pop.assign(k=pop['県番号_int'].astype(str)).merge(master, left_on='k', right_on='県番号')), '行')
print('zfill(2) で 0 を戻す:', len(pop.assign(k=pop['県番号_int'].astype(str).str.zfill(2)).merge(master, left_on='k', right_on='県番号')), '行')

💬 年度が int64 と object（文字列）の表は、 pandas が結合の前に ValueError で止めてくれる。 型をそろえると 47 行が 1 対 1 で結合できた。 県番号は整数にすると 01 が 1 になり、 文字列に戻しただけでは "1" と "01" が一致しないため、 マスタ 3 行のうち東京都の 13 だけが結合して 1 行になる。 こちらはエラーが出ずに行が静かに消えるので、 zfill(2) で桁をそろえてから結合し、 結合後の行数を確かめる。

🌐 関連手法・派生

• 外部キー (Foreign Key)：他テーブルの主キーを参照
• 候補キー (Candidate Key)：一意性を持つ列の候補（主キーになれる）
• スーパーキー：一意性を持つ列の組（候補キーの上位概念）
• UUID / ULID / Snowflake ID：分散環境向けの一意 ID 生成
• クラスタリングインデックス：主キー順にデータを物理配置

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

「主キー」をより深く理解するには、 周辺の用語を セットで 押さえるのが効率的です。 以下は前提（先に知っておくべき）、 並列（兄弟概念）、 発展（次に学ぶべき）の関係にある用語群：

クリックで各用語の詳細ページへ移動します。 全用語の体系は 用語集トップ または 概念マップ から俯瞰できます。

📚 関連グループ教材

「主キー」は単独で完結する概念ではなく、 より大きな分野の一部です。 上位カテゴリの教材を読むことで、 この用語の 位置づけ が立体的に見えてきます：

• 📚 データ処理 — このカテゴリの体系的解説

📚 参考文献・出典

• 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. et al. (2008). Database Systems: The Complete Book. Pearson.
• ISO/IEC 9075:2023. SQL — Foundation (Part 2).
• PostgreSQL Documentation: Primary Keys. URL
• SQLite Documentation: ROWID and Primary Keys. URL
• 独立行政法人統計センター. SSDSE-B-2026 (CC BY 4.0). URL
• ISO 3166-2:JP 都道府県コード規格.

🌟 拡張ハンドブック

📐 主キーの 3 つの絶対要件

1. 一意性（uniqueness）：どの 2 行も PK の値が異なる。
2. 非 NULL 性：すべての行で PK の値が NULL でない。
3. 不変性（実務的要件）：PK の値はライフサイクル中変更しない（FK が参照しているため）。

💼 主キー設計のチェックリスト

• □ 一意性が保証されているか
• □ NULL が入る可能性はないか
• □ 値が永続的に不変か
• □ 短く・軽量か（インデックス効率）
• □ 外部システムと整合する標準（ISO, RFC）に従っているか
• □ 分散システム要件（UUID 等）を満たしているか
• □ ビジネスロジック変更で揺らがないか
• □ シャーディング戦略と整合するか

📚 主キー × SSDSE-B-2026 完全ハンドブック

🗝️ 主キー設計判定フローチャート

1. 1 列で一意性が保てるか？ → YES なら単独 PK、 NO なら次へ
2. 業務的に意味のある列の組合せで一意性が保てるか？ → YES なら自然複合 PK
3. 分散環境（複数 DB 跨ぎ）か？ → YES なら UUID / ULID / Snowflake ID
4. INSERT 性能重視か？ → YES なら AUTOINCREMENT 連番
5. 外部連携重視か？ → YES なら公的なコード体系（SSDSE の地域コード、 JIS の都道府県コード、 ISO 3166-2:JP 等）
6. SSDSE-B-2026 の場合 → (年度, 地域コード) の自然複合 PK が最適

📐 主キー設計の意思決定マトリクス

💡 SSDSE-B-2026 で主キーを「壊して」みる演習

演習 1：PK なしで何が起こるか？

CREATE TABLE no_pk (
    年度 INTEGER, 地域コード TEXT, 総人口 INTEGER
);
INSERT INTO no_pk VALUES (2023, 'R13000', 14086000);
INSERT INTO no_pk VALUES (2023, 'R13000', 14086000);  -- 重複可能！

結果：同じレコードが 2 行発生。 集計時に「東京都 2 倍計算」のバグ。

演習 2：単独 PK で重複データ INSERT

CREATE TABLE single_pk (
    地域コード TEXT PRIMARY KEY,
    年度 INTEGER, 総人口 INTEGER
);
INSERT INTO single_pk VALUES ('R13000', 2023, 14086000);
INSERT INTO single_pk VALUES ('R13000', 2022, 14038000);  -- ❌ UNIQUE 違反

結果：単独 PK では「同じ地域の複数年データ」が入らない。 (年度, 地域コード) 複合 PK が必要な理由。

演習 3：FK 制約のテスト

CREATE TABLE master (code TEXT PRIMARY KEY);
INSERT INTO master VALUES ('R13000'), ('R14000');
CREATE TABLE fact (
    code TEXT, val INTEGER,
    FOREIGN KEY (code) REFERENCES master(code)
);
INSERT INTO fact VALUES ('R13000', 100);  -- OK
INSERT INTO fact VALUES ('R99999', 200);  -- ❌ FK 違反

結果：master に存在しない code は INSERT 不可。 これが「参照整合性」。

🔧 SSDSE-B-2026 を「データウェアハウス」設計に

-- ディメンション 1: 都道府県
CREATE TABLE dim_prefecture (
    地域コード TEXT PRIMARY KEY,
    都道府県 TEXT NOT NULL UNIQUE,
    地方区分 TEXT NOT NULL,
    人口階級 TEXT  -- 'メトロポリス', '大都市', '中規模', '小規模'
);

-- ディメンション 2: 年度（時間軸）
CREATE TABLE dim_time (
    年度 INTEGER PRIMARY KEY,
    元号 TEXT,
    年代 TEXT,  -- '2010年代', '2020年代'
    主要イベント TEXT
);

-- ファクトテーブル
CREATE TABLE fact_population (
    年度 INTEGER NOT NULL,
    地域コード TEXT NOT NULL,
    総人口 INTEGER,
    出生数 INTEGER,
    死亡数 INTEGER,
    婚姻件数 INTEGER,
    離婚件数 INTEGER,
    PRIMARY KEY (年度, 地域コード),
    FOREIGN KEY (年度) REFERENCES dim_time(年度),
    FOREIGN KEY (地域コード) REFERENCES dim_prefecture(地域コード)
);
-- スタースキーマ：1 ファクト + 2 ディメンション
-- 集計クエリは fact_population を中心に dim_* と JOIN

📚 主キーと SSDSE-B-2026：実プロジェクト 5 つのシナリオ

1. 毎月の SSDSE 更新を冪等取込：PK で UPSERT、 重複排除自動化
2. 過去版との差分検出：PK で JOIN、 LEFT/RIGHT EXCEPT で変化抽出
3. 複数年データの時系列集計：PK の年度部分で GROUP BY
4. 都道府県マスタの分離：3NF 化で 47 行マスタ + 564 行事実テーブル
5. 地方ブロック・人口階級階層：ディメンション拡張、 多次元分析

🗺 概念マップ

主キー (Primary Key) を中心に、 上位概念 (RDB スキーマ設計・関係モデル)、 並列概念 (外部キー・候補キー・代理キー・複合キー)、 制約 (一意性 + 非 NULL + 不変性)、 応用 (JOIN・正規化・SSDSE-B の SSDSE-2026 列など) を関係づけて整理する。

主キー (primary key) はリレーショナルデータベースで「行を一意に特定する 1 列または列の組合せ」で、 NOT NULL かつ UNIQUE 制約が強制される。 SSDSE-B-2026 では「年度（CSV 1 行目の列名は SSDSE-B-2026）+ 地域コード」が複合主キーに相当し、 これによって「同じ都道府県の同じ年のレコードは 1 つだけ」が保証される。 自然キー (意味のある値)・代理キー (UUID/ULID/連番) のどちらを使うか、 クラスタリングインデックスとして物理配置を決めるかなどの設計判断が、 後の JOIN 性能・データ統合・落とし穴の発生確率に直結する。

🔗 隣接手法への橋渡し

主キーは「テーブル設計 → データ整合性 → 分析」の連鎖で中心的な役割を果たし、 隣接する DB 設計概念と密接に絡む。

• 上流（DB 設計）: ER 図 でエンティティを定義し、 正規化 でテーブルを分割する際、 各テーブルに必ず主キーを定める。 候補キーから 1 つ選んだものが主キーになる。
• 並列（同じ「一意性保証」）: UNIQUE 制約 は主キー以外の列にも一意性を要求 (NULL は許容)、 外部キー は別テーブルの主キーを参照する整合性の鎖、 複合キー は複数列で 1 つの主キーを構成する変種。
• 下流（分析と統合）: JOIN で複数テーブルを結合する際の連結軸、 pandas.merge の on= パラメータも主キー対応列を指定、 データ統合 で異なるシステム間の同一エンティティを突合する基準。

主キーが設計されていないテーブルは「重複行が混入する」「JOIN 結果が膨らむ」「集計値が二重計上される」という致命的な分析バグを生み、 SSDSE-B-2026 のような分析用データセットでも (都道府県, 年) の組が暗黙の主キーとして扱われている。

🌳 手法選択フロー

「主キー」を実際に使うとき、 何をどう選ぶかを順に判断する。 上から順に答えていくと、 使うべき手法と評価の仕方が決まる。

1. 1 列で行を一意に決められるか
   決められるなら単一キー。 SSDSE-B-2026 では地域コードの一意数が 47 しかなく、 564 行を識別できない。 決められないなら複合キーへ。
2. 複数列の組で一意になるか
   地域コード + 年度の 2 列なら、 組の一意数が 564 となり全行を識別できる（実測）。 組にしても重複が残るなら、 データの粒度の理解が間違っている。
3. 自然キーか、 代理キーか
   地域コードのように意味を持つ列は、 市町村合併などで値が変わりうる。 変更に弱いなら意味のない連番（代理キー）を立て、 自然キーには一意制約を付ける。 外部キーから参照する側も単純になる。
4. NULL を許すか
   主キーは NULL を取れない。 未確定の値がある列は主キーにできないので、 候補から外すか、 確定するまで代理キーで運用する。

SSDSE-B-2026 は 47 県 × 12 年度 = 564 行。 「地域コードが主キー」と決めつけると 1 県あたり 12 行が重複扱いになり、 結合で行数が 12 倍に膨らむ。

🖼️ 主キーの図解 — 3 枚で理解する

主キーの役割を 3 つの図で視覚化する。 SVG を base64 化したインライン画像で、 外部依存なしに表示される。

図 1 は地域マスターと人口サマリの主キー−外部キー関係、 図 2 は主キーが満たすべき 3 つの制約 (一意性・非NULL・不変性)、 図 3 は自然キー (pref_code, isbn 等) と代理キー (UUID, SEQ 等) のトレードオフを示す。

🎮 触って理解する — 主キー診断ラボ

下の架空のサンプル名簿（氏名・メール等はすべて作例）で、列見出しをタップ／クリックして主キー候補に指定してみてください。複数の列を選ぶと複合キーになります。選んだ瞬間に「一意性チェック（重複＝赤）」と「NULL チェック（オレンジ）」が走り、主キーとして妥当かが即座に判定されます。

一意性の判定式：選択キーの「異なり値の数」＝「行数」かつ NULL 数 ＝ 0 のとき合格。下の図は操作に合わせてリアルタイム更新されます。

🧭 遊び方のヒント（この順に試すと全パターン体験できます）

1. 氏名だけを選ぶ → 「佐藤 陽菜」が 2 人いて赤くハイライト。同姓同名で失格。
2. メール → 値自体は重複しないが NULL（未登録）が 1 件。NULL があれば主キー失格。
3. 生年月日 → 2005-11-03 生まれが 2 人。日付は簡単に衝突する。
4. 氏名＋生年月日の 2 列 → 単独では失格だった列も、組合せなら全行一意になり合格（複合キーの体験）。
5. ID → 単独で合格。これが代理キー（連番）。「行を追加」を何回押しても自動採番で衝突しない。
6. ID を主キーにした状態で「重複 ID=1 で追加」→ UNIQUE 制約エラーで弾かれ、衝突行が点滅。「ID なしで追加」→ NOT NULL 制約エラー。
7. 全解除してから「重複 ID=1 で追加」→ 誰も止めずに入ってしまう。主キーが無いテーブルの危うさを体感。

💡 直感 — 主キーは「背番号」

主キーは行を一意に特定する背番号です。名前で選手を呼ぶと同姓同名で混乱しますが、背番号で呼べば必ず 1 人に届く。上のデモで「氏名」が赤くなるのはまさにこの混乱で、データベースは「どちらの佐藤 陽菜さんですか？」に答えられなくなります。さらに背番号は空欄不可（NULL は「不明」を意味し、不明どうしは等しいとも等しくないとも言えないため比較が破綻する）、シーズン途中で変えない（不変性）——この 3 点セットが主キーの要件です。

⚠️ よくある落とし穴 — デモで起きたことの一般化

• 「今たまたま一意」を「主キーにできる」と誤解する：デモの初期 5 行では「メール（NULL を除けば）」も一意に見えますが、一意性は将来の挿入も含めて保証すべき性質。行を追加していくと自然キーはいつか衝突します。
• 自然キーの変化：メールアドレスは機種変更・卒業で変わり、氏名は改姓で変わります。主キーが変わると、それを参照する全テーブルの外部キーを更新する大工事に。
• 氏名・日付をキーにする危険：同姓同名（デモの佐藤 陽菜）や同一生年月日（デモの 2005-11-03）は現実に高頻度で発生。氏名は表記揺れ（全角/半角スペース、旧字体）でも別値扱いになり、結合ズレの温床になります。
• NULL の見落とし：UNIQUE 制約は NULL を複数許す実装が多い（SQL 標準では NULL どうしは「等しい」と判定されない）ため、「UNIQUE だから主キーにできる」は誤り。主キーは UNIQUE ＋ NOT NULL の両方が必要です（欠損値も参照）。

🚀 発展 — 複合キー・代理キー・外部キーとのつながり

• 複合キー：デモの「氏名＋生年月日」のように、単独では一意にならない列も組合せで一意になれます。本ページで扱った SSDSE-B-2026 の (年度, 地域コード)（47 都道府県 × 2012〜2023 年の 12 年 = 564 行）が実データでの典型例。ただし列が増えるほど外部キー側も複合になり JOIN が複雑化します（テーブル結合）。
• 代理キー vs 自然キー：デモの ID 列のようにシステムが採番する連番/UUID が代理キー。値に意味が無いからこそ変更理由が発生せず安定します。自然キー（メール、マイナンバー、ISBN）は人間に読みやすい反面、変更・再利用・桁数改定のリスクを抱えます。実務では「代理キーを主キーに、自然キーには UNIQUE 制約を」が定石。
• 外部キーとの関係：主キーは外部キーから参照されることで初めてリレーショナル DB（RDB）の力を発揮します。参照整合性（存在しない主キー値を指す外部キーを拒否する仕組み、完全性）の土台であり、テーブル設計全体は ER 図で俯瞰できます。主キー制約の宣言方法は DDL（CREATE TABLE の PRIMARY KEY 句）を参照してください。

🔎 解説深化 — 「たまたま一意」と「設計上一意」を実データで見分ける

ここまでのセクションで主キーの 3 要件（一意・非 NULL・不変）と複合キー (年度, 地域コード) の設計を学びました。 この深化セクションでは一歩進めて、 「観測された一意性」と「設計として保証された一意性」はまったく別物であることを、 SSDSE-B-2026 の実測値で定量的に確かめます。 これは上の診断ラボ（架空名簿）で体験した「今たまたま一意」問題の、 実データ版・統計版です。

💡 直感 — 一意性は「観測」ではなく「約束」

SSDSE-B-2026 の 2023 年断面（47 都道府県 = 47 行）で、 年度・地域コード・都道府県名を除く数値 109 列それぞれの「異なり値の数」を数えると、 実に 74 列（約 67.9%）が nunique = 47、 つまりその瞬間だけ見れば全行一意です。 総人口（A1101）も 47 通りで完全に一意。 では「総人口を主キーにできる」でしょうか？

答えは No。 断面を 2012〜2023 年の全パネル 564 行に広げると、 総人口の異なり値は 520 に減り、 44 行が他の行と値を共有します。 実際の衝突例（すべて実測）：

• 2023 年の福井県と2017 年の徳島県：どちらも総人口 744,000 人。 県も年も違うのに値が同じ。
• 2023 年の秋田県と2021 年の和歌山県：どちらも 914,000 人。
• 滋賀県は 2012・2014・2016・2017・2018 年の 5 か年が同じ 1,414,000 人（千人単位への丸めの影響）。 沖縄県も 2021〜2023 年の 3 か年が 1,468,000 人で並びます。

主要列の「断面 vs パネル」一意性を並べると、 観測一意性がいかに脆いかが分かります：

つまり主キーとは「手元のデータで重複が無かった」という観測報告ではなく、 「将来追加される行も含めて、 DB が衝突を拒否し続ける」という約束（制約）です。 観測はいくらでも裏切られますが、 約束はスキーマが守ります。

⚠️ 落とし穴（重要）

• 「nunique == 行数」検査の合格をキー認定と混同する：df['A1101'].nunique() == len(df) は 2023 年断面なら True です。 しかしこの検査は一意性の必要条件を確認しただけで、 十分条件ではありません。 翌年分を concat した瞬間に崩壊し得ます（実際、 総人口は 564 行に広げると 44 行が衝突）。 キーの資格は「その列の値が何を識別する意図で振られたか」という意味論で決めるべきものです。
• 丸められた統計値は衝突しやすい：SSDSE-B の総人口は千人単位に丸められているため、 滋賀県のように 5 か年連続同値が起こります。 合計特殊出生率（小数 2 桁）に至っては 2023 年の 47 都道府県で 31 種類しか値が無く、 埼玉県と千葉県が 1.14、 栃木県と大阪府が 1.19 で衝突。 有効桁が少ない列ほど「値の空間 N」が小さくなり衝突確率が跳ね上がる—— これは上の計算例セクションで見た誕生日問題と同じ構造です。 「測定値・集計値は原理的にキーになれない」と覚えてください。
• 逆パターン：本物のキーが重複して見えたらデータ汚染を疑う：df.duplicated(subset=['SSDSE-B-2026','Code']).sum() は現在の SSDSE-B-2026 で 0（実測）。 もしこれが 0 でなくなったら、 それはキー設計の誤りではなく二重ロードや結合ミスの検出器が鳴ったということです。 pandas には SQL の PRIMARY KEY 制約が無いので、 set_index([...], verify_integrity=True) や merge(..., validate='one_to_one') を ETL の各段に置いて、 約束を手動で検査し続ける必要があります。

🚀 発展 — キー発見（key discovery）という研究分野

「ドキュメントの無い未知のテーブルから候補キーを自動で見つける」問題は、 データプロファイリング研究でキー発見・関数従属発見と呼ばれる一分野です（代表的アルゴリズムに TANE や HyFD）。 列の組合せは $2^{n}$ 通りに爆発するため、 単独列 → 2 列 → 3 列と段階的に持ち上げる格子（lattice）探索と枝刈りが使われます。 SSDSE-B-2026 は 112 列なので全探索は $2^{112}$ 通り—— 現実には「一意率 = nunique / 行数」が高い列から優先的に組合せる、 という発想が要になります（実測：Code の一意率は 47/564 ≈ 0.083、 (年度, Code) で 1.0 に到達）。

もう 1 つの発展は「不変のはずのキーが変わる」問題です。 都道府県コードは長期に安定した良質な自然キーですが、 市町村コードは平成の大合併期に大量に改番されました。 時系列データでキーの対応関係そのものが変化する場合の管理手法は、 データウェアハウス分野で Slowly Changing Dimension（SCD）として体系化されています。 「主キーの不変性」は無料で手に入る性質ではなく、 コード表の版管理という運用努力の産物です。

🔗 関連ページ

• 外部キー — 主キーを参照して参照整合性を築く相方。 完全性とセットで。
• テーブル結合 — 「キーの一意性検査（validate 引数）」が最も効く実践の場。
• パネルデータ — 本ページの (年度, 地域コード) 複合キーはパネルデータ構造そのもの。
• 欠損値 — NULL がキーに混ざるとなぜ破綻するかの背景。
• RDB / DDL — 約束（制約）をスキーマとして宣言する仕組み。
• メタデータ — 「どの列がキーか」を文書化するデータ辞書の考え方。