Диаграмма схемы базы данных, понятная всей команде

Диаграмма схемы: один из самых полезных документов, которыми может владеть бэкенд-команда, и один из первых, что устаревают. Кто-то рисует её перед запуском, она получает почётное место в вики, а через двадцать миграций описывает базу данных, которой больше не существует.

Второй сценарий провала хуже: диаграмма формально остаётся актуальной, но превращается в спагетти. Линии внешних ключей проходят прямо через три таблицы, чтобы добраться до четвёртой, кардинальность угадывается, а не показывается, и никто не может с одного взгляда понять, много ли у пользователя заказов или ровно один. LetDraw создан, чтобы диаграммы схем оставались одновременно читаемыми и верными, и их стоило хранить.

Таблицы, которые знают, что они таблицы

ER-таблица в LetDraw: это не блок с набранным внутри текстом. Это настоящий элемент таблицы с типизированными столбцами и маркерами ключей, поэтому структура входит в саму фигуру, а не является рисунком, который нужно синхронизировать вручную.

• Типизированные столбцы. Каждая строка содержит имя и тип, поэтому id bigint читается как схема, а не как подпись.
• Маркеры ключей. Первичные и внешние ключи отмечены на столбце, и читатель видит поверхность соединения, не выискивая её.
• Редактирование на месте. Добавьте столбец, смените тип или переименуйте поле, и раскладка подстроится. Вы редактируете модель, а не двигаете прямоугольники.

Поскольку столбцы структурированы, связи между таблицами можно рисовать правильно, а не для красоты. Здесь и появляется кардинальность.

Нотация «воронья лапка» прямо на линии связи

Связь между двумя таблицами полезна, только если она показывает форму данных. Один пользователь и много заказов: совсем другой мир, чем один пользователь и один заказ, и диаграмма, которая смазывает разницу, хуже, чем никакой. LetDraw рисует нотацию «воронья лапка» (crow's foot) прямо на линии связи, поэтому один-ко-многим, один-к-одному и многие-ко-многим читаются сразу по соединителю.

Линия связи должна показывать форму данных, а не только то, что две таблицы соприкасаются.

Когда вы моделируете код, а не таблицы, тот же движок соединителей рисует правильные UML-диаграммы классов с полыми наконечниками для наследования и другими стандартными наконечниками. Не нужно рисовать треугольник от руки и надеяться, что он встанет на место; нотация встроенная, поэтому стрелка наследования выглядит как наследование для любого, кто читает UML.

Связи внешних ключей, которые обходят ваши таблицы

Вот деталь, от которой зависит, переживёт ли диаграмма схемы отметку в десять таблиц. Когда схема растёт, наивный подход рисует прямую линию от одного ключа к другому, и эти линии быстро прорезают каждую таблицу на пути. Картинка превращается в узел.

LetDraw использует умную маршрутизацию для соединителей внешних ключей: линия связи считает ваши таблицы препятствиями и огибает их. Соединение между orders.user_id и users.id остаётся видимым, даже если между ними десяток таблиц. Диаграмма становится плотнее по мере роста схемы, но не становится нечитаемой, а ведь ради этого её и рисуют.

ER-диаграмма из SQL, который вы уже написали

Не нужно расставлять вручную ни одной таблицы. Откройте диалог «Создать из кода», вставьте ваши инструкции CREATE TABLE, и LetDraw построит ER-диаграмму за вас: таблицы с типизированными столбцами, отмеченные ключи и связи, нарисованные по внешним ключам. Вот DDL, стоящий за рисунком выше.

CREATE TABLE users (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email       text NOT NULL UNIQUE,
  created_at  timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE orders (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  user_id     bigint NOT NULL REFERENCES users (id),
  total_cents integer NOT NULL,
  status      text NOT NULL DEFAULT 'pending'
);
-- user_id REFERENCES users(id) becomes the crow's-foot relationship

Именно выражение REFERENCES LetDraw читает, чтобы провести линию один-ко-многим с «вороньей лапкой» на стороне orders. Дальше это обычный рисунок, который вы дорабатываете и публикуете:

• Переставьте таблицы, сгруппируйте те, что относятся к одному ограниченному контексту, и подпишите хитрые соединения
• Добавьте таблицы, которых ещё нет в DDL, и нарисуйте их связи вручную с теми же наконечниками «воронья лапка»
• Экспортируйте в PNG, SVG или PDF для дизайн-документа или превратите диаграмму обратно в Mermaid или D2, когда снова нужен код

Почему читаемая схема базы данных стоит усилий

Диаграмма схемы: это контракт о том, как устроены ваши данные, и она окупается, только если ей доверяют. Типизированные столбцы и отмеченные ключи делают её точной; кардинальность «воронья лапка» делает её честной относительно формы данных; умная маршрутизация сохраняет читаемость по мере роста. Сгенерируйте первый черновик из SQL, который вы и так поддерживаете, и стоимость поддержки актуальности упадёт почти до нуля, а только так такая диаграмма и остаётся живой.

Вставьте ваши инструкции CREATE TABLE и посмотрите, как ER-диаграмма собирается сама, вместе с ключами.