🔖 キーワード索引

この用語ページの主要トピックを一覧から飛べます。

🎨 直感で掴む

ER 図を 「組織図」と「家系図」の合体と例えると分かりやすい。 組織図は「箱」と「線」で組織構造を表す。 ER 図は「エンティティ（箱）」と「リレーションシップ（線）」でデータ構造を表す。

🎬 ストーリー：図書館システムを設計する

図書館の業務を IT 化する。 ヒアリングしたら：

• 会員が本を借りる
• 本には著者がいる
• 会員はカテゴリ別に好みがある
• 本にはジャンルがある

これを ER 図にすると：

[会員] --借りる(0..*)-- [貸出記録] --(*..1)-- [本] --書いた(*..*)-- [著者]
                                              |
                                              -属する(*..1)- [ジャンル]
    

これだけ描けば、 「会員テーブル」「本テーブル」「貸出記録テーブル」「著者テーブル」「ジャンルテーブル」と、 多対多を解消する「著者本テーブル（関連テーブル）」が必要、 と一目で分かる。

🎨 視覚的比喩：「立体パズル」

ER 図は 立体パズルの設計図。 各エンティティはパーツ、 リレーションシップは「どう組み合わさるか」。 設計図なしに作ると、 後で「ピースが合わない」事態に。 描いてから組むのが鉄則。

🌐 ER 図が活きる 4 つの場面

1. 新規 DB 設計：白紙からテーブル構造を考える。
2. 既存 DB のリバースエンジニアリング：レガシーシステムの構造を可視化。
3. ステークホルダー間のコミュニケーション：非エンジニアにも理解しやすい。
4. ドキュメント：DB 構造の継続的な記録、 新人教育。

🔍 SSDSE-B-2026 を ER 図で表現してみる

SSDSE-B-2026 は 1 つの大きな CSV ですが、 これを RDB に格納するなら：

[Prefecture] --(1..*)-- [YearlyStat] --属する(*..1)-- [Category]
   |                       |
   都道府県名               年度
   地域コード              人口・出生数・etc.
    

この設計だと、 1 県あたり 1 行ではなく「県 × 年度」で複数行になり、 経年変化を見やすい形に正規化される。 ER 図がなければこの判断は出てこない。

🎨 概念図で押さえる

ER 図はエンティティ（実体）と関係（リレーションシップ）を視覚化する。 ここでは「カーディナリティ・3 種類のリレーション・正規化までの流れ」を概念図で確認する。

🎨 R282 補強: ER 図の実装デモ

「ER 図 → 正規化 → CREATE TABLE → INSERT → 結合クエリ」までを SSDSE-B-2026 で一気通貫で示す。 ER 図は「絵」のままだと半分の理解しかない。

1. SQLite で DDL を発行

このコードでやること： 都道府県マスタ、 年度マスタ、 統計値テーブルを正規化して作成。 PK / FK 制約を全て明示する。

 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

import sqlite3

con = sqlite3.connect(':memory:')
con.executescript("""
CREATE TABLE pref (
  pref_code TEXT PRIMARY KEY,
  pref_name TEXT NOT NULL UNIQUE,
  region    TEXT
);
CREATE TABLE year (
  year INTEGER PRIMARY KEY
);
CREATE TABLE stat (
  pref_code TEXT NOT NULL,
  year      INTEGER NOT NULL,
  pop_total INTEGER,
  deaths    INTEGER,
  PRIMARY KEY (pref_code, year),
  FOREIGN KEY (pref_code) REFERENCES pref(pref_code),
  FOREIGN KEY (year)      REFERENCES year(year)
);
""")
print('テーブル作成完了')
for row in con.execute("SELECT name FROM sqlite_master WHERE type='table'"):
    print(' -', row[0])

💬 3 つのテーブルが ER 図通りに作成された。 PK 複合キー（pref_code, year）が stat に効く。

2. SSDSE-B-2026 から INSERT

このコードでやること： CSV を読み、 正規化された 3 テーブルに分割投入する。

 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

import pandas as pd

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', header=0)
# 2 行目の日本語名の行を落とし、都道府県コードの行だけ残す
df = df[df['Code'].astype(str).str.match(r'^R\d{5}$', na=False)].copy()
# 都道府県コードは 'Code' 列。'SSDSE-B-2026' 列は年度
df = df.rename(columns={'Code': 'pref_code', 'Prefecture': 'pref_name'})
df['SSDSE-B-2026'] = pd.to_numeric(df['SSDSE-B-2026'], errors='coerce')
for _c in ['A1101', 'A4200']:
    df[_c] = pd.to_numeric(df[_c], errors='coerce')

# pref マスタ
pref = df[['pref_code', 'pref_name']].drop_duplicates()
pref['region'] = pref['pref_name'].map({'北海道':'北海道', '青森県':'東北'}).fillna('その他')
pref.to_sql('pref', con, if_exists='append', index=False)

# year マスタ
year = pd.DataFrame({'year': sorted(df['SSDSE-B-2026'].unique())})
year.to_sql('year', con, if_exists='append', index=False)

