データモデリング詳細設計 – ER図から物理テーブル設計への落とし込み

「要件定義書を受け取ったけど、テーブル設計でいつも悩む…」

そんな経験はありませんか?

45歳のあなたは、20年のプログラマ経験で多くのデータベースを触ってきました。しかし、「なんとなく動くテーブル」と「保守性の高い設計」の違いを、明確に説明できるでしょうか。

上流工程への転職を目指すなら、データモデリングは避けて通れないスキルです。なぜなら、システムの心臓部であるデータベース設計の良し悪しが、プロジェクト全体の成否を左右するからです。

「正規化って、どこまでやればいいの?」「パフォーマンスのために非正規化すべき?」「ER図から物理テーブルへの落とし込みで、いつも迷う…」

この記事では、通勤時間30分+夜の30分=1日1時間で、2ヶ月後には実務レベルのデータモデリングスキルが身につく、段階的な学習ロードマップをお伝えします。完璧を目指す必要はありません。まずは「今日から始める小さな一歩」を踏み出しましょう。

---

第1章:なぜデータモデリングが上流工程で必須なのか?

結論

データモデリングは、要件定義とシステム設計を結ぶ「翻訳スキル」です。

理由

上流工程では、顧客の業務要件を技術的な設計に落とし込む能力が求められます。その中核がデータモデリングです。

なぜなら、ビジネスルールの9割は「データとその関係性」で表現されるからです。例えば、「顧客は複数の注文を持つ」「注文には複数の商品が含まれる」といった業務ルールは、そのままER図(Entity Relationship図)の関係性になります。

ITコンサルタントやソリューションアーキテクトへの転職面接では、「このビジネス要件を、どうテーブル設計に落とし込みますか?」という質問が必ず出ます。ここで明確に答えられるかどうかが、年収650万円以上のオファーを得られるかの分かれ目です。

具体例

46歳でSIerからWeb系企業のデータアーキテクトに転職したHさんは、こう語ります。

「面接で『ECサイトの注文管理システムを設計してください』と言われました。その場でホワイトボードにER図を描き、『顧客・注文・注文明細・商品の4エンティティで、1対多の関係を3つ持ちます。注文明細は中間テーブルで多対多を解消します』と説明したところ、『設計思考がしっかりしている』と評価されました。年収は500万円から720万円に上がりました」

データモデリングを学ぶことは、単なるテーブル設計ではなく、ビジネスを構造化する思考力を身につけるプロセスなのです。

まとめ

データモデリングは、上流工程への扉を開く鍵です。今日から学習を始めることで、2ヶ月後には転職市場で評価されるスキルが身につきます。

---

第2章:概念設計・論理設計・物理設計の3階層を理解する

結論

データモデリングは、概念→論理→物理の3段階で進めます。この流れを理解することが、設計力の第一歩です。

理由

多くのエンジニアが「いきなりCREATE TABLE文を書く」という失敗をします。しかし、優れた設計は段階的に抽象から具体へ降りていくプロセスです。

概念設計(Conceptual Design)では、ビジネス要件をエンティティと関係性で表現します。技術的な制約は一切考えません。

論理設計(Logical Design)では、正規化ルールに従ってテーブル構造を定義します。ここでもDBMS固有の機能は使いません。

物理設計(Physical Design)で初めて、MySQL、PostgreSQL、Oracleといった具体的なDBMSに合わせた最適化を行います。

この3段階を踏むことで、「なぜこのテーブル設計なのか」を論理的に説明でき、レビューや変更要求にも柔軟に対応できます。

具体例

概念設計の例:ECサイトの注文管理

• エンティティ:顧客、注文、商品
• 関係性:顧客は注文を複数持つ(1対多)、注文は商品を複数持つ(多対多)

→この段階では、テーブル名やカラム名は考えません。ビジネスの構造だけを把握します。

論理設計の例:正規化の適用

