SQL DDL エクスポートガイド | Dr.ERD で PostgreSQL 18 のスキーマを作る

このガイドでは、無料 ERD 作成ガイドと Mermaid 読み込みガイドで作った会員・注文・注文明細の 3 テーブルモデルを SQL DDL ファイルとして書き出す手順を説明します。Dr.ERD は SQL を実行せずファイルを作るだけなので、実行は自分で用意した信頼できるデータベースで行います。

現在の記事: SQL DDL の書き出し

1. 3 テーブルのモデルと PostgreSQL 18 の対象を準備

この実習は、前の 2 つのガイドで作成したモデルをそのまま使います。まず対象データベースが PostgreSQL 18 になっているか確認してください。Dr.ERD はモデルで選択した対象に合わせて DDL を生成するため、対象が違うと型と制約も変わります。

ファイル一覧から first-erd を開くか、新しいモデルを作成して対象データベースで PostgreSQL 18 を選びます。
Chrome または Edge で作業フォルダーを選択し、.drerd ファイルと書き出したファイルの保存先を用意します。アカウントは不要です。
キャンバスにテーブル 3 つとリレーション 2 つがあるか確認します。まだない場合は無料 ERD 作成ガイドを先に進めてください。

書き出すモデル: members、orders、order_items。
AI チャットは任意機能で、SQL DDL の書き出しには必要ありません。送信したメッセージにだけ現在の ERD の文脈が渡されます。

2. エクスポートメニューで SQL を選ぶ

ツールバーのエクスポートメニューで SQL を選ぶとエクスポート画面が開き、SQL プレビューに生成された DDL が表示されます。ファイル名と保存先は、エクスポートを押したあとに開くブラウザーの保存画面で自分で選びます。

エクスポートメニューで SQL を選びます。項目名は SQL、拡張子は .sql です。
エクスポート画面の SQL プレビューで CREATE TABLE 文と ALTER TABLE 文を確認します。
コメントを含めると外部キーを含めるは既定のオンのままにします。外部キーを含めるを切っても、検証エラーは消えずに外部キーが消えるだけです。
エクスポートを押し、ブラウザーの保存画面でファイル名（モデル名.sql）と保存先を決めて保存します。

Dr.ERD は SQL を実行しません。生成した DDL をファイルに保存するだけです。
プレビューの文字は画面上で選択してコピーできます。
範囲で選択したテーブルだけを書き出すこともでき、「参照元の親を含める」を併せて有効にすると参照先のテーブルも含まれます。

3. 書き出す前に確認すること

DDL はモデルに設定された値をそのまま出力します。書き出す前に NULL 許可、主キー、リレーションの対応を確認してください。設定が足りない場合、Dr.ERD は DDL を作らずエラーで案内します。

3 テーブルのカラム 10 個すべてで NULL 許可が切れているか確認します。切ったカラムだけが NOT NULL として出力されます。
主キー 3 つ（members.id、orders.id、order_items.id）が指定されているか確認します。
リレーション 2 つの参照キーと FK 対応（members.id → orders.member_id、orders.id → order_items.order_id）が設定されているか確認します。Mermaid の読み込みで作られたリレーションは FK 表示だけで対応が空なので、自分で設定する必要があります。
この実習に自動採番（Identity）カラムはありません。id の値は INSERT 時に手入力します。

リレーションが未設定の場合は「関係の参照キーと FK 対応を設定してください」というエラーになります。
親カラムが主キーでも UNIQUE でもない場合、参照キーの対応が有効にならず書き出せません。
N:M リレーションの中間テーブルは自動生成されないため、DDL を出力する前に自分で中間テーブルに分けてください。

4. 生成された DDL の読み方

PostgreSQL 18 の出力は、テーブルを作る CREATE TABLE 文と外部キーを付ける ALTER TABLE 文に分かれます。Dr.ERD は先にテーブルを作り、あとからリレーションを付ける順で出力するため、上から下へ実行すれば外部キーの参照先はすでに存在します。

CREATE TABLE 文でカラム名、型、NOT NULL、PRIMARY KEY を確認します。
ALTER TABLE 文で FOREIGN KEY（子カラム）REFERENCES 親テーブル（親カラム）を確認します。
制約名が自分のモデルのリレーション UUID から作られているか確認します。

制約名は fk_ のあとにリレーション UUID の先頭を付けます。リレーションごとに UUID が異なるため、例と名前が違っても正常です。
ON DELETE NO ACTION ON UPDATE NO ACTION は、子の行が残っている状態で親の行を削除・変更しようとするとデータベースが拒否するという意味です。
この実習の 2 つのリレーションは非識別なので、外部キーは子テーブルの主キーに入りません。
外部キーの型は参照するカラムと同じにする必要があります。異なる場合は「型が空か未対応です」というエラーで案内します。

5. 例の DDL（PostgreSQL 18 の出力）

以下は、この 3 テーブルモデルを PostgreSQL 18 として書き出した結果です。制約名はリレーション UUID から作られるため自分のモデルでは fk_ のあとが異なり、テーブル・カラム・型・参照関係は同じです。

