✨

失敗しないDB設計

に公開
DB
db設計
要件定義
tech

DB設計難しい、、、。 最近つよつよエンジニアさんと一緒にお仕事する機会がありその方々の仕事の仕方、思考法、見方にどうやったら近づけるのかを私なりにAqua Voiceを使ってペラペラ話しながらAIを使ってまとめたものです。

🧠 概念設計（Whatを整理する）

現実世界の“もの”と“関係”を言葉で明確にする段階。

DBの前に「どんな情報が存在して、どう繋がるのか」を定義する。

目的：

  • あいまいな用語をなくす
  • ドメイン（業務）の理解をチーム全体で揃える
  • 現実世界の関係を正しくモデル化する

やること：

  • ユースケースを洗い出す（例：「ユーザーが記事を投稿する」「投稿にタグを付ける」）
  • ユビキタス言語（業務で使う言葉）をまとめる
  • 主要な「もの（エンティティ）」と「関係（1対多、多対多）」をざっくり書く
  • ドメインモデル図や手書きERメモを作る

📎 成果物：ユースケース一覧、用語集、粗いER図（関係図）

🧩 論理設計（構造を定義する）

概念設計をもとに、データとして扱う「構造」「整合性」「制約」を明確にする段階。

目的：

  • データ間の関係・整合性を保証する
  • 製品に依存しない、論理的なデータモデルを設計する

やること：

  • エンティティを抽出する（User, Article, Tag など）
  • 各エンティティの属性（カラム）を洗い出す
  • 主キーを決める（基本はサロゲートキー）
  • 制約を決める（NOT NULL, UNIQUE, 外部キーなど）
  • リレーション（1対多・多対多）を定義し、中間テーブルを設ける
  • 正規化（1〜3正規形）を意識する

📎 成果物：ER図、論理データモデル（表構造）

💽 物理設計（どう実装するかを最適化する）

論理設計をDB製品（MySQL, PostgreSQLなど）上で効率的に動かすための段階。

目的：

  • 性能と保守性を両立する構造に落とし込む

やること：

  • カラム型を決める（uuid, varchar(255), numeric(12,2)など）
  • インデックス設計（検索・JOIN・ソート最適化）
  • 非正規化の判断（必要なら理由を明記）
  • 作成者・作成日時など共通メタデータを設計
  • クエリ計画（EXPLAIN）で確認

📎 成果物：CREATE TABLE定義書、インデックス設計表、DDLスクリプト

💡 まとめ（1枚で思い出せる要約）

ステップ 目的 主な作業 成果物
概念設計 言葉と関係の明確化 ユースケース、ユビキタス言語 用語集・概念ER図
論理設計 情報構造の定義 エンティティ、属性、制約、関係 ER図（論理）
物理設計 実装・性能最適化 型、インデックス、非正規化 CREATE TABLE, インデックス設計表

Discussion