データ設計者への第一歩 - L0 カリキュラム

ストーリー

「データベースは動いてるから大丈夫でしょう？」

あなたがそう思っていた矢先、本番環境のAPIレスポンスが突然10秒を超え始めた。高橋アーキテクトが画面を覗き込む。

「テーブル設計を見せてくれ。…ああ、これは典型的な設計負債だ。データ設計は建物の基礎工事と同じだよ。見えないところこそ、最も重要なんだ」

高橋アーキテクトが語るデータ設計の世界への第一歩を踏み出そう。

なぜデータ設計が重要なのか

アプリケーションの寿命とデータの寿命

アプリケーション: 書き換え・リプレースされる（3-5年サイクル）
ビジネスロジック: 要件変更で変わる（年単位）
データ: ビジネスが続く限り生き続ける（10年以上）

データ設計の失敗は、あとから修正するコストが指数関数的に増加する。

設計の質が影響するもの

影響範囲	良い設計	悪い設計
パフォーマンス	ミリ秒レベルの応答	秒単位の遅延
保守性	変更が容易	変更のたびに障害リスク
整合性	データの矛盾なし	不整合データの蓄積
スケーラビリティ	負荷増に対応可能	データ量増で性能劣化
開発速度	新機能追加が迅速	毎回データ移行が必要

データ設計のプロセス

概念設計 → 論理設計 → 物理設計

1. 概念設計（Conceptual Design）
   └─ ビジネス要件からエンティティと関連を抽出
   └─ ツール: ER図（概念レベル）

2. 論理設計（Logical Design）
   └─ 正規化、データ型、制約の定義
   └─ ツール: ER図（論理レベル）、テーブル定義書

3. 物理設計（Physical Design）
   └─ インデックス、パーティション、ストレージ設計
   └─ ツール: DDL、性能テスト

TypeScriptで考えるデータモデル

// 概念レベル: ビジネスの言葉で表現
interface User {
  name: string;
  email: string;
  orders: Order[];
}

// 論理レベル: 正規化されたモデル
interface UserTable {
  id: number;          // PK, AUTO_INCREMENT
  name: string;        // NOT NULL, VARCHAR(100)
  email: string;       // UNIQUE, NOT NULL
  createdAt: Date;     // NOT NULL, DEFAULT NOW()
}

interface OrderTable {
  id: number;          // PK, AUTO_INCREMENT
  userId: number;      // FK -> users.id, NOT NULL
  totalAmount: number; // DECIMAL(10,2), NOT NULL
  status: string;      // ENUM('pending','paid','shipped','delivered')
  createdAt: Date;
}

データ設計者の心得

高橋アーキテクトからの3つの教え:

未来を見据えろ - 今の要件だけでなく、1年後の拡張も考慮する
制約を味方にしろ - NOT NULL, UNIQUE, FK はバグを防ぐ防壁
命名に魂を込めろ - テーブル名・カラム名がドキュメントになる

まとめ

ポイント	内容
データの寿命	アプリよりもデータの方が長く生き続ける
設計プロセス	概念 → 論理 → 物理の3段階
設計の質	パフォーマンス・保守性・整合性に直結
心得	未来を見据え、制約を活用し、命名にこだわる

理解度チェックリスト

データ設計がアプリケーションの品質に与える影響を説明できる
概念設計・論理設計・物理設計の違いを理解している
データの寿命がアプリケーションより長い理由を説明できる

次のステップ

次のレッスンでは、データ設計の核となる正規化理論を学ぶ。第一正規形から BCNF まで、理論と実践を身につけよう。

推定読了時間: 15分