# stat 事実テーブル
stat = df[['pref_code', 'SSDSE-B-2026', 'A1101', 'A4200']].rename(
    columns={'SSDSE-B-2026':'year','A1101':'pop_total','A4200':'deaths'})
stat.to_sql('stat', con, if_exists='append', index=False)

print(f'pref: {con.execute("SELECT COUNT(*) FROM pref").fetchone()[0]} rows')
print(f'year: {con.execute("SELECT COUNT(*) FROM year").fetchone()[0]} rows')
print(f'stat: {con.execute("SELECT COUNT(*) FROM stat").fetchone()[0]} rows')

💬 47 都道府県 × 12 年度 = 564 行が事実テーブルに入り、 ER 図の関係が物理化された。

3. 結合クエリで ER 図の威力を確認

このコードでやること： pref と stat を JOIN し、 2023 年の死亡率 TOP5 を取得する。

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

q = """
SELECT p.pref_name,
       s.pop_total,
       s.deaths,
       ROUND(1000.0 * s.deaths / s.pop_total, 2) AS death_rate_permille
FROM stat s
JOIN pref p ON s.pref_code = p.pref_code
WHERE s.year = 2023
ORDER BY death_rate_permille DESC
LIMIT 5
"""
print(pd.read_sql(q, con))

💬 FK で結合した結果、 「県名 + 統計値」が 1 行に揃う。 これが ER 図 → 正規化の核心。

4. ER 図の妥当性検証

このコードでやること： 参照整合性違反を意図的に発生させ、 FK 制約が効くことを確認。

1
2
3
4
5
6

con.execute('PRAGMA foreign_keys = ON')
try:
    con.execute("INSERT INTO stat VALUES ('R99999', 2023, 1000, 50)")
    print('NG: 制約違反が許された')
except sqlite3.IntegrityError as e:
    print(f'OK: 参照整合性違反を検知 → {e}')

💬 ER 図に基づく FK 制約が物理レイヤで正しく効いている。 これがあれば「存在しない県コード」が紛れ込まない。

🎮 触って学ぶ：カーディナリティと連関テーブル

教材の定番例「学生・科目・成績」で、 リレーション「履修」の 多重度（カーディナリティ）を 1:1 / 1:N / N:M に切り替えると、 クロウフット（鳥の足, IE 記法）の記号と「意味」がどう変わるかを体感する。 実体（エンティティ）＝長方形、 関連＝線＋多重度記号で描く。 N:M は直接テーブル化できないので、 ボタンで 連関（中間）テーブル「履修」へ分解できる。 主キー（PK）・外部キー（FK）のハイライトで対応を確認しよう。

📐 数式または定義

ER 図には「数式」よりも「記法の規則」があります。 主要記法を整理。

1. Chen 記法（オリジナル、 1976）

• エンティティ＝四角形
• 属性＝楕円（エンティティから線で接続）
• リレーションシップ＝菱形
• 多重度＝線の上に「1」「N」「M:N」を書く

2. IE 記法（クロウフット、 現代主流）

• エンティティ＝四角形（属性も中に列挙）
• リレーションシップ＝線
• 多重度＝クロウフット（鳥の足）記号
• 「1 と必須」＝│、 「0 または 1」＝○│、 「1 以上」＝│Ϟ、 「0 以上」＝○Ϟ

3. 多重度（カーディナリティ）の表記

4. 主キーと外部キー

• 主キー (PK)：エンティティ内で一意に識別する属性。 下線または「PK」マーク。
• 外部キー (FK)：他エンティティの PK を参照する属性。 「FK」マーク。
• 複合主キー：複数属性で 1 つの PK。 関連テーブルで頻出。

5. 弱エンティティ

親エンティティに依存し、 単独では存在できない。 二重線の四角で表記。 例：「貸出記録」は「会員」と「本」がないと存在しない（が、 これは関連テーブルで表現するのが現代的）。

6. 多重度の決定式

2 つのエンティティ A, B の関係多重度は、 4 つの問いで決まる：

1. 1 つの A に対し、 B は最小何個？（0 or 1）
2. 1 つの A に対し、 B は最大何個？（1 or 多）
3. 1 つの B に対し、 A は最小何個？（0 or 1）
4. 1 つの B に対し、 A は最大何個？（1 or 多）

🔬 数式を言葉で読み解く

🔬 数式・定義を「言葉」で読み解く

「ER 図」は単なる絵ではなく、 厳密な意味を持つ記号体系です。 1 つ 1 つを正確に理解しないと、 後の DB 設計で破綻します。

1. 🎯 「エンティティ」とは何か

エンティティ（Entity）は、 業務上識別できる「もの」「人」「事象」を指します。 「会員」「本」「貸出記録」など。 物理的なものに限らず、 「予約」「契約」「イベント」のような抽象概念も含む。 ポイントは「同じ種類の複数の実体（インスタンス）」を抱える「型」であること。

2. 📥 「属性」とは何か

