🎯 STEP 1: データベース設計とは

良い設計が良いシステムを作る！データベース設計の重要性を学ぼう

📋 このステップで学ぶこと

データベース設計とは何か、なぜ必要なのか
設計が悪いとどんな問題が起こるのか（実例で理解）
良い設計と悪い設計の具体的な違い
設計を進める5つのステップ
データモデリングの3層構造（概念・論理・物理）
実際のプロジェクトでの設計の進め方

前提知識： SQL基礎（SELECT、INSERT、UPDATE、DELETE が理解できていること）

🎯 1. データベース設計とは何か？

まず「設計」とは何かを理解しよう

何かを作るとき、いきなり作り始める人はいませんよね。家を建てるとき、料理を作るとき、旅行に行くとき… 必ず「計画」を立てます。

データベース設計とは、「システムで使うデータをどのように保存するか、その計画（設計図）を作ること」です。

📝 身近な例：引っ越しの荷物整理

引っ越しをするとき、荷物を適当にダンボールに詰めると、後で何がどこにあるかわからなくなりますよね。

賢い人は「キッチン用品」「衣類」「書類」などラベルを付けて分類します。
さらに「よく使うもの」と「季節限定のもの」を分けたり、「壊れやすいもの」は別に印をつけたり…

これと同じことを、コンピュータのデータでやるのがデータベース設計です。

データベース設計で具体的に決めること

データベース設計では、以下のようなことを決めます。

        
                    決めること
                    具体例
                    なぜ決める必要があるか
                
                    どんなテーブルを作るか
                    ユーザーテーブル、商品テーブル、注文テーブル
                    データの種類ごとに整理するため
                
                    各テーブルにどんな列（カラム）を持たせるか
                    名前、メールアドレス、パスワード
                    必要な情報を漏れなく記録するため
                
                    データ型は何にするか
                    文字列（VARCHAR）、数値（INT）、日付（DATE）
                    正しいデータだけを保存するため
                
                    テーブル同士をどう繋ぐか
                    ユーザーIDで注文テーブルと紐付け
                    関連するデータを取り出せるようにするため
                
                    主キーと外部キーをどう設定するか
                    user_id、order_id
                    データの一意性と整合性を保つため
                
                    インデックスをどこに貼るか
                    よく検索するカラムに設定
                    検索を速くするため

決めること	具体例	なぜ決める必要があるか
どんなテーブルを作るか	ユーザーテーブル、商品テーブル、注文テーブル	データの種類ごとに整理するため
各テーブルにどんな列（カラム）を持たせるか	名前、メールアドレス、パスワード	必要な情報を漏れなく記録するため
データ型は何にするか	文字列（VARCHAR）、数値（INT）、日付（DATE）	正しいデータだけを保存するため
テーブル同士をどう繋ぐか	ユーザーIDで注文テーブルと紐付け	関連するデータを取り出せるようにするため
主キーと外部キーをどう設定するか	user_id、order_id	データの一意性と整合性を保つため
インデックスをどこに貼るか	よく検索するカラムに設定	検索を速くするため

🏠 例え話：家の設計図と同じ

家を建てるとき、いきなり工事を始めることはありませんよね。まず設計図を作ります。

設計図では、「リビングはここ」「キッチンはこの大きさ」「トイレは何個」など、全体の構造を決めます。

データベース設計も同じです。「ユーザー情報はこのテーブル」「注文情報はこのテーブル」「それぞれをどう繋ぐか」を最初に計画します。良い設計図があれば良い家が建つように、良いデータベース設計があれば良いシステムができます！

❌ 2. なぜ設計が重要なのか？悪い設計で起こる問題

「設計なんて面倒だから、とりあえず動くものを作ればいい」と思うかもしれません。
しかし、データベース設計をおろそかにすると、後で取り返しのつかない問題が発生します。

悪い設計が引き起こす5つの問題

⚠️ 問題1：データの重複（同じ情報があちこちに）

例：顧客の住所を注文テーブルに毎回記録していると、同じ顧客が10回注文すると住所も10回記録されます。