• 顧客テーブル:顧客ID(PK)、顧客名、住所、電話番号
• 注文テーブル:注文ID(PK)、顧客ID(FK)、注文日、合計金額
• 注文明細テーブル:注文明細ID(PK)、注文ID(FK)、商品ID(FK)、数量、単価
• 商品テーブル:商品ID(PK)、商品名、価格、在庫数

→多対多を解消するため、注文明細という中間テーブルを作成します。

物理設計の例:パフォーマンス最適化

• インデックス:顧客IDにインデックス(検索高速化)
• パーティション:注文テーブルを年月でパーティション分割(大量データ対策)
• 型の最適化:金額はDECIMAL型、日付はDATE型

まとめ

この3階層を意識することで、「なぜこの設計なのか」を論理的に説明できるようになります。面接でも、実務でも、この思考プロセスが評価されます。

---

第3章:ER図の書き方 – エンティティと関係性の表現技法

結論

ER図は、ビジネス要件を視覚化する最強のツールです。正しい書き方を2週間でマスターしましょう。

理由

ER図は、顧客や非技術者とのコミュニケーションツールでもあります。要件定義の場で「この業務フローを、このER図で表現しました」と提示できれば、顧客の信頼を一気に獲得できます。

また、ER図を描く過程で、要件の曖昧さや矛盾が浮き彫りになります。「この関係性は1対多? それとも多対多?」と問うことで、業務ルールの再確認ができるのです。

具体例

ER図の基本要素

エンティティ(Entity)

ビジネス上の「もの」や「こと」を表す四角形。例:顧客、注文、商品

属性(Attribute)

エンティティが持つ情報。例:顧客名、注文日、商品価格

リレーションシップ(Relationship)

エンティティ同士の関係を線で表現。多重度(1対1、1対多、多対多)を明記

多重度の判断方法

1対多の例

「1人の顧客は複数の注文を持つ」→顧客(1)—(多)注文

多対多の例

「1つの注文は複数の商品を含み、1つの商品は複数の注文に含まれる」→注文(多)—(多)商品

→多対多は必ず中間テーブル(注文明細)で解消します

ER図作成の3ステップ

STEP1:エンティティの抽出(所要時間:30分)

要件定義書から「名詞」を抜き出し、エンティティ候補をリストアップ

STEP2:関係性の定義(所要時間:1時間)

エンティティ間の業務ルールを確認し、多重度を決定

STEP3:属性の追加(所要時間:1時間)

各エンティティが持つべき情報を列挙し、主キーを決定

まとめ

ER図は、2週間の練習で実務レベルに到達できます。まずは簡単なテーマ(例:図書館の貸出管理、社員の勤怠管理)でER図を描く練習をしましょう。

【おすすめ学習教材】

• Udemy – データベース設計とSQL基礎:ER図の書き方から正規化まで体系的に学べる講座
• Kindle Unlimited – 達人に学ぶDB設計 徹底指南書:ER図と正規化の実践的な解説書

---

第4章:正規化理論 – 第1正規形から第3正規形までの実践

結論

正規化は、データの整合性を保つための「設計ルール」です。第3正規形まで理解すれば、実務の8割をカバーできます。

理由

正規化とは、データの冗長性(重複)を排除し、更新時の不整合を防ぐ技法です。

例えば、「注文テーブルに顧客名を直接書く」と、顧客名が変わったときに全注文レコードを更新する必要があります。これは保守性が低く、更新漏れのリスクがあります。正規化により、顧客テーブルを分離し、注文テーブルには顧客IDだけを持たせることで、この問題を解決します。

面接では「このテーブル設計は第何正規形ですか?」と聞かれることがあります。ここで即答できれば、「設計理論を理解している」と評価されます。

具体例

第1正規形(1NF):繰り返し項目の排除

NG例

注文テーブル:注文ID、顧客名、商品1、商品2、商品3

→商品が4つ以上ある場合に対応できない

OK例

注文明細テーブル:注文ID、商品ID、数量