• 単純属性：1 つの値しか持たない。 例：会員 ID、 名前。
• 複合属性：複数の値からなる。 例：住所＝市＋通り＋郵便番号。
• 多値属性：複数の値を持てる。 例：電話番号（複数登録可）。 → これは別エンティティに切り出す。
• 派生属性：他の属性から計算可能。 例：年齢＝生年月日から計算。 通常は格納せず、 SELECT 時に計算。
• キー属性：主キー候補。 一意性が必要。

3. 🧠 「リレーションシップ」と多重度

リレーションシップ（Relationship）は、 エンティティ間の 「関係」を表します。 動詞で命名するのが定石（「借りる」「所属する」「書く」）。 重要なのは 多重度（cardinality）：

• 1 対 1（1:1）：会員 ─ 会員カード（1 人 1 枚）
• 1 対 多（1:N）：部署 ─ 社員（1 部署に N 人）
• 多対多（M:N）：学生 ─ 講義（学生は複数履修、 講義は複数受講者）。 → 関連テーブルで解消するのが現代的。

4. 🔍 「関連テーブル」の重要性

多対多関係を物理 DB に落とすには、 関連テーブル（associative entity, junction table）が必須です。 例：「学生 ─ 履修 ─ 講義」と、 中間に履修テーブルを作る。 履修テーブルの PK は (学生 ID, 講義 ID) の複合主キー。 さらに「履修日」「成績」などの履修固有の属性をそこに置く。 これを ER 図上で「履修」エンティティとして明示的に描くのが論理設計のポイント。

5. 💬 「概念モデル → 論理モデル → 物理モデル」の三段階

• 概念モデル：業務世界のエンティティ・関係を素直に描く。 ステークホルダーとの会話用。 多対多 OK。
• 論理モデル：RDB に格納する形に変換。 多対多は関連テーブルで解消。 正規化（第 1〜3 正規形）を適用。 PK/FK を明示。 DB 製品中立。
• 物理モデル：特定 DB（PostgreSQL、 MySQL、 Oracle）に最適化。 データ型、 インデックス、 制約、 パーティション、 物理ストレージを定義。

6. 📚 正規化との連携

ER 図を描いた後、 各エンティティに対し 正規化を適用：

• 第 1 正規形 (1NF)：属性は単一値（多値属性は別テーブル）
• 第 2 正規形 (2NF)：1NF + 部分関数従属の除去（複合 PK の一部にしか依存しない属性を分離）
• 第 3 正規形 (3NF)：2NF + 推移的関数従属の除去（非 PK 属性間の従属を分離）
• BCNF、 4NF、 5NF：さらに高度な正規化。 実務では 3NF までが多い。

7. 🎨 非正規化（denormalization）の判断

読み取り性能のために、 あえて正規形を崩すことがあります（非正規化）。 「同じデータが複数箇所にコピーされる」リスクと、 「JOIN なしで読める」メリットのバランス。 DWH や OLAP では非正規化が定石（スタースキーマ、 スノーフレーク）。

🧮 実値で計算してみる — SSDSE-B-2026

SSDSE-B-2026 を RDB に格納するための ER 図設計を具体的に行います。

1. 元データの形

SSDSE-B-2026 は CSV 1 枚で、 行＝年度×都道府県（47 県 ×1 年 = 47 行）、 列＝112 個の指標（人口、 出生数、 病院数、 etc.）。 これを「1 テーブル」で持つのは正規化的に NG。

2. 概念モデル

[Prefecture] --(1..*)-- [YearlyStat] --(*..1)-- [Year]
                            |
                       多くの数値属性
    

3. 論理モデル — テーブル分割案 A（属性をワイドのまま）

• prefectures (pref_code PK, pref_name, region)
• yearly_stats (id PK, pref_code FK, year, A1101_pop, A1303_elderly, B4101_temp, ...)

4. 論理モデル — テーブル分割案 B（縦持ち、 EAV）

• prefectures (pref_code PK, pref_name)
• indicators (indicator_code PK, name, unit, description)
• observations (id PK, pref_code FK, year, indicator_code FK, value)

案 B は「指標が増えてもテーブル構造を変えずに済む」柔軟性が高いが、 SELECT に JOIN が必要で複雑。 案 A は単純だが列数が爆発する。

5. 物理モデル（PostgreSQL）

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

CREATE TABLE prefectures (
  pref_code  CHAR(6)      PRIMARY KEY,
  pref_name  VARCHAR(20)  NOT NULL,
  region     VARCHAR(20)
);

CREATE TABLE indicators (
  indicator_code VARCHAR(10) PRIMARY KEY,
  name           VARCHAR(100),
  unit           VARCHAR(20),
  description    TEXT
);

CREATE TABLE observations (
  id            BIGSERIAL  PRIMARY KEY,
  pref_code     CHAR(6)    REFERENCES prefectures(pref_code),
  year          SMALLINT,
  indicator_code VARCHAR(10) REFERENCES indicators(indicator_code),
  value         DOUBLE PRECISION,
  UNIQUE (pref_code, year, indicator_code)
);

CREATE INDEX idx_obs_pref_year ON observations(pref_code, year);
CREATE INDEX idx_obs_indicator ON observations(indicator_code);

6. 多重度の検証

