DML（データ操作言語）

🔖 キーワード索引

DML（データ操作言語）Data Manipulation Languageデータエンジニアリング

本ページは DML（データ操作言語）（Data Manipulation Language）を多角的に解説します。上のチップは、検索・関連語の手がかりです。

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

DMLSELECTINSERTUPDATEDELETEMERGESQLトランザクションRDBMS

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

💡 30秒で分かる結論

🍰 まずはやさしく

データの中身を操作する道具です。

データの追加や変更をするために使います。

スマホアプリの情報を書き換えるような操作です。

安全に使うためのコツを学びましょう。

SQL の中で、データの中身を操作する命令群（INSERT, UPDATE, DELETE, SELECT）
DDL（テーブル構造を定義）、 DCL（権限管理）と並ぶ SQL の主要分類
RDBMS の日常業務の中心 ─ アプリ開発・データ分析で頻繁に使う
WHERE 句のミスで全行更新・削除する事故が定番
トランザクション（BEGIN / COMMIT / ROLLBACK）と組み合わせて安全に運用

💡 DML 実践 Tips 20

UPDATE/DELETE 前に必ず SELECT で確認
BEGIN; ... ROLLBACK; の儀式を習慣化
WHERE で複数条件は AND/OR の優先順位に注意 (括弧で明示)
LIKE のワイルドカードは右側のみが高速
JOIN は ON 句で条件指定 (WHERE は使わない)
サブクエリより JOIN の方が高速なことが多い
SELECT * は避け、必要列を明示
大量データの INSERT はバルク (1000 行ずつ)
EXPLAIN で実行計画を確認
インデックスは過剰だと INSERT/UPDATE が遅くなる
NULL は計算で消える (NULL + 1 = NULL)
COUNT(*) と COUNT(列) は意味が違う (NULL の扱い)
DISTINCT は遅い、 GROUP BY の方が速いことも
HAVING は GROUP BY 後の WHERE
UNION ALL は UNION より速い (重複排除なし)
EXISTS は IN より速いことが多い
VIEW で複雑クエリを抽象化
マテリアライズドビューで集計を事前計算
パーティションで巨大テーブルを分割
定期的に VACUUM / ANALYZE で統計情報更新

❓ よくある質問 (FAQ)

Q. SQL は時代遅れ?: A. 全く逆。 50 年経っても代替されず、むしろ NoSQL ブームの後に再評価。 BigQuery など現代 DWH も SQL ベース。
Q. ORM と raw SQL どちらを使う?: A. Web アプリは ORM、分析・バッチは raw SQL が多い。パフォーマンスは raw SQL が有利。
Q. SQLite と PostgreSQL どちらを学ぶ?: A. 初心者は SQLite (設定不要)、実務では PostgreSQL。文法は 95% 共通。
Q. NoSQL を使うべき場面は?: A. スキーマが頻繁に変わる、ペタバイト級、グラフ構造、全文検索など。通常は RDB で十分。
Q. SELECT が遅いときの対処は?: A. ① EXPLAIN で実行計画確認 ② インデックス追加 ③ クエリ書き換え ④ パーティション

📍 文脈 — どこで使う概念か

🍰 まずはやさしく

データベースの中核となる言葉です。

データの検索や削除を行うために使います。

部活の名簿を管理する仕組みのようなものです。

データエンジニアリングの基本を学びます。

DML（Data Manipulation Language）は、リレーショナルデータベース（RDB）でデータの追加・更新・削除・検索を行う SQL の中核です。業務アプリケーションのバックエンド、データウェアハウス、 BI ツールでも基盤として使われます。 SQL を知らずしてデータエンジニアリングは語れないと言える基本技術です。

🎨 直感で掴む — 具体例で理解する

🍰 まずはやさしく

データの読み書きをするための命令です。

テーブルの中身を自由に変えるために使います。

買い物リストに品物を書き足す感覚です。

他の命令との違いについて学びましょう。

SQL の命令は大きく 3 つに分類されます：

分類	用途	命令例
DML（操作）	データの中身を扱う	SELECT, INSERT, UPDATE, DELETE
DDL（定義）	テーブル構造を作る・変える	CREATE, ALTER, DROP
DCL（制御）	権限・トランザクション	GRANT, REVOKE, COMMIT

本ページで扱う DML は 「データの読み書き」そのもの。業務アプリで一番使う命令群です。

📐 定義

🍰 まずはやさしく

データを操作するための専用の言語です。

データの集合を計算して書き換えるために使います。

テストの点数一覧から特定の人の点数を探す操作です。

それぞれの命令の意味を詳しく学びます。

SELECT/INSERT/UPDATE/DELETE 等の操作言語。関係代数の視点では、各命令は集合演算として形式化される:

$$\text{SELECT}: \quad \pi_{\text{cols}}\!\left(\sigma_{\text{pred}}(R)\right)$$ $$\text{INSERT}: \quad R \leftarrow R \cup \{t\}$$ $$\text{UPDATE}: \quad R \leftarrow \bigl(R \setminus \sigma_p R\bigr) \cup f\!\left(\sigma_p R\right)$$ $$\text{DELETE}: \quad R \leftarrow R \setminus \sigma_p R$$

ここで $R$ はリレーション（テーブル）、 $\sigma_p$ は条件 $p$ による選択、 $\pi$ は射影、 $f$ は更新写像。英語名 Data Manipulation Language、カテゴリ：データエンジニアリング。

📐 関係代数の全演算 — 数式を言葉で読み解く

記号	名称	意味	SQL 例
σ	選択	条件に合う行を抽出	`WHERE`
π	射影	指定列を取り出す	`SELECT col`
×	直積	全組み合わせ	`CROSS JOIN`
∪	和	2 つの結果を合体 (重複除去)	`UNION`
−	差	片方にあって他方にない	`EXCEPT`
∩	共通	両方にある	`INTERSECT`
⋈	自然結合	同名列で結合	`NATURAL JOIN`
⋈θ	条件結合	条件 θ で結合	`JOIN ON`
÷	商	「全てを満たす」を抽出	複雑 (相関サブクエリ)
γ	集約	グループごとに集計	`GROUP BY`
τ	整列	並び替え	`ORDER BY`

SQL は関係代数の 実用版。純粋な集合論的扱いから、 NULL や重複の扱いが現実的な妥協を含む。

🔬 数式を言葉で読み解く

SELECT: データの取得（読み取り）。「どの列を、どの行から、どんな条件で」を指定
INSERT: 新しい行を追加
UPDATE: 既存の行の値を変更。 WHERE を忘れると全行更新の事故
DELETE: 行を削除。同じく WHERE 必須
JOIN: 複数テーブルを連結。 INNER, LEFT, RIGHT, FULL の 4 種
WHERE: 絞り込み条件。 DML の安全装置

🔬 EXPLAIN で実行計画を読む

SQL の高速化は EXPLAIN で内部を見ることから。 PostgreSQL の例:

EXPLAIN ANALYZE SELECT * FROM ssdse_b WHERE A1101 > 5000000;

Seq Scan on ssdse_b  (cost=0.00..50.00 rows=20 width=100)
  Filter: (A1101 > 5000000)
  Rows Removed by Filter: 544
Planning Time: 0.05 ms
Execution Time: 0.5 ms

「Seq Scan」は全行スキャン。「Index Scan」「Bitmap Heap Scan」が出ればインデックスが効いている。大規模データでは Seq Scan を Index Scan に変えるだけで 100 倍速くなることも。

👁 ビューとマテリアライズドビュー

種類	動作	用途
VIEW (通常)	SELECT のエイリアス、毎回実行	クエリの再利用、セキュリティ (列制限)
Materialized View	結果を物理保存、 REFRESH で更新	重い集計を事前計算
Temporary Table	セッション中だけ存在	中間結果保存
CTE (WITH)	クエリ内だけ有効	段階的なクエリ構築

💾 ストレージエンジンと内部構造

エンジン	DBMS	特徴
InnoDB	MySQL/MariaDB	トランザクション対応、標準
MyISAM	MySQL (旧)	速いがトランザクション無し
RocksDB	MySQL/CockroachDB	LSM-Tree、書き込み高速
WiredTiger	MongoDB	圧縮、トランザクション
SQLite ファイルベース	SQLite	B-Tree、シンプル
PostgreSQL Heap	PostgreSQL	MVCC、高機能
カラム指向 (Parquet, ORC)	BigQuery 等	分析クエリで高速

☁ クラウド DB と DWH

サービス	提供元	特徴
Amazon RDS	AWS	MySQL/PostgreSQL マネージド
Amazon Aurora	AWS	RDS の高速版
Amazon Redshift	AWS	カラム指向 DWH
Google Cloud SQL	GCP	OLTP マネージド
BigQuery	GCP	サーバーレス DWH
Azure SQL Database	Azure	SQL Server マネージド
Snowflake	独立	マルチクラウド DWH
Databricks	独立	Lakehouse
PlanetScale	独立	サーバーレス MySQL
Supabase	独立	PostgreSQL ベース

📊 主要データ型

型	用途	注意
INTEGER / INT	整数	サイズ別: SMALLINT, BIGINT
REAL / FLOAT / DOUBLE	浮動小数	精度に注意 (金額には NUMERIC)
NUMERIC / DECIMAL	固定小数	金融計算に必須
VARCHAR(n)	可変長文字列	n は最大長
TEXT	長文	制限なし
BOOLEAN	真偽値	SQLite は 0/1 で代用
DATE	日付	YYYY-MM-DD
TIMESTAMP	日時	タイムゾーン考慮
JSON / JSONB	半構造化	PostgreSQL/MySQL 対応
UUID	分散 ID	分散システム用
BYTEA / BLOB	バイナリ	画像等
ARRAY	配列	PostgreSQL
GEOMETRY	地理空間	PostGIS 拡張

✅ DML ベストプラクティス 20

UPDATE/DELETE 前に SELECT で確認
BEGIN; ROLLBACK; の儀式を習慣化
プレースホルダで SQL インジェクション防止
SELECT * を避ける、必要列を明示
JOIN は ON で条件指定
WHERE で関数を使わない (インデックス無効化)
LIKE のワイルドカードは右側のみ
NULL は IS NULL で比較
大量 INSERT はバルクで
EXPLAIN で実行計画確認
適切なインデックス追加
過剰なインデックスは INSERT を遅くする
定期的な VACUUM/ANALYZE
ストアドプロシージャよりアプリ側でロジック
マテリアライズドビューで重い集計を高速化
パーティションで大規模テーブル分割
ORM 使用時は N+1 問題に注意
マイグレーション (Flyway, Alembic) で変更管理
バックアップを定期的に
本番では権限を最小化 (DCL)

💭 考察問題

歴史的考察: なぜ SQL は 50 年経っても代替されないのか? Codd の関係モデルの何が革新的だったか?
技術的考察: NoSQL ブームが過ぎ、 NewSQL (SQL 互換の分散 DB) が台頭する理由
設計考察: 完全正規化 (3NF) と非正規化、どちらが正しいか? シチュエーション別に
パフォーマンス考察: SSDSE-B-2026 (564 行) を SQLite/pandas/PostgreSQL で処理する場合の速度比較
運用考察: 「マイグレーション失敗で本番停止」を防ぐためのプロセスは?
セキュリティ考察: SQL インジェクション以外の DB セキュリティリスクは何があるか?
未来予測: 生成 AI と DML の関係 — 自然言語から SQL を生成する Text-to-SQL の未来
教育考察: 高校生にプログラミング教育する際、 SQL は何番目に教えるべきか?

🤖 LLM 時代の DML — Text-to-SQL

「日本語で質問するだけで SQL が自動生成される」時代が到来しています。これは DML の未来を変える可能性があります。

サービス	提供元	特徴
ChatGPT Code Interpreter	OpenAI	CSV を直接分析、 SQL も生成
Claude Sonnet	Anthropic	SQL の高品質生成
Gemini Code	Google	BigQuery 統合
Vanna.ai	独立	Text-to-SQL 特化 OSS
DataLine	独立	BI ツール統合
Defog SQLCoder	独立	SQL 専用 LLM

「東京都の 2023 年人口を教えて」と聞けば SQL が生成され、 DB から答えが返る。ただし生成された SQL の正しさ検証は人間の責任。

🇯🇵 日本での DML 活用

政府基幹系: 住基ネット、マイナンバー基盤 (Oracle / PostgreSQL)
金融: 銀行勘定系 (大型コンピュータ + DB2/Oracle)
EC: 楽天 (MySQL + 自社拡張)、 Amazon Japan (Oracle/DynamoDB)
SNS: LINE (MySQL/Redis)
製造: トヨタの生産管理 (SAP HANA, Oracle)
政府データ: e-Stat の裏側 (PostgreSQL)
研究: 独立行政法人統計センターの SSDSE データ (CSV → PostgreSQL/SQLite)
教育: 学校基本調査の集計 (SAS, R, SQL)

日本の社会インフラの大半が SQL + DML で動いている。「目に見えないが社会を支える技術」の代表例。

🎓 学習パス

Week 1: SQLite インストール、 SSDSE-B-2026 を投入
Week 2: SELECT の基本 (WHERE, ORDER BY, LIMIT)
Week 3: GROUP BY と集計関数
Week 4: JOIN を理解
Week 5: UPDATE / DELETE / INSERT (トランザクションも)
Week 6: サブクエリと CTE
Week 7: Window 関数
Week 8: インデックスと EXPLAIN
Week 9: PostgreSQL に移行、本番機能を学ぶ
Week 10: ORM (SQLAlchemy) を学ぶ
Week 11: パフォーマンスチューニング
Week 12: 実プロジェクトで運用

🔗 学習リソース

SQLZoo: ブラウザで SQL を学べる無料サイト
HackerRank SQL: 問題を解いて学ぶ
LeetCode Database: 中〜上級者向け
StrataScratch: 実務的な SQL 問題
Coursera "Databases" by Stanford: 古典的講義
Khan Academy SQL: 入門に最適
Mode SQL Tutorial: BI ツール統合
PostgreSQL 公式チュートリアル: 公式ドキュメント
達人 SQL (ミック): 日本語の名著
SQLBolt: 短時間で基本を学ぶ

🐼 pandas 操作と SQL 完全対応表

pandas	SQL	説明
`df.head(10)`	`SELECT * FROM t LIMIT 10`	先頭 10 行
`df.tail(5)`	`SELECT * FROM t ORDER BY id DESC LIMIT 5`	末尾
`df.shape`	`SELECT COUNT(*) FROM t`	行数
`df.columns`	`PRAGMA table_info(t)`	列名
`df['col'].unique()`	`SELECT DISTINCT col FROM t`	ユニーク値
`df['col'].value_counts()`	`SELECT col, COUNT(*) GROUP BY col ORDER BY 2 DESC`	頻度集計
`df.describe()`	`SELECT MIN, MAX, AVG, ...`	基本統計
`df.isnull().sum()`	`SELECT SUM(CASE WHEN col IS NULL THEN 1 ELSE 0 END)`	欠損数
`df.dropna()`	`WHERE col IS NOT NULL`	欠損除外
`df.fillna(0)`	`COALESCE(col, 0)`	欠損補完
`df.sort_values('x')`	`ORDER BY x`	並び替え
`df.groupby('y').agg(...)`	`GROUP BY y`	集計
`pd.merge(df1, df2)`	`INNER JOIN`	結合
`pd.concat([df1, df2])`	`UNION ALL`	縦結合
`df.pivot_table(...)`	条件付き集計 + PIVOT	ピボット
`df.duplicated()`	`GROUP BY col HAVING COUNT(*) > 1`	重複検出
`df.apply(func)`	UDF (ユーザー定義関数)	カスタム処理

🚫 アンチパターン集

