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

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