データベースサーバーなしでリレーショナルスキーマを設計します：テーブルを追加し、型・キー・既定値を持つ列を与え、リレーションシップでつなぎます。エンティティリレーション図は入力に合わせて再描画され、同じモデルから MySQL、PostgreSQL、SQL Server、SQLite、Oracle 用の CREATE TABLE DDL、Mermaid erDiagram ソース、ここで再インポートしたり移行ジェネレーターで開ける可搬なスキーマ JSON として書き出せます。すべてローカル実行です。
ERD とは？ERD は エンティティリレーションシップ図の略で、完成したデータベースの記録ではなく、データベースの設計図です。建物の設計図との比較が有用です：稼働中のデータベースが建物、ERD が設計図であり、先にコンクリートを流して後から測る人はいません。このページはその設計図のための製図台です — ここでモデルを形にすると、DDL、Mermaid ソース、スキーマ JSON はすべてその 1 つのモデルから出力されるため、図が生み出した SQL からずれることはありません。
同じ図の 3 つのレベル。概念ERD は、重要なものとその関係だけを、非プログラマーでも確認できる言葉で名指します。論理ERD は各ものを識別するキーを加え、多対多のリンクを解決しながら、特定エンジンの方言から自由なままです。物理ERD は、1 つの製品が要求するもの — 型の幅、既定値、NULL 可否、一意制約、削除規則 — を埋め、MySQL、PostgreSQL、SQL Server、SQLite、Oracle を選んだときにここから書き出されるレベルです。
箱の由来。システムの記述を読んで名詞に下線を引きます：顧客、請求書、商品、出荷。それがテーブルです。名詞に付く事実や性質 — 請求日、単価、メールアドレス — がその列です。2 つの名詞を結ぶ動詞（「注文は顧客によって発注される」など）がリレーションシップで、親の行の識別キーを子の行へ外部キーとしてコピーすることで格納されます。
リンクが多対多のとき。1 つのレシピは多くの材料を使い、1 つの材料は多くのレシピに現れるため、どちらのテーブルも相手の鍵を反復せずには保持できません。答えは、それらを組にすることだけが仕事の第 3 のエンティティ — ジャンクション（関連）テーブルで、各側への外部キーを 1 つずつ、しばしばそのキーの組を主キーとして持ちます。そのような組テーブルが大半を占めるモデルは完全に正常です：ホワイトボード上の多対多の線は、実際のスキーマでは必ず箱にならなければなりません。
DDL が存在する前に面倒を見る理由。図上の間違った線は消すのに 1 分です。リリース後に見つかった同じ間違いは、稼働データ上の移行を代价にします。図は非開発者がレビューできる唯一の成果物でもあり、リレーションシップの欠陥 — 逆向きのカーディナリティ、欠けた一意キー、親を失い得る子の行 — はここでは明らかに悪い線として現れますが、400 行の DDL ファイルでは制約の中に隠れます。
順方向か逆方向か？このデザイナーは順方向です：先にモデル、そこから DDL。兄弟ページの
SQL → ERD は逆方向です — 既存の
CREATE TABLE 文を貼り付けると図を再構築します。データベースが既に存在するなら、こちらが早い道です。
4 — 書き出し
Mermaid erDiagram ソース
JSON モデルはデータベースツールファミリーの交換形式です：
移行ジェネレーターに前後のスキーマとして貼り付けるか、ここに再インポートして後で編集を続けられます。