ストレージの無駄遣い
住所変更時に10箇所すべて更新が必要
更新漏れで古い住所が残るリスク

⚠️ 問題2：データの矛盾（同じはずなのに違う）

例：ある場所では「山田太郎」、別の場所では「山田太郎」（スペース付き）と表記が違う。

検索でヒットしない問題
集計結果が正しくない
どちらが正しいかわからない

⚠️ 問題3：パフォーマンス低下（システムが遅い）

例：1つの巨大なテーブルに全データを入れると、検索に時間がかかりすぎます。

ユーザーがページを開くのに何秒もかかる
大量アクセス時にシステムダウン
後から改善するのが非常に困難

⚠️ 問題4：拡張性がない（新機能追加が困難）

例：「お気に入り機能を追加したい」というとき、設計が悪いと大規模な改修が必要になります。

本来1日で終わる作業が1週間かかる
既存機能に影響が出てバグが発生
開発コストが何倍にも膨らむ

⚠️ 問題5：バグの多発（エラーが頻発）

例：データの整合性が取れておらず、「存在しない商品を参照する注文」などが発生。

アプリケーションがエラーで落ちる
ユーザーの信頼を失う
原因調査に膨大な時間がかかる

具体例：オンラインショップの悪い設計

実際の悪い設計例を見てみましょう。

❌ 悪い設計の例：すべてを1つのテーブルに入れる

注文テーブル（orders）
——————————————————————–
order_id | customer_name | customer_email | product_name | price | quantity
1        | 山田太郎      | yamada@…     | ノートPC     | 80000 | 1
2        | 山田太郎      | yamada@…     | マウス       | 2000  | 2
3        | 佐藤花子      | sato@…       | ノートPC     | 80000 | 1

この設計の問題点

上記の設計には、以下のような問題があります。

問題①：顧客情報の重複
山田太郎さんの名前とメールアドレスが2回も記録されています。もし山田太郎さんがメールアドレスを変更したら、全ての注文レコードを更新しなければなりません。

問題②：商品情報の重複
「ノートPC」と「80000円」の情報も複数回記録されています。商品名や価格が変わったとき、すべての注文を更新する必要があります。

問題③：価格変更への対応が困難
ノートPCが値下げされたとき、過去の注文の価格も変わってしまうと、売上計算が狂います。「注文時点での価格」と「現在の商品価格」を区別できていません。

良い設計のメリット

しっかりとデータベース設計をすると、以下のようなメリットがあります。

✅ データの整合性

データの重複や矛盾がなく、常に正しい情報が保たれます。更新も1箇所だけで済みます。

⚡ 高速なパフォーマンス

適切なインデックスと設計で、検索や更新が高速になります。大量データでも快適に動作します。

🔧 保守性の向上

変更が必要な場合も、影響範囲が限定的で修正しやすいです。バグ修正も楽になります。

📈 拡張性

新しい機能を追加する際も、既存の設計を活かせるため、開発が楽になります。

💡 設計に時間をかける価値

「設計に時間をかけるのはもったいない」と思うかもしれませんが、実は逆です。

最初にしっかり設計すれば、開発中のバグが減り、運用後のトラブルも少なくなります。結果的に、トータルの時間とコストを大幅に削減できます。

ある調査では、設計段階で発見した問題を直すコストは「1」、開発段階では「10」、運用段階では「100」と言われています。

🔄 3. 良い設計 vs 悪い設計の実例

実際のケースで、悪い設計をどう改善するかを比較してみましょう。

実例1：ECサイトの商品と注文

❌ 悪い設計の例：すべての情報を1つのテーブルにまとめる

注文情報テーブル（all_in_one）
———————————————————–
注文ID | 注文日     | 顧客名   | 顧客住所 | 商品名   | 価格  | 数量
1      | 2025-01-15 | 山田太郎 | 東京都… | ノートPC | 80000 | 1
2      | 2025-01-15 | 山田太郎 | 東京都… | マウス   | 2000  | 2
3      | 2025-01-16 | 佐藤花子 | 大阪府… | ノートPC | 80000 | 1

