Перейти к содержимому

Diagramming5 мин чтения

ER-диаграмма онлайн: сущности, связи и пример интернет-магазина

Карточки клиента, заказа и товаров соединены тонкими нитями в модель данных

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

Сначала предметная область, потом таблицы

Возьмём учебный интернет-магазин. Клиент оформляет заказ; заказ содержит позиции; каждая позиция относится к товару. «Заказ» и «товар» нельзя соединить одной строкой с количеством: один заказ содержит несколько товаров, а один товар встречается во многих заказах. Для этого нужна отдельная сущность «позиция заказа».

До выбора полей ответьте на вопросы. Может ли клиент существовать без заказов? Может ли заказ быть пустым черновиком? Сохраняется ли цена на момент покупки? Можно ли удалить товар, который уже продавался? Ответы определяют модель сильнее, чем аккуратные линии.

Нотации Чена и «воронья лапа»: как читать связи

В нотации Чена сущности обычно изображают прямоугольниками, отношения — ромбами, атрибуты — овалами. Она удобна для обсуждения концептуальной модели. «Воронья лапа» компактнее показывает кратность на концах связей: один, много, обязательное или необязательное участие. Важно не смешивать обозначения без легенды.

В примере клиент может иметь ноль или много заказов; каждый заказ принадлежит одному клиенту. Подтверждённый заказ содержит хотя бы одну позицию, каждая позиция относится к одному товару. Если система хранит пустые черновики, обязательность позиции для заказа нужно изменить. Именно такие оговорки делают ER полезной, а не декоративной.

Как построить ER-диаграмму на одном примере

СущностьКлюч и поляЧто важно проверить
CLIENTid, nameИмя не является уникальным ключом
ORDERid, client_id, created_atДопускаются ли заказы без учётной записи
ORDER_ITEMorder_id + line_number, product_id, quantity, unit_priceЦена фиксируется для конкретной покупки
PRODUCTid, nameЧто происходит с историей после удаления товара

Составной ключ позиции order_id + line_number позволяет хранить несколько строк одного товара в одном заказе, если бизнесу это нужно. Не объявляйте пару order_id + product_id единственным вариантом автоматически. Для денег и количества типы в диаграмме — ориентиры; точность, ограничения и правила округления задаются отдельно при проектировании хранения.

ER-модель с сущностями CLIENT, ORDER, ORDER_ITEM и PRODUCT, первичными и внешними ключами
Учебная модель заказа. Поля и кратности выбраны для описанного сценария, а не предлагаются как универсальная схема магазина.

Как создать ER-диаграмму онлайн в Эсборд

Через MCP внешний ассистент может передать исходник erDiagram и получить объект диаграммы. Этот пример создан на живой доске 5 октября 2026 года: сервер принял сущности, атрибуты PK/FK и связи, затем рассчитал компоновку. Исходник остаётся способом изменить содержание; не следует обещать независимое перетаскивание каждого поля как в редакторе базы данных.

Размещайте рядом с диаграммой спорные правила: «заказ без клиента», «удаление товара», «частичная отмена». Попросите коллегу пройти реальный сценарий по схеме. Комментарий «здесь должно быть много» без примера слабее, чем «покупатель добавляет один товар двумя строками с разными условиями».

Как сделать проверку перед передачей разработчику

  • У каждой сущности есть понятный смысл, а не только техническое имя.
  • Для каждой связи объяснены минимум и максимум объектов.
  • Первичные ключи уникальны в выбранных границах.
  • Внешние ключи не подменяют бизнес-правила удаления и истории.
  • Пример покупки проходит по схеме без придуманных на ходу полей.

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

ER, UML и SQL решают разные задачи

ER фокусируется на данных и отношениях. Диаграмма последовательности показывает обмен сообщениями во времени. SQL DDL задаёт конкретные таблицы и ограничения выбранной СУБД. Одна картинка не заменяет все три артефакта; связывайте их по смыслу и проверяйте согласованность изменений.

Для синтаксиса Mermaid ER есть официальная документация. Обзор соседних нотаций — в материале про UML онлайн. Начните с готового учебного примера, замените четыре сущности своими и сохраните список нерешённых вопросов вместе со схемой.

Открыть пример и перейти к своей задаче

Открыть учебный пример на доске. Просмотр по ссылке проверен без входа. Для собственной работы создайте доску и перенесите нужную структуру; доступность копирования зависит от настроек и вашей роли.

Обсудите модель данных до реализации

Соберите сущности, связи и открытые вопросы на одной доске. Начните с одного сценария.

Создать доску для модели

Предложить идею

Расскажите, чего не хватает в Эсборде и как это помогло бы в вашей работе.