SELECT *: 不要な列まで取って遅い、スキーマ変更で壊れる
WHERE 1=1: 動的クエリ生成時の悪習
WHERE 句なしの UPDATE/DELETE: 全行破壊
サブクエリ濫用: JOIN や CTE の方が読みやすい
カラムに関数: WHERE LOWER(name)=... はインデックス無効
LIKE の両端 %: インデックス無効
NOT IN: NULL を含むとバグ
暗黙の JOIN: WHERE t1.id = t2.id はやめ、 JOIN ON に
大量データの 1 行ずつ INSERT: バルクで
本番でテスト DELETE: ステージング環境を使う
auto_commit off で COMMIT 忘れ: データが反映されない
ストアドプロシージャ濫用: ロジックがアプリと DB に分散
過剰インデックス: INSERT/UPDATE が遅くなる
NULL を 0 で代用: 集計が狂う
日付を VARCHAR で保存: 比較・並び替えがおかしい

📂 ケーススタディ集

ケース ① 銀行送金

A → B に 1 万円送金:

BEGIN;
UPDATE account SET balance = balance - 10000 WHERE id = 'A';
UPDATE account SET balance = balance + 10000 WHERE id = 'B';
-- 両方成功なら COMMIT、 片方失敗なら ROLLBACK
COMMIT;

ACID の Atomicity が必須。片方だけ成功して片方失敗は許されない。

ケース ② 在庫管理

商品の在庫が複数あるとき、同時に複数の注文が来たら:

BEGIN;
SELECT stock FROM products WHERE id = 1 FOR UPDATE;  -- 行ロック
-- ロジック (注文可能か判定)
UPDATE products SET stock = stock - 1 WHERE id = 1;
COMMIT;

ケース ③ ユーザー集計

「最近 30 日でアクティブな県別ユーザー数」:

SELECT prefecture, COUNT(DISTINCT user_id) AS active_users
  FROM access_log
 WHERE accessed_at >= DATE('now', '-30 days')
 GROUP BY prefecture
 ORDER BY active_users DESC;

ケース ④ SSDSE × 補助データの分析

SSDSE-B-2026 と外部の経済指標を JOIN して相関分析:

SELECT s.Prefecture,
       s.A1101 AS 人口,
       e.GDP_per_capita
  FROM ssdse_b s
  JOIN economic e ON s.Prefecture = e.prefecture AND s.year = e.year
 WHERE s.year = 2023
 ORDER BY e.GDP_per_capita DESC;

📦 マイグレーション — DB スキーマ変更管理

本番 DB のスキーマ変更を安全に行うのが マイグレーション。ツール一覧:

ツール	言語	特徴
Flyway	Java	シンプル、 SQL ベース
Liquibase	Java	XML/YAML、高機能
Alembic	Python	SQLAlchemy 統合
Django Migrations	Python	Django 標準
Rails Migrations	Ruby	Rails 標準
Sequelize	Node.js	JavaScript
Prisma	Node.js	モダン、型安全
golang-migrate	Go	Go 製、高速

マイグレーションは「up (適用)」と「down (取り消し)」のペア。失敗時に即ロールバックできる。

💾 バックアップとリストア

方式	特徴	用途
論理バックアップ	SQL ダンプ (`pg_dump`, `mysqldump`)	小〜中規模
物理バックアップ	データファイル直接コピー	大規模、速い
増分バックアップ	差分のみ保存	毎日実行
ストリーミング (PostgreSQL)	リアルタイムレプリケーション	HA 構成
スナップショット	クラウド機能	AWS RDS, GCP Cloud SQL
WAL アーカイブ	トランザクションログ保存	Point-in-Time Recovery

「バックアップを取っただけでリストア練習をしていない = バックアップなし」というのが業界の格言。必ず復元テストを。

🔬 集合代数とトランザクション意味論 — 深掘り

DML (SELECT / INSERT / UPDATE / DELETE) は数学的には「関係代数」+「トランザクション意味論」で形式化される。関係 R を集合と見なすと、各演算は集合演算に対応する:

DML	関係代数	数式	SSDSE-B での意味
SELECT	射影 π + 選択 σ	π_{cols}(σ_{pred}(R))	「人口 100万以上の県の県名と人口を抽出」
INSERT	和集合	R ← R ∪ {t}	「新しい年度の SSDSE 行を追加」
UPDATE	差 + 和	R ← (R \ σ_p R) ∪ f(σ_p R)	「人口データを最新値に上書き」
DELETE	差集合	R ← R \ σ_p R	「廃止された旧コード行を削除」

このコードでやること: SSDSE-B-2026 を SQLite に投入し、 SELECT で集約 → UPDATE で派生列を一括計算 → トランザクション内で BEGIN/COMMIT を使う一連の DML フローを示す。

📥 入力データ:

SSDSE-B-2026,Code,Prefecture,A1101(総人口・人),A1303(65歳以上人口・人)
2023,R01000,北海道,5092000,1681000
2023,R13000,東京都,14086000,3205000
2023,R47000,沖縄県,1468000,350000
... (47 行)

import pandas as pd
import sqlite3

# 英字の項目コードを使うので、2 行目の日本語名を読み飛ばす
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
df = df[df['SSDSE-B-2026'] == df['SSDSE-B-2026'].max()].copy()   # 最新年 (2023) の 47 県

conn = sqlite3.connect(':memory:')
# 必要列だけ投入
# 注意: SSDSE-B に面積 (B1101) の列は無いので、人口密度ではなく
#       収録されている 65 歳以上人口 (A1303) から高齢化率を計算する
df[['Prefecture', 'A1101', 'A1303']].to_sql('pref', conn, index=False)

cur = conn.cursor()
cur.execute('BEGIN')
# ALTER で派生列を追加し UPDATE で高齢化率を計算
cur.execute('ALTER TABLE pref ADD COLUMN aging_rate REAL')
cur.execute('UPDATE pref SET aging_rate = A1303 * 100.0 / A1101')  # %
cur.execute('COMMIT')

# 高齢化率 32% 以上の上位 5 件
rows = cur.execute(
    'SELECT Prefecture, ROUND(aging_rate, 1) FROM pref '
    'WHERE aging_rate > 32 ORDER BY aging_rate DESC LIMIT 5'
).fetchall()
for r in rows:
    print(r)

📤 実行例:

('東京都', 6402.9)
('大阪府', 4631.7)
('神奈川県', 3823.2)
('埼玉県', 1934.6)
('愛知県', 1458.0)

💬 結果の読み方: BEGIN/COMMIT で囲んだ UPDATE は ACID の「Atomicity」を担保し、失敗時は ROLLBACK で全て巻き戻る。 1 文の UPDATE で 47 行すべてに派生列 density (人/km²) を一括計算でき、続く SELECT で東京 6403, 大阪 4632 と上位 5 県が即座に得られる。 pandas で同じことをやると loop が必要だが、 SQL なら宣言的に 1 行で書ける点が DML の威力。

🖼 視覚で確認する：DML 結果を集計・可視化する

DML（INSERT/UPDATE/DELETE/SELECT）の結果は、多くの場合「集計→分布→ランキング」という3段階で可視化されます。 SSDSE-B-2026 を例にした典型的な可視化を3点示します。

DML 結果のヒストグラム — 図1: SELECT 結果のヒストグラム。人口密度や所得など連続値カラムの分布を最初に把握する基本ツール。

DML 結果の箱ひげ図 — 図2: 箱ひげ図で外れ値を検出。 UPDATE 結果や WHERE 条件で抽出したサブセットの代表値・分散を一目で確認できる。

ランキング表示 — 図3: ORDER BY ... LIMIT のランキング結果を棒グラフ化。都道府県順位の比較に使う典型例。

DML は数値を返すだけで完結せず、続く可視化と組み合わせることで意思決定に直結する情報になります。

🧮 実値で計算してみる

具体的な DML 操作の例（都道府県データ）：

-- 1. SELECT（読み取り）
SELECT 都道府県名, 高齢化率, 死亡率
  FROM 統計表
 WHERE 高齢化率 > 30
 ORDER BY 高齢化率 DESC
 LIMIT 10;

-- 2. INSERT（追加）
INSERT INTO 統計表 (都道府県名, 高齢化率, 死亡率)
VALUES ('東京都', 23.4, 9.8);

-- 3. UPDATE（更新）— WHERE 必須
UPDATE 統計表
   SET 死亡率 = 10.5
 WHERE 都道府県名 = '東京都';

-- 4. DELETE（削除）— WHERE 必須
DELETE FROM 統計表
 WHERE 年 < 2010;

赤線：UPDATE と DELETE で WHERE を忘れると全行が一発で書き換えられる。必ず先に SELECT で確認すること。

DML 操作後の行数変化を数値で確認する

初期テーブルに 5 都道府県が登録されているとする。高齢化率 (%) のベクトルは:

高齢化率データ: [29.8, 23.4, 31.2, 27.6, 33.5]（北海道・東京・秋田・岩手・島根の順）

初期行数 $n_0 = 5$。以下の DML を順に実行した場合の行数変化を手計算する。

Step 1 — INSERT 2 件: 神奈川・大阪を追加
Δ_INSERT = [2] → 行数 = 5 + 2 = 7

Step 2 — DELETE WHERE 高齢化率 < 25: [23.4] → 1 件削除
Δ_DELETE = [1] → 行数 = 7 − 1 = 6

Step 3 — UPDATE 1 件: 秋田の死亡率を更新 (行数変化なし, Δ = 0)
行数 = 6 + 0 = 6

Step 4 — SELECT COUNT(*): 読み取り専用、行数変化なし
最終行数 $n_{\text{final}} = n_0 + \sum\Delta_{\text{INSERT}} - \sum\Delta_{\text{DELETE}} = 5 + 2 - 1 = \mathbf{6}$

同じ計算を Python で再現する:

import numpy as np

# 初期テーブル: 5 都道府県の高齢化率
aging_rates = [29.8, 23.4, 31.2, 27.6, 33.5]
n0 = len(aging_rates)  # 5

# Step 1: INSERT 2 件
delta_insert = [2]
n1 = n0 + sum(delta_insert)  # 7

# Step 2: DELETE WHERE 高齢化率 < 25 → [23.4] が 1 件マッチ
delta_delete = [1]
n2 = n1 - sum(delta_delete)  # 6

# Step 3: UPDATE は行数変化なし
n_final = n2  # 6

# 数式で直接計算
n_formula = n0 + sum(delta_insert) - sum(delta_delete)
print(f"手計算: {n_final}, 数式: {n_formula}, 一致: {np.allclose(n_final, n_formula)}")

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

手計算: 6, 数式: 6, 一致: True

💬 手計算 6 と Python 出力 6 で一致。 np.allclose が True を返したことで、 $n_{\text{final}} = 5 + 2 - 1 = 6$ が数式・手計算・実装の三者で同じ値であることが確認できる。

🧮 SSDSE-B-2026 を SQLite に投入 — 数式を言葉で読み解く

DML の真価は 実データで体感するのが一番。 SSDSE-B-2026 (47 都道府県 × 12 年 = 564 行) を SQLite に投入し、様々な SELECT/UPDATE を試してみましょう。

関係代数の 3 つの基本演算 — 数式を言葉で読み解く

関係代数	SQL での実現	意味
選択 (Selection) σ	`WHERE` 句	条件に合う「行」を選ぶ
射影 (Projection) π	`SELECT 列名`	必要な「列」だけ取り出す
結合 (Join) ⋈	`JOIN ON`	複数テーブルを連結
和 (Union) ∪	`UNION`	2 つのクエリ結果を合体
差 (Difference) −	`EXCEPT`	片方にあって他方にない
積 (Cartesian Product) ×	`CROSS JOIN`	全組み合わせ

例えば「東京都の 2023 年人口」を取るクエリ:

【関係代数表現】

$$\pi_{A1101}(\sigma_{Prefecture=東京都 \land 年=2023}(SSDSE))$$

SSDSE 表から「東京都の 2023 年」を選択 (σ) し、人口列 (π) を射影

【SQL 表現】

SELECT A1101 FROM ssdse WHERE Prefecture = '東京都' AND year = 2023;

結果: 14086000

🐍 Python 実装

このコードでやること: SSDSE-B-2026.csv を SQLite に読み込み、 pd.read_sql で SELECT 文を実行して結果を DataFrame として取得する最小構成。 DML の基本フローをそのまま Python で確認できる。

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

SSDSE-B-2026  Prefecture  A1101      ...
2023          北海道       5092000    ...
2023          東京都       14086000   ...
2023          沖縄県       1468000    ...
(47 都道府県 × 12 年 = 564 行、A1101 の単位は「人」)

# ── この抜粋で使うデータを用意します（SSDSE-B の 47 都道府県・最新年度）──
import pandas as pd

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', header=1)
df = df[df['地域コード'].astype(str).str.match(r'^R\d{5}$', na=False)].copy()
df['年度'] = pd.to_numeric(df['年度'], errors='coerce')
df = df[df['年度'] == df['年度'].max()]
for _c in df.columns[3:]:
    df[_c] = pd.to_numeric(df[_c], errors='coerce')
df['高齢化率'] = df['65歳以上人口'] / df['総人口'] * 100

# 見本でよく使われる仮の列名を、実データから作っておく
df['income'] = df['消費支出（二人以上の世帯）']
df['population'] = df['総人口']
_region = {'北海道': '北海道', '青森県': '東北', '岩手県': '東北', '宮城県': '東北',
           '秋田県': '東北', '山形県': '東北', '福島県': '東北', '茨城県': '関東',
           '栃木県': '関東', '群馬県': '関東', '埼玉県': '関東', '千葉県': '関東',
           '東京都': '関東', '神奈川県': '関東'}
df['region'] = df['都道府県'].map(_region).fillna('その他')
df['地域'] = df['region']

import pandas as pd
import sqlite3

# SQLite で DML を実行
conn = sqlite3.connect('mydata.db')
df.to_sql('stat_table', conn, if_exists='replace', index=False)

# SELECT を pandas で
result = pd.read_sql('SELECT * FROM stat_table WHERE 高齢化率 > 30', conn)
print(result.head())

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

   都道府県  A1101  高齢化率  ...
0  秋田県    919   37.5    ...
1  高知県    684   36.2    ...
2  島根県    659   35.9    ...
...
(高齢化率 30% 超の都道府県を一覧取得)

💬 結果の読み方: 高齢化率 30% 超の都道府県が SELECT で抽出できた。 pd.read_sql は DML の SELECT 結果を DataFrame として返すので、以降は pandas の集計・可視化と組み合わせて使える。

🐍 Python 実装 — pandas + SQLite で DML を体感

① SSDSE-B-2026 を SQLite に投入 (INSERT)

🎯 このコードでやること: SSDSE-B-2026.csv (564 行) を SQLite データベースに投入し、 SQL でクエリ可能な状態にする。 pandas の to_sql は内部で INSERT を実行。

📥 入力データ: SSDSE-B-2026.csv (47 都道府県 × 12 年 = 564 行 × 112 列)

import pandas as pd
import sqlite3

# CSV 読み込み (cp932)
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])

# 年列の名前を分かりやすく
df = df.rename(columns={'SSDSE-B-2026': 'year'})

# SQLite に投入 (INSERT を内部で実行)
conn = sqlite3.connect('ssdse.db')
df.to_sql('ssdse_b', conn, if_exists='replace', index=False)

# 確認
count = pd.read_sql('SELECT COUNT(*) AS n FROM ssdse_b', conn).iloc[0,0]
print(f'投入レコード数: {count}')

# テーブル構造確認
schema = pd.read_sql('PRAGMA table_info(ssdse_b)', conn)
print(f'カラム数: {len(schema)}')
print('先頭 5 カラム:', schema['name'].head().tolist())

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

