データベースデザイナー

ユーザーの要件に基づいて、本番環境ですぐに使える完全なデータベーススキーマを設計します。包括的なドキュメント、SQLスクリプト、およびDrawDB互換のER図ファイルを生成します。

コア設計原則

設計を開始する前に、常に references/design-principles.md を読んで以下を理解してください：

物理外部キーなし（論理関係のみ）
実際の使用状況に基づいた現実的なフィールドサイズ
最小限で戦略的なインデックス設計
すべてのテーブルとフィールドに必須のコメント
デフォルトのシステムフィールド（id、タイムスタンプ、論理削除）
snake_case 命名規則

ワークフロー

ステップ1：要件の理解

データベース設計に関する情報を収集します：

データベースの種類：MySQL 8.0（デフォルト）、PostgreSQL、SQL Server など
ビジネスドメイン：Eコマース、ブログ、CRM、ERP など
コアエンティティ：必要な主要テーブルは？
主要機能：データベースがサポートすべき機能は？
特別な要件：特定の制約や好みは？

ユーザーが最小限の情報しか提供しない場合、一般的なビジネスシナリオと references/design-examples.md に文書化されたベストプラクティスに基づいて、不足している詳細をインテリジェントに推測します。

主要な推測シナリオ：

ユーザーが「ユーザーテーブルを設計して」と言う → 推測：username、password、email、phone、status
ユーザーが「Eコマースシステム」と言う → 推測：user、product、order、order_detail テーブル
ユーザーが「ブログシステム」と言う → 推測：user、article、comment、tag、article_tag テーブル

ステップ2：参照ドキュメントの読み込み

設計要件に基づいて、適切な参照を読み込みます：

常に読み込む：コア設計ルールのための references/design-principles.md
形式生成のため：JSON/DBML仕様のための references/drawdb-formats.md
例のため：類似システム設計のための references/design-examples.md

ステップ3：データベーススキーマの設計

以下のガイドラインに従って、完全なテーブル構造を作成します：

テーブル設計チェックリスト

各テーブルについて：

✅ デフォルトのシステムフィールドを追加（ユーザーが別途指定しない限り）：
- id BIGINT AUTO_INCREMENT PRIMARY KEY
- created_at DATETIME DEFAULT CURRENT_TIMESTAMP
- updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
- is_deleted TINYINT(1) DEFAULT 0
✅ 現実的なサイズでビジネスフィールドを設計：
- username: VARCHAR(50)
- email: VARCHAR(100)
- phone: VARCHAR(20)
- title: VARCHAR(200)
- description: TEXT
- 完全なサイズ標準については references/design-principles.md を参照
✅ 適切な制約を追加：
- 必須フィールドには NOT NULL
- オプションフィールドには DEFAULT 値
- 一意性が必要なフィールドには UNIQUE（ただし外部キーとしては使用しない）
✅ すべてのテーブルとフィールドに COMMENT を追加（日本語）
✅ 物理的な FOREIGN KEY 制約を作成しない

インデックス設計戦略

各テーブルについて、以下のインデックスを分析して作成します：

WHERE句フィールド：フィルタリングで頻繁に使用されるフィールド
JOINフィールド：すべての xxx_id 外部キーフィールド
ORDER BY / GROUP BY フィールド：ソートおよびグループ化フィールド
一意制約：email、phone、order_no など → UNIQUE インデックス

インデックスの命名規則：

通常のインデックス：idx_field_name または idx_field1_field2
一意インデックス：uk_field_name

インデックスの制限：

テーブルあたり最大5つのインデックス（ユーザーがそれ以上を要求しない限り）
ビジネスクエリを直接サポートするインデックスのみを作成

関係設計

テーブル間の論理関係を特定します：

一対多 (1:N)：最も一般的
- 例：user (1) → order (N)
- 実装：orderテーブルに user_id を追加
- DrawDB：多対一関係
一対一 (1:1)：テーブル分割用
- 例：user (1) → user_profile (1)
- 実装：user_profileテーブルに user_id UNIQUE を追加
- DrawDB：一対一関係
多対多 (N:N)：結合テーブルが必要
- 例：article (N) ↔ tag (N)
- 実装：article_id + tag_id を持つ article_tag 結合テーブルを作成
- DrawDB：2つの多対一関係

ステップ4：出力の生成

必要なすべての出力ファイルを作成します：

4.1 包括的な設計ドキュメント（Markdown）

構造化された単一のMarkdownファイルを作成します：

構造：

# [プロジェクト名] データベース設計書

## 1. データベース概要
- データベースの種類
- 文字セット
- コアテーブル数
- 主要機能モジュール

## 2. テーブル構造設計

### 2.1 [テーブル名]
**テーブル名**: table_name
**説明**: テーブルの説明

**フィールド一覧**:
| フィールド名 | 型 | NULL許可 | デフォルト値 | 説明 |
|--------|------|--------|--------|------|
| id | BIGINT | NO | | 主キー |
| ... | ... | ... | ... | ... |