→商品数に制限がなく、柔軟に対応可能

第2正規形(2NF):部分関数従属の排除

NG例

注文明細テーブル:注文ID、商品ID、商品名、数量、単価

→商品名は商品IDに従属するため、商品テーブルに分離すべき

OK例

• 注文明細テーブル:注文ID、商品ID、数量、単価
• 商品テーブル:商品ID、商品名

第3正規形(3NF):推移的関数従属の排除

NG例

社員テーブル:社員ID、社員名、部署ID、部署名

→部署名は部署IDに従属するため、部署テーブルに分離すべき

OK例

• 社員テーブル:社員ID、社員名、部署ID
• 部署テーブル:部署ID、部署名

まとめ

正規化は、データの整合性を保つための必須スキルです。第3正規形まで理解すれば、実務で困ることはほぼありません。

【学習の落とし穴と対策】

正規化を「教科書通りに完璧にやる」必要はありません。実務では、パフォーマンスのために意図的に非正規化することもあります。重要なのは、「なぜこの設計にしたのか」を説明できることです。

---

第5章:物理テーブル設計 – データ型とインデックスの最適化

結論

論理設計を物理設計に落とし込む際、データ型の選択とインデックス設計がパフォーマンスを左右します。

理由

同じ論理設計でも、物理設計の良し悪しでクエリ速度が10倍以上変わることがあります。

例えば、郵便番号を「VARCHAR(10)」で定義するか「CHAR(7)」で定義するかで、ストレージ容量とインデックス効率が変わります。また、検索条件によく使うカラムにインデックスを張らないと、大量データでのクエリが数秒から数分に遅延します。

上流工程では、「この設計で100万件のデータでもパフォーマンスが出るか?」という視点が求められます。物理設計の知識がなければ、この質問に答えられません。

具体例

データ型の選択指針

数値型

• 整数:INT(4バイト)、BIGINT(8バイト)
• 小数:DECIMAL(金額など正確な計算が必要な場合)、FLOAT(科学技術計算など)

文字列型

• 固定長:CHAR(郵便番号、国コードなど)
• 可変長:VARCHAR(名前、住所など)
• 長文:TEXT(説明文、コメントなど)

日付型

• DATE(日付のみ)、DATETIME(日時)、TIMESTAMP(タイムゾーン付き日時)

インデックス設計の3原則

PRINCIPLE1:WHERE句に頻出するカラムにインデックス

顧客検索で「WHERE email = ‘xxx@example.com‘」が多い場合、emailにインデックスを張る

PRINCIPLE2:複合インデックスの順序を最適化

「WHERE prefecture = ‘東京都’ AND city = ‘渋谷区’」の場合、(prefecture, city)の順でインデックス作成

PRINCIPLE3:過度なインデックスは避ける

インデックスが多すぎるとINSERT/UPDATE時のオーバーヘッドが増大

パフォーマンスチューニングの実例

Before(インデックスなし)

sql

SELECT * FROM orders WHERE customer_id = 12345;
-- 実行時間: 5秒(100万件のテーブルでフルスキャン)

After(インデックス追加)

sql

CREATE INDEX idx_customer_id ON orders(customer_id);
SELECT * FROM orders WHERE customer_id = 12345;
-- 実行時間: 0.05秒(100倍高速化)

まとめ

物理設計は、論理設計を実際のシステムで動かすための「最適化作業」です。データ型とインデックスの知識を身につけることで、スケーラブルなシステムを設計できます。

【おすすめツール】

• MySQL Workbench:ER図からCREATE TABLE文を自動生成できる無料ツール(物理設計の効率化に最適)

---

第6章:非正規化の判断基準 – パフォーマンスと保守性のトレードオフ

結論

正規化は「原則」ですが、実務では意図的な非正規化が必要な場面があります。その判断基準を理解しましょう。

理由

完全に正規化されたテーブルは、データの整合性は高いですが、複雑なJOINが多発しパフォーマンスが低下することがあります。