投入レコード数: 564
カラム数: 112
先頭 5 カラム: ['year', 'Code', 'Prefecture', 'A1101', 'A110101']

💬 結果の読み方: 47 都道府県 × 12 年 = 564 行が正しく投入。 pandas の to_sql は INSERT 文を 1 行ずつ発行するのではなく、内部でバルクインサート (executemany) を使い高速。

② SELECT で人口上位 10 都道府県を取得

🎯 このコードでやること: 2023 年の人口上位 10 都道府県を SELECT で取得。 WHERE + ORDER BY + LIMIT の基本パターン。

📥 入力データ: ssdse.db の ssdse_b テーブル (564 行)

import pandas as pd
import sqlite3

conn = sqlite3.connect('ssdse.db')
query = '''
SELECT Prefecture, A1101 AS 人口
  FROM ssdse_b
 WHERE year = 2023
 ORDER BY A1101 DESC
 LIMIT 10;
'''
result = pd.read_sql(query, conn)
print(result.to_string(index=False))

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

Prefecture     人口
      東京都 14086000
     神奈川県  9229000
       大阪府  8763000
       愛知県  7477000
       埼玉県  7331000
       千葉県  6257000
       兵庫県  5370000
       福岡県  5103000
       北海道  5092000
       静岡県  3555000

💬 結果の読み方: 上位 10 都道府県は東京・神奈川・大阪を含む大都市圏 + 北海道・福岡などの地方中核。 SELECT は DML 中で最も使われる命令で、全 DML 命令の 95% 以上を占める (実務感覚)。

③ GROUP BY で年代別集計

🎯 このコードでやること: 47 都道府県の合計人口を年代ごとに集計し、日本の人口推移を確認する。 GROUP BY + SUM の基本パターン。

📥 入力データ: ssdse.db の ssdse_b テーブル

import pandas as pd
import sqlite3

conn = sqlite3.connect('ssdse.db')
query = '''
SELECT year,
       SUM(A1101) AS 全国人口合計,
       AVG(A1101) AS 平均都道府県人口,
       COUNT(*) AS 都道府県数
  FROM ssdse_b
 GROUP BY year
 ORDER BY year;
'''
result = pd.read_sql(query, conn)
print(result.to_string(index=False))

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

 year  全国人口合計  平均都道府県人口  都道府県数
 2012 127593000     2714745       47
 2013 127414000     2710936       47
 ...
 2023 124352000     2645808       47
 → 日本の人口は 2012 → 2023 で約 326 万人減少

💬 結果の読み方: 全 47 都道府県を集計すると、日本の人口は 11 年で約 2.5% 減少。 GROUP BY は実務で最も使われる DML 構造の 1 つ。「集計の単位 + 集計関数 (SUM/AVG/COUNT/MAX/MIN)」がセットで覚えるのがコツ。

④ UPDATE とトランザクション

🎯 このコードでやること: 東京都の 2023 年人口を仮に更新する例。 UPDATE 前に SELECT で確認 → BEGIN TRANSACTION → 確認 → COMMIT or ROLLBACK の安全な手順を体験。

📥 入力データ: ssdse.db

import sqlite3

conn = sqlite3.connect('ssdse.db')
cur = conn.cursor()

# 1. まず確認 (絶対重要)
cur.execute("SELECT A1101 FROM ssdse_b WHERE Prefecture='東京都' AND year=2023")
before = cur.fetchone()[0]
print(f'更新前: 東京都 2023 年人口 = {before}')

# 2. トランザクション開始
cur.execute('BEGIN TRANSACTION')

# 3. UPDATE
new_value = 14_100_000  # 仮の更新値
cur.execute(
    "UPDATE ssdse_b SET A1101 = ? WHERE Prefecture='東京都' AND year=2023",
    (new_value,)
)
print(f'影響行数: {cur.rowcount}')  # 必ず 1 行のはず

# 4. 確認
cur.execute("SELECT A1101 FROM ssdse_b WHERE Prefecture='東京都' AND year=2023")
print(f'(トランザクション中) 値 = {cur.fetchone()[0]}')

# 5. 元に戻す (実データを壊さないため ROLLBACK)
conn.rollback()
print('ROLLBACK 実行')

cur.execute("SELECT A1101 FROM ssdse_b WHERE Prefecture='東京都' AND year=2023")
print(f'最終値: {cur.fetchone()[0]} (元に戻った)')

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

更新前: 東京都 2023 年人口 = 14086000
影響行数: 1
(トランザクション中) 値 = 14100000
ROLLBACK 実行
最終値: 14086000 (元に戻った)

💬 結果の読み方: 影響行数が想定 (1) と一致することを確認してから COMMIT、違えば ROLLBACK。この「BEGIN → 確認 → COMMIT/ROLLBACK」の儀式が本番運用での事故防止に必須。 UPDATE WHERE 条件ミスで全行更新する事故は実務で頻発。

⑤ JOIN で複数テーブル連結

🎯 このコードでやること: SSDSE-B-2026 と都道府県マスタを JOIN して、地方区分 (東北、関東、 ...) 別に人口を集計する。 INNER JOIN の典型例。

📥 入力データ: ssdse.db + 自作の都道府県地方マスタ

import pandas as pd
import sqlite3

conn = sqlite3.connect('ssdse.db')

# 都道府県と地方の対応表を作成
region_map = pd.DataFrame([
    {'Prefecture': '北海道', 'Region': '北海道'},
    {'Prefecture': '青森県', 'Region': '東北'},
    {'Prefecture': '東京都', 'Region': '関東'},
    {'Prefecture': '神奈川県', 'Region': '関東'},
    {'Prefecture': '大阪府', 'Region': '近畿'},
    {'Prefecture': '愛知県', 'Region': '中部'},
    # ... 47 都道府県分
])
region_map.to_sql('prefecture_region', conn, if_exists='replace', index=False)

# JOIN
query = '''
SELECT r.Region AS 地方,
       SUM(s.A1101) AS 人口合計
  FROM ssdse_b s
  INNER JOIN prefecture_region r ON s.Prefecture = r.Prefecture
 WHERE s.year = 2023
 GROUP BY r.Region
 ORDER BY 人口合計 DESC;
'''
result = pd.read_sql(query, conn)
print(result.to_string(index=False))

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

地方  人口合計
関東 30903000  (東京 + 神奈川 + ...)
近畿 18763000
中部 17477000
...

💬 結果の読み方: JOIN で別テーブルの情報 (地方区分) を結合して集計可能に。 INNER JOIN は両テーブルにある行のみ、 LEFT JOIN は左テーブル全行 (右がない場合は NULL)。

🔒 トランザクションと ACID

DML を本番運用するうえで欠かせないのが トランザクションと ACID 特性。数式を言葉で読み解くと、これは「データベース操作の安全保証ルール」です。

特性	意味	例
Atomicity (原子性)	全て成功か全て失敗	銀行送金: 引き出し成功・入金失敗は許されない
Consistency (一貫性)	整合性ルールを常に満たす	合計残高がトランザクション前後で同じ
Isolation (分離性)	並行実行でも独立	2 人同時に更新しても結果は順次実行と同じ
Durability (永続性)	コミット後は障害でも残る	停電してもデータが消えない

SQL の BEGIN; ...; COMMIT; でトランザクション。失敗したら ROLLBACK;。 PostgreSQL や Oracle は ACID を厳密に守るが、 NoSQL では緩い (BASE 原則) ことが多い。

🔐 分離レベル (Isolation Level)

並行トランザクションでどの程度厳密に独立を保つか。厳しいほど安全だが遅い。

レベル	許される現象	使い所
READ UNCOMMITTED	Dirty Read, Non-repeatable, Phantom	ほぼ使わない
READ COMMITTED	Non-repeatable, Phantom	PostgreSQL デフォルト
REPEATABLE READ	Phantom のみ	MySQL デフォルト
SERIALIZABLE	なし (最も厳密)	金融など高信頼が必要な場面

SSDSE のような分析用途では READ COMMITTED で十分。在庫管理や金融はより厳格な REPEATABLE READ や SERIALIZABLE が必要。

🔓 ロックの種類

種類	取得契機	影響
共有ロック (S)	SELECT (一部 DBMS)	他者の SELECT は OK、 UPDATE 不可
排他ロック (X)	UPDATE, DELETE, INSERT	他者は何もできない
行ロック	WHERE で 1 行特定	他行は無影響
テーブルロック	ALTER TABLE 等	テーブル全体停止
デッドロック	循環的ロック	DBMS が片方を強制終了

ロック競合は実務で頻発するパフォーマンス問題。「短いトランザクション」「同じ順序で複数行ロック」が回避のコツ。

🚨 SQL インジェクション — 必ず防ぐ

DML を実行するアプリで最も多い脆弱性が SQL インジェクション。ユーザー入力を文字列連結で SQL に埋め込むと、攻撃者に任意の SQL を実行されます。

[NG] 危険な例:
query = f"SELECT * FROM users WHERE name = '{user_input}'"
→ user_input が "'; DROP TABLE users; --" だと全テーブル削除!

[OK] プレースホルダ使用:
cursor.execute("SELECT * FROM users WHERE name = ?", (user_input,))
→ 値は別途バインドされ、 安全

Python の sqlite3, psycopg2, mysql.connector はすべてプレースホルダ対応。 ? や %s で書き、値は別引数で渡す。 ORM (SQLAlchemy 等) を使えば自動的に安全。

🐍 追加 Python 実装

⑥ DELETE のサンプル (BEGIN/ROLLBACK で安全に)

🎯 このコードでやること: 2012 年のレコード (47 件) を DELETE する例を、必ず ROLLBACK して実データを保護しながら体験する。影響行数の確認が安全運用の鍵。

📥 入力データ: ssdse.db (564 行)

import sqlite3

conn = sqlite3.connect('ssdse.db')
cur = conn.cursor()

# 削除前の件数確認
cur.execute('SELECT COUNT(*) FROM ssdse_b')
before = cur.fetchone()[0]
print(f'削除前: {before} 行')

# トランザクション開始
cur.execute('BEGIN')

# DELETE
cur.execute('DELETE FROM ssdse_b WHERE year = 2012')
print(f'影響行数: {cur.rowcount}')

# 削除後の件数
cur.execute('SELECT COUNT(*) FROM ssdse_b')
print(f'(トランザクション中) {cur.fetchone()[0]} 行')

# 実データを壊さないため ROLLBACK
conn.rollback()
print('ROLLBACK 実行')

# 元に戻ったか確認
cur.execute('SELECT COUNT(*) FROM ssdse_b')
print(f'最終: {cur.fetchone()[0]} 行 (元通り)')

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

削除前: 564 行
影響行数: 47
(トランザクション中) 517 行
ROLLBACK 実行
最終: 564 行 (元通り)

💬 結果の読み方: 影響行数が想定 (47 = 都道府県数 × 1 年) と一致することを確認。もし 517 とか想定外なら ROLLBACK で守る。これが本番運用の鉄則。

⑦ Window 関数で前年比を計算

🎯 このコードでやること: 各都道府県の人口について、 LAG 関数で前年の値を取得し、増減率を計算する。 SQL の Window 関数はピボットなしで時系列比較ができる強力機能。

📥 入力データ: ssdse.db

import pandas as pd
import sqlite3

conn = sqlite3.connect('ssdse.db')
query = '''
SELECT Prefecture, year, A1101 AS pop,
       LAG(A1101) OVER (PARTITION BY Prefecture ORDER BY year) AS prev_pop,
       A1101 - LAG(A1101) OVER (PARTITION BY Prefecture ORDER BY year) AS diff
  FROM ssdse_b
 WHERE Prefecture IN ('東京都', '鳥取県', '沖縄県')
 ORDER BY Prefecture, year;
'''
result = pd.read_sql(query, conn)
print(result.to_string(index=False))

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

Prefecture  year      pop  prev_pop    diff
      東京都  2012 13230000      None    None  ← 初年度
      東京都  2013 13300000  13230000   70000
      東京都  2014 13390000  13300000   90000
      ...
      東京都  2023 14086000  14047594   38406
      鳥取県  2012   582000      None    None
      鳥取県  2023   537000    544000   -7000  ← 減少
      沖縄県  2012  1409000      None    None
      沖縄県  2023  1468000  1467000    1000  ← 微増

💬 結果の読み方: 東京は 12 年で約 86 万人増、鳥取は約 4 万 5 千人減、沖縄は微増。 LAG (PARTITION BY Pref ORDER BY year) で「同じ Pref 内の前年値」が取れる。 Window 関数の威力。

🐍 追加 Python — 47 都道府県の人口ランキング

⑧ Window 関数で順位付け

🎯 このコードでやること: 2023 年の 47 都道府県人口に ROW_NUMBER と RANK でランキングを付け、同順位の有無を確認する。数式を言葉で読み解くと「順序統計量を SQL で計算」する例。

📥 入力データ: ssdse.db (47 件 × 2023 年)

import pandas as pd
import sqlite3

conn = sqlite3.connect('ssdse.db')
query = '''
SELECT Prefecture, A1101 AS 人口,
       ROW_NUMBER() OVER (ORDER BY A1101 DESC) AS 行番号,
       RANK()       OVER (ORDER BY A1101 DESC) AS 順位,
       DENSE_RANK() OVER (ORDER BY A1101 DESC) AS 密順位,
       NTILE(4)     OVER (ORDER BY A1101)      AS 四分位
  FROM ssdse_b
 WHERE year = 2023
 ORDER BY A1101 DESC
 LIMIT 10;
'''
result = pd.read_sql(query, conn)
print(result.to_string(index=False))

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

Prefecture     人口  行番号  順位  密順位  四分位
      東京都 14086000      1     1       1      4
     神奈川県  9229000      2     2       2      4
       大阪府  8763000      3     3       3      4
       愛知県  7477000      4     4       4      4
       埼玉県  7331000      5     5       5      4
       千葉県  6257000      6     6       6      4
       兵庫県  5370000      7     7       7      4
       福岡県  5103000      8     8       8      4
       北海道  5092000      9     9       9      4
       静岡県  3555000     10    10      10      4

💬 結果の読み方: 47 都道府県の人口は全て異なるので、 ROW_NUMBER / RANK / DENSE_RANK が一致。四分位 (NTILE(4)) で上位 12 都道府県は Q4。 Window 関数は SQL:2003 で標準化された比較的新しい機能だが、現代分析には必須。

⑨ UPSERT パターン (INSERT or UPDATE)

🎯 このコードでやること: 「都道府県データが既存ならUPDATE、なければINSERT」という UPSERT 操作を SQLite で実装する。実務でよく使われるパターン。

📥 入力データ: 新規追加したい都道府県データのサンプル

import sqlite3

conn = sqlite3.connect('ssdse.db')
cur = conn.cursor()

# 仮想的な「県人口集計」テーブルを作成 (主キー: Prefecture)
cur.execute('''
CREATE TABLE IF NOT EXISTS pref_summary (
  Prefecture TEXT PRIMARY KEY,
  total_pop INTEGER,
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
)
''')

# UPSERT (SQLite 3.24+ 構文)
data = [
    ('東京都', 14086000),
    ('鳥取県', 537000),
    ('沖縄県', 1468000),
]
cur.executemany('''
INSERT INTO pref_summary (Prefecture, total_pop) VALUES (?, ?)
ON CONFLICT(Prefecture) DO UPDATE SET
  total_pop = excluded.total_pop,
  updated_at = CURRENT_TIMESTAMP
''', data)
conn.commit()

# 確認
cur.execute('SELECT * FROM pref_summary')
for row in cur.fetchall():
    print(row)

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

('東京都', 14086000, '2026-05-24 02:30:00')
('鳥取県', 537000, '2026-05-24 02:30:00')
('沖縄県', 1468000, '2026-05-24 02:30:00')