✅ 良い設計の例：情報を適切に分割する

「顧客」「商品」「注文」「注文詳細」を別々のテーブルに分けます。

まず、顧客情報を独立したテーブルにします。

顧客テーブル（customers）
———————————–
顧客ID | 顧客名   | メール         | 住所
1      | 山田太郎 | yamada@…     | 東京都…
2      | 佐藤花子 | sato@…       | 大阪府…

次に、商品情報を独立したテーブルにします。

商品テーブル（products）
———————————–
商品ID | 商品名   | 価格
101    | ノートPC | 80000
102    | マウス   | 2000

注文の基本情報を管理するテーブルを作ります。顧客IDで顧客テーブルと紐付けます。

注文テーブル（orders）
———————————–
注文ID | 注文日     | 顧客ID
1      | 2025-01-15 | 1
2      | 2025-01-16 | 2

最後に、「どの注文でどの商品を何個買ったか」を記録するテーブルです。ここに「その時点の単価」を記録することがポイントです。

注文詳細テーブル（order_details）
———————————–
注文詳細ID | 注文ID | 商品ID | 数量 | 単価
1          | 1      | 101    | 1    | 80000
2          | 1      | 102    | 2    | 2000
3          | 2      | 101    | 1    | 80000

良い設計のポイント

✅ 顧客情報は1回だけ記録される（重複なし）
✅ 住所変更は顧客テーブルだけ更新すればOK
✅ 商品価格も1箇所で管理
✅ 注文詳細に「その時の単価」を記録することで、価格変更の影響を受けない
✅ データの整合性が保証される

実例2：ブログシステム

❌ 悪い設計の例

記事テーブル（posts）
———————————————————–
記事ID | タイトル     | 本文 | 投稿者名 | 投稿者メール | カテゴリ名
1      | DB設計入門   | …  | 山田太郎 | yamada@…   | 技術
2      | SQL応用      | …  | 山田太郎 | yamada@…   | 技術
3      | 初めての投稿 | …  | 佐藤花子 | sato@…     | 雑記

この設計の問題点

投稿者情報が記事ごとに重複している
カテゴリ名も文字列で毎回記録している（「技術」と「テクノロジー」のようなタイポのリスク）
投稿者のメール変更時、全記事を更新する必要がある

✅ 良い設計の例：テーブルを分割する

ユーザー情報を独立したテーブルにします。

ユーザーテーブル（users）
———————————–
ユーザーID | ユーザー名 | メール
1          | 山田太郎   | yamada@…
2          | 佐藤花子   | sato@…

カテゴリもマスタテーブルとして管理します。これにより、カテゴリ名の表記揺れを防げます。

カテゴリテーブル（categories）
———————————–
カテゴリID | カテゴリ名
1          | 技術
2          | 雑記

記事テーブルは、ユーザーIDとカテゴリIDで他のテーブルを参照します。

記事テーブル（posts）
———————————–
記事ID | タイトル     | 本文 | ユーザーID | カテゴリID
1      | DB設計入門   | …  | 1          | 1
2      | SQL応用      | …  | 1          | 1
3      | 初めての投稿 | …  | 2          | 2

良い設計のポイント

✅ ユーザー情報はIDで参照（重複なし）
✅ カテゴリもマスタテーブルで管理（タイポ防止）
✅ データ更新が簡単
✅ 外部キー制約で存在しないユーザーやカテゴリを参照できない

💡 設計の基本原則

良い設計の基本は「同じ情報を複数の場所に保存しない」ことです。
これを「正規化」と言い、Part 2（ステップ7〜12）で詳しく学びます。

🗺️ 4. 設計フローの全体像

データベース設計は、以下の5つのステップで進めていきます。いきなりテーブルを作り始めるのではなく、段階を追って進めることが重要です。