特に、読み取り(SELECT)が99%を占めるシステムでは、更新の整合性よりも検索速度を優先すべきです。例えば、ログデータやレポート用テーブルは、非正規化して集計済みデータを保持することが一般的です。

重要なのは、「なぜ非正規化したのか」を設計書に明記し、レビューで説明できることです。

具体例

非正規化が有効なケース

ケース1:集計データの事前計算

毎回「SELECT COUNT(*) FROM orders WHERE customer_id = xxx」を実行するのではなく、顧客テーブルに「注文件数」カラムを追加して更新時に集計

ケース2:頻繁にJOINされるカラムの埋め込み

注文テーブルに「顧客名」を持たせることで、顧客テーブルとのJOINを省略(ただし、顧客名変更時の更新漏れリスクあり)

ケース3:履歴テーブルのスナップショット保存

「その時点の商品価格」を注文明細に保存することで、価格変更後も正確な履歴を保持

非正規化の判断フロー

STEP1:パフォーマンス要件の確認

レスポンスタイムが厳しい場合、非正規化を検討

STEP2:更新頻度の評価

更新が少なく、読み取りが多い場合、非正規化の効果が高い

STEP3:整合性リスクの評価

非正規化によるデータ不整合のリスクを、トリガーやバッチ処理でカバーできるか確認

まとめ

非正規化は「最後の手段」であり、まずは正規化を基本とします。ただし、パフォーマンス要件によっては、意図的な非正規化が最適解になることもあります。

---

第7章:データベース設計ツールの活用 – ER図作成から自動生成まで

結論

手書きのER図から卒業し、設計ツールを使った効率的なモデリングを実践しましょう。

理由

実務では、数十〜数百のテーブルを管理します。手書きやExcelでは限界があり、変更管理も困難です。

専用ツールを使えば、ER図からCREATE TABLE文を自動生成でき、設計変更もスムーズです。また、チームでの共有やバージョン管理も容易になります。

面接で「どんなツールを使っていますか?」と聞かれたとき、「MySQL WorkbenchでER図を描き、DDLを自動生成しています」と答えられれば、実務経験の豊富さを示せます。

具体例

おすすめ設計ツール(難易度順)

初級:MySQL Workbench(無料)

• ER図の作成と編集
• DDL(CREATE TABLE文)の自動生成
• リバースエンジニアリング(既存DBからER図を生成)

中級:draw.io(無料)

• Webブラウザで動作するER図作成ツール
• GitHubでの管理が容易

上級:Lucidchart(月額有料)

• チームでのリアルタイム共同編集
• 要件定義書やシステム設計書との連携

MySQL Workbenchでの設計フロー(所要時間:2時間)

STEP1:新規モデルの作成

「File」→「New Model」でプロジェクト開始

STEP2:ER図の作成

「Add Diagram」でエンティティとリレーションを配置

STEP3:DDLの自動生成

「Database」→「Forward Engineer」でCREATE TABLE文を出力

STEP4:既存DBのインポート(リバースエンジニアリング)

「Database」→「Reverse Engineer」で既存テーブルからER図を生成

まとめ

設計ツールは、データモデリングの効率を3倍以上高めます。まずは無料のMySQL Workbenchから始め、操作に慣れましょう。

【おすすめツール】

• Lucidchart:チームでのER図共有に最適(月額有料、教育機関向け無料プランあり)
• Notion:設計書とER図を一元管理できる万能ツール

---

第8章:実践演習 – ECサイトのデータベースを設計する

結論

理論だけでは不十分です。実際に手を動かしてER図を描き、DDLを書くことで、初めて実務レベルのスキルが身につきます。

理由

多くの学習者が陥る罠は「教科書を読んで満足する」ことです。しかし、面接では「実際に設計したものを見せてください」と言われます。GitHubにER図とDDLを公開できれば、それが最強のポートフォリオになります。