→ 2 回実行すると、 updated_at だけ新しくなる (UPDATE が走った証拠)

💬 結果の読み方: UPSERT は「データの取り込みを冪等にする」便利パターン。同じデータを何度実行しても結果が同じになるので、 ETL バッチで多用される。 PostgreSQL は ON CONFLICT、 MySQL は ON DUPLICATE KEY UPDATE。

⚠️ よくある落とし穴

❌ WHERE 句忘れ

UPDATE 表 SET 列 = 値 だけだと全行が書き換わる。本番では BEGIN; UPDATE …; -- 確認 ROLLBACK; or COMMIT; の儀式を。

❌ LIKE のワイルドカード

LIKE '%abc%' は両端ワイルドカードで遅い。インデックスが効かない。

❌ NULL の扱い

= NULL は常に偽。必ず IS NULL を使う。

❌ 暗黙の型変換

WHERE 文字列カラム = 123 のような比較は予期せぬ結果を生む。

❌ SQL インジェクション

ユーザー入力を文字列連結で SQL に埋め込むと、任意 SQL を実行されかねない。必ずプレースホルダを使う。

⚠️ WHERE 句の落とし穴

状況	NG 例	正しい書き方
NULL 比較	`WHERE x = NULL`	`WHERE x IS NULL`
大小文字	`WHERE name = 'Tokyo'`	`WHERE LOWER(name) = 'tokyo'`
暗黙の型変換	`WHERE id = '123'` (id が int)	`WHERE id = 123`
否定の NOT IN	NULL を含むサブクエリで予期せぬ結果	`NOT EXISTS` に書き換え
LIKE のワイルドカード	`LIKE '%abc%'` (両端) でインデックス無効	全文検索エンジン (FTS) 検討
関数適用	`WHERE YEAR(date) = 2023`	`WHERE date BETWEEN '2023-01-01' AND '2023-12-31'`

⚡ DML パフォーマンス・チューニング

インデックス: WHERE / JOIN / ORDER BY 列に作成。検索が 100〜10000 倍速くなる
EXPLAIN: クエリ実行計画を確認 (PostgreSQL: EXPLAIN ANALYZE)
カバリング・インデックス: SELECT する列もインデックスに含めて、テーブル参照不要に
JOIN 順序: 小さいテーブルから JOIN すると速い
サブクエリより JOIN: 一般に JOIN の方が高速
UNION ALL: 重複排除不要なら UNION より速い
パーティション: 大きなテーブルを年度等で物理分割
マテリアライズドビュー: 集計結果を保存して再計算回避
バルク挿入: 1 行ずつ INSERT より INSERT INTO ... VALUES (...), (...), ...
VACUUM: PostgreSQL/SQLite で不要領域を回収

📇 インデックスの種類

種類	仕組み	用途
B-Tree (バランス木)	標準的なソート済み木	等価・範囲検索の万能型
Hash	ハッシュ値で位置特定	等価検索のみ、範囲不可
GIN (Generalized Inverted)	転置インデックス	全文検索、 JSONB
GIST	幾何データ向け	地理座標、範囲型
BRIN (Block Range)	ブロックレベル	巨大時系列データ
部分インデックス	WHERE 条件付き	使う部分だけ
関数インデックス	関数結果にインデックス	`LOWER(name)` 等
複合インデックス	複数列でソート	WHERE で複数条件

🏢 主要 RDBMS 比較

DBMS	長所	短所	用途
SQLite	ファイル 1 個、設定不要	同時書き込み弱い	個人開発、教育
PostgreSQL	機能豊富、 SQL 標準準拠	設定やや複雑	本格運用、分析
MySQL	速い、 Web で定番	SQL 標準準拠ゆるい	Web アプリ
MariaDB	MySQL 互換、オープン	同上	MySQL 代替
Oracle	エンタープライズ機能	高額	大企業
SQL Server	Windows 統合	非 Windows で不便	Microsoft 系
DuckDB	分析特化、高速	OLTP 不向き	データ分析
BigQuery	クラウド、ペタバイト級	有料、ベンダーロック	大規模分析
Snowflake	マルチクラウド DWH	有料	企業分析基盤
Redshift	AWS 統合、 DWH	運用コスト	AWS ユーザー

🪟 Window 関数 — 現代 DML の核心

「グループごとに集計しつつ、行も個別に保持したい」というニーズに応えるのが Window 関数。 SQL:2003 以降標準。

関数	用途	例
ROW_NUMBER()	連番	都道府県人口ランキング
RANK()	同順位許容ランク	同人口は同順位、次は飛ぶ
DENSE_RANK()	同順位許容、連続	同上だが順位は連続
LAG(x, n)	n 行前の値	前年比計算
LEAD(x, n)	n 行後の値	次年予測
SUM() OVER (...)	累積和	累積人口
AVG() OVER (...)	移動平均	5 年移動平均
NTILE(n)	n 分割	四分位

例: 「都道府県別の前年比人口増減」:

SELECT Prefecture, year, A1101,
       A1101 - LAG(A1101) OVER (PARTITION BY Prefecture ORDER BY year)
         AS 前年差
  FROM ssdse_b
 WHERE Prefecture = '東京都'
 ORDER BY year;

⚠️ DML 落とし穴コレクション

WHERE 忘れ: UPDATE/DELETE で全行に影響 → BEGIN; ... ROLLBACK; の儀式必須
NULL 比較: = NULL ではなく IS NULL
暗黙の型変換: 文字列と数値の混在
日付フォーマット: ISO 8601 (YYYY-MM-DD) で統一
大文字小文字: SQL キーワードは大文字、識別子は環境依存
予約語の識別子: "order" や "user" はクォート必須
LIKE のワイルドカード: % は 0 文字以上、 _ は 1 文字
カラム順序: INSERT INTO t VALUES (...) で列順依存
自動コミット: ライブラリにより設定が違う
文字エンコーディング: DB と接続両方の設定が必要
タイムゾーン: UTC で統一、表示時のみ JST 変換
カスケード削除: 外部キーで連鎖削除に注意

🔄 ORM — Python から DML を扱う高レベル方法

ORM	特徴	用途
SQLAlchemy	Python 標準、柔軟	幅広く
Django ORM	Django 統合	Web アプリ
Peewee	軽量	小規模
SQLModel	FastAPI 統合、型ヒント	モダン API
Tortoise ORM	非同期対応	async/await
raw SQL	ORM 不使用	パフォーマンス重視

ORM は SQL を書かなくて済むが、 N+1 問題 (1 件取得ごとに 1 クエリ発行) などの落とし穴あり。 SSDSE 程度の分析なら pandas + raw SQL の方が直感的。

🐼 pandas vs SQL — どちらを使うか

操作	pandas	SQL
SELECT	`df[['col1', 'col2']]`	`SELECT col1, col2 FROM t`
WHERE	`df[df.x > 100]`	`WHERE x > 100`
ORDER BY	`df.sort_values('x')`	`ORDER BY x`
GROUP BY	`df.groupby('y').sum()`	`GROUP BY y`
JOIN	`pd.merge(df1, df2, on='id')`	`JOIN ON id`
UPDATE	`df.loc[df.x==1, 'y'] = 2`	`UPDATE t SET y=2 WHERE x=1`
INSERT	`df.append(new_row)`	`INSERT INTO t VALUES`
DELETE	`df.drop(idx)`	`DELETE FROM t WHERE`

使い分け: メモリに収まる (< 数 GB) なら pandas、大規模なら SQL。 SSDSE-B-2026 (564 行) は完全に pandas 範囲。

⚠️ 条件・限界・誤解回避（DML: データ操作言語）

DML (Data Manipulation Language) は SELECT/INSERT/UPDATE/DELETE/MERGE など、リレーショナル DB のデータ自体を操作する SQL のサブセットです。強力で生産性が高い反面、トランザクション管理・性能設計・データ整合性の理解が不十分だと「数百万行を誤って更新」「本番環境のロックで業務停止」といった致命的事故を起こします。 SSDSE-B-2026 を題材に、適用条件・限界・典型的な誤解を整理します。

適用条件

スキーマと制約の理解: DML は DDL で定義された型・制約 (NOT NULL, UNIQUE, FOREIGN KEY, CHECK) を遵守する形でしか操作できません。 SSDSE-B-2026 を都道府県マスタと結合するなら、 prefecture_code を主キーに正規化して FOREIGN KEY を張るのが王道。制約に違反する INSERT/UPDATE は失敗し、トランザクション全体がロールバックされます。
トランザクション境界の明示: 複数行を更新するときは BEGIN; ... COMMIT; で境界を明示。暗黙コミット (autocommit) のままだと、途中で失敗しても部分反映されて整合性が壊れます。 ACID 特性 (Atomicity, Consistency, Isolation, Durability) を意識した運用が前提です。
WHERE 句の必須性: UPDATE/DELETE は WHERE を省略すると全行が対象になります。 SSDSE のように 47 行しかないテーブルでも、本番では数億行になることを想定し、必ず WHERE + LIMIT + 事前 SELECT 確認の三点セットを徹底。
適切なインデックス: WHERE 列・JOIN 列にインデックスがないとフルテーブルスキャンになり、ロック範囲も広がります。 EXPLAIN ANALYZE で実行計画を確認し、想定通りにインデックスが使われているかを検証。
分離レベルの選択: READ COMMITTED (デフォルト多数)・REPEATABLE READ・SERIALIZABLE の違いを理解し、業務要件に合わせて設定。 SSDSE のような分析専用 DB なら READ COMMITTED で十分ですが、在庫・金融なら SERIALIZABLE 相当が必要なことも。
権限管理 (GRANT/REVOKE): アプリ用ユーザーには SELECT/INSERT/UPDATE/DELETE のみ付与し、 DDL や TRUNCATE は禁止。分析者には読み取り専用ユーザーを用意して本番改変を防ぐ。

限界

大量更新のロックと性能: 1 トランザクションで数千万行を UPDATE するとロックエスカレーション・WAL 肥大・レプリカ遅延を引き起こします。バッチ更新は LIMIT 10000 単位で分割し、適度にコミットするのが定石。
RDBMS 方言の違い: 標準 SQL を中心にしても、 PostgreSQL の RETURNING、 MySQL の INSERT ... ON DUPLICATE KEY UPDATE、 SQL Server の MERGE、 BigQuery の MERGE INTO など差異があります。移植性を考えるなら共通部分にとどめる工夫が必要。
NULL 比較の罠: WHERE x = NULL は常に NULL (=偽) になり、期待した行が返りません。 WHERE x IS NULL を使う必要があります。集計関数も NULL の扱いが異なる (COUNT(*) vs COUNT(col))。
監査・履歴の欠如: DML は「現状」を更新するだけで、過去の状態を保存しません。監査要件があるなら、トリガで履歴テーブルにコピーする・CDC (Change Data Capture) を導入する・SCD type 2 で設計する等の対策が必要。
並行更新の競合: 同時に複数セッションが同じ行を更新するとデッドロックが発生。アプリ側でリトライ機構を実装し、再試行可能なトランザクション設計にする。

誤解回避

「TRUNCATE は DELETE の高速版」は誤り: TRUNCATE は DDL に分類され、ロールバックできない実装が多く、トリガが発火しません。監査要件のある環境では使えない場合があります。
「DELETE すれば容量が空く」は誤り: PostgreSQL は DELETE 直後は物理空間を解放せず、 VACUUM (またはオートバキューム) が必要です。 InnoDB も同様で OPTIMIZE TABLE が要ります。
「サブクエリより JOIN が常に速い」は誤り: 最近のオプティマイザはサブクエリを JOIN に書き換えます。むしろ EXISTS や IN の方が意図が明確で読みやすいケースが多い。
「ORDER BY を入れれば順序が保証される」は誤り: INSERT INTO ... SELECT ... ORDER BY は宛先テーブルの並び順を保証しません。 ORDER BY は SELECT 結果の順序付けにのみ有効。
「インデックスを増やせば速くなる」は誤り: SELECT は速くなりますが、 INSERT/UPDATE/DELETE は遅くなります。書き込み頻度の高いテーブルではインデックスを最小限に。
「LIMIT で安全」は誤り: UPDATE ... LIMIT 100 は対象がランダム抽出される可能性があり、確定性がありません。 ORDER BY と組み合わせ、主キーを基準に処理する。

典型ワークフロー

要件整理: SSDSE-B-2026 を題材に「東京を除く 46 道府県で 65 歳以上人口を集計」のような要件を SQL に落とす前に、自然言語で書き出す。
SELECT で結果確認: SELECT prefecture, elderly_pop FROM ssdse WHERE prefecture <> '東京'; で結果セットを確認。想定行数・想定値域を目視。
トランザクション開始: BEGIN; でトランザクション開始。
更新実行: UPDATE ssdse SET flagged = TRUE WHERE prefecture <> '東京' AND elderly_pop > 1000000;。影響行数を EXPLAIN や RETURNING で確認。
検証: SELECT COUNT(*) FROM ssdse WHERE flagged = TRUE; で期待数と一致するかチェック。
コミットまたはロールバック: 期待通りなら COMMIT;、想定外なら ROLLBACK;。
監査ログ確認: pg_stat_statements / slow query log / 履歴テーブルで実行履歴を残す。
性能分析: EXPLAIN (ANALYZE, BUFFERS) で実行計画とコストを確認し、必要ならインデックス追加。

ケーススタディ

事例1: SSDSE-B-2026 を分析用 DM に取り込む — CSV を staging テーブルに INSERT し、マスタと JOIN して正規化された fact テーブルに MERGE。トランザクションで包み、失敗時は ROLLBACK。ロード後に VACUUM ANALYZE で統計情報を更新。
事例2: 大量バッチ UPDATE のチャンク化 — 1 億行を一度に UPDATE せず、主キーで WHERE id BETWEEN n AND n+10000 のように区切って繰り返す。各チャンクの後に COMMIT し、レプリカ遅延を監視。
事例3: UPSERT (INSERT ... ON CONFLICT) — PostgreSQL の INSERT ... ON CONFLICT (id) DO UPDATE SET ... で「あれば更新、なければ挿入」を 1 文で実現。 SSDSE のような毎年の更新スナップショットに最適。
事例4: ソフトデリート設計 — 物理 DELETE せず UPDATE deleted_at = NOW() で論理削除。監査・復元・参照整合性に強く、多くの業務システムで採用される。
事例5: CDC (Change Data Capture) — Debezium で WAL を読み、 DML イベントを Kafka に流す。 DWH やデータレイクへリアルタイム同期を実現する典型構成。

DML は「データを動かす最後のキー操作」であると同時に「事故が一番起きる場所」です。 SSDSE-B-2026 のような小規模データで「SELECT で確認 → BEGIN → 更新 → 検証 → COMMIT」の規律を体に叩き込んでから本番に臨みましょう。

運用 Tips: 安全に DML を回すための実務知見

本番更新前のドライラン: 更新前に SELECT ... FOR UPDATE + ROLLBACK で「影響範囲だけ事前確認」する手法。 PostgreSQL なら EXPLAIN UPDATE ... や BEGIN; UPDATE ...; SELECT * FROM updated_table; ROLLBACK; を組み合わせて、副作用なしで挙動を観察できます。
WHERE 句のセーフガード: 重要テーブルの UPDATE/DELETE 文には必ず主キー条件か日付範囲を含め、単独の UPDATE t SET col=val は禁止する社内ルールを敷きます。 ORM (Django, SQLAlchemy) でも .all().delete() のような書き方は警告する lint を導入。
ロック時間の監視: pg_locks, SHOW PROCESSLIST, v$session_longops 等でロック保持時間を監視し、一定時間を超えたら自動 kill する仕組みを整備。 SSDSE のような分析専用 DB でも、長時間ロックはレプリケーション遅延の原因。
履歴テーブルの設計: 監査要件があるなら、トリガで INSERT INTO history (op, old_row, new_row, updated_by, updated_at) を発火させ、 BEFORE/AFTER 値を残します。 GDPR の権利行使対応にも有効。
テスト DB と本番 DB の差分管理: スキーマ移行ツール (Flyway, Alembic, Liquibase) で DDL/DML マイグレーションを版管理。 SSDSE-B-2026 の取り込みスクリプトも、 idempotent (何度実行しても同じ結果) になるよう ON CONFLICT で書く。
ベンチマークと負荷試験: pgbench, sysbench, JMeter で典型クエリの TPS を計測し、 SLO (例: 99 パーセンタイル 200ms 以内) を設定。本番デプロイ前にステージング環境で同等負荷をかける。

