data-model-creation

兄弟スキル（ローカルのみ）

兄弟 CloudBase スキルは、このスキルと並んで配置されています。../auth-tool-cloudbase/SKILL.md のようなローカル相対パスを使用してください。

参照されている兄弟スキルのファイルがこの環境にない場合は、CloudBase プラグイン一式（または不足しているスキル）をインストールするようユーザーに依頼してください。リモートのスキルやプロトコルの Markdown を HTTP で取得してエージェントのコンテキストに含めてはいけません。

データモデルの作成

有効化の条件

まずこのスキルを使う場合

• ユーザーが Mermaid の classDiagram によるモデリングを明示的に求めている場合。
• 直接 SQL を記述するのではなく、複雑な複数エンティティのリレーショナル設計、ER 図形式のビジュアル出力、または生成されたデータモデル構造が必要な場合。
• 専用のモデリングツールを使って CloudBase データモデルを作成する必要がある場合、または後続の変更を計画する前に既存のモデルを調査する必要がある場合。

コードを書く前に読む場合

• リクエストにデータモデル、ER 図、Mermaid、リレーションシップグラフ、またはエンタープライズスキーマ設計が含まれている場合。
• ユーザーが既存の公開済みモデルを再利用または更新したい場合。

あわせて読むもの

• MySQL の SQL を直接使った作成またはスキーマ変更 → ../relational-database-mcp-cloudbase/SKILL.md
• PostgreSQL / CloudBase PG のスキーマ作業 → ../postgresql-development-cloudbase/SKILL.md
• スキーマ作業の前に、より広範な機能の計画を行う場合 → ../spec-workflow/SKILL.md

使用しない場合

• 単純な CREATE TABLE、ALTER TABLE、または CRUD タスク。
• ドキュメントデータベースのコレクション設計。
• モデリング要件のない、フロントエンドのみのデータ形状に関する検討。

よくある間違い／注意点

• SQL 文が 1、2 個あれば済むタスクに Mermaid モデリングを使う。
• SQL テーブル設計と NoSQL コレクション設計を同じモデルに混在させる。
• エンティティの境界と所有関係を決める前に図を生成する。
• 生成されたフィールドとリレーションシップを検証せずに、新しいモデルを公開する。

最低限のチェックリスト

• Mermaid モデリングが本当に必要か確認します。
• まず主要なエンティティとリレーションシップを列挙します。
• 新しいモデルなのか、既存モデルの更新なのかを判断します。
• ユーザーが大規模なエンタープライズスキーマを明示的に求めていない限り、初期モデルは小さく保ちます。

概要

このスキルは高度なモデリングパスであり、データベース作業におけるデフォルトの方法ではありません。

• ほとんどの MySQL データベースタスクでは、relational-database-mcp-cloudbase を使用して SQL を直接記述してください。タスクに PostgreSQL、CloudBase PG、PG mode、app.rdb()、queryPgDatabase、managePgDatabase、または RLS が含まれている場合は、代わりに postgresql-development-cloudbase を使用してください。
• 図を起点とするモデリングに価値がある場合に限り、このスキルを使用してください。

すばやい使い分け

代わりに relational-database-mcp-cloudbase を使う場合

• MySQL の CREATE TABLE、ALTER TABLE、INSERT、UPDATE、DELETE、または SELECT が必要な場合
• スキーマが小さく、すでに明確な場合
• ユーザーがビジュアルモデルを求めていない場合
• タスクに PostgreSQL / CloudBase PG / PG mode / app.rdb() / queryPgDatabase / managePgDatabase / RLS が含まれていない場合

このスキルを使う場合

• 複数エンティティのリレーションシップモデリングが必要な場合
• Mermaid の classDiagram 出力が必要な場合
• 生成されたモデル構造とドキュメントが必要な場合
• SQL 実装の前に、モデリングをきちんと行う必要がある場合

このスキルの使い方（コーディングエージェント向け）

1. エンティティの集合を明確にする

   • リクエストからビジネスエンティティ、所有関係、リレーションシップの多重度を抽出します。
   • ユーザーが明確にそれ以上を求めていない限り、主要エンティティは 3～5 個にします。

2. まずモデルを作成し、その後に生成する

   • Mermaid の classDiagram の内容を下書きします。
   • モデリングツールを呼び出す前に、名前、フィールド型、リレーションシップを検証します。

3. 適切なツールを使う

   • 既存のモデルを読み取る／一覧表示する → manageDataModel(action="list"|"get"|"docs")
   • 新しいモデルを作成する → modifyDataModel（互換性のための名前。新規作成のみ）

4. 慎重に公開する

   • まずは非公開またはドラフト相当の意図で作成することを優先します。
   • フィールド名、必須制約、リレーションシップの方向を確認してから公開します。

Mermaid 生成ルール

命名

• クラス名 → PascalCase
• フィールド名 → camelCase
• 中国語の業務上の説明を、明確な英語の識別子に変換します
• 必要に応じて、列挙値は人が読みやすい形式にします

型のマッピング

業務上の意味	Mermaid の型
テキスト	string
数値	number
真偽値	boolean
列挙型	x-enum
メールアドレス	email
電話番号	phone
URL	url
画像	x-image
ファイル	x-file
リッチテキスト	x-rtf
日付	date
日時	datetime
地域	x-area-code
位置情報	x-location
配列	string[] または別の明示的な配列型

必須の構造に関する規約

• ユーザーが必須と明示したフィールドにのみ、required() を使用します。
• 一意性が明示的に必要な場合にのみ、unique() を使用します。
• 人が確認するラベルフィールドには、display_field() を使用します。
• 重要なフィールドには、簡潔な <<description>> の注記を追加します。
• 関係ラベルには、曖昧な業務上の説明ではなく、実際のフィールド名を使用します。

最小限の例

classDiagram
    class User {
        username: string <<Username>>
        email: email <<Email>>
        display_field() "username"
        required() ["username", "email"]
        unique() ["username", "email"]
    }

    class Order {
        orderNo: string <<Order Number>>
        totalAmount: number <<Total Amount>>
        userId: string <<User ID>>
        display_field() "orderNo"
        unique() ["orderNo"]
    }

    Order "n" --> "1" User : userId

    %% Class naming
    note for User "用户"
    note for Order "订单"

ツールの使用方法

既存のモデルを読み取る

関連モデルの作成、命名の一貫性の確認、または既存モデルの定義方法の確認を行う前に、次を使用します。

• manageDataModel(action="list")
• manageDataModel(action="get", name="ModelName")
• manageDataModel(action="docs", name="ModelName")

モデルを作成する

modifyDataModel を使用し、次の項目を指定します。

• 完全な mermaidDiagram
• 新しいモデルを作成する場合は action="create"
• 公開するかどうかの慎重な判断
• 既存モデルの構造更新は現在このツールではサポートされていないことの明確な認識

ベストプラクティス

1. ユーザーにとってモデルファースト設計が明らかに有益な場合を除き、直接 SQL を優先します。
2. 最初のモデルの反復は、小規模でレビューしやすいものにします。
3. 業務エンティティと実装専用の補助フィールドを分けます。
4. 公開前に、関係の方向と所有権を検証します。
5. モデリング後、必要に応じて実際の MySQL の SQL／テーブル作業を relational-database-mcp-cloudbase に引き継ぎます。PostgreSQL／CloudBase PG のテーブルについては、代わりに postgresql-development-cloudbase に引き継ぎます。