📋 データベース設計の流れ（5ステップ）1
要件定義
「何を作りたいのか」を明確にする。どんなデータが必要で、どんな機能が必要かを洗い出す。
2
概念設計（ER図作成）
「どんなエンティティ（実体）があるか」を整理。エンティティ同士の関係を図にする。
3
論理設計（正規化）
データの重複や矛盾を排除するため、正規化のルールに従ってテーブルを設計する。
4
物理設計
実際のDBMSに合わせて、データ型、インデックス、パーティションなどを決定する。
5
実装・テスト
実際にテーブルを作成し、データを投入してテスト。パフォーマンスを確認し、必要に応じて調整。

各ステップの詳細

📌 ステップ1：要件定義

やること：

システムで管理したいデータをリストアップ
必要な機能を洗い出し
ユーザーやクライアントからのヒアリング

ECサイトの場合の例：

「顧客情報を管理したい」（名前、住所、電話番号、メール）
「商品情報を管理したい」（商品名、価格、在庫数、画像）
「注文履歴を記録したい」（いつ、誰が、何を、いくつ買ったか）
「在庫管理をしたい」（入荷、出荷、現在の在庫数）

📌 ステップ2：概念設計（ER図作成）

やること：

エンティティ（実体）を抽出：「顧客」「商品」「注文」など
エンティティ同士の関係を整理：「顧客は注文を行う」「注文は商品を含む」
ER図（Entity-Relationship図）を作成

※ER図については、STEP 3で詳しく学びます

📌 ステップ3：論理設計（正規化）

やること：

正規化のルールに従ってテーブルを分割
主キー、外部キーを決定
データの整合性を保証する設計

※正規化については、Part 2（STEP 7〜12）で詳しく学びます

📌 ステップ4：物理設計

やること：

具体的なデータ型を決定（VARCHAR(255)、INT、DATETIME など）
インデックスを設計（どのカラムに貼るか）
パーティション設計（大量データの場合）
DBMSに依存する設定（MySQL、PostgreSQL など）

📌 ステップ5：実装・テスト

やること：

CREATE TABLE文でテーブル作成
テストデータを投入
想定通りにクエリが動くか確認
パフォーマンステスト
必要に応じて設計を見直し

💡 設計は一度で完璧にはならない

設計は一度で完璧にはならないことが多いです。実装しながら問題を発見し、何度も見直すのが普通です。

ただし、最初の設計を丁寧にすることで、後での修正コストを大幅に減らせます。「動けばいい」という姿勢ではなく、「なぜこの設計にするのか」を常に考えましょう。

🏗️ 5. データモデリングの3層構造

データベース設計には、3つのレベル（層）があります。それぞれ異なる視点で設計を進めていきます。

なぜ3層に分けるのでしょうか？それは、一度にすべてを考えようとすると複雑すぎるからです。段階的に詳細を詰めていくことで、設計ミスを防ぎ、関係者との認識合わせもしやすくなります。

        📊 データモデリングの3層構造
        
                    レベル
                    説明
                    成果物
                
                    概念モデル
(Conceptual)
                    何を管理するかを整理する段階。技術的な詳細は気にせず、ビジネスの視点で考える。
                    エンティティ一覧、ER図（簡易版）、関係の記述
                
                    論理モデル
(Logical)
                    どう構造化するかを決める段階。正規化を適用し、テーブル設計を行う。
                    正規化されたテーブル設計、主キー・外部キーの定義、詳細なER図
                
                    物理モデル
(Physical)
                    どう実装するかを決める段階。DBMSに依存する具体的な設定を行う。
                    CREATE TABLE文、インデックス定義、ストレージ設計

レベル	説明	成果物
概念モデル (Conceptual)	何を管理するかを整理する段階。技術的な詳細は気にせず、ビジネスの視点で考える。	エンティティ一覧、ER図（簡易版）、関係の記述
論理モデル (Logical)	どう構造化するかを決める段階。正規化を適用し、テーブル設計を行う。	正規化されたテーブル設計、主キー・外部キーの定義、詳細なER図
物理モデル (Physical)	どう実装するかを決める段階。DBMSに依存する具体的な設定を行う。	CREATE TABLE文、インデックス定義、ストレージ設計

各レベルの詳細と具体例

📝 概念モデル（Conceptual Model）