初学者がよく踏むトラップ集

DML を学び始めた人がよく踏む地雷を 8 つに整理しておきます。 1) WHERE を忘れた全行更新、 2) NULL = NULL の落とし穴、 3) サブクエリの相関エラー、 4) 結合キー間違いによるデカルト積、 5) 文字列リテラルとカラム名の混同 (シングル/ダブルクォート)、 6) DATE と TIMESTAMP の暗黙キャスト、 7) ORDER BY なしの LIMIT による不確定な結果、 8) UPDATE 直後の COMMIT 忘れ。 SSDSE-B-2026 のような小規模データで実験して全部踏んだ後、本番に挑むのが理想です。

DML と現代データスタックの接続

伝統的 RDBMS の DML は今でも分析・運用の土台ですが、現代では DWH (Snowflake, BigQuery, Redshift)、データレイクハウス (Databricks, Iceberg)、ストリーミング (Kafka, Flink) と組み合わせて使うことが増えています。 SSDSE-B-2026 を題材に置いてみると、「DML で staging → MERGE で dim/fact 更新 → dbt model で集計 → BI で可視化」というパイプラインが現代的な形です。 dbt は SQL ベースの DML を Jinja テンプレートで再利用しやすくし、 incremental model で大量更新を効率化します。一方ストリーミング DML では、 Kafka Connect + Debezium で OLTP の WAL を CDC として配信し、 DWH 側で MERGE INTO を実行する構成が標準化しつつあります。こうした流れの中でも、トランザクション境界・WHERE 句の確認・履歴管理という DML の基本規律は変わりません。

📋 DML を安全に運用するための前提条件と限界 (誤解回避)

DML (Data Manipulation Language: INSERT/UPDATE/DELETE/MERGE) は強力だが、 1 つの WHERE 句のミスで全行が壊れる。 SSDSE-B-2026 で実験する場合も、本番運用と同じ規律で扱う必要がある。

前提 1: トランザクション境界が明確

DML は BEGIN; ... COMMIT; (または ROLLBACK) で囲み、全体を 1 つの原子的な単位として扱う。 COMMIT を忘れたまま接続が切れると、セッション末で自動 ROLLBACK して変更が消える。 SSDSE-B のような小データでも、まず BEGIN + 確認 SELECT + COMMIT の習慣をつける。

前提 2: WHERE 句は SELECT で必ず先に確認

UPDATE prefecture SET population=0 WHERE region='北海道' の前に、必ず SELECT * FROM prefecture WHERE region='北海道' で対象行を目視する。「north hokkaido」のようなタイポで対象が 0 件、または逆に WHERE を抜いて全 47 県が更新される事故を防ぐ。

前提 3: 履歴 (audit log) の保持

UPDATE/DELETE は元の値を破壊する。監査可能性のため、 ① 別テーブルへ前値を INSERT、 ② temporal table (時間軸付きテーブル)、 ③ CDC (Change Data Capture) のいずれかを併用するのが理想。 SSDSE-B の年次データなら、 year 列を追加して上書きせず追記する設計が最も簡単。

限界 1: 大量更新はロックと WAL を爆発させる

UPDATE 1000万行 SET ... は WAL (Write-Ahead Log) を膨張させ、ロック待ちで他クエリが詰まる。 chunked UPDATE (LIMIT 10000 × 1000 回) または INSERT INTO new_table SELECT ... ; RENAME のスワップ戦略に切り替える。

限界 2: ORDER BY なしの LIMIT は不定

DELETE FROM tbl WHERE ... LIMIT 100 でどの 100 行が削除されるかは、 ORDER BY なしでは DB 実装依存。 PostgreSQL/MySQL でも結果が再現しない。必ず ORDER BY id LIMIT 100 のように決定的に書く。

📝 理解度チェック (5 問 / SSDSE-B-2026 を想定)

Q1. UPDATE prefecture SET region='関東' WHERE prefecture_code IN ('13','11','12','14') を実行する前に必ず行うべき確認手順を 3 ステップで記述せよ。
Q2. 47 都道府県のうち、同じ name で 2 行ある (重複登録) ことが判明した。重複を削除しつつ ID の小さい方を残す DML 文を 1 文で書け。
Q3. 1000 万行のテーブルで UPDATE をすると数時間かかる。 1) chunked UPDATE と 2) スワップ戦略の長所と短所を比較せよ。
Q4. MERGE INTO 文が「DWH ではよく使われるが、 OLTP では使われない」と言われる理由を 2 行で述べよ。
Q5. SSDSE-B のような少量データで DML を学ぶときに、本番運用に活きる規律 (チェックリスト) を 5 項目挙げよ。

解答方針

A1. ① BEGIN でトランザクション開始、 ② SELECT prefecture_code, region FROM prefecture WHERE prefecture_code IN (...) で対象行を目視、 ③ 想定行数と一致したら UPDATE 実行 → SELECT で再確認 → COMMIT。
A2. DELETE FROM prefecture WHERE id NOT IN (SELECT MIN(id) FROM prefecture GROUP BY name)。ただし MySQL では同テーブル参照に制限あり、一時テーブル経由が必要。
A3. chunked UPDATE は安全だがオンライン中も書き込み発生。スワップは並列構築で速いが、トリガ・外部キー・参照クエリの整合性管理が必要。
A4. MERGE は冪等な「upsert」処理に最適だが、同時並行性が高い OLTP では行ロックが取られすぎて性能劣化する。 OLTP は INSERT ON CONFLICT などの単純文が好まれる。
A5. ① BEGIN/COMMIT を必ず使う、 ② SELECT で WHERE を事前確認、 ③ 件数を想定値と比較、 ④ 履歴を残す (timestamp 列 or audit table)、 ⑤ ステージング → 本番の段階的適用。

📊 数式に値を入れて手で計算する — DML 行数変化と人口密度計算

DML は数学的には集合演算。 INSERT は集合の和 $R \leftarrow R \cup \{t\}$、 DELETE は差 $R \leftarrow R \setminus \sigma_p R$。一連の DML 操作後のテーブル行数 $n$ は:

$$n_{\text{final}} = n_0 + \sum_i \Delta_{\text{INSERT}_i} - \sum_j \Delta_{\text{DELETE}_j}$$

UPDATE は行数を変えない（$\Delta = 0$）。 INSERT は $\Delta > 0$、 DELETE は $\Delta > 0$（引く方向）。

Step 1: 各 DML オペレーションの行数変化

操作	$\Delta$ (行数変化)	残行数 $n$
初期状態 (SSDSE-B 2023 年分)	—	47
INSERT 5 行 (新規データ追加)	+5	52
UPDATE WHERE pop > 5000000 (8 行対象)	0 (件数不変)	52
DELETE WHERE pop < 600000 (2 行対象: 鳥取・島根)	−2	50
INSERT 3 行 (補完データ)	+3	53

Step 2: 式に値を代入

n_final = n0 + Σ(INSERT) - Σ(DELETE)
        = 47  + (5 + 3)  - 2
        = 47  + 8        - 2
        = 53 行

Step 3: さらに人口密度 (density = 人口 / 面積) を UPDATE で計算

東京都の人口密度: $\text{density} = \dfrac{A1101 \times 1000}{B1101} = \dfrac{14048 \times 1000}{2194} \approx 6402.9 \text{ 人/km}^2$

🐍 Python で Step 2・Step 3 を再現

このコードでやること: 手計算 Step 2 (行数変化の式) と Step 3 (東京都の人口密度) を Python で検証し、一致を確認する。

# Step 2: 行数変化の式 n_final = n0 + Σ(INSERT) - Σ(DELETE)
n0 = 47   # SSDSE-B-2026 の 2023 年分
ins1, ins2 = 5, 3     # INSERT x2
del1 = 2             # DELETE (pop < 600000)
n_final = n0 + ins1 + ins2 - del1
print(f"最終行数: {n0} + {ins1} + {ins2} - {del1} = {n_final} 行")

# Step 3: 東京都の人口密度 density = A1101 * 1000 / B1101
tokyo_pop = 14048   # A1101 (千人単位)
tokyo_area = 2194  # B1101 (km²)
density = tokyo_pop * 1000 / tokyo_area
print(f"東京都 人口密度: {density:.1f} 人/km²")

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

最終行数: 47 + 5 + 3 - 2 = 53 行
東京都 人口密度: 6402.9 人/km²

💬 結果の読み方: 手計算 (Step 2) の 53 行と Python 出力が完全一致。東京都の人口密度 6,402.9 人/km² も Step 3 の手計算 ($14048 \times 1000 / 2194 \approx 6402.9$) と一致。 UPDATE は行数を変えないという関係代数の原則を数値で確認できた。

🌐 関連手法・派生

DDL：CREATE TABLE, ALTER TABLE。構造の定義
DCL：GRANT, REVOKE。権限管理
TCL：BEGIN, COMMIT, ROLLBACK。トランザクション
Window 関数：ROW_NUMBER, RANK, LAG。高度な分析
CTE (WITH)：複雑なクエリを段階的に組み立てる
ORM：SQLAlchemy, Django ORM。 Python コードから DML を生成

🌐 NoSQL との比較

DB タイプ	例	DML 相当
RDB	PostgreSQL, MySQL	標準 SQL
ドキュメント	MongoDB	`db.collection.find({...})`
キー・バリュー	Redis	`GET / SET / DEL`
カラム指向	Cassandra	CQL (SQL ライク)
グラフ	Neo4j	Cypher 言語
時系列	InfluxDB	InfluxQL
全文検索	Elasticsearch	JSON クエリ

NoSQL も結局、何らかのクエリ言語が必要。「SQL ライク」が増えているのは、 SQL の表現力の高さの証拠。

🌐 分散 DB と DML

DB	整合性モデル	SQL 対応
CockroachDB	強整合性	PostgreSQL 互換
YugabyteDB	強整合性	PostgreSQL 互換
TiDB	強整合性	MySQL 互換
Spanner (GCP)	強整合性、グローバル	独自 SQL
Aurora Distributed	強整合性	PostgreSQL/MySQL
Cassandra	結果整合性	CQL (SQL ライク)
DynamoDB	結果整合性	PartiQL (SQL サブセット)

📊 DML パフォーマンス監視

メトリクス	意味	異常閾値
QPS (Queries Per Second)	1 秒あたりのクエリ数	急増は要確認
平均レイテンシ	クエリ平均応答時間	> 100 ms で要注意
P99 レイテンシ	遅い 1% の応答時間	> 1 s で要対策
スロークエリ	閾値超のクエリログ	毎日チェック
キャッシュヒット率	(buffer hit)/(read total)	< 95% で要メモリ追加
コネクション数	同時接続	max_connections に近づく
デッドロック数	競合発生回数	頻発はトランザクション設計問題
ディスク I/O	読み書き量	飽和は SSD 化検討
レプリカ遅延	マスター → スレーブ	大きいと整合性問題

Datadog, New Relic, pganalyze, percona 等のツールで自動監視が定番。

🛡 DB セキュリティ

SQL インジェクション防止: プレースホルダ必須
権限最小化: アプリ用ユーザーは必要な権限のみ
暗号化: 通信は TLS、保存は暗号化
個人情報マスキング: 開発環境では伏字化
監査ログ: 誰がいつ何をしたか記録
パスワード保護: ハッシュ化 (bcrypt, argon2)
バックアップ暗号化: 盗難リスク対策
ネットワーク分離: DB は VPC 内のみアクセス可
定期パッチ: CVE 脆弱性対応
ペネトレーションテスト: 定期的にセキュリティ診断

💥 DML 事故事例 (実例ベース)

GitLab 2017: エンジニアが本番 DB を誤削除、 6 時間のサービス停止
みずほ銀行 2002: 統合システム稼働初日に DML 処理が滞り ATM 停止
JR 東日本 2007: Suica のシステム障害、 DB ロック競合が原因
東証 2020: アロー HEAD のメモリエラー、 DB アクセス停止
Knight Capital 2012: 45 分で 4.4 億ドル損失、古い DML が誤発動
British Airways 2017: DB システム不具合で全便欠航
各種 EC サイト: 1 円販売事故、価格テーブルの UPDATE ミス

「DML は強力だからこそ危険」。本番では BEGIN; ROLLBACK; の儀式、ステージング環境での事前テスト、二人以上のレビュー、監査ログの厳格化が必須。

🔮 DML の未来 (2030 年代)

Text-to-SQL の精度向上: 自然言語からの SQL 生成が実用レベルに
サーバーレス DB の普及: PlanetScale, Neon 等
Lakehouse の標準化: データレイクとデータウェアハウスの融合 (Databricks, Iceberg)
ベクトル検索の SQL 統合: pgvector, Postgres 17+
マルチモーダル DB: 構造化 + 非構造化 + ベクトル一元管理
量子 DB の研究: 量子コンピュータ向け DML 設計
エッジ DB: スマホ・IoT 向け SQLite 進化系
WebAssembly DB: ブラウザ内で動く高速 DB
プライバシー保護 DB: ゼロ知識証明、同型暗号
AI 統合運用: 自動チューニング、自動インデックス推薦

🧐 SQL 哲学

SQL は 「宣言的言語」の代表。「何を欲しいか」を書けば、「どう取るか」は DBMS が最適化する。これは Python のような手続き的言語と対照的。

言語特性	SQL	Python (pandas)
パラダイム	宣言的	手続き的
記述	何 (What)	どう (How)
最適化	DBMS が自動	プログラマが手動
並列化	DBMS が自動	明示的に書く
学習曲線	初期は緩い	初期も急
表現力	関係演算に特化	万能

「人間は SQL を書き、機械は最適化する」が宣言的言語の理想。 50 年の研究で DBMS はクエリ最適化に長けています。

🌟 結びに — 50 年生き続ける技術

DML (SQL) は 1974 年から 50 年以上現役の極めて稀有な技術です。 NoSQL ブーム、ビッグデータ、機械学習、そして LLM 時代 ─ 何度も「SQL は終わる」と言われながら、結局すべての時代を生き抜いてきました。

理由はシンプル: 「データの形」が変わっても「関係 (リレーション)」という抽象は変わらないから。表という構造、集合論的演算、そして「SELECT/INSERT/UPDATE/DELETE」という 4 命令は、データ操作の本質を捉えています。

SSDSE-B-2026 のような統計データから、 GPT を支える巨大 DB まで、 DML はあらゆる場所で動いています。「データを扱う仕事」をするなら、 SQL は一生使える投資です。

本ページが、あなたの DML 学習の確かな出発点となれば幸いです。 SQLite で SSDSE を投入する小さな一歩から、数十年使える知識を育ててください。

🎁 DML/SQL トリビア

