データモデリングとは
このレッスンで分かること
- データモデリングは業務概念をテーブルと関連に翻訳する作業です
- 概念 → 論理 → 物理 の 3 段階で詳細化します
- 最初から
CREATE TABLEを書かず、登場人物と関係を先に決めます
データモデリング とは
データ構造を視覚的に表現するデータモデリングの基本を解説します。本レッスンでは、データモデリング の基本から実際の使いどころまでを整理し、現場で迷わず使える形に落とし込みます。
なぜ重要か
アプリの「データ構造」は、後から直すのが最も難しい部分です。テーブル設計が雑だと、機能追加のたびに JOIN が膨らみ、バグの温床になり、性能も落ちます。コードはリファクタしやすいですが、本番データが溜まったテーブルは、列の意味を変えただけで全機能が動かなくなります。逆に、最初に 業務の概念をきれいに切り出した設計 ができていれば、SQL は短くなり、データ品質も保たれ、後からの拡張も小さな差分で済みます。データモデリング とは、現実世界の業務やサービスを データの世界の構造（テーブルと関連） に翻訳する作業のことです。プログラミングの「設計図」がクラス図なら、データ系の設計図が データモデル です。SQL を書く前に、この設計の腕を磨くことが、結果的に SQL を速く正確に書けるようになる近道になります。
モデリングの良し悪しは、半年後に「機能追加が一瞬で終わるか、全テーブル作り直しになるか」で効いてきます。コードと違って後から直しにくいぶん、最初の設計に時間をかける価値があります。
3 段階のモデル
データモデリングは伝統的に 3 段階に分けて考えます。各段階は「誰のための図か」「どこまで実装に踏み込むか」で区別します。一気に 物理モデル（CREATE TABLE）を書こうとすると、業務の理解と実装の制約が混ざってしまい、議論が空転します。段階を分けることで、業務担当者と開発者それぞれが、自分のレベルの会話に集中できます。
| 段階 | 主な目的 | 主な利用者 | 出力例 |
|---|---|---|---|
| 概念モデル | 業務上の概念を洗い出す | 業務担当・PM | エンティティ名のラフ図 |
| 論理モデル | 属性と関連を確定する | 設計者・開発者 | 属性付き ER 図 |
| 物理モデル | DBMS に載せる形にする | DB エンジニア | CREATE TABLE 文 |
概念モデル では「ユーザ」「注文」「商品」のような 登場人物（エンティティ） を洗い出します。論理モデル では、各エンティティが持つ 属性、エンティティ同士の関連（1対多 か 多対多 か）、主キー 候補を決めます。物理モデルでは、それを DBMS の機能（インデックス、データ型、制約）に合わせて落とし込みます。
ステップごとの動作
概念から物理に進むほど「実装の制約」が入り込みます。例えば概念では「顧客は注文を出す」と言えれば十分ですが、論理では「顧客 ID と注文 ID を別テーブルに分けるか」を決め、物理では「主キーは BIGINT か CHAR(26) か」「どの列にインデックスを張るか」まで踏み込みます。
図の流れを順序リストで書き直すと、次の通りです。
- 業務担当にヒアリングし、登場人物を洗い出す
- 概念モデルでエンティティのラフ図を描く
- 論理モデルで属性・関連・主キーを確定する
- 物理モデルで型・制約・インデックスを決める
CREATE TABLE文に落とす
代表例
まずは「ブログサービス」を題材に、概念から論理に落とす流れを見ます。業務的な登場人物は「ユーザ」「記事」「コメント」の 3 つです。論理モデルでは、それぞれを 1 つのテーブルにし、関連を 外部キー で表現します。
SQL クエリ
-- 論理モデルに対応する物理テーブル (簡略版)
CREATE TABLE users (
id INT PRIMARY KEY,
name TEXT NOT NULL
);
CREATE TABLE posts (
id INT PRIMARY KEY,
user_id INT NOT NULL,
title TEXT NOT NULL
);この 2 テーブルは、概念モデルでの「ユーザは記事を書く」関係を、外部キー posts.user_id で表現しています。関係性は「線」で考え、それを「列」に落とす のがモデリングの基本動作です。線の向きと多重度（1 対多なのか多対多なのか）を最初に固めてから、列の配置に進みます。
次に、もう少し業務に近い例として「タスク管理」を見ます。各タスクは 1 人の担当者を持ち、担当者は複数のタスクを抱えます。これは典型的な 1対多 の関係です。
SQL クエリ
SELECT u.name AS assignee, COUNT(t.id) AS task_count
FROM users u
LEFT JOIN tasks t ON t.assignee_id = u.id
GROUP BY u.id, u.name
ORDER BY u.id;LEFT JOIN を使うことで、タスクを 1 件も持たない担当者も 0 件として表示できます。論理モデルで関連線を引いた段階で、こうした SQL の書きやすさが決まります。逆に、設計段階で関連を見落とすと、後からアプリ側のループで補うはめになり、性能も保守性も悪化します。
よくある落とし穴
テーブルを増やすことを恐れない。概念ごとにテーブルを分けるほうが、後から JOIN するだけで済むので結果的にシンプルになります。1 つのテーブルに無理やり詰め込むと、列が増えて NULL だらけになり、用途別に列を読み替える複雑なクエリが必要になります。
物理モデルから書き始めない。最初から CREATE TABLE を書くと、業務の概念を取りこぼします。まず「登場人物」と「関係」を紙やホワイトボードに描いてから DDL に落とすのが安全です。
業務の語彙をそのままエンティティ名・列名にすると、要件変更時に翻訳コストがかかりません。
customerをcust_aと略すよりは、フル単語で書いた方が長期的には読みやすくなります。
ここまでの要点
業務概念 → テーブル + 関連、を 3 段階 (概念・論理・物理) で詳細化する。関係を「線」で先に決め、列 (FK) に落とす。CREATE TABLE は最後。
まとめ
- データモデリングは「業務の概念」を「テーブルと関連」に翻訳する作業
- 概念 → 論理 → 物理 の 3 段階で段階的に詳細化する
- 関係性を先に決め、それを列（外部キー）に落とすのが基本動作
- いきなり CREATE TABLE を書くと業務の本質を取りこぼす
- 業務語彙をそのまま使うと、長期的なメンテコストが下がる
次のレッスン
次は ER図の読み方・書き方 です。データベース設計の基本となるER図の読み方と書き方を解説します。
事前確認 — 進む前に次の 3 つができることを確認しましょう。
- モデリングとは の要点を自分の言葉で説明できる
- このレッスンの最小コード (または操作手順) を見ずに書ける
- 練習問題やクイズで間違えた箇所を読み直して理解した
理解度チェック (30 秒)
Q. モデリングとは とは何か、1 文で説明してください。
A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。
関連レッスン
テーブル構造
schema.sql
CREATE TABLE users (
id INT PRIMARY KEY,
name TEXT NOT NULL
);
CREATE TABLE tasks (
id INT PRIMARY KEY,
title TEXT NOT NULL,
assignee_id INT
);
INSERT INTO users (id, name) VALUES
(1, '田中'),
(2, '鈴木'),
(3, '佐藤');
INSERT INTO tasks (id, title, assignee_id) VALUES
(1, '要件定義', 1),
(2, '画面設計', 1),
(3, 'DB設計', 2),
(4, 'コーディング', 2),
(5, 'テスト', 2);期待される出力
| assignee | task_count |
|---|---|
| 田中 | 2 |
| 鈴木 | 3 |
| 佐藤 | 0 |