目的：ビジネス要件を理解し、「何を管理するか」を明確にする

特徴：

技術的な詳細は含まない（データ型やインデックスは考えない）
エンティティと関係性だけを表現
ビジネスユーザー（非エンジニア）とも共有できる
「〇〇は△△を持つ」「〇〇は△△と関連する」という形で記述

概念モデルの具体例（ブログシステム）：

【例】ブログシステムの概念モデル

エンティティ（管理したいもの）：
– ユーザー（投稿者）… ブログを書く人
– 記事 ……………. ブログの投稿
– カテゴリ ………… 記事の分類
– コメント ………… 記事への感想

関係性：
– ユーザーは記事を投稿する（1対多：1人が複数の記事を投稿）
– 記事はカテゴリに属する（多対1：複数の記事が1つのカテゴリに属する）
– 記事はコメントを持つ（1対多：1つの記事に複数のコメント）
– ユーザーはコメントを投稿する（1対多：1人が複数のコメントを投稿）

📊 論理モデル（Logical Model）

目的：データの整合性を保証し、効率的な構造を設計する

特徴：

正規化を適用（データの重複を排除）
主キー、外部キーを定義
データ型は抽象的（「文字列」「数値」程度）
特定のDBMSに依存しない

論理モデルの具体例（ブログシステム）：

【例】ブログシステムの論理モデル

users（ユーザー）
– user_id（主キー）… 一意の識別子
– username ………. ユーザー名
– email …………. メールアドレス
– created_at …….. 登録日時

categories（カテゴリ）
– category_id（主キー）… 一意の識別子
– category_name …….. カテゴリ名

posts（記事）
– post_id（主キー）………. 一意の識別子
– user_id（外部キー → users）… 投稿者への参照
– category_id（外部キー → categories）… カテゴリへの参照
– title ………………… タイトル
– content ………………. 本文
– created_at ……………. 投稿日時

comments（コメント）
– comment_id（主キー）………. 一意の識別子
– post_id（外部キー → posts）….. 記事への参照
– user_id（外部キー → users）….. コメント投稿者への参照
– comment_text ……………. コメント本文
– created_at ……………… 投稿日時

🔧 物理モデル（Physical Model）

目的：実際のDBMSで動作する具体的な設計

特徴：

具体的なデータ型を指定（VARCHAR(255)、INT など）
インデックスを設定（検索を高速化）
DBMSに依存する機能を使用（AUTO_INCREMENT、ENGINE など）
文字コード、ストレージエンジンなども決定

物理モデルの具体例（MySQLでのブログシステム）：

※コードが長いため横スクロールできます