文の順序: CREATE TABLE 3 つ → ALTER TABLE の外部キー 2 つ。
NULL 許可を切った 10 カラムすべてが NOT NULL として出力されます。
自分のモデルの制約名が例と違っても、参照先と参照動作が同じなら同じ構造です。

CREATE TABLE "members" (
  "id" BIGINT NOT NULL,
  "name" VARCHAR(100) NOT NULL,
  PRIMARY KEY ("id")
);

CREATE TABLE "orders" (
  "id" BIGINT NOT NULL,
  "member_id" BIGINT NOT NULL,
  "created_at" TIMESTAMP NOT NULL,
  PRIMARY KEY ("id")
);

CREATE TABLE "order_items" (
  "id" BIGINT NOT NULL,
  "order_id" BIGINT NOT NULL,
  "product_name" VARCHAR(100) NOT NULL,
  "quantity" INTEGER NOT NULL,
  "unit_price" NUMERIC(12,2) NOT NULL,
  PRIMARY KEY ("id")
);

ALTER TABLE "orders" ADD CONSTRAINT "fk_11111111222243338444" FOREIGN KEY ("member_id") REFERENCES "members" ("id") ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE "order_items" ADD CONSTRAINT "fk_66666666777748888999" FOREIGN KEY ("order_id") REFERENCES "orders" ("id") ON DELETE NO ACTION ON UPDATE NO ACTION;

6. MySQL 8.4 と Oracle 19c では何が違うか

Dr.ERD はモデルで選択した対象に合わせて SQL を生成します。同じモデルでも対象が違えば型と文法が変わるため、PostgreSQL 18 の例を MySQL や Oracle にそのまま実行することはできません。主な違いは次のとおりです。

MySQL 8.4（InnoDB）を対象にすると、データ辞書の金額ドメインは DECIMAL(18,2) を提案します。MySQL では NUMERIC は DECIMAL の同義語です。
MySQL の TIMESTAMP は 1970 年から 2038 年までの範囲なので、日時ドメインは DATETIME を提案します。
Oracle 19c は BIGINT の代わりに NUMBER(19,0)、VARCHAR の代わりにバイト長を付けた VARCHAR2(100 BYTE) を使います。BOOLEAN 型がないため、真偽ドメインは提案されません。

MySQL の出力は識別子をバッククォート（`）で囲み、CREATE TABLE の末尾に ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 を付け、自動採番カラムは AUTO_INCREMENT として出力します。
Oracle の出力は識別子を二重引用符で囲みます。Oracle には ON UPDATE 動作がないため、外部キーに ON UPDATE 句は出力されません。
生成された DDL は、表示された対象でのみそのまま実行してください。別のデータベースへ移す場合は型を再確認する必要があります。

7. 保存した DDL をデータベースで確認する

Dr.ERD は SQL を実行しないため、保存したファイルは自分で実行します。その際は、すでに使っているテスト用データベースか 1 つのトランザクションを使うと、誤って残るテーブルを作らずに済みます。PostgreSQL のインストールと接続方法はこのガイドの範囲外です。

一時的なテスト用データベースで実行するか、トランザクションで囲んで確認後に戻します。PostgreSQL では BEGIN; と ROLLBACK; の間で確認できます。
テーブル 3 つ（members、orders、order_items）と外部キー 2 つが作成されたか確認します。
親の行がない状態で子の行を挿入してみます。INSERT INTO orders (id, member_id, created_at) VALUES (1, 999, NOW()); は外部キー検証で拒否される必要があります。
確認が終わったら ROLLBACK で戻すか、一時データベースを削除します。

期待する結果: CREATE TABLE 3 つ、ALTER TABLE 2 つ、外部キー 2 つ。
id は自動採番ではないため、1、2、3 のように自分で値を入れます。
親の行がないのに子の行が入る場合は外部キーが適用されていません。DDL が対象データベースに合っているか確認してください。

8. よくある問題の解決

書き出しから実行までで多い 5 つの状況と確認方法です。

主キーがない: 親テーブルに主キーがないと参照キーの対応を設定できません。members.id、orders.id、order_items.id で「PK を設定」を押してから、もう一度リレーションを確認してください。
リレーションの対応が未設定: Mermaid の読み込みで作られたリレーションには FK 表示だけでキーの対応がありません。リレーションの編集で参照キーと FK 対応を設定してください。
外部キーの型が一致しない: 参照するカラムと外部キーのカラムは型・長さ・小数が同じである必要があります。members.id が BIGINT なら orders.member_id も BIGINT です。
N:M リレーション: 中間テーブルは自動生成されません。自分で中間テーブルを作り、1:N のリレーション 2 つに分けてから書き出してください。
フォルダーの書き込み権限: 保存画面が開かない、または保存に失敗する場合は、作業フォルダーへのアクセスを再び許可するか、書き込みできる別のフォルダーを選んでください。

9. 次のステップ

モデルと DDL をそろえて管理すると、レビューと配布が楽になります。

変更があれば .drerd ファイルを保存し、SQL DDL を書き出し直して内容をそろえます。
ドキュメントやレビューには Mermaid、表形式の資料には Excel の書き出しを併用してください。