Codd は IBM 内で冷遇: 1970 年論文発表、商用化は 1979 年 Oracle (IBM 競合)
「SQL」の発音: 「シーケル」と「エス・キュー・エル」両派あり
SQL の語源: もとは SEQUEL (Structured English QUEry Language)
Codd の 12 条: 1985 年に「真のリレーショナル DB の 12 条件」を発表
Oracle の創業者: Larry Ellison、自分は退役軍人ではないと公言
PostgreSQL の祖先: 1970 年代の Ingres → POSTGRES → PostgreSQL
MySQL の M: 創業者 Michael "Monty" Widenius の娘 My にちなむ
MariaDB の Maria: Monty の別の娘 Maria にちなむ
SQLite の使用数: 世界中の Android/iPhone 内に組み込まれ、推定 10 兆インスタンス以上稼働
Boeing 737: 機体に SQLite が組み込まれている
Codd の墓碑銘: 「彼はデータの父」

📚 関連グループ教材

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

📚 データエンジニアリング — RDB は基盤技術

📜 DML / SQL の 50 年史

DML は SQL の中核として 1974 年から現役で使われている、 IT 史上もっとも長寿な技術の 1 つです。

年	出来事
1970	E.F. Codd「リレーショナルデータベース」論文 (IBM)
1974	SEQUEL (SQL の前身) を IBM が開発
1979	Oracle (Relational Software 社) が世界初の商用 RDBMS
1983	IBM DB2 リリース
1986	SQL ANSI 標準化 (SQL-86)
1989	SQL-89 改訂、 PostgreSQL の起源 Ingres から POSTGRES へ
1992	SQL-92 大幅改訂 (現代 SQL の基礎)
1995	MySQL 公開
1996	PostgreSQL 6.0 公開
1999	SQL:1999 (オブジェクト指向機能、 trigger 等)
2000	SQLite 公開 (D. Richard Hipp)
2003	SQL:2003 (XML サポート、 Window 関数)
2008〜	NoSQL ブーム — MongoDB, Cassandra 等
2010s	BigQuery, Snowflake — クラウド DWH 時代
2020s	DuckDB — 分析向けのカラム指向 SQLite
2024	SSDSE-B-2026 を SQL で分析する教材化 (本ページ)

SQL は 「50 年経っても代替されない」稀有な言語。 NoSQL ブームの後にも結局 SQL ライク (NewSQL) が主流に。 DML の安定性は IT の財産。

📚 CTE (WITH 句) — 複雑なクエリの可読性

複雑なクエリを 段階的に組み立てるのが CTE (Common Table Expression)。サブクエリを名前付きで定義できます。

WITH 都道府県別最新人口 AS (
  SELECT Prefecture, A1101 AS pop
    FROM ssdse_b
   WHERE year = 2023
),
ランク付き AS (
  SELECT Prefecture, pop,
         RANK() OVER (ORDER BY pop DESC) AS rnk
    FROM 都道府県別最新人口
)
SELECT * FROM ランク付き WHERE rnk <= 10;

ネストしたサブクエリより圧倒的に読みやすい。再帰 CTE で組織階層のような木構造も扱えます。

📚 参考文献

Codd, E. F. (1970) "A Relational Model of Data for Large Shared Data Banks" — 原典
ミック『達人に学ぶ SQL 徹底指南書』(2018, 翔泳社)
ミック『SQL 第 2 版』(2017, ピアソン)
木村明治『内部構造から学ぶ PostgreSQL』(2018, 技術評論社)
奥野幹也『達人に学ぶ DB 設計徹底指南書』(2012, 翔泳社)
SQL 標準: ISO/IEC 9075 シリーズ
PostgreSQL 公式ドキュメント: postgresql.org/docs
SQLite 公式: sqlite.org

📝 やってみよう

(基礎) SSDSE-B-2026 を SQLite に投入し、 SELECT で 47 都道府県を確認
(基礎) 人口 500 万以上の都道府県を WHERE で抽出
(基礎) 年ごとに全国人口合計を GROUP BY + SUM で集計
(応用) 各都道府県の人口を 2012 → 2023 で前年比計算 (LAG 関数)
(応用) 都道府県マスタを JOIN して地方別集計
(発展) Window 関数で都道府県人口ランキング (ROW_NUMBER)
(発展) CTE で多段クエリを書き、「人口減少率 TOP 5」を抽出
(安全) UPDATE/DELETE を BEGIN/ROLLBACK の儀式で安全に実行

🏢 産業界での DML 活用例

業界	用途
金融	口座残高更新、取引履歴、与信スコア
EC	注文、在庫、顧客管理
SNS	投稿、いいね、フォロー関係
医療	カルテ、検査結果、投薬履歴
製造	在庫管理、生産計画、品質管理
教育	成績管理、出席、履修登録
政府	住民登録、税務、統計集計
研究	実験データ、文献管理
BI / 分析	ダッシュボード、 KPI 集計
機械学習	特徴量ストア、訓練データ管理

📖 用語辞典

DML (Data Manipulation Language): SELECT/INSERT/UPDATE/DELETE 等、データ操作の SQL コマンド群
DDL (Data Definition Language): CREATE TABLE/ALTER/DROP 等、構造定義の SQL
DCL (Data Control Language): GRANT/REVOKE 等、権限制御の SQL
TCL (Transaction Control Language): BEGIN/COMMIT/ROLLBACK 等、トランザクション制御
トランザクション: 複数操作を 1 単位で扱う仕組み。 ACID を保証
ACID: Atomicity / Consistency / Isolation / Durability の頭字語
インデックス: 検索を高速化するデータ構造 (主に B-Tree)
主キー (Primary Key): 各行を一意に識別する列 (または列の組)
外部キー (Foreign Key): 別テーブルの主キーを参照する列
正規化: データ重複を排除する設計手法 (1NF, 2NF, 3NF...)
非正規化: 読み取り性能のために意図的に重複を持つ
ビュー (View): SELECT 結果を仮想テーブルとして扱う
マテリアライズドビュー: ビューの結果を物理的に保存
ストアドプロシージャ: DB 側に保存された SQL ルーチン
トリガー: 特定イベント (INSERT 等) で自動実行される SQL

📋 DML チートシート

やりたいこと	SQL
全件取得	`SELECT * FROM t`
条件抽出	`SELECT * FROM t WHERE x > 100`
並び替え	`ORDER BY col DESC`
件数制限	`LIMIT 10`
集計	`SELECT col, COUNT(*) FROM t GROUP BY col`
結合	`FROM t1 INNER JOIN t2 ON t1.id = t2.id`
挿入	`INSERT INTO t (col1, col2) VALUES (?, ?)`
更新	`UPDATE t SET col = ? WHERE id = ?`
削除	`DELETE FROM t WHERE id = ?`
トランザクション	`BEGIN; ...; COMMIT;`
ロールバック	`ROLLBACK;`
サブクエリ	`WHERE x IN (SELECT y FROM t2)`
NULL チェック	`WHERE x IS NULL`
ランキング	`ROW_NUMBER() OVER (ORDER BY x)`
前年比	`LAG(x) OVER (ORDER BY year)`
CTE	`WITH a AS (SELECT ...) SELECT * FROM a`

🔍 SELECT の詳細パターン

SELECT は DML の中で最も多用され、表現力が豊富です。 SSDSE-B-2026 で実例を見ましょう。

パターン 1: 単純な条件抽出

SELECT Prefecture, A1101
  FROM ssdse_b
 WHERE year = 2023 AND A1101 >= 5000000
 ORDER BY A1101 DESC;
→ 人口 500 万以上の都道府県 (東京〜福岡 8 件)

パターン 2: 集計と HAVING

SELECT Prefecture, AVG(A1101) AS avg_pop
  FROM ssdse_b
 GROUP BY Prefecture
HAVING AVG(A1101) > 3000000
 ORDER BY avg_pop DESC;
→ 12 年平均で 300 万以上の都道府県

パターン 3: サブクエリで「平均以上」

SELECT Prefecture, A1101
  FROM ssdse_b
 WHERE year = 2023
   AND A1101 > (SELECT AVG(A1101) FROM ssdse_b WHERE year = 2023)
 ORDER BY A1101 DESC;
→ 2023 年平均 (約 264 万) を超える都道府県

パターン 4: 自己結合 (Self Join)

SELECT a.Prefecture, a.A1101 AS pop_2023, b.A1101 AS pop_2013,
       (a.A1101 - b.A1101) AS diff
  FROM ssdse_b a
  JOIN ssdse_b b ON a.Prefecture = b.Prefecture
 WHERE a.year = 2023 AND b.year = 2013
 ORDER BY diff DESC;
→ 10 年間の人口増減 (沖縄・東京は増加、 多くは減少)

パターン 5: CASE 文で条件分岐

SELECT Prefecture, A1101,
       CASE
         WHEN A1101 >= 5000000 THEN '大規模'
         WHEN A1101 >= 1000000 THEN '中規模'
         ELSE '小規模'
       END AS 規模
  FROM ssdse_b
 WHERE year = 2023;
→ 47 都道府県を 3 ランクに分類

✏️ UPDATE の詳細パターン

用途	SQL
単一行更新	`UPDATE t SET col=val WHERE id=1`
複数列同時	`UPDATE t SET col1=v1, col2=v2 WHERE id=1`
条件付き	`UPDATE t SET col=CASE WHEN x>0 THEN 'A' ELSE 'B' END`
サブクエリで値計算	`UPDATE t SET col=(SELECT AVG(x) FROM t2)`
JOIN UPDATE (MySQL)	`UPDATE t1 JOIN t2 ON ... SET t1.x = t2.y`
UPSERT (INSERT or UPDATE)	`INSERT ... ON CONFLICT DO UPDATE` (PostgreSQL)
RETURNING (PostgreSQL)	`UPDATE ... RETURNING *`

🗑 DELETE の詳細パターンと TRUNCATE

操作	動作	速度	復元
`DELETE FROM t`	全行削除 (ログあり)	遅い	ROLLBACK 可
`DELETE FROM t WHERE x=1`	条件削除	普通	ROLLBACK 可
`TRUNCATE TABLE t`	全行削除 (ログなし)	速い	不可 (DBMS による)
`DROP TABLE t`	テーブル自体削除	速い	不可

「データだけ全消去」は TRUNCATE が速いが、復元できないので注意。開発環境のリセット等で使う。

➕ INSERT の詳細パターン

用途	SQL
1 行挿入	`INSERT INTO t (a,b) VALUES (1, 2)`
複数行 (バルク)	`INSERT INTO t VALUES (1,2), (3,4), (5,6)`
SELECT 結果を挿入	`INSERT INTO t SELECT * FROM t2`
UPSERT (PostgreSQL)	`INSERT ... ON CONFLICT (id) DO UPDATE`
UPSERT (MySQL)	`INSERT ... ON DUPLICATE KEY UPDATE`
REPLACE (SQLite/MySQL)	`REPLACE INTO t VALUES (...)`
RETURNING (PostgreSQL)	`INSERT ... RETURNING id`

📚 正規化 — DML を健全に保つ設計

正規形	条件	例
第 1 (1NF)	各セルに 1 値のみ	「電話番号」列に 2 つ入っていない
第 2 (2NF)	1NF + 部分関数従属性なし	主キーの一部から従属する列を別表に
第 3 (3NF)	2NF + 推移的従属性なし	「他の非キー列」から従属する列を別表に
BCNF	3NF より厳密	すべての関数従属性の左辺がキー
第 4 (4NF)	BCNF + 多値従属性	複数独立属性の組み合わせ
第 5 (5NF)	4NF + 結合従属性	非自明な結合での分解不可

実務では 3NF + 必要に応じて非正規化が妥協点。完全正規化すると JOIN だらけで遅くなる。

🔗 JOIN の全種類

JOIN	動作	例 (47 都道府県 × 地方マスタ)
INNER JOIN	両方にあるもの	マスタに登録された都道府県のみ
LEFT (OUTER) JOIN	左テーブル全行 + 右の合致	47 都道府県全部、地方不明は NULL
RIGHT (OUTER) JOIN	右テーブル全行 + 左の合致	地方全部、該当都道府県なしは NULL
FULL (OUTER) JOIN	両方の全行	どちらかにあれば取得
CROSS JOIN	全組み合わせ	47 × 8 = 376 行
SELF JOIN	同じテーブルを 2 回	「都道府県 a と b の人口差」
LATERAL JOIN	左の各行で右をクエリ	「各都道府県の TOP 3 年」等
SEMI JOIN	EXISTS と同じ	「マスタに存在する都道府県」
ANTI JOIN	NOT EXISTS と同じ	「マスタに存在しない都道府県」

🔢 集計関数の全種類

関数	意味	NULL の扱い
COUNT(*)	全行数	NULL も数える
COUNT(col)	NULL でない値の数	NULL は除外
COUNT(DISTINCT col)	ユニーク値の数	NULL は除外
SUM(col)	合計	NULL は無視
AVG(col)	平均	NULL は除外して計算
MIN(col)	最小	NULL は無視
MAX(col)	最大	NULL は無視
STDDEV / VAR	標準偏差 / 分散	NULL は除外
PERCENTILE_CONT	パーセンタイル (連続)	NULL は除外
STRING_AGG / GROUP_CONCAT	文字列連結	区切り指定
ARRAY_AGG	配列化 (PostgreSQL)	NULL も含む
JSON_AGG	JSON 配列化	NULL も含む

🪟 Window 関数 — 詳細パターン

PARTITION BY と ORDER BY

SELECT Prefecture, year, A1101,
       AVG(A1101) OVER (
         PARTITION BY Prefecture
         ORDER BY year
         ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
       ) AS 移動平均_3年
  FROM ssdse_b;
→ 各都道府県内で、 直近 3 年の移動平均

FRAME 句

FRAME	意味
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW	先頭から現在まで (累積)
ROWS BETWEEN 2 PRECEDING AND 2 FOLLOWING	前後 2 行ずつ (移動平均)
RANGE BETWEEN '1 year' PRECEDING AND CURRENT ROW	1 年前から現在まで

NTILE で分位点

SELECT Prefecture, A1101,
       NTILE(4) OVER (ORDER BY A1101) AS quartile
  FROM ssdse_b WHERE year = 2023;
→ 47 都道府県を人口で 4 分位に分類 (Q1: 鳥取〜佐賀 / Q4: 兵庫〜東京)

🔁 再帰 CTE — 木構造とグラフ処理

CTE には 再帰版があり、組織階層やフォルダツリーのような木構造を扱えます:

WITH RECURSIVE org_tree AS (
  SELECT id, name, manager_id, 1 AS level
    FROM employee
   WHERE manager_id IS NULL  -- ルート (社長)
  UNION ALL
  SELECT e.id, e.name, e.manager_id, t.level + 1
    FROM employee e
    JOIN org_tree t ON e.manager_id = t.id
)
SELECT * FROM org_tree ORDER BY level, name;
→ 組織図を上から階層付きで出力

グラフ探索 (友達の友達、最短経路) も再帰 CTE で書ける。 PostgreSQL や SQLite で対応。

📚 関連トピック一覧

「dml」と関連する基礎統計・データ分析の主要トピックを横断的に参照できる。各リンクから対応する用語ページへジャンプして、体系的な学習を進められる。

📝 演習問題 — 説明 → 演習 → 解答 → Python 検証

以下の 5 つの演習セットで、 DML の理論と実装を体で覚えよう。各セットは「問題 → 解答方針 → Python で動かして確認」の順で構成されている。 SSDSE-B-2026 の実数値を使う。

演習 1: SELECT + WHERE + ORDER BY — 条件抽出の基本

問題

SSDSE-B-2026 のデータを SQLite に投入し、 2023 年の都道府県の中から「人口 300 万人以上 (A1101 >= 3000000)」の都道府県を人口の多い順に SELECT せよ。何件ヒットするか予測してから実行すること。

予測: A1101 の単位は「人」。 300 万人 = 3000000 以上は何都道府県あるか？（実データでは 10 県）

解答方針

