JP‐3. Manual
Note
本マニュアルは作成中のため、誤った記載が含まれている可能性があります。
ERD Designer では、プロジェクト単位で ER 図を管理します。効果的なプロジェクト管理により、複数のデータベース設計を並行して進めることができます。
新規プロジェクトの詳細作成手順
新しいプロジェクトを作成する際は、将来的な拡張性と保守性を考慮して設定を行うことが重要です。
-
プロジェクト作成の開始 : スタート画面の「CREATE NEW ER DIAGRAM」ボタンをクリックします
-
プロジェクト名の決定 : プロジェクト名は、チームメンバーが一目でプロジェクトの内容を理解できるような名前を付けましょう。(例：「ECサイト_会員管理システム_v1.0」「社内勤怠管理_DB設計」など)
-
データベースタイプの選択 : 対象となるデータベース管理システムを正確に選択することで、各 DBMS 固有のデータ型や制約が適切に反映されます
プロジェクトの保存と自動保存機能
ERD Designer には強力な自動保存機能が組み込まれており、作業中のデータ損失を防ぎます。
-
自動保存 : テーブルやリレーションシップの変更は、操作完了と同時にブラウザのローカルストレージ (Google Drive App の場合は Google Drive 上の該当ファイル) に自動保存されます
-
保存場所 : オンラインツールの場合は、データはブラウザの IndexedDB に保存され、オンラインには送信されません
プロジェクトの読み込みと履歴管理
- 最近のプロジェクト : スタート画面には、最近編集したプロジェクトが一覧表示されます。クリックすることで素早く再開できます
- ファイルからの読み込み : 「IMPORT FROM ERD FILE」を選択することで、以前にエクスポートした erd ファイルからプロジェクトを復元できます
キャンバスインターフェースは、エンティティ関係図を設計するメインワークスペースです。このセクションでは、インターフェースで利用可能な各メニューとコントロールの詳細な概要を説明します。
タイトルパネルはインターフェースの左上部に表示され、以下が含まれます。
- データベースのロゴ: 現在編集中のファイルで利用しているデータベースのアイコンが表示されます
- 図名フィールド: 現在の ER 図名を表示し、編集を可能にします
-
設定ボタン（⚙️）: アプリケーション設定へのアクセス
- Perspective: 視点管理画面を開きます。テーブルとメモを機能別・目的別にグループ化して表示を切り替えることができます
- Column Group: カラムグループ管理画面を開きます。複数のカラムをまとめて定義し、テーブルに一括で追加できます
- DB Schema: データベーススキーマ管理画面を開きます（PostgreSQL、MS SQL Server のみ）
- Import from DDL: DDL スクリプトから ER 図をインポートします（実験的機能）
編集モードパネルは左側に配置されており、5つの主要ツールが含まれています：
- 目的: 既存の要素を選択・操作するためのデフォルトモード
- 使用方法: キャンバス上のテーブル、リレーション、メモをクリックして選択
-
機能:
- 単一クリックで個別の要素を選択
- ドラッグして選択した要素を移動
- ダブルクリックで要素のプロパティを編集
- 目的: キャンバスをパンして移動
- 使用方法: ドラッグしてキャンバス全体の表示を移動
- 使用場面: 表示領域を超えて拡張された大きな図で作業する際に便利
- 目的: 新しいデータベーステーブルを作成
- 使用方法: キャンバスをクリックして新しいテーブルを配置
- プロセス: テーブルのプロパティを定義するためのテーブル作成ダイアログが開きます
- 目的: テーブル間の関係を作成
- 使用方法: 親テーブルをクリックし、次に別の子テーブルをクリックして関係を作成 (親テーブルから子テーブルへのドラッグ操作でも可能です)
- 機能: さまざまなリレーションタイプ（一対一、一対多、多対多）をサポート
- 目的: 図にテキストノートを追加したり、グルーピングの囲みとしても利用可能
- 使用方法: キャンバスをクリックして新しいメモを配置
- 機能: カスタマイズ可能なテキスト、フォント、色、サイズ、前後の位置
-
活用例:
- 設計時の注釈やコメントの追加
- 重要な設計上の制約事項や注意点の記録
-
前後関係の制御:
- Foreground（前景）: メモを最前面に配置し、テーブルやリレーション線の上に表示
- Background（背景）: メモを最背面に配置し、テーブルのグルーピングや領域の区分けに使用
編集モードパネルの下に配置され、追加機能を提供します：
- 機能: 新規作成するテーブルやメモの背景色を設定
- 用途: テーブルやメモ作成時のデフォルト色を事前に決めることで、作業効率を向上
- 機能: 作成した Perspective を選択して、表示するテーブルとメモを切り替え
- 用途: 大規模な ER 図で特定の機能やモジュールに焦点を当てて作業
- 詳細: 11. Perspective セクションを参照
- アンドゥ: 最後のアクションを元に戻す（Ctrl+Z, Cmd+Z）
- リドゥ: 以前に元に戻したアクションを再適用（Ctrl+Y, Cmd+Shift+Z）
- 視覚的インジケーター: 利用可能なアクションがない場合はボタンが無効化
エクスポートボタンは複数のエクスポートオプションへのアクセスを提供します：
-
Export DDL: SQL データ定義言語スクリプトを生成
- 対応データベース: PostgreSQL、MySQL、MS SQL Server
- オプション: Tables、Indexes、Foreign Keys、Comments、Schemas
-
Save as Image: 図を PNG 画像としてエクスポート
- ドキュメントやプレゼンテーション資料への活用
-
Export Specification: テーブル定義書を生成
- オンラインツール: Excel ファイル形式（
.xlsx） - Google Drive App: Google Spreadsheet 形式
- 内容: テーブル一覧、カラム定義、インデックス、外部キー制約など
- オンラインツール: Excel ファイル形式（
-
Save to ERD File: ERD Designer のネイティブ形式（
.erdファイル）を出力- バックアップや他の環境への移行に使用
ERD Designer では、作業効率と視認性を向上させるための豊富なカスタマイズオプションを提供しています。
表示設定の詳細カスタマイズ
-
Display Style 設定 : テーブル名とカラム名の表示スタイルを選択できます
- Physical: テーブル名およびカラム名の物理名を表示
- Logical: テーブル名およびカラム名の論理名を表示
-
Both: テーブル名およびカラム名の論理名と物理名を
/区切りで表示
-
カラム情報の表示 :
- キーアイコン : 主キーと外部キーの場合にアイコンを表示
- データ型表示 : INT, VARCHAR 等のデータ型情報を表示
- 制約表示 : NOT NULL, UNIQUEの制約条件を表示
-
複合一意キー制約表示 : 複合一意キー制約が指定されているカラムに
+を表示 -
インデクス設定表示 : インデクスが指定されているカラムに
*を表示 - 説明表示 : 説明が記載されているカラムにマウスカーソルをホバーさせるとツールチップで表示
-
リレーション線のスタイル設定 :
- 色設定: 異なる種類のリレーションを色分けして視認性を向上
- 太さ調整: 線の太さを3段階から設定
- 線種選択: 直線、水平/垂直線から選択
データベース固有設定
- データベースタイプ別設定 : 選択した DBMS に応じて、サポートされるデータ型や制約が自動調整されます
テーマとカラーリング
- テーブル色分け: 機能別、重要度別にテーブルの背景色を設定
効率的な設計作業のために、主要な操作をキーボードショートカットで実行できます。
編集操作系ショートカット
| 操作 | Windows/Linux | Mac | 説明 |
|---|---|---|---|
| 元に戻す | Ctrl+Z | Cmd+Z | 直前の操作を取り消します |
| やり直し | Ctrl+Y | Cmd+Y, Cmd+Shift+Z | 取り消した操作を再実行します |
| 削除 | Delete, Backspace | Delete, Backspace | 選択した要素を削除します |
データベース設計において、テーブルは情報を格納する基本的な単位です。ERD Designer では、直感的な操作でテーブルを作成し、論理的な配置を行うことができます。
テーブル作成の詳細手順
-
モード選択 : テーブルを新規作成する際は、左メニューの「TABLE」を押下し、Create Table モードにします。
-
作成位置の決定 : キャンバス上でテーブルを配置したい位置を決めます。関連するテーブル群は近くに配置することで、関係性を視覚的に表現できます。
-
テーブル作成の実行 : 配置したい位置にマウスカーソルを移動させ、クリックします。
-
テーブル名の入力 :
- 物理名 : データベース上で実際に使用されるテーブル名を入力します（例 : user_accounts、product_categories）
- 論理名 : 設計書やドキュメントで使用される名称等を入力します（例 : ユーザーアカウント、商品カテゴリ）
-
作成の確定 : 「OK」ボタンをクリックしてテーブル作成を完了します。テキストフィールドにフォーカスがある際にEnterキー押下でも構いません。
効果的なテーブル配置戦略
- 機能別グループ化 : 関連する機能のテーブルを近い位置に配置します（例 : ユーザー管理系、商品管理系、注文管理系）
- 階層構造の表現 : 親子関係にあるテーブルは、親を上位に、子を下位に配置して依存関係を明確にします
- 主要エンティティの中央配置 : 多くのテーブルから参照される中核的なテーブル（例 : usersテーブル）は、図の中央付近に配置します
- 十分な間隔の確保 : テーブル間には適切な間隔を設けることで、後からリレーション線を引く際の視認性を向上させます
配置調整の高度なテクニック
- 複数選択移動 : 短径選択、もしくは Ctrl（Cmd）キーを押しながら複数のテーブルを選択し、まとめて移動することで配置の調整効率を向上させます
テーブルのプロパティ設定は、データベースの品質と保守性に直接影響する重要な作業です。
基本プロパティの詳細設定
物理名（Physical Name）の設定方針
- 命名規則の統一 : プロジェクト全体で一貫した命名規則を採用します（例：snake_case、単数形の使用等）
- 予約語の回避 : 可能な限り、データベース固有の予約語を避けた名前を選択します
- 将来拡張性の考慮 : 後から機能追加される可能性を考慮した命名を行います
論理名（Logical Name）の活用
- 日本語名の設定 : 業務担当者や非技術者との コミュニケーションを円滑にするため、わかりやすい日本語名を設定します
- 略語の展開 : 物理名に略語を使用する場合は、その意味を明確にする論理名を併記します
説明（Description）の効果的な活用
- テーブルの役割説明: そのテーブルが何を管理するのか、どのような業務で使用されるのかを記述します
- 制約事項の明記: 特別な制約やビジネスルールがある場合は、コメントに記載します
- 変更履歴の記録: 重要な設計変更があった場合の経緯を残します
スキーマ（Schema）設定
ERD Designer では、PostgreSQL および MS SQL Server で使用されるスキーマ（名前空間）の管理に対応しています。
Important
スキーマを設定する場合、予めスキーマを作成する必要があります。スキーマが作成されていない場合、テーブル編集ダイアログでスキーマの編集項目が表示されません。 スキーマの作成方法は「Schema 管理」を参照してください。
- スキーマの役割: データベース内でテーブルやその他のオブジェクトを論理的にグループ化する名前空間
- 設定方法: テーブル編集ダイアログの「Schema」フィールドでスキーマ名を指定
-
スキーマの活用例:
-
機能別の分離:
user_management、product_catalog、order_processingなど -
環境別の分離:
development、staging、productionなど - 権限管理: スキーマ単位でアクセス権限を制御
-
機能別の分離:
-
DDL 出力時の動作: Schemas オプションを有効にすると、CREATE TABLE 文にスキーマ名が含まれます（例:
CREATE TABLE user_management.users (...)）
Note
MySQL はスキーマとデータベースを同義として扱うため、ERD Designer ではスキーマ設定は MySQL に対しては適用されません。
既存テーブルの編集と削除は、設計の進化に伴って頻繁に発生する操作です。安全かつ効率的に実行する方法を説明します。
テーブル編集の詳細プロセス
編集ダイアログの起動方法
- ダブルクリック : 対象テーブルをダブルクリックして編集ダイアログを開きます
- 操作アイコン: テーブルを選択後、右下の編集アイコンを押下します
編集可能な項目と注意点
- テーブル名変更 : 既存のリレーションシップに影響しないよう、関連テーブルとの整合性を確認します
- カラム構造変更 : 主キーの変更は外部キー関係に大きな影響を与えるため、慎重に実行します
- 制約条件変更 : インデックスや制約の変更は、パフォーマンスに影響する可能性があります
安全なテーブル削除の手順
削除前の確認事項
- 依存関係の確認 : 削除対象テーブルを参照している外部キーがないかを確認します
- データ影響範囲の把握 : 削除によって失われる情報の範囲を確認します
- バックアップの確認 : 重要なテーブルの場合は、設計データのバックアップを確認します
削除の実行方法
- テーブルの選択 : 削除対象のテーブルをクリックして選択状態にします
- 削除コマンドの実行: 右下の削除アイコンをクリックします
- 確認ダイアログ: 表示される確認ダイアログで削除の意思を再確認します
- 関連削除の確認: 関連するリレーションシップも同時に削除されることを確認します
テーブル選択後、Delete キー、もしくは Backspace キー押下で確認ダイアログが表示されることなく削除できます。
削除時の自動処理
- リレーションシップの自動削除 : 削除されるテーブルに関連するすべてのリレーションシップが自動的に削除されます
- カラム共有モデルの処理: 削除されるテーブル専用のカラム定義は、他で使用されていない場合自動削除されます
ERD Designer では、プロジェクトの規模や目的に応じてテーブルの表示方法を柔軟にカスタマイズできます。
色のカスタマイズ
テーブルヘッダー色の設定例
- 機能別色分け: ユーザー管理系は青、商品管理系は緑等、機能別に色を統一
- 重要度別色分け: 核となるテーブルは濃い色、補助的なテーブルは薄い色
データベーステーブルにおけるカラム設計は、アプリケーションの品質と性能に直接影響する重要な作業です。ERD Designer では、直感的なインターフェースを通じて、正確で効率的なカラム定義を支援します。
カラム追加の詳細プロセス
追加手順の詳細説明
-
テーブル編集モードの開始 : 対象となるテーブルをダブルクリックして、テーブル編集ダイアログを開きます
-
カラム追加コマンドの実行 : ダイアログ内の「Add Column」ボタンをクリックします
-
基本情報の入力:
- 物理名 : データベース上で使用される実際のカラム名（例 : user_id、created_at）
- 論理名 : 設計書や業務仕様書で使用される説明的な名前（例 : ユーザーID、作成日時）
- 説明 : カラムの業務的な意味や制約条件の説明
-
データ型と制約の設定 : 後述する詳細設定を行います
-
設定の確定 : 「OK」ボタンをクリックして新しいカラムをテーブルに追加します
既存カラムの編集方法
編集アクセス方法
- ダイレクト編集 : カラム一覧で対象カラム名をダブルクリック
編集時の注意事項
- 既存データへの影響 : 本番環境のテーブルでは、カラム変更がデータ損失を引き起こす可能性があります
- リレーションシップへの影響 : 主キーや外部キーの変更は、関連するテーブルにも影響を与えます
- パフォーマンスへの影響 : データ型やインデックスの変更は、クエリ性能に影響する場合があります
カラム順序の管理
- ドラッグ＆ドロップ : カラム一覧内でドラッグすることで、カラムの表示順序を変更できます
- 論理的順序 : 主キー → 外部キー → 業務カラム → システムカラム（作成日時等）の順序が推奨されます
- 頻度順序 : よく検索されるカラムを上位に配置することで、開発効率を向上させます
適切なデータ型の選択は、データベースの性能、ストレージ効率、およびデータ整合性に大きな影響を与えます。
主キーと外部キーは、データベースの整合性とリレーションシップの基盤となる重要な要素です。
主キーの設計原則と設定方法
主キー設計の基本方針
- 一意性の保証 : テーブル内の各行を一意に識別できる値
- 不変性の確保 : 一度設定された主キー値は、原則として変更しない
- 単純性の重視 : 可能な限りシンプルな構造を採用
- 効率性の考慮 : インデックス効率とストレージ効率を両立
単一カラム主キーの設定
- 対象カラムの選択 : 主キーに設定したいカラムを選択します
- Primary Keyチェックボックス : カラム編集ダイアログで「Primary Key」にチェックを入れます
- 自動増分の設定: 数値型を指定する場合は自動増分の設定が可能です (提供しているデータベースエンジンのみ)
複合主キーの設定方法
- 複数カラムの選択 : 主キーを構成する複数のカラムをそれぞれ編集します
- Primary Key設定 : 各カラムで「Primary Key」にチェックを入れます
- 順序の確認 : 主キーの構成順序が検索パフォーマンスに影響することを考慮します
外部キーの効果的な設定
外部キー制約の設計原則
- 参照整合性の確保 : 親テーブルに存在する値のみを参照
- 性能への配慮 : 外部キーカラムにはインデックスを設定
- カスケード動作の定義 : 親レコード削除時の子レコードの扱いを明確化
外部キー設定の詳細
外部キーの設定は、テーブル間のリレーションシップを作成することで行います。リレーションシップの作成方法などについては、8. リレーションシップの定義 セクションを参照してください。
データの品質と整合性を保つための制約条件と、効率的なデータ入力を支援する初期値の設定について説明します。
制約条件の詳細設定
NOT NULL制約の活用
- 設定目的 : 必須項目の定義、データの完全性確保
- 設定方法 : カラム編集で「NOT NULL」チェックボックスを有効化
- 適用例 : ユーザー名、メールアドレス、作成日時等
- 設計考慮点 : 将来的な要件変更の可能性を考慮して慎重に設定
UNIQUE制約による一意性確保
- 単一カラム UNIQUE : メールアドレス、ニックネーム等
- 設定方法 : 「UNIQUE」チェックボックスを有効化
- インデックス効果 : DBMS の機能により、UNIQUE 制約は自動的にインデックスを作成
DEFAULT値による初期値設定
静的デフォルト値の設定
- 固定値: 'Active'、0、false等の固定値
- 設定方法: 「Default Value」フィールドに値を入力
- データ型対応: 各データ型に適した形式で入力
複数のカラムの組み合わせに対して一意性を保証する複合一意制約（Composite Unique Constraint）の設定方法を説明します。
複合一意制約とは
複合一意制約は、複数のカラムの組み合わせが一意であることを保証する制約です。個別のカラムでは重複が許可されますが、指定したカラムの組み合わせは重複できません。
使用例
- ユーザーと商品の組み合わせ: 同じユーザーが同じ商品を複数回お気に入り登録できないようにする
- 期間の重複防止: 同じリソースの予約期間が重複しないようにする
- 複合キー: 複数のカラムで自然キーを構成する場合
複合一意制約の作成手順
-
テーブル編集ダイアログを開く: 対象テーブルをダブルクリックします
-
UNIQUE CONSTRAINT タブの選択: ダイアログ内の「UNIQUE CONSTRAINT」タブをクリックします
-
新規制約の追加: 「Add Unique Constraint」ボタンをクリックします
-
制約の設定:
- Constraint Name: 制約の名称を入力します（例: uq_user_product、uq_room_datetime）
-
カラムの選択: 制約に含めるカラムを選択します
- 左側のリストから対象カラムを選択
- 複数のカラムを選択することで複合一意制約を作成
- カラム順序: 選択したカラムの順序を調整します
-
制約の保存: 「OK」ボタンをクリックして制約を保存します
設計時の考慮事項
制約名の命名規則
-
プレフィックスの使用:
uq_で始める命名規則を推奨（例: uq_email、uq_username_email） - カラム名の含有: 制約に含まれるカラム名を反映した名前にする
- 一意性の確保: テーブル内で制約名が重複しないようにする
複合一意制約の設計原則
- 最小限のカラム: 一意性を保証するために必要最小限のカラムで構成
- NULL値の扱い: NULL値を含むカラムの場合、データベースによって動作が異なることに注意
- インデックスの自動作成: 多くのDBMSでは、一意制約に対して自動的にインデックスが作成されます
実践例
例1: お気に入り登録の重複防止
テーブル名: user_favorites
複合一意制約: uq_user_product
対象カラム: user_id + product_id
目的: 同じユーザーが同じ商品を複数回お気に入り登録できないようにする
例2: 期間の重複防止
テーブル名: room_reservations
複合一意制約: uq_room_datetime
対象カラム: room_id + start_datetime
目的: 同じ部屋の同じ時間帯に複数の予約が入らないようにする
例3: 複合自然キー
テーブル名: product_prices
複合一意制約: uq_product_date
対象カラム: product_id + effective_date
目的: 同じ商品の同じ有効日に複数の価格レコードが存在しないようにする
複合一意制約の編集と削除
編集方法
- UNIQUE CONSTRAINT タブを開く
- 対象の制約を選択してダブルクリック、または編集ボタンをクリック
- カラムの追加・削除や順序を変更
- 「OK」で保存
削除方法
- UNIQUE CONSTRAINT タブを開く
- 対象の制約を選択
- 削除ボタンをクリック、または Delete キーを押す
Warning
複合一意制約を削除すると、その制約によって保証されていたデータの一意性が失われます。削除前に影響範囲を十分に確認してください。
データベースのパフォーマンス最適化において、インデックスは極めて重要な要素です。適切なインデックス設計により、検索性能を大幅に向上させることができます。
インデックス作成の詳細プロセス
基本的なインデックス作成手順
- テーブル編集ダイアログの表示 : 対象カラムのテーブル編集画面を開きます
- インデックスタブの選択 : ダイアログ内の「INDEX」タブをクリックします
- 新規インデックスの追加 : 「Add Index」ボタンで新しいインデックスを作成します
-
インデックス設定の詳細化 :
- インデックス名 : 識別しやすい名前を設定（例：idx_user_email、idx_order_date）
- インデックスタイプ : 用途に応じたタイプを選択
- カラム順序 : 複合インデックスの場合はカラムの順序を設定
複合インデックスの設計原則
カラム順序の重要性
- 選択性の高いカラムを先頭に : より多くの行を絞り込めるカラムを最初に配置
- 検索頻度の考慮 : よく検索されるカラムを前方に配置
- 最左前置マッチの活用 : 先頭から連続するカラムでのインデックス利用
インデックス性能の最適化
カバリングインデックスの活用
- 概念 : 検索に必要なすべてのカラムをインデックスに含める
- 利点 : テーブルアクセスを完全に回避し、大幅な性能向上
- 設計例 : SELECT文で頻繁に使用されるカラム群をまとめてインデックス化
インデックス保守の考慮事項
更新性能への影響
- トレードオフ : 検索性能向上と引き換えに、INSERT/UPDATE/DELETE性能が低下
- 適切なバランス : アプリケーションの読み書き比率を考慮したインデックス設計
- 定期的な見直し : アプリケーションの使用パターン変化に応じたインデックス調整
ストレージ容量への影響
- 容量計算 : インデックスサイズの見積もりと容量計画
- 重複インデックスの排除 : 類似するインデックスの統廃合
- 定期的なメンテナンス : インデックスの断片化解消と最適化
カラムモデルは、カラムの定義情報（物理名、論理名、データ型、精度、説明など）を一元管理する機能です。ERD Designer では、カラムを作成すると自動的にカラムモデルとして登録され、複数のテーブル間で同じカラム定義を再利用できます。
カラムモデルの利点
- 設計の一貫性: 同じ意味を持つカラム（例: user_id）を複数のテーブルで統一的に定義
- 作業効率の向上: 一度定義したカラムを再利用することで、入力作業を削減
- 一括変更: カラムモデルを更新すると、それを使用するすべてのテーブルに変更が反映
- メンテナンス性: データ型の変更が必要な場合、一箇所の修正で全体に適用
新しいカラムを作成すると、その定義は自動的にカラムモデルとして登録されます。
自動登録される情報
- 物理名（Physical Name）
- 論理名（Logical Name）
- データ型（Column Type）とその属性（精度、スケール、unsignedなど）
- 説明（Description）
登録タイミング
- カラム編集ダイアログで「OK」をクリックした時点
- カラムの定義を変更した時点（既存のカラムモデルが更新される）
Note
Primary Key、NOT NULL、UNIQUE、Auto Increment、Default Value などの制約条件は、カラムモデルには含まれません。これらはテーブルごとに個別に管理されます。
既に定義されているカラムモデルを検索して、新しいカラムに適用できます。
基本的な再利用手順
- カラム追加の開始: テーブル編集ダイアログで「Add Column」をクリック
- 検索ダイアログの表示: 「Create new column model.」の右側にある検索アイコン（🔍）をクリック
-
カラムモデルの検索: Search column model ダイアログが表示されます
- Physical Name: 物理名で絞り込み
- Logical Name: 論理名で絞り込み
- Type: データ型で絞り込み
- Description: 説明文で絞り込み
- モデルの選択: 再利用したいカラムモデルをクリックして選択
- 適用: 「OK」ボタンをクリック、またはカラムモデルをダブルクリック
フィルタリング機能
検索ダイアログでは、各フィールドに文字を入力することで、リアルタイムに結果を絞り込むことができます。複数の条件を組み合わせることも可能です。
カラムモデルの関連付け状態の確認
カラム編集ダイアログを開くと、現在のカラムモデルの関連付け状態が表示されます：
- 新規カラムモデル: 「Create new column model.」と表示
- 既存モデルと関連付け済み: 「Associated with column model '〈論理名〉'」と表示
別のカラムモデルへの切り替え
- カラム編集ダイアログの検索アイコンをクリック
- 新しく関連付けたいカラムモデルを選択
- 既存の関連付けが新しいモデルに置き換わります
カラムモデルの関連付け解除
関連付けを解除すると、そのカラムは独立したカラムモデルとして新規作成されます。
- カラム編集ダイアログで、カラムモデル名の右側にある「×」アイコンをクリック
- 確認ダイアログが表示されるので、「UNLINK」をクリック
- 関連付けが解除され、「Create new column model.」の状態に戻ります
Important
カラムモデルの関連付けを解除しても、カラムのデータ型や名前などの情報は保持されます。新しい独立したカラムモデルとして扱われるだけです。
カラムモデルを更新すると、そのモデルを参照しているすべてのカラムに変更が自動的に反映されます。
一括更新の手順
- 対象カラムの編集: いずれかのテーブルで、更新したいカラムを編集
- カラム定義の変更: データ型、精度、論理名、説明などを変更
- 保存: 「OK」ボタンをクリック
- 自動反映: 同じカラムモデルを使用している他のすべてのカラムに変更が反映されます
一括更新の対象となる項目
- 物理名（Physical Name）
- 論理名（Logical Name）
- データ型（Column Type）
- 精度（Precision）とスケール（Scale）
- Unsigned 属性
- 配列（Array）属性
- 説明（Description）
一括更新の対象外となる項目
- Primary Key
- NOT NULL
- UNIQUE
- Auto Increment
- Default Value
Warning
データ型の変更は、既存のリレーションシップに影響を与える可能性があります。外部キーで参照されているカラムのデータ型を変更する場合は、参照整合性が保たれるよう注意してください。
カラムモデルを再利用する際、物理名や論理名を個別のテーブルで上書きすることができます。
オーバーライドの方法
-
カラムモデルを関連付けた状態で、カラム編集ダイアログを開く
-
Physical Name または Logical Name フィールドに新しい名前を入力
-
「OK」をクリックして保存
オーバーライドの動作
- 入力した名前がそのテーブルのカラム名として使用されます
- カラムモデル自体は変更されません
- 他のテーブルで同じカラムモデルを使用している場合、影響はありません
- フィールドを空にすると、カラムモデルの名前が使用されます
使用例
あるテーブルで user_id というカラムモデルを使用しているが、特定のテーブルでは author_id という名前で使いたい場合に便利です。
外部キー制約が設定されているカラムは、参照先カラムと同じデータ型である必要があります。
外部キー設定時の制約
- データ型の固定: リレーションシップで使用されているカラムは、データ型を変更できません
- カラムモデルの変更制限: 外部キーカラムの関連付けを変更する場合、参照先カラムと互換性のあるデータ型を持つカラムモデルのみ選択可能
- 型の一致: 精度、スケール、unsigned 属性なども一致している必要があります
リレーション作成時の自動処理
リレーションシップを作成する際、子テーブルに新しいカラムを追加する場合：
- 親テーブルのカラムモデルが自動的に参照されます
- データ型、精度などが親カラムと同じになります
- Primary Key、NOT NULL、UNIQUE は引き継がれません（個別設定が必要）
カラムモデルは、以下の条件を満たすと自動的に削除されます：
自動削除の条件
- どのテーブルのカラムからも参照されていない
- ユーザーが意図的にすべての参照を解除した
削除されるタイミング
- テーブルを削除したとき
- カラムを削除したとき
- カラムモデルの関連付けを解除して別のモデルに切り替えたとき
Note
カラムモデルの削除は自動的に行われるため、手動での削除操作は不要です。使用されていないカラムモデルが蓄積されることはありません。
例1: 共通のIDカラムの統一
複数のテーブルで使用される user_id を統一的に管理：
-
userテーブルでuser_idをINTEGER型で作成 -
postテーブルで外部キーとして同じuser_idを再利用 -
commentテーブルでも同じuser_idを再利用 - 後で
user_idをBIGINTに変更すると、すべてのテーブルに反映
例2: タイムスタンプカラムの再利用
created_at や updated_at などの共通カラムを統一：
-
TIMESTAMP型でcreated_atカラムを作成 - すべてのテーブルで同じカラムモデルを再利用
- 日時形式を変更する必要が生じた場合、一箇所の修正で全体に適用
例3: 金額カラムの統一
金額を表すカラムを DECIMAL(10, 2) で統一：
-
priceカラムをDECIMAL(10, 2)で作成 - 商品価格、注文金額、支払金額など、すべての金額カラムで再利用
- 精度の変更が必要になった場合、一括で変更可能
Column Group（カラムグループ）は、複数のカラムをひとつのグループとしてまとめて定義し、テーブルに一括で追加できる機能です。繰り返し使用される定型的なカラムセットを効率的に管理できます。
Column Group の利点
- 作業効率の向上: よく使うカラムセットを一度に追加でき、入力作業を大幅に削減
- 一貫性の確保: 同じカラムセットを複数のテーブルで統一的に使用できる
- メンテナンス性: グループ定義を更新すると、それを使用するすべてのテーブルに反映される
- 設計の標準化: チーム内で共通のカラムセット（監査カラム、住所情報など）を標準化できる
カラムモデルとの違い
-
カラムモデル: 個別のカラム定義を管理（例:
user_id、created_at） -
Column Group: 複数のカラムをセットで管理（例: 住所情報グループ =
postal_code+prefecture+city+address）
Note
Column Group に含まれるカラムは、それぞれが独立したカラムモデルとして管理されます。グループはあくまでカラムの「まとまり」を表現する機能です。
Column Group を新規作成する手順を説明します。
作成手順
-
Column Group 管理画面を開く: タイトルパネルの設定ボタン（⚙️）をクリックし、「Column Group」を選択します
-
新規グループの追加: 表示されたダイアログで「Add」ボタンをクリックします
-
グループ名の入力:
- GroupName: グループの名称を入力します（例: 住所情報、監査カラム、価格情報）
- Description: グループの説明や用途を記載します（オプション）
-
カラムの追加: 「Add column」ボタンをクリックして、グループに含めるカラムを追加します
- 新規カラムを作成する場合: カラム編集ダイアログで詳細を定義
- 既存カラムモデルを再利用する場合: 検索アイコンからカラムモデルを選択
-
カラム順序の調整: ドラッグ＆ドロップまたは矢印ボタンでカラムの表示順を調整します
-
グループの保存: 「OK」ボタンをクリックして Column Group を保存します
作成例: 監査カラムグループ
GroupName: 監査カラム
Description: レコードの作成・更新情報を管理するカラムセット
カラム構成:
- created_at (TIMESTAMP): レコード作成日時
- created_by (INTEGER): 作成者ID
- updated_at (TIMESTAMP): 最終更新日時
- updated_by (INTEGER): 更新者ID
既存の Column Group を編集または削除する方法を説明します。
Column Group の編集
-
Column Group 管理画面を開く: 設定ボタン（⚙️）から「Column Group」を選択
-
グループの選択: 左側のリストから編集したいグループをクリック
-
編集の開始:
- グループをダブルクリック、または
- グループを選択して「Edit」ボタンをクリック
-
内容の編集:
- グループ名や説明の変更
- カラムの追加・削除・並び替え
- 個別カラムの定義変更
-
変更の保存: 「OK」ボタンをクリック
編集時の注意点
- グループに含まれるカラムモデルを変更すると、そのカラムモデルを使用するすべてのテーブルに影響します
Column Group の削除
-
Column Group 管理画面を開く: 設定ボタン（⚙️）→「Column Group」を選択
-
グループの選択: 削除したいグループをクリック
-
削除の実行: 「Delete」ボタンをクリック
-
確認: 確認ダイアログで削除を確定
Important
Column Group を削除すると、それを利用したテーブルから該当定義が削除されます。
作成した Column Group をテーブルに追加する方法を説明します。
追加手順
-
テーブル編集ダイアログを開く: 対象テーブルをダブルクリック
-
Column Group 追加ボタンをクリック: カラム一覧の下部にある「Add group column」ボタン（アイコン: ≡+）をクリック
-
Column Group の選択:
- Column Group 管理ダイアログが表示されます
- 左側のリストから追加したいグループを選択
- 右側にグループ内のカラム一覧が表示されます
-
グループの確定: 「OK」ボタンをクリック
-
テーブルへの反映: 選択した Column Group 内のすべてのカラムがテーブルに一括で追加されます
追加後の操作
- カラム順序の調整: 追加されたカラムグループは他のカラムと同様にドラッグ＆ドロップで並び替え可能
- 制約の設定: Primary Key、NOT NULL、UNIQUE などはカラムグループ定義のものが反映されます
例1: 住所情報グループ
顧客テーブル、配送先テーブル、店舗テーブルなど、複数のテーブルで住所情報を統一的に管理：
GroupName: 住所情報
カラム構成:
- postal_code (VARCHAR(7)): 郵便番号
- prefecture (VARCHAR(50)): 都道府県
- city (VARCHAR(100)): 市区町村
- address (VARCHAR(200)): 番地・建物名
例2: 監査カラムグループ
すべてのテーブルに作成・更新情報を記録：
GroupName: 監査カラム
カラム構成:
- created_at (TIMESTAMP, NOT NULL, DEFAULT CURRENT_TIMESTAMP): 作成日時
- created_by (INTEGER): 作成者ID
- updated_at (TIMESTAMP): 更新日時
- updated_by (INTEGER): 更新者ID
例3: 価格情報グループ
商品、サービス、料金プランなどで価格関連情報を統一：
GroupName: 価格情報
カラム構成:
- price (DECIMAL(10, 2), NOT NULL): 価格
- tax_rate (DECIMAL(5, 2), DEFAULT 0.10): 税率
- currency_code (VARCHAR(3), DEFAULT 'JPY'): 通貨コード
例4: 期間管理グループ
キャンペーン、契約、予約などで有効期間を管理：
GroupName: 期間管理
カラム構成:
- start_date (DATE, NOT NULL): 開始日
- end_date (DATE): 終了日
- is_active (BOOLEAN, DEFAULT true): 有効フラグ
活用のメリット
- 新規テーブル作成時: グループを選択するだけで必要なカラムセットを一括追加
- 設計標準化: チーム全体で共通のカラムセット定義を共有
- 入力ミスの防止: 繰り返し入力によるタイポや定義ミスを削減
- 将来の拡張: 標準カラムセットに項目を追加する際、グループ定義を更新するだけで済む
データベース設計において、テーブル間のリレーションシップは情報の整合性と効率的なデータ管理の基盤となります。ERD Designer では、様々な種類のリレーションシップを正確に表現し、管理することができます。
基本的なリレーションシップパターンの詳細
1:1（一対一）リレーションシップ
-
特徴 : 親テーブルの1つのレコードが、子テーブルの最大1つのレコードと関連
-
実装方法 : 子テーブルの外部キーにUNIQUE制約を追加
-
使用例:
- ユーザーテーブル ↔ ユーザープロファイルテーブル
- 商品テーブル ↔ 商品詳細テーブル
- 従業員テーブル ↔ 従業員個人情報テーブル
-
設計考慮点 :
- 本当に分割が必要かを検討（正規化の妥当性）
- アクセス頻度の違いによる分割（頻繁にアクセスされる基本情報と、稀にアクセスされる詳細情報）
- セキュリティ要件による分割（一般情報と機密情報）
1:N（一対多）リレーションシップ
- 特徴 : 親テーブルの1つのレコードが、子テーブルの複数のレコードと関連
- 実装方法 : 子テーブルに親テーブルの主キーを外部キーとして追加
- 最も一般的なパターン : データベース設計の大部分を占める
-
使用例 :
- 顧客テーブル ← 注文テーブル（1人の顧客が複数の注文）
- カテゴリテーブル ← 商品テーブル（1つのカテゴリに複数の商品）
- 部署テーブル ← 従業員テーブル（1つの部署に複数の従業員）
N:M（多対多）リレーションシップ
- 特徴 : 両方のテーブルのレコードが、相互に複数のレコードと関連
- 実装方法 : 中間テーブル（結合テーブル）を使用して2つの1:Nリレーションシップに分解
-
使用例:
- 学生テーブル ↔ 授業テーブル（学生は複数の授業を履修、授業には複数の学生が参加）
- 商品テーブル ↔ タグテーブル（商品は複数のタグを持ち、タグは複数の商品に適用）
- ユーザーテーブル ↔ ロールテーブル（ユーザーは複数の役割を持ち、役割は複数のユーザーに割り当て）
中間テーブルの設計原則
- 命名規則: 関連する2つのテーブル名を組み合わせ（例：student_courses、product_tags）
- 主キー設計: 関連する2つの外部キーの複合主キー、または独立したサロゲートキー
- 追加属性: リレーションシップ自体の属性（例：登録日時、有効期限など）
Memo 機能を使用すると、ER 図上に自由なテキストノートを配置できます。設計時の注釈、将来の拡張計画、重要な制約事項などを記録するのに便利です。
Memo 作成の基本手順
- MEMO モードの選択: 画面左側の編集モードパネルから「MEMO」を選択します
- 配置位置の決定: キャンバス上で Memo を配置したい位置をクリックします
- テキストの入力: 表示されるダイアログでメモの内容を入力します
- 作成の確定: 「OK」ボタンをクリックして Memo を作成します
Memo の編集と削除
- 編集: Memo をダブルクリックすることで直接編集できます。編集後は Memo 以外の箇所をクリックすれば保存されます
- 移動: SELECT モードで Memo をドラッグして移動できます
- 削除: Memo を選択して削除アイコンをクリックします。もしくは Delete キーまたは Backspace キーを押します
Memo の外観をカスタマイズすることで、目的に応じた視覚的な整理が可能です。
設定可能な項目
- テキスト内容: Memo に表示するテキスト（複数行対応）
- フォントサイズ: テキストの大きさを調整
- 色: Memo の背景色を変更
- サイズ: Memo ボックスの幅と高さを調整
Memo の前後関係（Z-order）を制御することで、異なる用途に活用できます。
Foreground（前景）モード
- 配置: Memo が最前面に表示され、テーブルやリレーション線の上に重なります
-
用途:
- 重要な注意事項やアラートの表示
- 特定のテーブルやリレーションに対するコメント
- TODO や課題の明示
Background（背景）モード
- 配置: Memo が最背面に表示され、テーブルやリレーション線の下に配置されます
-
用途:
- 関連するテーブル群のグルーピング（領域の区分け）
- セクションの見出しや分類
- 機能モジュール単位での視覚的な整理
Schema（スキーマ）は、データベース内でテーブルやその他のオブジェクト（ビュー、関数など）を論理的にグループ化するための名前空間です。
Schema の主な用途
- 機能別の分離: ユーザー管理、商品管理、注文管理など、機能ごとにスキーマを分ける
- 環境別の管理: 開発、テスト、本番環境を同一データベース内で分離
- 権限管理: スキーマ単位でアクセス権限を制御
- 名前の衝突回避: 異なるスキーマ内であれば同じテーブル名を使用可能
対応データベース
-
PostgreSQL: スキーマを完全サポート（デフォルトは
publicスキーマ） -
MS SQL Server: スキーマを完全サポート（デフォルトは
dboスキーマ） - MySQL: スキーマとデータベースを同義として扱うため、ERD Designer では未対応
ERD Designer では、Schema の管理を簡単に行うことができます。
Schema の作成方法
- 設定画面へのアクセス: 設定ボタン（⚙️）をクリックして表示されるメニューから「DB Schema」をクリックします。
- 新規 Schema の追加: 「Add Schema」ボタンをクリックし、スキーマ名を入力します
- 保存: 「OK」ボタンをクリックして Schema を作成します
Schema の編集
作成した Schema の名前を変更する場合は、Schema 一覧から対象の Schema を選択し、編集アイコンをクリックします。
Schema の削除
使用していない Schema を削除する場合は、Schema 一覧から対象の Schema を選択し、削除アイコンをクリックします。
Important
Schema を削除しても、その Schema に割り当てられていたテーブルは削除されません。テーブルの Schema 設定が空になるだけです。
デフォルト Schema の設定
Schema 一覧にてデフォルト Schema を設定すると、DDL 出力時にスキーマ未設定のテーブルのスキーマ定義がデフォルト Schema として出力されます。
作成した Schema をテーブルに割り当てることで、論理的なグループ化が可能になります。
割り当て手順
- テーブル編集ダイアログを開く: 対象テーブルをダブルクリックします
- Schema フィールドを設定: テーブルプロパティの「Schema」フィールドで、割り当てたいスキーマを選択します
- 保存: 「OK」ボタンをクリックして変更を保存します
Schema 割り当ての確認
- テーブル名の表示時に、スキーマ名が含まれる場合があります（例:
user_management.users） - DDL エクスポート時に Schemas オプションを有効にすると、スキーマ名が DDL に含まれます
Schema を設定したテーブルから DDL をエクスポートする際、Schemas オプションを有効にすることで、スキーマ名を含む DDL が生成されます。
PostgreSQL の場合
CREATE SCHEMA IF NOT EXISTS user_management;
CREATE TABLE user_management.users (
user_id INT PRIMARY KEY,
username VARCHAR(50) NOT NULL,
...
);MS SQL Server の場合
CREATE SCHEMA user_management;
CREATE TABLE user_management.users (
user_id INT PRIMARY KEY,
username VARCHAR(50) NOT NULL,
...
);Tip
スキーマを使用することで、大規模なデータベースでも整理された状態を保ち、管理性を大幅に向上させることができます。
Perspective は、ER 図内のテーブルとメモを機能別・目的別など応じて論理的にグループ化し、表示を切り替えることができる機能です。大規模な ER 図において、必要な情報だけを表示して作業効率を向上させることができます。
Perspective の利点
- 情報の整理: 大規模な ER 図を機能別・モジュール別に分類して表示
- 作業効率の向上: 現在作業中の部分だけを表示して、画面の見通しを改善
- フェーズ管理: 開発フェーズごとに必要なテーブルセットを切り替え
- プレゼンテーション: 説明したい部分だけを表示して、わかりやすく提示
- 複数ビューの管理: 同じ ER 図から複数の視点を作成し、柔軟に切り替え
使用シーン
- 機能別ビュー: ユーザー管理、商品管理、注文管理など、機能ごとの表示
- フェーズ別ビュー: Phase 1、Phase 2 など、開発段階ごとの表示
- 担当者別ビュー: チームメンバーごとの担当範囲を表示
- レイヤー別ビュー: マスターデータ、トランザクションデータなど、データ特性ごとの表示
Note
Perspective は ERD Designer が扱う表示の切り替え機能であり、テーブルやリレーションシップの定義そのものには影響しません。
新しい Perspective を作成する手順を説明します。
作成手順
-
Perspective 管理画面を開く: タイトルパネルの設定ボタン（⚙️）をクリックし、「Perspective」を選択します
-
新規 Perspective の追加: 「Add perspective」ボタン（＋アイコン）をクリックします
-
Perspective 情報の入力:
- Name: Perspective の名称を入力します（例: ユーザー管理、商品管理、Phase 1）
- Description: Perspective の説明や用途を記載します（オプション）
-
テーブルとメモの選択:
- 左側の列に、ER 図内のすべてのテーブルとメモがリスト表示されます
- 各 Perspective 列のチェックボックスをクリックして、含めたい要素を選択します
- ひとつのテーブルを複数の Perspective に含めることも可能です
-
Perspective の保存: 「OK」ボタンをクリックして保存します
作成例
Name: ユーザー管理
Description: ユーザー認証と権限管理に関連するテーブル
含まれるテーブル:
- users（ユーザー）
- roles（ロール）
- permissions（権限）
- user_roles（ユーザーロール関連）
既存の Perspective を編集または削除する方法を説明します。
Perspective の編集
-
Perspective 管理画面を開く: 設定ボタン（⚙️）→「Perspective」を選択
-
Perspective の選択: 編集したい Perspective の列をクリックして選択状態にします
-
編集の開始: 「Edit perspective」ボタン（鉛筆アイコン）をクリック
-
内容の編集:
- Perspective の名前や説明を変更
- 含まれるテーブルやメモのチェックを変更
-
変更の保存: 「OK」ボタンをクリック
Perspective の並び替え
- Perspective の列をドラッグ＆ドロップして表示順序を変更できます
- または、矢印ボタン（← →）で順序を調整できます
Perspective の削除
-
Perspective 管理画面を開く: 設定ボタン（⚙️）→「Perspective」を選択
-
Perspective の選択: 削除したい Perspective をクリック
-
削除の実行: 「Remove」ボタン（ゴミ箱アイコン）をクリック
Important
Perspective を削除しても、ER 図内のテーブルやメモは削除されません。表示設定が削除されるだけです。
作成した Perspective を使って、ER 図の表示を切り替える方法を説明します。
表示切り替えの方法
画面左側のパネルに Perspective のリストが表示されます。
-
Perspective の選択: 左パネルのリストから表示したい Perspective の名前を選択
-
画面への反映: キャンバス上で、選択した Perspective に含まれるテーブルとメモのみが表示されます
すべて表示に戻す
- リスト内の「(Default)」を選択すると、すべてのテーブルとメモが表示されます
Show half-bounded line オプション
Perspective の表示切り替えパネルには「Show half-bounded line」チェックボックスがあります。
- 有効時: Perspective に含まれるテーブルと、含まれないテーブルの間のリレーション線（半分だけ含まれる線）も表示されます
- 無効時: Perspective に含まれるテーブル間のリレーション線のみが表示されます
- 用途: 他の機能との関連性を確認したい場合に有効にすると便利です
Perspective 管理画面での確認
設定ボタン（⚙️）→「Perspective」を選択すると、Perspective 管理画面が開きます。ここでは複数の Perspective を並べて比較できます：
テーブル/メモ | ユーザー管理 | 商品管理 | 注文管理
----------------|------------|---------|--------
users | ✓ | | ✓
products | | ✓ | ✓
orders | | | ✓
...
例1: 機能別 Perspective
大規模なシステムを機能モジュールごとに分割：
Perspective 1: ユーザー管理
- users, roles, permissions, user_roles
Perspective 2: 商品管理
- products, categories, product_images, inventory
Perspective 3: 注文管理
- orders, order_items, payments, shipments
例2: 開発フェーズ別 Perspective
段階的な開発計画に応じて表示を切り替え：
Perspective 1: Phase 1（MVP）
- 最小限の機能に必要なテーブルのみ
- users, products, orders
Perspective 2: Phase 2（拡張機能）
- Phase 1 + 追加機能のテーブル
- users, products, orders, reviews, wishlists
Perspective 3: Phase 3（完全版）
- すべてのテーブルを含む
例3: データ種別 Perspective
データの性質ごとに分類：
Perspective 1: マスターデータ
- categories, brands, users, stores
Perspective 2: トランザクションデータ
- orders, order_items, payments, shipments
Perspective 3: 分析用データ
- sales_summary, user_analytics, product_metrics
例4: チーム担当別 Perspective
開発チームの担当範囲ごとに表示：
Perspective 1: フロントエンドチーム
- UI に直接関連するテーブルのみ
Perspective 2: バックエンドチーム
- API で使用するすべてのテーブル
Perspective 3: データチーム
- 分析・レポート関連のテーブル
例5: レビュー・プレゼンテーション用
特定の説明やレビューのために焦点を絞った表示：
Perspective: ユーザーフロー説明用
- ユーザー登録から購入までの流れに関連するテーブルのみ表示
- users, authentication, cart, orders, payments
活用のメリット
- 視認性向上: 必要な情報だけを表示して、画面の見通しを改善
- 作業効率: 現在の作業に関係ない要素を非表示にして集中力を維持
- コミュニケーション: チームメンバーや関係者に説明する際、わかりやすく提示
- 段階的開発: フェーズごとの実装範囲を明確に可視化
- ドキュメント化: 機能別の ER 図を画像エクスポートして、設計書に含める
Export 機能により、DDL や ER 図の画像、テーブル定義書を出力できます。
オプションの詳細説明
- Tables: CREATE TABLE 文を生成します。通常は必ず有効にします
- Indexes: CREATE INDEX 文を生成します。パフォーマンス最適化のために推奨
- Foreign Keys: ALTER TABLE 文による外部キー制約を生成します。参照整合性の確保のために推奨
- Comments: COMMENT 文を生成します。データベースレベルでのドキュメント化に有用
- Schemas: スキーマ名を含む DDL を生成します（PostgreSQL、MS SQL Server のみ）
ER 図を PNG 形式の画像ファイルとして保存できます。
用途
- ドキュメント（Word、Markdown など）への埋め込み
- デザインレビューでの共有
- プロジェクト管理ツールへのアップロード
テーブル定義書は、設計内容を表形式でまとめたドキュメントです。
出力形式
-
オンラインツールの場合: Excel ファイル（
.xlsx） - Google Drive App の場合: Google Spreadsheet
内容
- テーブル一覧（テーブル名、論理名、説明）
- カラム定義（カラム名、論理名、データ型、制約、説明）
- インデックス一覧
- 外部キー制約一覧
ERD Designer のネイティブ形式（.erd）でファイルを保存します。
Important
ERD ファイルのエクスポートはオンラインツールのみサポートしています。
Google Drive App を利用している場合は、Google Drive に保存されている .erd ファイルを利用してください。
用途
- 定期的なバックアップ
- 別の環境（別のブラウザ、別のマシン）への移行
- バージョン管理システム（Git など）での管理
- チームメンバーとのファイル共有
以前にエクスポートした .erd ファイルを読み込んで、ER 図を復元できます。
Important
ERD ファイルのインポートはオンラインツールのみサポートしています。
手順
- オンラインツール Top 画面にて「IMPORT FROM ERD FILE」を選択します。
- 保存した
.erdファイルを選択します。 - ER 図が復元され、編集を続行できます。
用途
- バックアップからの復元
- 別の環境からのプロジェクト移行
- チームメンバーから受け取ったファイルの読み込み
既存のデータベースから生成された DDL を読み込んで、自動的に ER 図を作成する機能です。
機能概要
この機能を使用すると、以下のような場面で役立ちます：
- 既存データベースの可視化とドキュメント化
- レガシーシステムのリバースエンジニアリング
- 他のツールで作成した DDL からの移行
- データベースの構造分析
基本的な使い方
- 設定ボタン（⚙️）をクリックして表示されるメニューから「Import from DDL」を選択
- DDL テキストを入力します
- 必要に応じて「Comment Separator」を設定します
- 「CHECK DDL」ボタンをクリックして DDL を解析します
- 解析の結果、問題なければ「IMPORT」ボタンをクリックします
Comment Separator 機能
カラムのコメントに論理名と説明を含めている場合、セパレータを指定することで自動的に分離できます。
例:
COMMENT ON COLUMN users.username IS 'ユーザー名 | ログイン時に使用する一意の識別子';この場合、Comment Separator に | を指定すると：
- 論理名:
ユーザー名 - 説明:
ログイン時に使用する一意の識別子
として自動的に分割されます。
制限事項
Warning
DDL インポート機能は実験的機能（Experimental）であり、以下の制限があります：
- 複雑な DDL 構文（ビュー、トリガー、ストアドプロシージャなど）には対応していません
- 一部の高度なデータ型や制約は正しく解析されない場合があります
- パーティション定義、継承などの特殊な機能には対応していません
- DDL の方言や独自拡張には対応していない場合があります
トラブルシューティング
インポートが失敗する場合
- DDL が対応データベースの標準的な構文に準拠しているか確認してください
- 不要な文（USE、SET など）を削除してから再試行してください
- エラーメッセージを確認し、問題のある箇所を特定してください
一部のテーブルが生成されない場合
- CREATE TABLE 文が正しい構文であるか確認してください
- カラムが定義されていないテーブルは生成されません
外部キーが正しく設定されない場合
- ALTER TABLE 文で外部キーを追加している場合、参照先テーブルが先に定義されているか確認してください
- 外部キー制約の構文が正しいか確認してください