**インデックス一覧**:
| インデックス名 | 種類 | フィールド |
|--------|------|------|
| uk_email | UNIQUE | email |
| idx_username | INDEX | username |

### 2.2 [次のテーブル]
...

## 3. テーブル関係説明
- table1 → table2 (1:N): 説明
- table3 ↔ table4 (N:N): 結合テーブル経由の説明

## 4. インデックス戦略説明
インデックス設計の決定の根拠を説明

4.2 SQLスクリプト

実行可能なSQLスクリプトを作成します：

-- Database: project_name
-- Generated: YYYY-MM-DD

-- テーブルが存在する場合は削除（依存関係の逆順）
DROP TABLE IF EXISTS `table3`;
DROP TABLE IF EXISTS `table2`;
DROP TABLE IF EXISTS `table1`;

-- テーブルを作成（依存関係の順序）
CREATE TABLE `table1` (
  `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT 'コメント',
  ...
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_field` (`field`),
  KEY `idx_field` (`field`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='テーブルコメント';

CREATE TABLE `table2` (
  ...
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='テーブルコメント';

4.3 DrawDB JSON形式

references/drawdb-formats.md に従って、DrawDB互換のJSONファイルを生成します：

重要な形式要件：

テーブルID：ランダムな21文字の文字列を使用（例："_KV5MtPf2m4sI7Inu8pat"）
フィールドID：ランダムな21文字の文字列を使用（例："B8rPRTDtOv9oD2Gp4bhWL"）
インデックスID：すべてのテーブルで0から始まる数値のインクリメント
リレーションシップID：ランダムな21文字の文字列を使用
フィールドタイプ：完全な型定義を含める（例："VARCHAR(100)"、タイプとサイズを分離しない）
サイズフィールドなし：型情報は型文字列に埋め込まれます
インデックスフィールド：フィールド名の文字列を使用、フィールドIDは使用しない（例：["email"]、[1] ではない）
座標：x/y位置に浮動小数点数を使用

ID生成：

import random
import string

def generate_id():
    chars = string.ascii_letters + string.digits + '_-'
    return ''.join(random.choice(chars) for _ in range(21))

レイアウト戦略：

グリッドレイアウトを使用：x = (index % 3) * 450 + 50、y = floor(index / 3) * 400 + 50
定義済みの色を順に使用：["#6360f7", "#bc49c4", "#ffe159", "#89e667", "#ff9159", "#59d9ff", "#ff5959", "#a0a0a0"]

リレーションシップ生成：

すべての xxx_id 外部キーフィールドに対してリレーションシップを生成
テーブルとフィールドには実際のランダムな文字列IDを使用
UNIQUE制約に基づいてカーディナリティを設定：
- UNIQUEあり → "one_to_one"
- UNIQUEなし → "many_to_one"

構造：

{
  "tables": [
    {
      "id": "random_string",
      "name": "table_name",
      "comment": "テーブルコメント",
      "color": "#6360f7",
      "fields": [
        {
          "id": "random_string",
          "name": "id",
          "type": "BIGINT",
          "default": "",
          "check": "",
          "primary": true,
          "unique": true,
          "notNull": true,
          "increment": true,
          "comment": "主キーID"
        }
      ],
      "indices": [
        {
          "id": 0,
          "fields": ["field_name"],
          "name": "idx_field_name",
          "unique": false
        }
      ],
      "x": 50.0,
      "y": 50.0
    }
  ],
  "relationships": [
    {
      "name": "",
      "startTableId": "random_string",
      "endTableId": "random_string",
      "endFieldId": "random_string",
      "startFieldId": "random_string",
      "id": "random_string",
      "updateConstraint": "No action",
      "deleteConstraint": "No action",
      "cardinality": "many_to_one"
    }
  ],
  "notes": [],
  "subjectAreas": [],
  "database": "generic",
  "types": [],
  "title": "Project Database"
}

4.4 DrawDB DBML形式

references/drawdb-formats.md に従ってDBMLファイルを生成します：

重要なポイント：

小文字のデータ型を使用：bigint、varchar(50)、datetime
属性を角括弧で追加：[pk, increment, not null, unique, note: 'コメント']
テーブル定義内の indexes { } ブロックでインデックスを定義
Ref ブロックを使用してテーブル外でリレーションシップを定義
適切なリレーションシップ記号を使用：>（多対一）、-（一対一）

構造：

Table table_name [headercolor: #6360f7] {
  id bigint [pk, increment, not null, unique, note: 'コメント']
  field varchar(100) [not null, note: 'コメント']
  
  indexes {
    field [unique, name: 'uk_field']
  }
  
  Note: 'テーブルコメント'
}

Ref fk_name {
  table1.field > table2.id [delete: no action, update: no action]
}

ステップ5：最終化と提供

5.1 出力ディレクトリ規則

推奨アプローチ（Claude Code公式標準に従う）：

すべてのデータベース設計ファイルを outputs/<project-name>/database/ に保存します：

outputs/
└── <project-name>/              # プロジェクト名（例：e-commerce-system）
    └── database/
        ├── schema-design.md     # 包括的な設計ドキュメント
        ├── schema.sql           # 実行可能なSQLスクリプト
        ├── drawdb-schema.json   # DrawDB JSON形式
        └── drawdb-schema.dbml   # DrawDB DBML形式

例：

outputs/
├── e-commerce-system/
│   └── database/
│       ├── schema-design.md
│       ├── schema.sql
│       ├── drawdb-schema.json
│       └── drawdb-schema.dbml
└── task-management-app/
    └── database/
        ├── schema-design.md
        └── schema.sql

代替アプローチ（従来のプロジェクト構造）：

プロジェクトに既存のディレクトリ構造がある場合は、以下も使用できます：

project-root/
└── database/
    ├── schema-design.md
    ├── schema.sql
    ├── drawdb-schema.json
    └── drawdb-schema.dbml

5.2 出力ファイル一覧

必須出力（4ファイル）：

schema-design.md - 包括的なデータベース設計ドキュメント（日本語）
schema.sql - 実行可能なSQLスクリプト
drawdb-schema.json - DrawDB JSON形式
drawdb-schema.dbml - DrawDB DBML形式

オプション出力：

er-diagram.png - ER図の可視化（ツールが利用可能な場合）
index-strategy.md - インデックス戦略のドキュメント

5.3 ファイル命名規則

ケバブケースを使用：user-authentication-schema.sql
必要に応じてバージョン/日付を含める：schema-v1.0.sql または schema-2024-12-10.sql
説明的な名前を使用：e-commerce-database-schema.sql

5.4 提供サマリー

すべてのファイルを生成した後、以下のサマリーを提供します：

設計上の決定に関する簡単な概要
作成されたテーブルの数
主要なリレーションシップとその根拠
DrawDBへのインポート方法（JSONまたはDBML）
ファイルの保存場所の確認
次のステップの提案（例：インデックスのレビュー、開発環境での実装）

特別な処理

ユーザーが「システムフィールド不要」と言った場合

最小限の構造のみを作成します：

CREATE TABLE `table_name` (
  `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主キー',
  /* ビジネスフィールドのみ */
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='テーブルコメント';

ユーザーが非MySQLデータベースを指定した場合

それに応じてSQL構文を適応させます：

PostgreSQL：

AUTO_INCREMENT の代わりに SERIAL または BIGSERIAL を使用
DATETIME の代わりに TIMESTAMP を使用
デフォルト値と制約の構文が異なる

SQL Server：

AUTO_INCREMENT の代わりに IDENTITY(1,1) を使用
DATETIME の代わりに DATETIME2 を使用
Unicodeサポートには NVARCHAR を使用

Oracle：

自動インクリメントには SEQUENCE を使用
VARCHAR の代わりに VARCHAR2 を使用
時間フィールドには DATE または TIMESTAMP を使用

要件があいまいな場合

インテリジェントな推測を適用します：

ビジネスドメインを特定（Eコマース、ブログ、CRMなど）
references/design-examples.md の類似例を参照
ドメインに適した一般的なフィールドを含める
典型的なクエリパターンに基づいて妥当なインデックスを設計
設計ドキュメントで行った前提を説明

品質検証

最終確定前に、以下を確認します：

呼び出し例

ユーザーが言う：「ECサイトのデータベースを設計して。ユーザー、商品、注文機能を含めて」 → design-principles.md と design-examples.md を読む → 設計：user_info、product_info、order_info、order_detail テーブル → 4つの出力ファイルをすべて生成

ユーザーが言う：「ブログのデータベースを設計して」 → 推測：user、article、comment、tag、article_tag テーブル → 標準の設計原則に従う → すべての出力を生成

ユーザーが言う：「PostgreSQL用のユーザーテーブルを作成して」 → 単一テーブル設計 → SQL構文をPostgreSQLに適応 → すべての出力形式に含める

参考文献

references/design-principles.md - コア設計ルールと標準
references/drawdb-formats.md - JSONおよびDBML形式の仕様
references/design-examples.md - 実際の設計例

お気に入りのAIに質問する

ドキュメント

データベースデザイナー

コア設計原則

ワークフロー

ステップ1：要件の理解

ステップ2：参照ドキュメントの読み込み

ステップ3：データベーススキーマの設計

テーブル設計チェックリスト

インデックス設計戦略

関係設計

ステップ4：出力の生成

4.1 包括的な設計ドキュメント（Markdown）

4.2 SQLスクリプト

4.3 DrawDB JSON形式

4.4 DrawDB DBML形式

ステップ5：最終化と提供

5.1 出力ディレクトリ規則

5.2 出力ファイル一覧

5.3 ファイル命名規則

5.4 提供サマリー

特別な処理

ユーザーが「システムフィールド不要」と言った場合

ユーザーが非MySQLデータベースを指定した場合

要件があいまいな場合

品質検証

呼び出し例

参考文献

Individual skills in this repo

academic-writing-style

product-manager

solution-architect

ui-designer

ui-ux-pro-max

関連スキル

steipete/bluebubbles

steipete/eightctl

steipete/blucli

steipete/bear-notes

steipete/camsnap

steipete/gifgrep