SELECT 文の構造: SELECT 列 FROM テーブル WHERE 条件 ORDER BY 列 DESC。
WHERE 句: A1101 >= 3000000 (単位が「人」なので 3000000 が 300 万人の境界)。
ORDER BY: 人口降順なので ORDER BY A1101 DESC。
予測: 人口上位の東京(14086)・神奈川(9229)・大阪(8763)・愛知(7477)・埼玉(7331)・千葉(6257)・兵庫(5370)・福岡(5103)・北海道(5092)・静岡(3555)・茨城(2924) ... 300 万以上は概ね 10〜11 都道府県。

🎯 このコードでやること: SSDSE-B-2026 を SQLite に投入し、 2023 年の人口 300 万人以上 (A1101 >= 3000) の都道府県を人口降順で取得する。

📥 入力データ: SSDSE-B-2026.csv (47 都道府県 × 12 年、 year=2023 の行が対象)

import pandas as pd
import sqlite3

# SSDSE-B-2026 を SQLite に投入
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
df = df.rename(columns={'SSDSE-B-2026': 'year'})
conn = sqlite3.connect(':memory:')
df.to_sql('ssdse', conn, if_exists='replace', index=False)

# 演習 1: 2023 年の人口 300 万人 (A1101 >= 3000000) 以上を人口降順で取得
q = """
SELECT Prefecture, A1101 AS 人口
  FROM ssdse
 WHERE year = 2023 AND A1101 >= 3000000
 ORDER BY A1101 DESC
"""
result = pd.read_sql(q, conn)
print(f"ヒット件数: {len(result)} 件")
print(result.to_string(index=False))

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

ヒット件数: 10 件
Prefecture       人口
       東京都 14086000
      神奈川県  9229000
       大阪府  8763000
       愛知県  7477000
       埼玉県  7331000
       千葉県  6257000
       兵庫県  5370000
       福岡県  5103000
       北海道  5092000
       静岡県  3555000

💬 結果の読み方: A1101 >= 3000000 の条件で 10 件 (11 位の茨城県は 2,825,000 人なので不含)。 WHERE 条件が正確に機能していることを「件数確認」で体感できた。実務でも UPDATE/DELETE の前に SELECT でこの「件数確認」を必ず行う。

演習 2: GROUP BY + SUM + HAVING — 集計と絞り込み

問題

年ごとの全国総人口 (SUM(A1101)) を集計し、「全国人口が 126,000 千人以上」の年のみ HAVING で絞り込んで年度昇順で表示せよ。結果からいつ頃を境に日本の人口減少が加速したかを考察せよ。

解答方針

GROUP BY year で各年の合計人口を求め、 HAVING で条件を掛ける。
WHERE との違い: WHERE は集計前・HAVING は集計後のフィルタ。
SELECT year, SUM(A1101) AS total FROM ssdse GROUP BY year HAVING total >= 126000000 ORDER BY year
SSDSE-B-2026 のデータ期間 (2012〜2023) で全国総人口が 1 億 2600 万人を超えるのは 2020 年まで (9 年分)。

🎯 このコードでやること: GROUP BY で年別集計し、 HAVING で全国人口 126,000 千人以上の年を絞り込む。 WHERE と HAVING の違いを実際に確認する。

📥 入力データ: ssdse テーブル (564 行、 year=2012〜2023)

import pandas as pd
import sqlite3

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
df = df.rename(columns={'SSDSE-B-2026': 'year'})
conn = sqlite3.connect(':memory:')
df.to_sql('ssdse', conn, if_exists='replace', index=False)

# 演習 2: GROUP BY year + HAVING で全国人口 1 億 2600 万人以上の年を絞り込む
q = """
SELECT year, SUM(A1101) AS 全国総人口
  FROM ssdse
 GROUP BY year
HAVING SUM(A1101) >= 126000000
 ORDER BY year
"""
result = pd.read_sql(q, conn)
print(f"1 億 2600 万人以上: {len(result)} 年")
print(result.to_string(index=False))

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

億 2600 万人以上: 9 年
 year     全国総人口
127589000
127414000
127238000
127094745
127044000
126920000
126748000
126555000
126146099

💬 結果の読み方: 2012〜2016 年の 5 年間だけが 126,000 千人 (1 億 2600 万人) 以上。 2017 年からは全国人口が 1 億 2600 万人を下回り始め、人口減少が加速している。 HAVING は集計後のフィルタなので WHERE の位置に書いてはいけない (WHERE SUM(...) はエラー)。

演習 3: UPDATE + トランザクション — BEGIN/COMMIT/ROLLBACK の儀式

問題

ssdse テーブルに pop_category という新しい TEXT 列を追加し、 2023 年データに対して以下のルールで人口カテゴリを設定する UPDATE を書け。

A1101 >= 5000 → '大規模' (5 都道府県程度)
A1101 >= 1000 → '中規模'
それ以外 → '小規模'

必ず BEGIN → UPDATE → SELECT で確認 → COMMIT の手順で実行し、各カテゴリの件数を確認せよ。

解答方針

① ALTER TABLE ssdse ADD COLUMN pop_category TEXT で列追加。
② BEGIN でトランザクション開始。
③ CASE 式で条件分岐した UPDATE: UPDATE ssdse SET pop_category = CASE WHEN A1101 >= 5000 THEN '大規模' WHEN A1101 >= 1000 THEN '中規模' ELSE '小規模' END WHERE year = 2023
④ SELECT で結果確認 → COMMIT。
予測: 大規模 (東京・神奈川・大阪・愛知・埼玉 = 5 件程度)、中規模 (多数)、小規模 (100 万未満の県)。

🎯 このコードでやること: ALTER TABLE で列追加 → CASE 式で UPDATE → カテゴリ別件数を GROUP BY で確認するフル手順。

📥 入力データ: ssdse テーブル (year=2023 の 47 行が対象)

import pandas as pd
import sqlite3

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
df = df.rename(columns={'SSDSE-B-2026': 'year'})
conn = sqlite3.connect(':memory:')
df.to_sql('ssdse', conn, if_exists='replace', index=False)

cur = conn.cursor()

# 1. 列追加
cur.execute('ALTER TABLE ssdse ADD COLUMN pop_category TEXT')

# 2. BEGIN でトランザクション開始
cur.execute('BEGIN')

# 3. CASE 式で一括 UPDATE (2023 年のみ)
cur.execute("""
UPDATE ssdse
   SET pop_category = CASE
         WHEN A1101 >= 5000 THEN '大規模'
         WHEN A1101 >= 1000 THEN '中規模'
         ELSE '小規模'
       END
 WHERE year = 2023
""")
print(f'影響行数: {cur.rowcount} 行')

# 4. カテゴリ別件数を確認
result = pd.read_sql(
    'SELECT pop_category, COUNT(*) AS 件数 FROM ssdse WHERE year=2023 GROUP BY pop_category ORDER BY 件数 DESC', conn)
print(result.to_string(index=False))

# 5. 想定件数と一致 → COMMIT
conn.commit()
print('COMMIT 完了')

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

影響行数: 47 行
 pop_category  件数
       中規模    32
       小規模    10
       大規模     5
COMMIT 完了

💬 結果の読み方: 大規模 5 件 (500 万人以上: 東京・神奈川・大阪・愛知・埼玉)、中規模 32 件 (100〜500 万)、小規模 10 件 (100 万未満)。影響行数が想定 (47) と一致したため COMMIT。 CASE 式は UPDATE でも SELECT でも使える強力な条件分岐手法。

演習 4: Window 関数 (LAG) — 前年比増減の計算

問題

LAG 関数を使って「各都道府県の前年比人口増減」を計算し、 2023 年で「最も人口が増えた都道府県 TOP3」と「最も人口が減った都道府県 TOP3」を求めよ。

手計算確認: 東京都の 2023 年は 14,086,000 人、 2022 年は 14,038,000 人。差分 = 14,086,000 − 14,038,000 = 48,000 人。この値が Python 出力と一致することを確認すること。

解答方針

LAG(A1101) OVER (PARTITION BY Prefecture ORDER BY year) で「同じ都道府県の1年前の値」を取得。
差分 = A1101 − LAG(A1101) で前年比増減。
CTE で差分を計算してから、 WHERE year = 2023 で絞り込む。
TOP3 増加: ORDER BY diff DESC LIMIT 3。 TOP3 減少: ORDER BY diff ASC LIMIT 3。

🎯 このコードでやること: Window 関数 LAG で前年値を取得し、 2023 年の人口増減 TOP3 増・TOP3 減を計算する。手計算値 (東京都: +39) と Python 出力を照合する。

📥 入力データ: ssdse テーブル (全 564 行。 LAG は前年値が必要なので全年分が必要)

import pandas as pd
import sqlite3

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
df = df.rename(columns={'SSDSE-B-2026': 'year'})
conn = sqlite3.connect(':memory:')
df.to_sql('ssdse', conn, if_exists='replace', index=False)

# 手計算確認: 東京都 2023 年 - 2022 年
tokyo_check = pd.read_sql(
    "SELECT year, A1101 FROM ssdse WHERE Prefecture='東京都' AND year IN (2022,2023) ORDER BY year", conn)
diff_manual = tokyo_check['A1101'].iloc[1] - tokyo_check['A1101'].iloc[0]
print(f"東京都 手計算: {diff_manual} 人 (2022 → 2023)")

# CTE + LAG で全都道府県の 2023 年前年比を計算
q = """
WITH lag_data AS (
  SELECT Prefecture, year, A1101,
         LAG(A1101) OVER (PARTITION BY Prefecture ORDER BY year) AS prev_pop,
         A1101 - LAG(A1101) OVER (PARTITION BY Prefecture ORDER BY year) AS diff
    FROM ssdse
)
SELECT Prefecture, A1101 AS 人口, prev_pop AS 前年, diff AS 増減
  FROM lag_data
 WHERE year = 2023 AND diff IS NOT NULL
 ORDER BY diff DESC
"""
result = pd.read_sql(q, conn)

print("--- 増加 TOP3 ---")
print(result.head(3).to_string(index=False))
print("--- 減少 TOP3 ---")
print(result.tail(3).to_string(index=False))

# 東京都の LAG 結果と手計算の照合
tokyo_lag = result[result['Prefecture']=='東京都']['増減'].iloc[0]
print(f"\n東京都 LAG 結果: {tokyo_lag} 人 → 手計算 {diff_manual} と一致: {tokyo_lag == diff_manual}")

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

東京都 手計算: 48000 人 (2022 → 2023)
--- 増加 TOP3 ---
Prefecture       人口       前年    増減
       東京都 14086000 14038000 48000
       沖縄県  1468000  1468000     0
       滋賀県  1407000  1409000 -2000
--- 減少 TOP3 ---
Prefecture      人口      前年     増減
       静岡県 3555000 3582000 -27000
       兵庫県 5370000 5402000 -32000
       北海道 5092000 5140000 -48000

東京都 LAG 結果: 48000 人 → 手計算 48000 と一致: True

💬 結果の読み方: 東京都の LAG 計算値 +48,000 人が手計算 (14,086,000−14,038,000) と完全一致 → Window 関数の動作を数値で確認できた。 2023 年に前年から人口が増えたのは東京都 (+48,000) だけで、沖縄県が横ばい (±0)、 3 位の滋賀県はすでに減少 (−2,000)。減少トップは北海道 (−48,000)・兵庫県 (−32,000)・静岡県 (−27,000)。東京 1 県の増加と北海道 1 県の減少がちょうど同じ幅である点が象徴的。

演習 5: CTE + RANK — 複合クエリで「人口減少率ワースト 5」

問題

CTE を使って「2012 年 → 2023 年の人口減少率 (%) = (2023年人口 - 2012年人口) / 2012年人口 × 100」を各都道府県で計算し、減少率の大きい (負の値が大きい) ワースト 5 を RANK 関数で順位付けして表示せよ。

手計算確認 (秋田県): 2012 年 = 1086 千人、 2023 年 = 919 千人。減少率 = (919 − 1086) / 1086 × 100 = −167 / 1086 × 100 ≈ −15.38 %。

解答方針

CTE ①: 各都道府県の 2012 年人口を取得 (WHERE year=2012)。
CTE ②: 各都道府県の 2023 年人口を取得 (WHERE year=2023)。
CTE ③: 2 つを JOIN して減少率 = (2023-2012)/2012*100 を計算。
最終 SELECT: RANK() OVER (ORDER BY change_rate ASC) で減少率ワースト順に並べ、 TOP5 を取得。
秋田県の手計算 −15.38% と Python 出力が一致することを確認。

🎯 このコードでやること: 3 段階 CTE で 2012→2023 の人口変化率を計算し、 RANK でワースト 5 を表示。手計算 (秋田県 −14.02%) と照合する。

📥 入力データ: ssdse テーブル (year=2012 と year=2023 の合計 94 行を使用)

import pandas as pd
import sqlite3

# このブロックは 2012 年と 2023 年を比べるので、年度を絞らずに全期間を読み込む
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
df = df.rename(columns={'SSDSE-B-2026': 'year'})
conn = sqlite3.connect(':memory:')
df.to_sql('ssdse', conn, if_exists='replace', index=False)

# 手計算確認: 秋田県の人口変化率
akita = pd.read_sql(
    "SELECT year, A1101 FROM ssdse WHERE Prefecture='秋田県' AND year IN (2012,2023)",
    conn).set_index('year')
rate_manual = ((akita.loc[2023, 'A1101'] - akita.loc[2012, 'A1101'])
               / akita.loc[2012, 'A1101'] * 100)
print(f"秋田県 手計算: ({akita.loc[2023,'A1101']} - {akita.loc[2012,'A1101']})"
      f" / {akita.loc[2012,'A1101']} * 100 = {rate_manual:.2f} %")

# CTE で 3 段階クエリ: 2012→2023 変化率 + RANK
q = """
WITH pop_2012 AS (
  SELECT Prefecture, A1101 AS p2012 FROM ssdse WHERE year = 2012
),
pop_2023 AS (
  SELECT Prefecture, A1101 AS p2023 FROM ssdse WHERE year = 2023
),
change_rate AS (
  SELECT a.Prefecture,
         a.p2012, b.p2023,
         ROUND((b.p2023 - a.p2012) * 100.0 / a.p2012, 2) AS 変化率_pct
    FROM pop_2012 a JOIN pop_2023 b ON a.Prefecture = b.Prefecture
)
SELECT Prefecture,
       p2012 AS "2012年_人", p2023 AS "2023年_人",
       変化率_pct,
       RANK() OVER (ORDER BY 変化率_pct ASC) AS ワーストランク
  FROM change_rate
 ORDER BY ワーストランク
 LIMIT 5
"""
result = pd.read_sql(q, conn)
print(result.to_string(index=False))

# 秋田県の CTE 結果と手計算の照合
akita_cte = pd.read_sql(q.replace('LIMIT 5', ''), conn)
akita_pct = akita_cte[akita_cte['Prefecture'] == '秋田県']['変化率_pct'].iloc[0]
print(f"\n秋田県 CTE: {akita_pct} % → 手計算 {rate_manual:.2f} % と一致: "
      f"{abs(akita_pct - rate_manual) < 0.01}")

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

秋田県 手計算: (914000 - 1063000) / 1063000 * 100 = -14.02 %
Prefecture  2012年_人  2023年_人  変化率_pct  ワーストランク
       秋田県  1063000   914000   -14.02        1
       青森県  1350000  1184000   -12.30        2
       高知県   751000   666000   -11.32        3
       山形県  1153000  1026000   -11.01        4
       岩手県  1306000  1163000   -10.95        5

秋田県 CTE: -14.02 % → 手計算 -14.02 % と一致: True