• prefectures (1) ─ (N) observations: 1 県に複数観測値、 1 観測値は 1 県 → 多重度 OK
• indicators (1) ─ (N) observations: 1 指標に複数観測、 1 観測は 1 指標 → 多重度 OK
• observations の (pref_code, year, indicator_code) は一意 → UNIQUE 制約で保証

7. クエリ例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

-- 47 都道府県の 2023 年高齢化率トップ 10
SELECT
  p.pref_name,
  obs.value AS aging_rate
FROM observations obs
JOIN prefectures p ON obs.pref_code = p.pref_code
WHERE obs.indicator_code = 'AGING_RATE'
  AND obs.year = 2023
ORDER BY obs.value DESC
LIMIT 10;

8. 元 CSV の縦持ち化スクリプト

 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])

# wide → long
indicators = ['A1101', 'A1303', 'B4101', 'F3101', 'I510120']
long_df = df.melt(
    id_vars=['SSDSE-B-2026', 'Code', 'Prefecture'],
    value_vars=indicators,
    var_name='indicator_code',
    value_name='value'
)
long_df.rename(columns={'SSDSE-B-2026': 'year', 'Code': 'pref_code'}, inplace=True)
long_df.to_csv('observations.csv', index=False)
print(long_df.head())
print(f'rows: {len(long_df)}')

9. インデックス設計

「県別＋年度」検索が多いなら (pref_code, year) の複合インデックス。 「指標別」検索なら (indicator_code) 単独インデックス。 全部にインデックスを張ると INSERT が遅くなる。 トレードオフ。

10. 拡張性

将来 SSDSE-B-2027, 2028 が出ても、 observations テーブルに INSERT するだけで済む。 これが 正規化された ER 設計の強み。

🧮 数式に値を入れて手で計算する: 多対多解消で増える表数

合成データで n×m 関係を中間表で正規化する場合のテーブル数を計算する。

Step 1: 元のエンティティ

Step 2: 合計

🐍 Python で再現

1
2
3
4
5
6
7

n_relations = 4
entities = 2 * n_relations
junction = n_relations
total = entities + junction
print(f"エンティティ: {entities}")
print(f"中間表: {junction}")
print(f"合計表数: {total}")

📤 実行結果

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

🐍 Python 実装

① SQLAlchemy で ER モデルを Python クラスで定義

 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

from sqlalchemy import create_engine, Column, String, Integer, Float, ForeignKey
from sqlalchemy.orm import declarative_base, relationship

Base = declarative_base()

class Prefecture(Base):
    __tablename__ = 'prefectures'
    pref_code = Column(String(6), primary_key=True)
    pref_name = Column(String(20), nullable=False)
    region = Column(String(20))
    observations = relationship('Observation', back_populates='prefecture')

class Indicator(Base):
    __tablename__ = 'indicators'
    indicator_code = Column(String(10), primary_key=True)
    name = Column(String(100))
    unit = Column(String(20))
    observations = relationship('Observation', back_populates='indicator')

class Observation(Base):
    __tablename__ = 'observations'
    id = Column(Integer, primary_key=True, autoincrement=True)
    pref_code = Column(String(6), ForeignKey('prefectures.pref_code'))
    year = Column(Integer)
    indicator_code = Column(String(10), ForeignKey('indicators.indicator_code'))
    value = Column(Float)
    prefecture = relationship('Prefecture', back_populates='observations')
    indicator = relationship('Indicator', back_populates='observations')

engine = create_engine('postgresql://user:pass@localhost/ssdse')
Base.metadata.create_all(engine)

② pgAdmin / DBeaver でリバースエンジニアリング

1
2
3
4
5
6
7
8

# pgAdmin の手順（GUI 操作）:
# 1. 対象 DB に接続
# 2. Schema → Right click → Generate ERD
# 3. PDF / PNG で保存

# CLI 版（schemaspy）:
# java -jar schemaspy.jar -dp postgresql.jar -t pgsql \
#   -host localhost -db ssdse -u user -p pass -o ./erd_out

③ Mermaid でテキストから ER 図を描く

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

