Конструктор ERD

Проектируйте реляционную схему без сервера баз данных: добавляйте таблицы, задавайте им столбцы с типами, ключами и значениями по умолчанию, затем соединяйте их связями. Диаграмма связей перерисовывается по мере ввода, а та же модель экспортируется как DDL CREATE TABLE для MySQL, PostgreSQL, SQL Server, SQLite или Oracle, как исходник Mermaid erDiagram либо как переносимый JSON схемы, который можно импортировать здесь обратно или открыть в генераторе миграций. Всё выполняется локально.
Что такое ERD? ERD — это сокращение от entity relationship diagram, диаграмма «сущность-связь», и это проектный чертёж базы данных, а не запись уже готовой. Удобная аналогия — строительный чертёж: работающая база данных — это здание, ERD — чертёж, и никто не заливает фундамент, а потом замеряет. Эта страница — чертёжный стол для такого чертежа: вы формируете модель здесь, а DDL, исходник Mermaid и JSON схемы печатаются из одной и той же модели, поэтому картинка не может разойтись с SQL, который из неё получился.
Одна и та же диаграмма на трёх уровнях. Концептуальная ERD называет только важные сущности и то, как они связаны, словами, которые может проверить непрограммист. Логическая ERD добавляет ключи, идентифицирующие каждую сущность, и разрешает связи «многие ко многим», оставаясь независимой от диалекта какого-либо движка. Физическая ERD дополняет то, что требует конкретный продукт, — ширины типов, значения по умолчанию, допустимость NULL, уникальные ограничения, правила удаления, — и именно этот уровень вы экспортируете здесь, выбрав MySQL, PostgreSQL, SQL Server, SQLite или Oracle.
Откуда берутся прямоугольники. Прочитайте описание системы и подчеркните существительные: клиент, счёт, товар, отгрузка. Это таблицы. Факты и свойства, привязанные к существительному, — дата счёта, цена за единицу, адрес электронной почты, — это его столбцы. Глагол, который связывает два существительных, как в «заказ размещает клиент», — это связь, и хранится она копированием идентифицирующего ключа родительской строки в дочернюю строку как внешнего ключа.
Когда связь «многие ко многим». Один рецепт использует много ингредиентов, а один ингредиент встречается во многих рецептах, поэтому ни одна таблица не может хранить ключ другой, не повторяясь. Ответ — третья сущность, единственная задача которой связать их: соединительная (или ассоциативная) таблица, хранящая по одному внешнему ключу с каждой стороны, часто с этой парой ключей как собственным первичным ключом. Модель, которая в основном состоит из таких связующих таблиц, — вполне нормальна: линия «многие ко многим» на доске всегда должна стать прямоугольником в настоящей схеме.
Зачем заморачиваться до появления DDL. Неверная линия на чертеже стирается за минуту; та же ошибка, найденная после выпуска, стоит миграции над живыми данными. Диаграмма — ещё и единственный артефакт, который могут проверить непрограммисты, а ошибки связей — кардинальность наоборот, отсутствующий уникальный ключ, дочерние строки, которые могут остаться без родителя, — здесь выглядят как очевидно плохие линии, тогда как в 400-строчном файле DDL они прячутся среди ограничений.
Прямо или обратно? Этот конструктор работает прямо: сначала модель, затем DDL. Родственная страница SQL в ERD идёт в обратную сторону — вставьте существующие операторы CREATE TABLE, и она восстановит диаграмму, что быстрее, когда база данных уже существует.
1 — Таблицы
Правка Имя таблицы Столбцы Связи Actions
2 — Столбцы
Столбец Тип PK AI NN UQ По умолчанию Actions
PK = первичный ключ, AI = автоинкремент / identity, NN = NOT NULL, UQ = уникальный
3 — Связи (внешние ключи)
Дочерняя таблица Дочерний столбец Actions Родительская таблица Родительский столбец При удалении Actions
Внешний ключ превращается в строку CONSTRAINT ... FOREIGN KEY в DDL.
4 — Экспорт
Исходник Mermaid erDiagram
Модель JSON — формат обмена для семейства инструментов баз данных: вставьте её в Генератор миграций как схему «до / после» или импортируйте здесь обратно, чтобы продолжить правку позже.