— usersテーブルの作成
— ユーザー情報を格納するテーブル
CREATE TABLE users (
    user_id INT AUTO_INCREMENT PRIMARY KEY,  — 自動採番の主キー
    username VARCHAR(50) NOT NULL UNIQUE,     — ユーザー名（50文字以内、必須、重複不可）
    email VARCHAR(255) NOT NULL UNIQUE,       — メール（255文字以内、必須、重複不可）
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,  — 登録日時（自動で現在時刻）
    INDEX idx_username (username),            — ユーザー名での検索を高速化
    INDEX idx_email (email)                   — メールでの検索を高速化
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;      — InnoDBエンジン、UTF-8文字セット

— postsテーブルの作成
— 記事情報を格納するテーブル
CREATE TABLE posts (
    post_id INT AUTO_INCREMENT PRIMARY KEY,   — 自動採番の主キー
    user_id INT NOT NULL,                     — 投稿者のID（必須）
    category_id INT NOT NULL,                 — カテゴリのID（必須）
    title VARCHAR(200) NOT NULL,              — タイトル（200文字以内、必須）
    content TEXT NOT NULL,                    — 本文（長い文章用）
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,  — 投稿日時
    FOREIGN KEY (user_id) REFERENCES users(user_id),        — usersテーブルへの外部キー
    FOREIGN KEY (category_id) REFERENCES categories(category_id),  — categoriesテーブルへの外部キー
    INDEX idx_user_id (user_id),              — ユーザーIDでの検索を高速化
    INDEX idx_category_id (category_id),      — カテゴリIDでの検索を高速化
    INDEX idx_created_at (created_at)         — 日時での検索を高速化
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

💡 3層構造のメリット

段階的に設計を進めることで：

✅ ビジネス要件の理解漏れを防ぐ（まず「何を管理するか」を明確に）
✅ 技術的な詳細に早すぎる段階で囚われない（最初はシンプルに考える）
✅ 各段階でレビューができるので、設計の質が向上
✅ DBMSを変更する場合も、論理モデルまでは使い回せる（MySQL → PostgreSQLなど）

💼 6. 実際のプロジェクトでの設計の進め方

実際のプロジェクトでは、どのように設計を進めていくのでしょうか？ECサイト構築プロジェクトを例に、実践的な流れを見てみましょう。

🎯 実践的な設計プロセス（ECサイトの例）

ステップ1：キックオフミーティング

クライアントや関係者と打ち合わせ
「どんなECサイトを作りたいか」をヒアリング
必要な機能をリストアップ（商品検索、カート、決済、会員登録など）
想定ユーザー数、商品数、アクセス数の確認

ステップ2：要件整理

管理したいデータを洗い出し
「顧客」「商品」「注文」「在庫」「配送」「決済」など
各データに必要な情報を整理
優先度を付ける（必須/あれば良い/将来対応）

ステップ3：概念設計（ER図作成）

エンティティを抽出（draw.ioなどのツールを使用）
関係性を図示
クライアントと認識合わせ（非エンジニアでも理解できるレベル）

ステップ4：論理設計

正規化を適用
テーブル設計書を作成（Excel、Notionなど）
主キー・外部キーを定義
チーム内でレビュー

ステップ5：物理設計

データ型を決定
インデックス設計
パフォーマンス要件を考慮（将来のデータ量増加も見据えて）

ステップ6：実装とテスト

テーブル作成（CREATE TABLE文）
テストデータ投入
クエリ動作確認
パフォーマンステスト（大量データでの動作確認）

ステップ7：レビューと改善

チームでレビュー
問題点があれば設計を見直し
ドキュメント更新

設計時の重要なポイント

👥 関係者とのコミュニケーション

設計は一人で進めない。クライアント、開発チーム、運用チームと密に連携することが重要。認識のズレは後から大きな手戻りになります。

📝 ドキュメント作成

設計書、ER図、テーブル定義書など、きちんとドキュメント化する。後から見返せることが大切。「なぜこの設計にしたか」も記録しておく。

🔄 反復的な改善

最初から完璧を目指さない。実装しながら問題を発見し、改善していく姿勢が大事。ただし、基本設計は慎重に。

⚡ パフォーマンス考慮

将来のデータ量増加を見据えて設計する。「今は100件だから問題ない」ではなく、「将来100万件になったら？」を考える。

⚠️ よくある失敗パターン

❌ 要件定義が不十分なまま設計を開始 → 後で大幅な設計変更が必要に
❌ 正規化を理解せずに設計 → データの重複や矛盾が発生
❌ パフォーマンスを考慮しない → 運用開始後に性能問題が発覚
❌ ドキュメントを作らない → 後から理解できない、引き継げない
❌ レビューをしない → 設計ミスに気づかず進んでしまう
❌ 「動けばいい」で終わる → 保守性が低く、改修が困難に

🎯 7. このコースで学ぶこと

このコース全20ステップで、データベース設計の基礎から実践までを網羅的に学びます。

📚 コースの構成

Part 1: 基礎理論（ステップ1〜6）

データベース設計の基本概念（今学んでいる内容）
エンティティとリレーションシップ
ER図の書き方
データ型の選択
主キーと外部キー
命名規則とベストプラクティス

Part 2: 正規化（ステップ7〜12）

正規化とは何か、なぜ必要か
第1正規形、第2正規形、第3正規形
BCNF（ボイスコッド正規形）
正規化の総合演習

Part 3: 実践設計（ステップ13〜17）

インデックス設計戦略
データウェアハウス設計（OLAP）
スタースキーマとスノーフレークスキーマ
NoSQL基礎（MongoDB）

Part 4: 総合プロジェクト（ステップ18〜20）

SNS設計プロジェクト（Twitter風サービス）
ECサイト設計プロジェクト
予約システム設計プロジェクト（ホテル・レストラン）

💡 学習のポイント

✅ 順番通りに学ぶ：各ステップは前のステップの知識を前提としています
✅ 手を動かす：読むだけでなく、実際にER図を書いたり、SQLを書いたりしましょう
✅ 練習問題を解く：各ステップの練習問題で理解度を確認
✅ プロジェクトに挑戦：Part 4の総合プロジェクトで実践力をつける
✅ 「なぜ」を考える：なぜこの設計なのか、別の方法はないか、を常に考える

📝 STEP 1 のまとめ

✅ このステップで学んだこと

データベース設計とは、データをどう保存するかの設計図を作ること
良い設計はデータの整合性、パフォーマンス、保守性を保証する
悪い設計は重複、矛盾、パフォーマンス低下を引き起こす
設計は5つのステップで進める：要件定義 → 概念設計 → 論理設計 → 物理設計 → 実装
データモデリングには3つのレベルがある：概念、論理、物理
実際のプロジェクトでは、関係者との連携と反復的な改善が重要

💡 次のステップへ

データベース設計は、システム開発の土台です。家を建てるときの設計図と同じように、しっかりとした設計があれば、良いシステムが作れます。

次のSTEP 2では、エンティティとリレーションシップについて学び、「データをどう整理するか」の基本概念を深めていきましょう。

📝 理解度チェック

問題 1 基礎

データベース設計とは何か、自分の言葉で説明してください。

【解答例】

データベース設計とは、システムで使うデータをどのように保存するか、その設計図を作ることです。

具体的には、以下のようなことを決めます。

どんなテーブルを作るか（顧客、商品、注文など）
各テーブルにどんなカラムを持たせるか（名前、価格、日付など）
テーブル同士をどう繋ぐか（顧客IDで紐付けるなど）

ポイント：「設計図」「テーブル」「カラム」「関係性」などのキーワードが入っていればOKです。

問題 2 基礎

悪いデータベース設計によって引き起こされる問題を3つ挙げてください。

【解答例】

以下の5つから3つを選んで答えられればOKです。

データの重複：同じ情報が複数の場所に保存され、更新が大変になる
データの矛盾：ある場所では「山田太郎」、別の場所では「山田太郎」と表記が違うなど、整合性が取れなくなる
パフォーマンス低下：検索に時間がかかりすぎて、システムが遅くなる
拡張性がない：新機能を追加しようとすると、大規模な改修が必要になる
バグが多発：データの整合性が取れず、エラーが頻発する

問題 3 基礎

データベース設計の5つのステップを順番に挙げてください。

【解答】

要件定義：「何を作りたいのか」を明確にする
概念設計（ER図作成）：「どんなエンティティがあるか」を整理
論理設計（正規化）：データの重複や矛盾を排除するため、正規化を適用
物理設計：実際のDBMSに合わせて、データ型やインデックスを決定
実装・テスト：テーブルを作成し、動作確認

問題 4 応用

データモデリングの3層構造（概念モデル、論理モデル、物理モデル）について、それぞれの役割を説明してください。

【解答】

1. 概念モデル（Conceptual Model）

役割：「何を管理するか」を整理する段階
ビジネスの視点で考え、技術的な詳細は気にしない
エンティティと関係性を抽出する
成果物：エンティティ一覧、簡易ER図

2. 論理モデル（Logical Model）

役割：「どう構造化するか」を決める段階
正規化を適用し、テーブル設計を行う
主キー・外部キーを定義する
成果物：正規化されたテーブル設計、詳細ER図

3. 物理モデル（Physical Model）

役割：「どう実装するか」を決める段階
実際のDBMSに合わせて設計
具体的なデータ型、インデックス、ストレージなどを決定
成果物：CREATE TABLE文、インデックス定義

問題 5 発展

以下の「悪い設計」の例を見て、どこが問題かを指摘し、どう改善すべきか考えてください。

学生成績テーブル（student_grades）
————————————————————
student_id | student_name | subject | grade | teacher_name
1          | 山田太郎     | 数学    | 85    | 佐藤先生
1          | 山田太郎     | 英語    | 90    | 鈴木先生
2          | 田中花子     | 数学    | 78    | 佐藤先生

【問題点】

学生情報の重複：山田太郎の情報が2回記録されている。名前変更時に複数レコードを更新する必要がある。
教師情報の重複：佐藤先生の情報が2回記録されている。
科目と教師の関係が不明確：「数学」と「佐藤先生」の関係がテーブル構造から読み取れない。

【改善案】

テーブルを4つに分割する。

students（学生）… 学生情報を一元管理
———————————–
student_id | student_name
1          | 山田太郎
2          | 田中花子

teachers（教師）… 教師情報を一元管理
———————————–
teacher_id | teacher_name
1          | 佐藤先生
2          | 鈴木先生

subjects（科目）… 科目と担当教師の関係を管理
———————————–
subject_id | subject_name | teacher_id
1          | 数学         | 1
2          | 英語         | 2

grades（成績）… どの学生がどの科目で何点取ったかを管理
———————————–
grade_id | student_id | subject_id | grade
1        | 1          | 1          | 85
2        | 1          | 2          | 90
3        | 2          | 1          | 78

改善のポイント：
✅ 学生情報の重複を解消
✅ 教師情報の重複を解消
✅ 科目と教師の関係を明確化
✅ データの更新が簡単になる
✅ 外部キー制約でデータの整合性を保証できる

❓ よくある質問

Q1: データベース設計は、プログラミング経験がなくても学べますか？

はい、学べます！ただし、SQLの基礎知識（SELECT、INSERT、UPDATE、DELETEなど）は必須です。このコースの前提条件として「SQL基礎コース修了」を推奨しているのはそのためです。プログラミング経験は必須ではありませんが、論理的思考力は必要です。

Q2: データベース設計を学ぶと、どんな仕事に役立ちますか？

様々な職種で役立ちます。

・データベースエンジニア：設計が本業
・バックエンドエンジニア：APIとDBの設計を担当
・データアナリスト：データ構造を理解して効率的に分析
・プロジェクトマネージャー：技術的な判断ができる
・システムアーキテクト：全体設計の中でDB設計を統括

Q3: 正規化は必ず行わないといけませんか？

基本的には「はい」ですが、例外もあります。正規化はデータの整合性を保証するため非常に重要です。ただし、パフォーマンスのために意図的に「非正規化」することもあります。これは「正規化を理解した上で、戦略的に崩す」ということです。Part 2で詳しく学びます。

Q4: ER図は必ず書かないといけませんか？手を動かさずに頭の中で考えてはダメですか？

ER図は必ず書くことを強くおすすめします。頭の中だけで考えると、複雑な関係を見落としたり、後から見返せなかったりします。ER図を書くことで、チームメンバーとの共有も簡単になります。また、設計の問題点にも気づきやすくなります。

Q5: このコースを修了したら、すぐに実務で設計できるようになりますか？

基礎は身につきますが、実務経験も重要です。このコースで、データベース設計の基本から応用まで学べます。総合プロジェクト（Part 4）では実践的な設計も行います。ただし、実務では業務知識や組織の慣習なども関わってくるため、最初は先輩のレビューを受けながら進めることをおすすめします。

Q6: MySQLとPostgreSQLで設計方法は違いますか？

概念設計と論理設計は同じですが、物理設計は異なります。このコースで学ぶ「エンティティとリレーションシップ」「正規化」などの基本概念は、どのDBMSでも共通です。ただし、物理設計（データ型、インデックスの種類、パーティション方法など）はDBMSによって異なります。このコースでは主にMySQLを使いますが、基本は他のDBMSでも応用できます。

📝

学習メモ

データベース設計・データモデリング - Step 1

📋 過去のメモ一覧 ▼