不需要資料庫伺服器也能設計關係模式：新增表，為它們定義帶型別、鍵和預設值的列，然後用關係把表連線起來。實體關係圖隨你的輸入即時重繪，同一個模型可以匯出為 MySQL、PostgreSQL、SQL Server、SQLite 或 Oracle 的 CREATE TABLE DDL、Mermaid erDiagram 原始碼，或可在此重新匯入、也可用遷移生成器開啟的可移植 模式 JSON。全部本地執行。
什麼是 ERD？ ERD 是 實體關係圖（entity relationship diagram）的縮寫，它是數據庫的設計圖紙，而不是對建成數據庫的記錄。一個有用的類比是建築藍圖：運行中的數據庫是大樓，ERD 是藍圖，沒有人會先澆混凝土再測量。本頁就是這張藍圖繪圖桌——你在這裡塑造模型，DDL、Mermaid 源碼和模式 JSON 都從這一個模型打印出來，因此圖不會偏離它生成的 SQL。
同一張圖的三個層次。 概念 ERD 只命名重要的事物及其關係，用非程式設計師也能核對的語言。邏輯 ERD 增加標識每個事物的鍵並化解多對多連線，同時不涉及任何引擎的方言。物理 ERD 補齊特定產品要求的一切——型別寬度、預設值、可空性、唯一約束、刪除規則——當你在本頁選擇 MySQL、PostgreSQL、SQL Server、SQLite 或 Oracle 時匯出的就是這一層。
方框從哪裡來。 讀一段系統描述並圈出名詞：客戶、發票、產品、發貨。這些就是表。掛在名詞上的事實和屬性——發票日期、單價、電子郵件地址——就是它的列。把兩個名詞綁在一起的動詞，比如“訂單由客戶下達”，就是一個關係，它通過把父行中起標識作用的鍵複製到子行作為外部索引鍵來儲存。
什麼時候是多對多。 一個菜譜用多種食材，一種食材出現在多個菜譜裡，兩張表都無法儲存對方的鍵而不自我重複。答案是第三張實體表，它唯一的職責就是配對——即連線（或關聯）表，為每一方儲存一個外部索引鍵，通常把這對鍵作為自己的主鍵。一個模型裡大多是這種配對錶完全正常：白板上的多對多連線在真真實模式裡總要變成一個方框。
為什麼要在 DDL 出現之前費這個勁。 圖紙上畫錯一條線，擦掉只要一分鐘；同樣的錯誤在釋出之後才發現，代價是對生產資料做一次遷移。圖也是非開發人員唯一能評審的產物，關係錯誤——弄反的基數、缺失的唯一鍵、可以沒有父行的子行——在這裡會以明顯錯誤的線的形式暴露，而在 400 行的 DDL 檔案裡它們藏在約束中間。
正向還是逆向？ 本設計器是正向的：先建模，再輸出 DDL。姊妹頁
SQL 轉 ERD走另一條路——貼上現有
CREATE TABLE 語句，它會重建圖，這在資料庫已經存在時是更快的路線。
4 — 匯出
Mermaid erDiagram 原始碼
JSON 模型是資料庫工具家族的交換格式：把它作為修改前/後的模式貼上到
遷移生成器，或在這裡重新匯入以便日後繼續編輯。