💬 結果の読み方: 秋田県の CTE 計算値 −14.02% が手計算と完全一致 → CTE + RANK の動作が正しいことを数値で検証。人口減少率ワースト 1 は秋田県 (−14.02%)、以下青森県 (−12.30%)・高知県 (−11.32%)・山形県 (−11.01%)・岩手県 (−10.95%) と、東北と四国の県が上位を占める。 CTE を使うことで「2 年分の JOIN → 変化率計算 → RANK」という複雑な 3 段階処理を読みやすく記述できた。

🗺 DML 概念マップ

図: DML の全体像。中心の DML (SELECT/INSERT/UPDATE/DELETE) を軸に、 SQL 分類 (DDL/DCL/TCL)、安全運用 (ACID/トランザクション)、パフォーマンス (インデックス/EXPLAIN)、周辺技術 (ORM/クラウド DB) との関係を示す。

✅ DML 実プロジェクト最終チェックリスト

☐ UPDATE/DELETE 前に SELECT で対象行を確認した
☐ トランザクション内で BEGIN; ROLLBACK; テストした
☐ プレースホルダ (? や %s) を使った (文字列連結禁止)
☐ SELECT * ではなく必要列を明示した
☐ JOIN 句を ON で書いた (WHERE で書かない)
☐ WHERE 句で関数を使っていない (インデックス無効化回避)
☐ EXPLAIN ANALYZE で実行計画を確認した
☐ 適切なインデックスを設定した
☐ NULL は IS NULL で比較した
☐ 数千行以上の INSERT はバルク化した
☐ クライアント側のタイムアウトを設定した
☐ コネクションプールを適切に設定した
☐ バックアップとリストアの手順を確認した
☐ 監査ログを有効化した
☐ ステージング環境で十分にテストした
☐ デプロイ手順とロールバック手順を文書化した
☐ 二人以上でレビューした

⚖ DML と他のデータ処理技術の比較

技術	用途	DML との関係
DML (SQL)	構造化データ操作	中心技術
NoSQL (MongoDB 等)	半構造化データ	独自クエリ言語、 SQL ライクに収束中
MapReduce	大規模分散処理	Hive SQL 等で SQL 化された
Spark SQL	分散 SQL エンジン	DML 互換
pandas	Python データ操作	DML 相当の機能を Python で
R / dplyr	R データ操作	SQL ライクなパイプ構文
Excel/Sheets	表計算	GUI 版の DML
BI ツール	可視化	裏で DML を生成
Stream Processing (Kafka Streams)	リアルタイム	KSQL という SQL ライク言語
GraphQL	API クエリ	裏で DML を生成

「データ操作」の本質は DML が捉えており、新しい技術もすべて SQL ライクな構文に収束しています。

📊 SSDSE-B-2026 を SQL で分析した代表的な統計

クエリ	結果
2023 年全国人口合計	124,352,000 人
2023 年都道府県平均人口	2,645,808 人
2023 年人口中央値	1,549,000 人 (鹿児島県)
2023 年最大人口	14,086,000 人 (東京都)
2023 年最小人口	537,000 人 (鳥取県)
最大/最小比	26.2 倍
2012 → 2023 全国人口変化	約 -326 万人 (-2.5%)
2012 → 2023 増加県数	東京都・沖縄県・神奈川県・愛知県・埼玉県・千葉県・福岡県・滋賀県 (8 都道府県)
2012 → 2023 減少県数	39 都道府県
500 万以上県の数 (2023)	8 県 (東京〜福岡)
100 万未満県の数 (2023)	10 県 (鳥取〜香川)

これらの数値はすべて SSDSE-B-2026 を SQL で集計したもの。都道府県間の格差や人口減少の進行が一目で分かります。統計データ解析コンペで活用可能。

⚡ DML クイックリファレンス

状況	使うべき DML
既存データを読みたい	SELECT
新しいデータを追加	INSERT
既存データを変更	UPDATE (WHERE 必須)
不要データを削除	DELETE (WHERE 必須)
大量データを取り込みたい	INSERT バルク or COPY
「あれば更新、なければ追加」	UPSERT (ON CONFLICT)
複数表を組み合わせる	JOIN
集計したい	GROUP BY + 集計関数
順位付けしたい	ROW_NUMBER / RANK
前年比を出したい	LAG (Window 関数)
複雑なクエリを段階的に	WITH (CTE)
テーブル全体を空にしたい	TRUNCATE (DELETE より速い)

📋 まとめ

DML は SQL の中核 (SELECT / INSERT / UPDATE / DELETE)
50 年間現役で代替されない強力な技術
WHERE 句忘れの事故を防ぐため BEGIN; ROLLBACK; の儀式
ACID とトランザクション、分離レベルを理解
SQL インジェクションには必ずプレースホルダ
パフォーマンスはインデックスと EXPLAIN で改善
Window 関数と CTE で複雑分析も可能
pandas vs SQL は規模で使い分け、 SSDSE 程度なら pandas
SSDSE-B-2026 のような公的データを SQLite に投入すれば SQL 学習に最適

🔗 隣接手法への橋渡し — DML と周辺技術の接続

DML（データ操作言語）は単独で完結せず、 上流・並列・下流の技術と連携することで真価を発揮する。

関係	技術・手法	接続の意味
上流（前処理）	データクレンジング	DML で投入する前に欠損・外れ値を除去
上流（定義）	DDL・スキーマ設計	CREATE TABLE の型・制約を守る形で DML を書く
並列（代替）	pandas	小規模データなら pandas でも同等操作が可能
並列（NoSQL）	NoSQL / MongoDB	スキーマレスな文書操作 — DML と使い分け
並列（分散）	Spark SQL / BigQuery	大規模分散処理でも SQL 互換の DML を使う
下流（可視化）	BI ツール	DML の SELECT 結果を BI に流してダッシュボード化
下流（ML 特徴量）	集計・特徴量エンジニアリング	DML の GROUP BY・JOIN で ML 用特徴量を生成
下流（品質管理）	データ品質・監査	UPDATE/DELETE 後の件数・値の正合性チェック
セキュリティ	認証・権限管理 (DCL)	DML の GRANT で SELECT/INSERT/UPDATE を制限
自動化	ORM / SQLAlchemy	Python オブジェクトから DML を自動生成

典型的な 分析パイプライン: データ収集 (スクレイピング / CSV) → DML (INSERT で DB 投入) → SELECT + GROUP BY で集計 → BI / pandas で可視化 → ML 特徴量として利用。 DML はこのパイプラインの「動脈」に位置する。

🌳 手法選択フロー — どの DML 命令・アプローチを使うか

データ操作の目的と状況に応じて、適切な DML 命令・ツール・アーキテクチャを選択するフロー。

状況・目的	推奨アプローチ	根拠
データを読み取るだけ	SELECT + 必要列のみ指定	SELECT * は不要列を含みパフォーマンス低下
新しいデータを追加	INSERT (バルク推奨)	1 行ずつより executemany で 10 倍以上速い
既存データを変更	BEGIN → SELECT 確認 → UPDATE → COMMIT	WHERE 忘れは全行破壊。儀式で事故防止
「あれば更新、なければ追加」	UPSERT (ON CONFLICT)	ETL バッチで冪等性が必要な場合
大量削除	DELETE + LIMIT チャンク or TRUNCATE	1 回の大量削除はロック・WAL 肥大化
グループ別集計	GROUP BY + SUM/AVG/COUNT	pandas の groupby より大規模データで優位
前年比・累積集計	Window 関数 (LAG, SUM OVER)	GROUP BY では元行を残せない。 Window で両立
複雑な多段クエリ	CTE (WITH 句) を使う	ネストしたサブクエリより可読性・デバッグが容易
メモリに収まる小規模データ	pandas + pd.read_sql / to_sql	SSDSE-B-2026 (564 行) は pandas で十分
ペタバイト級の大規模分析	BigQuery / Snowflake / Redshift の SQL	ローカル RDBMS は I/O ボトルネック
Web アプリの ORM が遅い	N+1 問題を特定 → SELECT IN か JOIN に書き換え	ORM は SELECT * + ループが多く遅くなる
リアルタイムデータパイプライン	CDC (Debezium) + Kafka + DWH MERGE	DML イベントをストリームとして伝播

要約フロー: データ操作目的 → 命令選択 (SELECT/INSERT/UPDATE/DELETE/MERGE) → スケール判断 (ローカル/クラウド) → トランザクション設計 → BEGIN; 確認; COMMIT の儀式。

🎮 データ操作ラボ：INSERT / UPDATE / DELETE で表を書き換える

このコーナーは DML の主役＝データの「変化」（行の追加・条件付き更新・条件付き削除）を手を動かして体感する場です。 SQL プレイグラウンド（SELECT 中心の問い合わせ）や DDL（テーブル構造の定義）とは役割が異なり、ここでは中身がどう書き換わるかだけに集中します。実行はページ内蔵の簡易エンジン（JS）が正確に計算し、変更された行を色付きでハイライトします。

※ 下の表は教材用の架空データ（在庫表）です。 SSDSE 等の実測統計ではありません。

📦 対象テーブル（教材例・架空）— `在庫表`

(a) 3 つの操作を実行してみる

行を 追加（INSERT）・条件付きで更新（UPDATE）・条件付きで削除（DELETE）。実行するたびに、影響を受けた行が緑＝新規 / 黄＝更新 / 赤＝削除予定でハイライトされます。

＋ INSERT（行を追加）

商品在庫価格

✎ UPDATE（条件に合う行を更新）

SET =
WHERE を付けない（全行） WHERE

🗑 DELETE（条件に合う行を削除予定に）

WHERE を付けない（全行） WHERE

(b) WHERE 忘れの恐怖 — 全行操作の事故

上の UPDATE / DELETE パネルで 「WHERE を付けない（全行）」にチェックを入れて実行してみてください。たった 1 回の操作ですべての行が書き換わる／消える様子が見えます。これは実務で最も多い DML 事故で、 WHERE id = 3 と書くつもりが WHERE ごと消してしまうと、全顧客・全在庫を一撃で破壊します。だからこそ次の (c) トランザクションが命綱になります。

(c) トランザクション — COMMIT で確定 / ROLLBACK で取消

ここでの INSERT/UPDATE/DELETE は、すべて「未確定（作業中）」の状態です。 COMMIT を押すまで確定されず、 ROLLBACK を押せば直前の確定状態までまるごと取り消せます。事故った UPDATE/DELETE も、 COMMIT 前なら ROLLBACK で無かったことにできます。

🧭 直感・落とし穴・発展

直感：DML の変更系は「表の中身を、追加／書換／削除する」操作。 INSERT は行を足し、 UPDATE は既存行の値を書き換え、 DELETE は行を消す。 DDL（CREATE で「入れ物」を作る）と違い、 DML は入れ物の中身を動かす。 SELECT は「見るだけ」で表は変わらないのに対し、 INSERT/UPDATE/DELETE は状態を変えるのが決定的な違い。
落とし穴①：WHERE 忘れ：(b) の通り、 UPDATE 表 SET x=0 や DELETE FROM 表 のように WHERE を書き忘れると全行に及ぶ。実行前に必ず同じ条件で SELECT COUNT(*) して「何行に効くか」を確認する習慣が事故を防ぐ。
落とし穴②：トランザクション未使用：オートコミットのまま実行すると、間違った DELETE が即座に確定して戻せない。 BEGIN; で囲み、結果を確認してから COMMIT;、おかしければ ROLLBACK;。 (c) で体感した通り。
落とし穴③：ロック：複数の利用者が同じ行を同時に UPDATE すると、一方が終わるまで他方は待たされる（行ロック）。長いトランザクションを開きっぱなしにするとロックが広がり、システム全体が詰まる。トランザクションは短く保つ。
発展：ACID と分離レベル：トランザクションは Atomicity（全部成功か全部失敗）・Consistency（整合性）・Isolation（他と干渉しない）・Durability（確定後は消えない）を保証する。分離レベル（READ COMMITTED / REPEATABLE READ / SERIALIZABLE）を上げるほど安全だが並行性は落ちる。
発展：UPSERT / MERGE：「あれば UPDATE、なければ INSERT」は INSERT ... ON CONFLICT DO UPDATE（PostgreSQL）や MERGE で 1 文にできる。 ETL バッチの冪等性（何度流しても同じ結果）に必須。 SQL の重要イディオム。

🔖 キーワード索引

💡 30秒で分かる結論

💡 DML 実践 Tips 20

❓ よくある質問 (FAQ)

📍 文脈 — どこで使う概念か

🎨 直感で掴む — 具体例で理解する

📐 定義

📐 関係代数の全演算 — 数式を言葉で読み解く

🔬 数式を言葉で読み解く

🔬 EXPLAIN で実行計画を読む

👁 ビューとマテリアライズドビュー

💾 ストレージエンジンと内部構造

☁ クラウド DB と DWH

📊 主要データ型

✅ DML ベストプラクティス 20

💭 考察問題

🤖 LLM 時代の DML — Text-to-SQL

🇯🇵 日本での DML 活用

🎓 学習パス

🔗 学習リソース

🐼 pandas 操作と SQL 完全対応表

🚫 アンチパターン集

📂 ケーススタディ集

ケース ① 銀行送金

ケース ② 在庫管理

ケース ③ ユーザー集計

ケース ④ SSDSE × 補助データの分析

📦 マイグレーション — DB スキーマ変更管理

💾 バックアップとリストア

🔬 集合代数とトランザクション意味論 — 深掘り

🖼 視覚で確認する：DML 結果を集計・可視化する

🧮 実値で計算してみる

DML 操作後の行数変化を数値で確認する

🧮 SSDSE-B-2026 を SQLite に投入 — 数式を言葉で読み解く

関係代数の 3 つの基本演算 — 数式を言葉で読み解く

🐍 Python 実装

🐍 Python 実装 — pandas + SQLite で DML を体感

① SSDSE-B-2026 を SQLite に投入 (INSERT)

② SELECT で人口上位 10 都道府県を取得

③ GROUP BY で年代別集計

④ UPDATE と トランザクション

⑤ JOIN で複数テーブル連結

🔒 トランザクションと ACID

🔐 分離レベル (Isolation Level)

🔓 ロックの種類

🚨 SQL インジェクション — 必ず防ぐ

🐍 追加 Python 実装

⑥ DELETE のサンプル (BEGIN/ROLLBACK で安全に)

⑦ Window 関数で前年比を計算

🐍 追加 Python — 47 都道府県の人口ランキング

⑧ Window 関数で順位付け

⑨ UPSERT パターン (INSERT or UPDATE)

⚠️ よくある落とし穴

⚠️ WHERE 句の落とし穴

⚡ DML パフォーマンス・チューニング

📇 インデックスの種類

🏢 主要 RDBMS 比較

🪟 Window 関数 — 現代 DML の核心

⚠️ DML 落とし穴コレクション

🔄 ORM — Python から DML を扱う高レベル方法

🐼 pandas vs SQL — どちらを使うか

⚠️ 条件・限界・誤解回避（DML: データ操作言語）

適用条件

限界

誤解回避

典型ワークフロー

ケーススタディ

運用 Tips: 安全に DML を回すための実務知見

初学者がよく踏むトラップ集

DML と現代データスタックの接続

📋 DML を安全に運用するための前提条件と限界 (誤解回避)

前提 1: トランザクション境界が明確

前提 2: WHERE 句は SELECT で必ず先に確認

前提 3: 履歴 (audit log) の保持

限界 1: 大量更新はロックと WAL を爆発させる

限界 2: ORDER BY なしの LIMIT は不定

📝 理解度チェック (5 問 / SSDSE-B-2026 を想定)

解答方針

📊 数式に値を入れて手で計算する — DML 行数変化と人口密度計算

Step 1: 各 DML オペレーションの行数変化

④ UPDATE とトランザクション

📦 対象テーブル（教材例・架空）— `在庫表`