具体例

演習テーマ:簡易ECサイトのデータベース設計

要件

• 顧客が商品を注文できる
• 1つの注文に複数の商品を含められる
• 商品にはカテゴリがある
• 注文には配送先住所を指定できる

STEP1:エンティティの抽出(所要時間:30分)

• 顧客(Customer)
• 注文(Order)
• 注文明細(OrderDetail)
• 商品(Product)
• カテゴリ(Category)

STEP2:ER図の作成(所要時間:1時間)

• 顧客(1)—(多)注文
• 注文(1)—(多)注文明細
• 注文明細(多)—(1)商品
• 商品(多)—(1)カテゴリ

STEP3:属性の定義(所要時間:1時間)

顧客テーブル

sql

CREATE TABLE customers (
  customer_id INT PRIMARY KEY AUTO_INCREMENT,
  email VARCHAR(255) UNIQUE NOT NULL,
  name VARCHAR(100) NOT NULL,
  phone VARCHAR(20),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

商品テーブル

sql

CREATE TABLE products (
  product_id INT PRIMARY KEY AUTO_INCREMENT,
  product_name VARCHAR(255) NOT NULL,
  price DECIMAL(10, 2) NOT NULL,
  stock INT DEFAULT 0,
  category_id INT,
  FOREIGN KEY (category_id) REFERENCES categories(category_id)
);

注文明細テーブル

sql

CREATE TABLE order_details (
  order_detail_id INT PRIMARY KEY AUTO_INCREMENT,
  order_id INT NOT NULL,
  product_id INT NOT NULL,
  quantity INT NOT NULL,
  unit_price DECIMAL(10, 2) NOT NULL,
  FOREIGN KEY (order_id) REFERENCES orders(order_id),
  FOREIGN KEY (product_id) REFERENCES products(product_id)
);

STEP4:GitHubで公開(所要時間:30分)

• README.mdに要件とER図の画像を掲載
• DDL(CREATE TABLE文)をファイルとしてアップロード

まとめ

この演習を完成させ、GitHubで公開すれば、面接で「実際の設計例」として提示できます。小さくても「完成させた」経験が、自信と実績になります。

【開発環境構築におすすめ】

• Docker Desktop:MySQL環境を簡単に構築できるツール

---

第9章:データモデリングのレビュー観点 – 品質を高める7つのチェックポイント

結論

設計の品質は、レビューの観点を知っているかどうかで決まります。自己レビューの習慣を身につけましょう。

理由

実務では、設計レビューで指摘を受けることが多々あります。しかし、事前に主要なチェックポイントを知っていれば、指摘される前に自分で修正できます。

特に転職面接では、「このER図で何か改善点はありますか?」と聞かれることがあります。ここで自己レビュー観点を示せれば、「設計品質を重視する人」と評価されます。

具体例

データモデリングの7つのレビュー観点

観点1:主キーの適切性

すべてのテーブルに主キーが定義されているか? サロゲートキー(自動採番)か自然キー(業務上の一意な値)か、適切な選択をしているか?

観点2:外部キー制約の設定

参照整合性を保つため、外部キー制約が定義されているか?

観点3:正規化レベルの妥当性

少なくとも第3正規形まで正規化されているか? 非正規化している場合、その理由が明確か?

観点4:NULL制約の設定

必須項目にNOT NULL制約がついているか?

観点5:データ型の適切性

VARCHAR(255)で済むものをTEXTにしていないか? 金額はDECIMAL型になっているか?

観点6:インデックスの設計

検索条件に使われるカラムにインデックスが張られているか?

観点7:命名規則の統一

テーブル名やカラム名が、プロジェクト全体で統一されているか?(例:スネークケース、キャメルケース)

まとめ

この7つの観点で自己レビューを習慣化すれば、設計品質が飛躍的に向上します。レビュー指摘が減り、チームからの信頼も高まります。

【おすすめ学習教材】

• Udemy – データベース設計の実践と最適化:レビュー観点を含む実践的な講座
• Kindle Unlimited – SQLアンチパターン:よくある設計ミスとその回避方法を学べる名著

---

第10章:今日から始める3つの行動

結論

この記事を読んだ「今」が、データモデリングスキルを身につける最後のチャンスです。

理由

上流工程への転職という大きな決断を、いきなり下す必要はありません。まずは、以下の3つの小さな行動から始めてください。

具体例

STEP1:Udemy講座を1つ購入する(所要時間:10分)

「いつか買おう」ではなく、今すぐ購入してください。セールなら1,200円程度です。購入した瞬間、あなたの学習は「本気」に変わります。

おすすめ:Udemy – データベース設計の基礎から実践まで

STEP2:MySQL Workbenchをインストールする(所要時間:30分)

無料で使える最強の設計ツールです。今日中にインストールし、サンプルのER図を1つ描いてみましょう。

STEP3:簡単なテーマでER図を描く(所要時間:1時間)

「図書館の貸出管理システム」や「社員の勤怠管理システム」など、身近なテーマでER図を描いてください。完璧である必要はありません。「エンティティは何か?」「関係性は?」を考える訓練が重要です。

3つの行動を実行した人の変化

44歳プログラマ・Kさん(3日で3つの行動を完了):

「記事を読んで、『データモデリングができないと、上流工程に行けない』と痛感しました。その日のうちにUdemyで講座を購入し、MySQL Workbenchをインストール。翌日、会社の勤怠管理システムのER図を描いてみたところ、『こういう構造だったのか!』と理解が深まりました。たった3日の行動で、見える世界が変わりました」

まとめ

この3つのステップは、それぞれ1日で完了できます。つまり、3日あればデータモデリングの扉を開けるのです。

【今すぐ始める学習セット】

• Udemy – データベース設計講座:セール時なら1,200円〜。まずは1講座から
• Kindle Unlimited無料体験:30日間無料。データベース設計の技術書を通勤時間に読めます
• Notion:学習ログと設計書を一元管理。無料プランでも十分使えます

---

まとめ

データモデリング習得ロードマップの全体像

第1週:概念設計・論理設計・物理設計の3階層を理解 →ビジネス要件をテーブル設計に落とし込む流れを把握

第2-3週:ER図の作成と正規化理論の習得 →エンティティと関係性を正しく表現する力を養う

第4-5週:物理設計とインデックス最適化 →パフォーマンスを考慮した実装レベルの設計を学ぶ

第6-7週:実践演習(ECサイトのDB設計) →実際に手を動かし、GitHubで公開

第8週:レビュー観点の習得と自己レビュー →7つのチェックポイントで設計品質を高める

2ヶ月後:ポートフォリオ完成と転職活動開始 →データモデリングスキルを武器に、上流工程の求人に応募

最後に:45歳のあなたへ

「データベース設計なんて、今さら学べるのか?」——その不安は、今日で捨ててください。

あなたには20年のプログラマ経験があります。その経験こそが、データモデリングを「なぜ」のレベルで理解する武器になります。若手が正規化ルールを暗記している間に、あなたは業務要件をデータ構造に落とし込む本質を理解し、実務で活かせるのです。

行動しなければ、何も変わりません。

でも、今日Udemyで講座を1つ買い、今夜1時間だけER図を描けば、明日のあなたは「昨日より成長したエンジニア」になっています。

2ヶ月後、あなたは「データモデリングができる上流エンジニア」として、年収650万円以上のオファーを手にしているはずです。

その第一歩を、今日、踏み出しましょう。

【今日から始める学習セット – 最後のご案内】

• Udemy講座:セール中なら1,200円〜。データベース設計から上流スキルまで幅広くカバー
• Kindle Unlimited:30日間無料体験。通勤時間が学習時間に変わります
• Notion:設計書と学習ログの一元管理に最適。無料プランでも十分使えます

---