🎨 直感で掴む

データを「分析・モデリングに使える形に整える」工程。 分析の質はここで 8 割決まります。

本ページでは ER図 を、 定義・前提条件・使い方・落とし穴の順に整理して解説します。 厳密な定義より、 まず何を、 いつ、 どう使うかを理解することを優先してください。

📐 定義

エンティティと関係を表す設計図

英語名 Entity-Relationship Diagram。

🎯 いつ・どこで使うか

• 「データエンジニアリング」分野の標準的な道具として、 多くの分析で登場します。
• 📚 データエンジニアリング を学ぶときに必ず通過する基本概念です。
• 論文・実務レポートで頻出する用語なので、 1 度はちゃんと理解しておくと後が楽です。

📋 前提条件・適用範囲

この用語を理解・使用するときは、 次のような前提を意識してください：

• データの性質：尺度（名義/順序/間隔/比例）と分布を確認
• サンプル数：手法によって最低限のサンプル数が異なります
• 独立性：観測が独立であるかを確認（時系列・パネル等では別の手法が必要）
• 欠損・外れ値：前処理の方針を明確に

⚠️ よくある落とし穴

🐍 Python での扱い

SSDSE-B-2026 のような公的統計データを Python で扱う際の基本パターン：

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

import pandas as pd
import numpy as np

# データ読み込み
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='utf-8', skiprows=1)
print(df.shape)
print(df.dtypes)
print(df.describe())

# 「ER図」の文脈で扱う場合の例：
# 分野: データエンジニアリング
# 関連手法は同カテゴリの他用語を参照してください。

具体的なコードは データエンジニアリング を参照してください。

📝 レポートでの報告

分析結果を報告するときに含めるべき情報：

• 使ったデータ：出典・期間・サンプル数
• 適用条件の確認：前提が満たされているか
• 計算結果：数値だけでなく不確実性（CI・SE）も
• 解釈：何を意味するか、 何を意味しないか
• 限界：適用範囲外への拡張は避ける

✅ チェックリスト

• □ 「ER図」を使う場面か再確認したか
• □ データの尺度・分布・サンプル数を確認したか
• □ 前提条件を満たしているか
• □ 計算した値だけでなく不確実性も把握したか
• □ 解釈と限界を区別したか
• □ 関連グループ教材で全体像を確認したか

📚 関連グループ教材

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

• 📚 データエンジニアリング — このカテゴリの全体像を学ぶ
• 📚 データリテラシー — このカテゴリの全体像を学ぶ

🔗 同カテゴリの他用語

🧮 SSDSE-B-2026 を ER 図でモデル化する

SSDSE-B-2026 は都道府県×年度の長形式パネルデータ。 これを ER 図化すると次のような構造：

[Prefecture]                [Year]
   PK: code        ←──→     PK: year
   prefecture_jp
        │
        │  1:N
        ↓
[Statistics]
   FK: code (Prefecture.code)
   FK: year (Year.year)
   PK: (code, year)
   total_population
   aged_population
   births
   deaths
   migration_in
   ...
   consumption_total

「都道府県マスタ」「年度マスタ」「統計値ファクトテーブル」の 3 テーブル構成にすると、 後で都道府県名の表記揺れ（旧字体・略称）に対応しやすい。

SSDSE-B-2026 は1NF（第一正規形）でほぼ平坦だが、 都道府県名と年度は冗長。 3NF 化するとリレーショナルDB として保守性が上がる。

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

# SSDSE-B-2026 を 3NF に分解する
import pandas as pd
import sqlite3

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=1)
pref = df[['地域コード','都道府県']].drop_duplicates().rename(
    columns={'地域コード':'code','都道府県':'name'})
year = pd.DataFrame({'year': sorted(df['年度'].unique())})
stat = df[['年度','地域コード','総人口','65歳以上人口','出生数','死亡数']].rename(
    columns={'年度':'year','地域コード':'code'})

con = sqlite3.connect(':memory:')
pref.to_sql('Prefecture', con, index=False)
year.to_sql('Year',       con, index=False)
stat.to_sql('Statistics', con, index=False)

# 結合クエリ（ER関係に沿った JOIN）
q = '''SELECT p.name, s.year, s.総人口, s.65歳以上人口
       FROM Statistics s
       JOIN Prefecture p ON s.code=p.code
       WHERE s.year=2023 ORDER BY s.総人口 DESC LIMIT 5'''
print(pd.read_sql(q, con))

🔬 ER 図の表記法と最適化

3 つの主要記法

正規化の段階

• 1NF：繰り返し列を排除 — 「電話番号1,2,3」を別テーブルへ
• 2NF：部分関数従属を排除 — 複合主キーの一部だけに依存する列を分離
• 3NF：推移的関数従属を排除 — 「都道府県→地方」のような派生属性を別テーブルへ
• BCNF：候補キー以外への関数従属を排除

SSDSE-B-2026 を 3NF 化すると、 47 都道府県 × 12 年 = 564 行のファクトテーブルになり、 集計クエリの保守が圧倒的に楽になる。

スター・スキーマ vs スノーフレーク

分析用 DWH では、 3NF まで正規化せずスター・スキーマ（ファクト＋ディメンション）が一般的。 SSDSE-B-2026 を BI 連携するなら、 1 ファクトテーブル＋ 都道府県／年度／指標カテゴリの 3 ディメンションで構成すると BigQuery／Snowflake で高速。

⚠️ ER 設計の落とし穴

🔗 関連用語（拡張）