エンティティ関係図（ERD）とは何ですか？
「エンティティ関係図（ERD）は、関係データベースの設計、文書化、分析に使用される構造的なブループリントです。システム内のテーブル（エンティティ）、それらが含む特定の列（属性）、およびそれらのテーブルがどのようにリンクされているかを可視化します。PlantUMLでは、ERDは「情報工学（IE）表記法」を使用して作成され、標準のクロウズフット表記法を用いて関係制約を表現します。
マイクロサービスのデータストアを設計している場合、SQLの結合パスを最適化している場合、または企業全体のデータウェアハウスアーキテクチャをマッピングしている場合、テキスト駆動型のUML ERDにより、データベーススキーマが完全に明確になります。VPasCodeを使用すると、明快で宣言的な構文でデータベーステーブル、インデックスキー、論理関係を定義できます。エンジンはテーブルボックスのサイズ調整を自動的に行い、重複するレイアウト線なしに外部キー接続文字列をルーティングします。
コア構文ガイド：要素と構造
PlantUMLで堅牢なIEスタイルのERDを構築するには、構造化されたエンティティブロック、明確なキー指定、クロウズフットの基数修飾子に依存します。
1. エンティティ（データベーステーブル）の宣言
データベーステーブルは「entity」キーワードで宣言します。その後にテーブル名と波かっこを記述します。波かっこ内にはテーブルの列を記述します。スキーマを明確かつ読みやすくするため、水平線セパレータ（--）を使用して、主キー／外部キーと通常のデータ属性を分離してください：
entity "users" as users_table {
id : INT [PK]
--
email : VARCHAR(255)
created_at : TIMESTAMP
}
2. 主キーおよび外部キーの指定
テキストによるインジケータ（例：[PK]や[FK]）は十分に機能しますが、PlantUMLのIEエンジンは視覚的なキーインジケータもサポートしています。属性の前にアスタリスク（*）を配置すると、その列が**必須（null不可）**であることを示します。一方、明確なテキスト文字列またはタグを追加することで、明示的なインデックスコンテキストを追加できます：
エンティティ "orders" {
* id : INT <<PK>>
--
* user_id : INT <<FK>>
discount_code : VARCHAR(50)
}
3. クロウズフットの基数と関係のマッピング
テーブルを接続し参照整合性制約を強制するために、ダッシュ、括弧、パイプ文字の組み合わせを使用してください。IE表記では、これらの記号が異なる**クロウズフット**の頭部を形成し、データベースの関係を表します：
||--||**厳密に1対1:** 厳密で必須の1対1のマッピング。||--o|**1対0または1:** オプションの1対1のマッピング。||--|{**1対1または複数:** 必須の1対多の依存関係。||--o{**1対0、1、または複数:** 標準的なオプションの1対多の関係。
クリーンなデータベーススキーマのためのベストプラクティス
- キャスティング規則を維持する：エンティティ宣言が予測可能になるようにしてください。実際のSQLマッピングテーブルには小文字のスネークケース（例：
order_items）を使用し、概念的なドメインモデルには大文字のキャメルケースを使用してください。 - 常に外部キーを文書化する： 2つのテーブルをリンクする際は、常に子テーブルブロック内に外部キー列を指定してください。これにより、データ移行中にエンジニアリングチームが明確な参照コンテキストを持つことができます。
- クロウズフットの間隔を制御する：数十のテーブルを含む複雑なデータベーススキーマは、すぐに混雑してしまうことがあります。関係線が自然でない形で交差し始めたら、ダブルダッシュ接続子（
--）を3本または4本のダッシュ（---）に置き換えて、テーブルを離し、レイアウトエンジンがグリッドを整理するための余地を確保してください。
実際のPlantUML ERDの例
例1：コアECサイトの関係データベースモデル（キーとマッピング）
この機能的ブループリントは、コアECサイトのデータベーストランザクションループをモデル化しており、ユーザー、注文、支払い台帳が厳密なクロウズフット関係を使ってどのようにリンクしているかを示しています。
@startuml
' エンティティボックスのレンダリングをシャープな現代的な四角に固定
hide circle
skinparam LINETYPE ortho
entity "users" as user {
* id : INT <<PK>>
--
* email : VARCHAR(100)
* password_hash : VARCHAR(255)
phone : VARCHAR(20)
}
entity "orders" as order {
* id : INT <<PK>>
--
* user_id : INT <<FK>>
* total_amount : DECIMAL(10,2)
status : VARCHAR(50)
}
entity "payment_ledgers" as ledger {
* id : INT <<PK>>
--
* order_id : INT <<FK>>
* transaction_reference : VARCHAR(100)
gateway : VARCHAR(50)
}
' 関係スキーマのバインディングを定義
user ||--o{ order : "注文する"
order ||--|| ledger : "生成する"
@enduml
構文の分解： 指令 hide circle はデフォルトのUMLクラストークンのバブル表示を無効にし、skinparam LINETYPE ortho は関係パスを明確な90度の直角に強制します。このスキーマは、ユーザーが注文をゼロ個または複数個行えること（||--o{）、一方で注文は必ず1つの関連する支払い台帳レコードを持つ必要があること（||--||).
例2：高度なコンテンツ管理システムスキーマ（多対多の交差）
この高度なエンタープライズブループリントは、完全なコンテンツ管理システム（CMS）のトポロジーをマッピングしています。中間のマッピングテーブルを活用することで、多対多のアーキテクチャをクリーンに扱う方法を示しています。
@startuml
hide circle
skinparam LINETYPE ortho
entity "posts" as post {
* id : INT <<PK>>
--
* author_id : INT <<FK>>
* title : VARCHAR(255)
slug : VARCHAR(255)
body : TEXT
}
entity "categories" as category {
* id : INT <<PK>>
--
* name : VARCHAR(100)
description : VARCHAR(255)
}
entity "post_category_mappings" as mapping {
* post_id : INT <<PK>><<FK>>
* category_id : INT <<PK>><<FK>>
--
assigned_at : TIMESTAMP
}
entity "comments" as comment {
* id : INT <<PK>>
--
* post_id : INT <<FK>>
author_name : VARCHAR(100)
* content : TEXT
}
' 関係リンク構造
post ||--o{ mapping : "含む"
category ||--o{ mapping : "分類する"
post ||--o{ comment : "添付する"
@enduml
構文の分解： このテンプレートは、投稿とカテゴリの間の古典的な多対多関係をモデル化しています。直接接続するのではなく、中間テーブル（post_category_mappings）を導入し、両方のカラムが複合主キーとして機能します。クロウズフットのインジケータは、関係がコメント層まで段階的に伝わることを明確に示しています。