erDiagram
    PREFECTURE ||--o{ OBSERVATION : has
    INDICATOR ||--o{ OBSERVATION : measured
    PREFECTURE {
        string pref_code PK
        string pref_name
        string region
    }
    INDICATOR {
        string indicator_code PK
        string name
        string unit
    }
    OBSERVATION {
        int id PK
        string pref_code FK
        int year
        string indicator_code FK
        float value
    }

④ DrawIO で対話的に ER 図を描く

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

<!-- drawio はテキストベースの XML を内部で持つ -->
<mxfile>
  <diagram>
    <mxGraphModel>
      <root>
        <mxCell vertex="1" value="Prefecture\npref_code (PK)\npref_name\nregion"/>
        <mxCell vertex="1" value="Observation\nid (PK)\npref_code (FK)\nyear\nvalue"/>
      </root>
    </mxGraphModel>
  </diagram>
</mxfile>

⑤ Alembic で ER モデル変更のマイグレーション

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

# alembic init alembic
# 設定ファイル env.py に Base.metadata を登録

# モデル変更後:
# alembic revision --autogenerate -m "add region column"
# alembic upgrade head

# 出力例（versions/abc123_add_region.py）:
def upgrade():
    op.add_column('prefectures',
        sa.Column('region', sa.String(length=20)))

def downgrade():
    op.drop_column('prefectures', 'region')

⑥ Mermaid + 自動 PR チェック（CI 統合）

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

name: ERD Render
on:
  pull_request:
    paths: ['docs/erd.md']
jobs:
  render:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: neenjaw/compass-mermaid-action@v1
        with:
          mermaid-files: docs/erd.md
      - run: |
          gh pr comment ${{ github.event.pull_request.number }} \
            --body "Updated ER diagram → $ARTIFACT_URL"

⚠️ 落とし穴 — よくある失敗 5 件

🌐 関連手法・派生

• 正規化：第 1〜5 正規形。 ER 図の論理化に必須。
• 主キー / 外部キー：主キー / 外部キー
• テーブル設計：テーブル
• SQL：SQL
• データベース：データベース
• RDB / RDBMS：RDB
• NoSQL：NoSQL
• UML クラス図：ER 図と類似だが OOP 寄り。
• データウェアハウス：スタースキーマ、 スノーフレーク。
• ER ツール：DrawIO、 dbdiagram.io、 Lucidchart、 Visual Paradigm。

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

📚 関連グループ教材

• 📚 データエンジニアリング — ER 図を含む DB 設計全般
• 📚 データリテラシー — データ理解の基礎

📖 用語辞典 10 語 — この分野の必須語彙

エンティティ

業務上識別できる「もの」「人」「事象」。 テーブルの素。

属性

エンティティが持つ性質。 カラムの素。

リレーションシップ

エンティティ間の関係。 外部キーで実装。

主キー (PK)

エンティティを一意識別する属性。

外部キー (FK)

他エンティティの PK を参照する属性。

多重度

関係の最小・最大個数。 1:1, 1:N, M:N。

関連テーブル

多対多を解消する中間テーブル。

弱エンティティ

親に依存し単独で存在しないエンティティ。

正規化

データ冗長性を排除する設計手法。

非正規化

読み取り性能のために正規形を崩す。

📚 参考文献・規格・ドキュメント

1. Chen, P.P. (1976) The Entity-Relationship Model — Toward a Unified View of Data, ACM TODS, 1(1): 9-36.
2. Codd, E.F. (1970) A Relational Model of Data for Large Shared Data Banks, CACM, 13(6): 377-387.
3. ミック (2012) 『達人に学ぶDB設計徹底指南書』翔泳社.
4. Karwin, B. (2010) SQL Antipatterns, Pragmatic Bookshelf.
5. Kent, W. (1983) A Simple Guide to Five Normal Forms, CACM, 26(2): 120-125.
6. Kimball, R. (2013) The Data Warehouse Toolkit, 3rd ed., Wiley.
7. 増永良文 (2017)『リレーショナルデータベース入門』第 3 版, サイエンス社.

🗺 概念マップ

ER 図を中心とした概念ツリー：

データモデリング
├─ 概念モデリング
│  ├─ ER 図 (ERD)  ← この用語
│  │  ├─ Chen 記法
│  │  ├─ IE 記法 (Crow's Foot)
│  │  ├─ Barker 記法
│  │  └─ IDEF1X
│  ├─ UML クラス図
│  └─ ファクト指向モデリング (ORM)
├─ 論理モデリング (正規化)
└─ 物理モデリング (DBMS 固有)

派生・関連：
├─ ディメンショナルモデリング (DWH)
│  ├─ スタースキーマ
│  └─ スノーフレークスキーマ
├─ Data Vault モデリング
├─ NoSQL 設計パターン
│  ├─ ドキュメント (MongoDB)
│  ├─ KVS (Redis, DynamoDB)
│  ├─ カラムストア (Cassandra)
│  └─ グラフ (Neo4j)
└─ Event Sourcing

📜 歴史と系譜

ER 図の歴史を整理。

1. 1970: コッドのリレーショナルモデル

エドガー・F・コッドが「A Relational Model of Data for Large Shared Data Banks」を発表。 リレーショナルデータベースの理論的基盤を確立。

2. 1976: チェンの ER モデル

Peter Chen が論文「The Entity-Relationship Model — Toward a Unified View of Data」を発表。 「エンティティ」「リレーションシップ」「属性」の 3 要素で DB 構造を表現する手法を提唱。 ER 図の誕生。

3. 1981: IE 記法（クロウフット）

James Martin の Information Engineering で「クロウフット（鳥の足）」記法が普及。 Chen 記法より省スペースで読みやすく、 現代の主流に。

4. 1985: SQL 標準化

ANSI SQL 標準化。 ER 図から SQL DDL への変換が体系化される。 ER 図 → CREATE TABLE 文 の機械的変換が可能に。

5. 1990s: CASE ツールの普及

ERwin、 ER/Studio、 PowerDesigner などの専用ツールが企業で広く採用。 ER 図のラウンドトリップ（順方向・逆方向同期）が実現。

6. 2000s: UML の隆盛

UML クラス図が ER 図の代替候補として浮上。 ただし DB 専用の表現力では ER 図が依然優位。

7. 2010s: NoSQL とスキーマレス

MongoDB、 Cassandra、 DynamoDB の登場で「スキーマレス」が流行。 ER 図不要論も。 しかし大規模システムでは結局スキーマ設計が必要、 という揺り戻し。

8. 2020s: ドキュメント・アズ・コード

Mermaid、 PlantUML、 dbdiagram.io でテキストベース ER 図が普及。 git で変更履歴管理、 CI で自動レンダリング。 DevOps 文化との融合。

🔧 実装詳細

ER 図実装の細部。

1. ツール選定

• 無料・OSS：DrawIO、 Mermaid、 PlantUML、 dbdiagram.io
• 商用：ERwin、 ER/Studio、 PowerDesigner、 Lucidchart
• クラウド系：Miro、 Figma（協同編集）
• DB 統合：pgAdmin、 MySQL Workbench、 DBeaver

2. 命名規則

• テーブル：複数形、 snake_case（users、 yearly_stats）
• カラム：snake_case（first_name、 created_at）
• PK：id または table_id（user_id）
• FK：参照先テーブル名_id（pref_code）
• タイムスタンプ：created_at、 updated_at、 deleted_at
• 真偽値：is_active、 has_paid（is_/has_ プレフィクス）

3. データ型の選定

• 整数：SMALLINT / INTEGER / BIGINT を用途別に選ぶ（容量節約）
• 文字列：VARCHAR(N) で最大長を制限、 TEXT は無制限
• 金額：DECIMAL(p, s) で精度確保。 FLOAT は丸め誤差 NG
• 日付：DATE / TIMESTAMP / TIMESTAMPTZ（タイムゾーン考慮）
• 真偽値：BOOLEAN
• JSON：JSONB（PostgreSQL）、 JSON（MySQL）
• 地理：PostGIS の GEOMETRY 型

4. 制約の活用

• NOT NULL：必須項目
• UNIQUE：一意制約
• CHECK：ドメイン制約（age >= 0 など）
• FOREIGN KEY：参照整合性
• DEFAULT：デフォルト値

5. インデックス設計

• PK は自動で BTREE インデックス
• 外部キーには自動でインデックス（多くの DBMS）
• WHERE 句で頻出のカラムに追加
• JOIN キーに追加
• ORDER BY、 GROUP BY に活用
• 多すぎると INSERT が遅くなる

⚙️ 運用とトラブルシュート

ER 図運用での難題。

1. 仕様変更への追随

業務要件は変わり続ける。 ER 図も常にアップデート。 ツール選定時に「ラウンドトリップ可能性」を確認。

2. マイグレーション

Alembic、 Flyway、 Liquibase でスキーマ変更を git 管理。 本番反映前にステージングで検証。

3. パフォーマンスチューニング

EXPLAIN ANALYZE で実行計画確認。 SELECT 遅延は (a) インデックス追加、 (b) クエリ書き換え、 (c) パーティション、 (d) 非正規化 の順で対処。

4. ドキュメント生成

schemaspy、 sqldef、 tbls で DB スキーマから ER 図とドキュメントを自動生成。 README で公開。

5. データ品質

参照整合性、 制約、 トリガーで DB レベルで品質確保。 アプリ層だけに頼らない。

💴 コストと見積もり

ER 図関連のコスト。

1. ツール費用

2. 設計フェーズの人的コスト

中規模システム（50 テーブル程度）の初期 ER 設計：シニアエンジニア 1 名 × 1 ヶ月 ≈ 150 万円。 修正フェーズはさらに同程度。

3. 教育コスト

新人エンジニアに ER 図の読み書きを教えるのに 20〜40 時間。 OJT で覚えさせる方が定着率高い。

🛡 ガバナンス・セキュリティ

ER 図関連のガバナンス。

1. データオーナーシップ

各エンティティの所有部門を明確化。 個人情報（人）は人事部、 売上（売上）は経理部、 など。 RACI マトリクス。

2. データ品質管理

DAMA 6 次元（正確性・完全性・一貫性・適時性・一意性・妥当性）で各エンティティを評価。

3. 個人情報の取り扱い

個人情報を含むカラムに「PII」フラグ。 暗号化、 アクセスログ、 匿名化を必須化。

4. データ系譜（Data Lineage）

エンティティ間のデータの流れを記録。 Apache Atlas、 OpenLineage で自動化。

5. 監査

DB 構造変更履歴を git で管理。 SOX 法、 J-SOX 対応。

🏭 産業事例 6 件 — 現場ではどう使われているか

📊 ER 図記法の比較

📋 正規化レベル早見表

ER 図設計で頻出する「第 N 正規形」の到達条件と典型的なユースケースを表に整理する。 SSDSE-B-2026 のような分析用データセットでは 3NF が標準だが、 DWH では意図的に 2NF に留めるケースもある。

🗂 SSDSE-B-2026 を ER 図化する際の典型カラム対応

SSDSE-B-2026 (47 都道府県 × 多変量年次データ) を RDB スキーマに落とす際の対応関係を示す。 「年×都道府県」が複合 PK、 指標は属性 (人口・出生数など) となる。

📝 演習 5 問 — 理解度チェック

💥 現場の失敗例 — こうして詰んだ

❓ よくある質問 (FAQ) 10 問

Q. ER 図と UML クラス図、 どちらを使うべき？

A. DB 設計が主なら ER 図、 ソフトウェア設計と統合したいなら UML。 ER 図は「データ」、 UML は「データ＋振る舞い」。 用途に応じて。

Q. NoSQL でも ER 図は必要？

A. MongoDB、 Cassandra でも「コレクション間の関係」を可視化する価値あり。 ただし正規化原則は緩い。 アクセスパターン中心の設計が重要。

Q. 無料ツールでおすすめは？

A. DrawIO（GUI）、 Mermaid（テキスト）、 dbdiagram.io（DSL）。 用途で使い分ける。

Q. チームで共同編集するには？

A. Mermaid / PlantUML をテキストで git 管理 + CI で画像化が最強。 Miro / Lucidchart などのリアルタイム共同編集も選択肢。

Q. 既存 DB から ER 図を生成できる？

A. Yes。 pgAdmin、 MySQL Workbench、 DBeaver、 schemaspy で自動生成。 ただし命名規則が悪い DB だと読みづらい。

Q. 第 3 正規形まで満たせば十分？

A. 業務系なら 3NF が標準。 OLAP / DWH では意図的に非正規化（スタースキーマ）。 用途次第。

Q. ER 図の更新はどのタイミング？

A. スキーマ変更 PR と同じタイミング。 Mermaid 化していれば自動。 「文書更新を後回しにしない」が鉄則。

Q. ER 図と論理モデルは何が違う？

A. 概念モデル（業務寄り）→ 論理モデル（RDB 設計、 正規化済み）→ 物理モデル（特定 DBMS 向け）。 ER 図は概念〜論理を表現する。

Q. エンティティ名は単数？複数？

A. テーブル名は複数形（users、 orders）、 ER 図上のエンティティ名は単数（User、 Order）が多数派。 流派次第。

Q. ER 図の学習に最適な書籍は？

A. 『達人に学ぶ DB 設計徹底指南書』(ミック著)、 『SQL アンチパターン』(Karwin 著)、 『リレーショナルデータベース入門』(増永良文著)。

🔗 隣接手法への橋渡し

ER 図は単独の作図ではなく、 業務分析 ・正規化 ・物理 DB 設計 ・SQL DDL 生成を結ぶ設計ドキュメントである。 エンティティ ・関係 ・属性 ・カーディナリティを業務要件と紐付けて記述する。

• 上流（前処理・データ整備）: 要件定義 (リサーチクエスチョン) / データモデリング (DB) / ドメイン知識
• 並列（代替・補完手法）: UML (データベース設計) / DFD (データベース設計) / クラス図 (設計)
• 下流（評価・解釈・応用）: RDBMS (データベース) / スキーマ設計 / DB 正規化

ER 図は「実体 (Entity) ・関係 (Relationship) ・属性で DB スキーマを表現する」設計手法で、 上流の業務要件分析でエンティティを抽出し、 並列の UML クラス図・正規化と組み合わせ、 下流の物理 DB 設計・SQL DDL 生成へと運ぶ。

🌳 意思決定ツリー — 状況別の手順

ER 図の選定・運用での意思決定をツリーで整理。

🌳 ツリー 1: 採用すべきか

現状システムに課題があるか？
├─ Yes → 課題はコスト／性能／拡張性／信頼性？
│  ├─ コスト → ROI 試算で ER 図 採用検討
│  ├─ 性能 → ベンチマークで比較
│  ├─ 拡張性 → スケーラビリティ要件を整理
│  └─ 信頼性 → SLA, MTBF を比較
└─ No → 「動いているものは触らない」原則
    

🌳 ツリー 2: アーキテクチャ選定

ワークロードの特性は？
├─ 予測可能・常時稼働 → リザーブド／専有
├─ 変動大・短期 → サーバーレス／スポット
├─ レイテンシ厳しい → エッジ／フォグ
└─ コンプライアンス厳しい → プライベート／オンプレ
    

🌳 ツリー 3: トラブル対応

症状は？
├─ 完全停止 → ロールバック先行、 原因究明は後
├─ 性能劣化 → メトリクス／ログ／トレースで根因分析
├─ コスト急増 → 利用量分析、 不正アクセス疑い
└─ セキュリティイベント → CSIRT 起動、 隔離
    

📝 補足：直感を「三要素」で描き直す

ER 図の本質は、 世界を 3 つの品詞に分けて絵にすることだと捉えると迷わない。 これは前述の「組織図＋家系図」の比喩を、 文法の言葉で言い換えたものである。

1. SSDSE-B-2026 の実測で三要素を確認する

実データ（SSDSE-B-2026.csv、 cp932、 skiprows=[1]）は 564 行 × 112 列。 内訳を三要素に写像すると次のとおり。 これは捏造ではなく実ファイルの形状に一致する。

たとえば 2023 年の総人口列 A1101 は東京都＝14,086,000 が最大値（実データ）。 この 1 マスは「実体＝都道府県(東京都)、 年度(2023)」×「属性＝総人口」の交点にすぎない。 1 マスを主キーで一意に特定できることが、 ER 図がめざす「行の意味の明確化」である。

2. 多重度を「4 つの問い」でなく「矢印の向き」で掴む

数式セクションの 4 問法を、 直感側から補う。 「片側から相手を見たとき何本の線が出るか」だけを見る。

3. PK / FK は図の上でどう描かれるか

• 主キー (PK)：属性名に下線、 または行末に「PK」。 複合 PK は複数行に下線（例：観測値の (Code, 年)）。
• 外部キー (FK)：行末に「FK」、 IE 記法では相手の実体へ線で接続。 FK は「1 つの値しか持てない」ため、 これが後述の「多対多を直接描けない」理由に直結する。

関連ページ：主キー ／ 外部キー ／ テーブル ／ データベース ／ RDB 詳細。

📝 補足：落とし穴の深掘り（重要）

冒頭「落とし穴 5 件」を、 原因まで遡って整理する。 表面の症状だけ覚えても再発するので、 「なぜ起きるか」を押さえる。

1. なぜ多対多は「中間テーブルなし」で表現できないのか

2. 多重度の誤り — 1:N と N:M の取り違え

「1 県に複数の観測値」だけ見て 1:N と決めると、 反対向き（1 観測値は何県に属すか）を検証し忘れる。 両方向を必ず問う。 SSDSE では「1 観測値 ＝ ちょうど 1 県」なので安全に 1:N。 だが「県 ─ 指標」を素朴に結ぶと、 1 県は多指標・1 指標は多県で N:M になり、 連関テーブル（＝観測値）が必要になる。 実は SSDSE の 109 指標列は、 この N:M を暗黙に横持ちで潰した状態と読める。

3. 正規化「不足」と「過剰」は両方が罠

原則は 「まず 3NF、 必要なら意図して崩す」。 崩す判断（非正規化）は性能計測の後に行う。 早すぎる非正規化は技術的負債になる。

4. 弱実体（weak entity）の扱い

単独では識別できず、 親に依存する実体を 弱実体と呼ぶ。 自分だけでは主キーを構成できず、 親の PK＋自分の部分キーで複合 PK を作る（識別関係）。 SSDSE の「観測値」は、 都道府県と年度がないと意味を持たない典型的な弱実体で、 PK は (Code, 年)。 弱実体を強実体と誤認して代理キー（連番 id）だけ振ると、 (Code, 年) の一意性制約を張り忘れ、 重複行が忍び込む。

5. 命名の一貫性

同じ概念が pref_code / prefCode / 都道府県コード / Code と揺れると、 JOIN 条件で人的ミスが多発する。 プロジェクト開始時に snake_case 統一・FK は参照先_id 形式などを文書化し、 SSDSE の日本語列（年度・Code・Prefecture）も論理名へ正規化してから設計に入る。

6. 概念 / 論理 / 物理設計の混同

📝 補足：発展 — 変換・正規化・記法・NoSQL

1. ER 図 → リレーショナルスキーマの機械的変換規則

ER 図は、 ほぼ機械的に表定義へ落とせる。 この 7 つの規則を覚えると設計が速い。

2. 正規化（第 1〜3 正規形）との関係

ER 図の「論理化」は、 実体の各表に正規化を適用する工程そのもの。 テーブルの粒度を決める理論的裏付けが正規形である（本用語集に正規化の独立ページは未整備のため、 ここでは要点をテキストで示す）。

• 1NF：各セルが単一値。 SSDSE の 109 指標列はすべてスカラー → 満たす。
• 2NF：複合 PK (Code, 年) の 一部にしか依存しない属性を分離。 県名・地方区分は Code だけで決まる → prefectures 表へ。
• 3NF：非キー属性間の推移従属を排除。 「地方区分」が「県名」経由で決まるなら、 さらに整理。

3. 記法の違い — IE / IDEF1X / UML

比較表（📊 比較表）に加え、 実務で迷いやすい点を補う。

• IE 記法（クロウフット）：多重度を線の端の記号で表す現代主流。 「鳥の足＝多、 縦棒＝1、 ○＝任意(0)」。
• IDEF1X：米政府調達由来。 識別関係（実線）と非識別関係（破線）を厳密に区別し、 弱実体・FK 伝播を明示する。 弱実体の議論に強い。
• UML クラス図：多重度を 0..1 / 1..* のように数値範囲で書く。 データだけでなく「振る舞い（メソッド）」も持てるのが ER 図との差。

4. NoSQL での設計思想の違い

ER 図＋正規化は「書き込みの整合性」を最優先する RDB の思想。 NoSQL は逆に アクセスパターン駆動で設計する。

ただし NoSQL でも「どの実体がどう関係するか」を把握する意味で ER 的思考は有効で、 スキーマレス＝無設計ではない。 大規模化すると結局スキーマ設計へ回帰する、 というのが歴史セクションで触れた揺り戻しである。