ER-диаграмма (Entity-Relationship Diagram, ERD) — графическая нотация для описания структуры данных предметной области: сущностей, их атрибутов и связей. Аналитик использует её, чтобы перевести словесные требования в проверяемую модель до разработки схемы хранения. ER не описывает потоки данных — для них см. 03.04.02 Диаграмма потоков данных (DFD); на одном проекте обе модели отвечают на разные вопросы, имена сущностей и хранилищ на DFD согласуйте с ER.

Цель ER-моделирования — построить непротиворечивую информационную модель, которая станет основой для логической модели данных и, при реляционной реализации, схемы БД (07.01 Базы данных и SQL на уровне аналитика). ER сервиса не равен контракту API: ресурсы REST и поля OpenAPI проектируют отдельно (03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf), 10.01.04 Шаблон спецификации REST API).

1. Суть темы

ER-модель отвечает на вопрос: какие объекты храним, как они связаны и какие ограничения действуют. Кардинальность и обязательность связей — это не «декор диаграммы», а зафиксированные бизнес-правила, которые должны совпадать с требованиями и критериями приёмки.

Уровни абстракции

На одном проекте ER-диаграммы живут на разных уровнях — не смешивайте их на одном листе без явной пометки:

УровеньАудиторияЧто показываемЧего избегаем
Концептуальныйбизнес, productсущности, связи, ключевые атрибуты; нотация Чена или Min-Maxтипов SQL, PK/FK в теле сущности
Логическийаналитик, архитектор БДсущности как таблицы, ключи, кардинальность; Crow's Foot / IDEF1Xиндексы, партиции, DDL конкретной СУБД
Физическийразработка, DBAтаблицы, типы, индексы, ограничения СУБД— зона 03.03.02 Логическая и физическая модель данных

На воркшопе с бизнесом рисуйте концептуальный ER: имена из предметной области, без int и FK. На ревью с разработкой переходите к логическому слою и фиксируете решения в 10.01.03 Шаблон спецификации БД сервиса.

Границы одной диаграммы

Одна ER-диаграмма — один контекст данных: подсистема, сервис или bounded context (03.01.03 Декомпозиция системы на подсистемы и модули, 03.06.02 Основы Domain-Driven Design). «ER на всю компанию» быстро теряет читаемость и смешивает несвязанные домены. Если сущности из разных контекстов ссылаются друг на друга — показывайте внешнюю сущность как «чёрный ящик» или выносите интеграционную модель в отдельный артефакт (03.01.04 Интерфейсы и интеграционные взаимодействия).

Когда ER недостаточен

Классический ER ориентирован на реляционное хранение структурированных сущностей. Для документных БД, графов, event sourcing или аналитических витрин ER остаётся полезным для ядра домена, но не описывает всю архитектуру хранения — см. 03.03.02 Логическая и физическая модель данных и 07.01 Базы данных и SQL на уровне аналитика.

2. Ключевые понятия

2.1 Сущность (Entity)

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

Типы сущностей:

  • Сильная (независимая) — существует сама по себе: Клиент, Товар.
  • Слабая (зависимая) — не идентифицируется без родителя; ключ включает ключ родительской сущности. Пример: Позиция заказа без Заказа не имеет смысла. В IDEF1X такая связь называется идентифицирующей; слабость видна по составному PK с FK родителя — в Mermaid и Crow's Foot отдельного символа нет, детали реализации см. 03.03.02 Логическая и физическая модель данных.
  • Ассоциативная — разрешает связь M:N и может иметь собственные атрибуты: ЗаказТовара между Заказ и Товар с полями Количество, Цена.

2.2 Атрибут (Attribute)

Атрибут — поименованное свойство сущности.

Классификация:

  • Простой (атомарный) — не делится на значимые части: ДатаРождения, Цена.
  • Составной — состоит из частей (Адрес = Город + Улица + Дом); на логическом уровне обычно раскладывается в атомарные колонки.
  • Многозначный — несколько значений на экземпляр (НомерТелефона у клиента); выносится в отдельную сущность или отдельную таблицу.
  • Производный — вычисляется из других атрибутов: Возраст из ДатаРождения, СуммаЗаказа из позиций. На ревью модели зафиксируйте решение: хранить (denormalization для отчётов) или вычислять (консистентность через правило). Сам факт производности не диктует выбор — его задают NFR и согласование с 03.03.02 Логическая и физическая модель данных.
  • Ключевой — уникально идентифицирует экземпляр (см. ниже).

2.3 Связь (Relationship)

Связь — осмысленная ассоциация между сущностями. Именуется глаголом или отглагольным существительным: Клиент оформляет Заказ.

Степень связи (арность):

  • Бинарная — между двумя сущностями (наиболее частая).
  • Унарная (рекурсивная) — сущность ссылается на себя: Сотрудник управляет Сотрудником. На двух концах одной сущности указывайте роли (руководитель / подчинённый), иначе связь неоднозначна.
  • Тернарная — три сущности (Преподаватель – Студент – Курс). Часто избыточна: вместо тернарника вводят ассоциативную сущность Запись на курс с атрибутами Дата, Оценка и тремя связями 1:M.

2.4 Обобщение и специализация (ISA)

Связь «является видом»: Клиент / VIP-клиент, Платёж / КарточныйПлатёж. В нотации Чена — треугольник «is-a» к родителю; в Crow's Foot — generalization/inheritance, если инструмент поддерживает.

На ER-воркшопе достаточно зафиксировать иерархию имён и общие атрибуты; стратегию таблиц при реляционной реализации здесь не выбирают. На ревью уточните дискриминатор: все атрибуты в родителе или часть только у потомков? Наследовать ли ключ родителя? Одна таблица, таблица на подтип или общая + расширения — см. 03.03.02 Логическая и физическая модель данных.

2.5 Ключи

  • Потенциальный ключ (Candidate Key) — атрибут или набор, уникально идентифицирующий экземпляр: Email, IdКлиента.
  • Первичный ключ (PK) — выбранный потенциальный ключ: неизменяемость, непустота, минимальность.
  • Уникальный ключ (UK, Alternate Key) — потенциальный ключ, не выбранный как PK; на логической диаграмме и в спецификации БД помечается как UK или UNIQUE (например, email при суррогатном customer_id).
  • Естественный ключ — бизнес-атрибут (НомерПаспорта); риск при смене формата.
  • Суррогатный ключ — искусственный идентификатор (UUID, автоинкремент); рекомендуется для большинства сущностей.
  • Внешний ключ (FK) — атрибут дочерней сущности, ссылающийся на PK родителя.

2.6 Кардинальность и модальность

Кардинальность (максимум) — сколько экземпляров B может быть связано с одним A:

  • 1:1 — не более одного с каждой стороны. Пример: Сотрудник – Пропуск. Уточните владельца FK: FK обычно кладётся в сущность, которая зависит от другой (пропуск не существует без сотрудника → FK в Пропуск).
  • 1:M — одному A соответствует ноль или много B; каждому B — ровно один A. Пример: Заказчик – Заказ.
  • M:N — с обеих сторон «много». На логическом уровне не оставляйте M:N — вводите ассоциативную сущность и две связи 1:M.

Модальность (минимум / обязательность):

  • Обязательная (минимум 1): экземпляр не существует без связи.
  • Необязательная (минимум 0): связь может отсутствовать.

Классическая ER и Crow's Foot выражают базовую кардинальность и модальность. Правила с условием по статусу, лимитам или фильтрам («не более трёх активных заказов») на диаграмме не изображаются — их фиксируют в требованиях, словаре данных и ограничениях спецификации; при необходимости — на диаграмме состояний.

2.7 Основные нотации

Выбор зависит от корпоративного стандарта и аудитории.

Нотация Чена (Chen's Notation) — оригинал 1976 г.: сущность — прямоугольник, связь — ромб, атрибуты — овалы; кардинальность 1 / N на линиях. Удобна для концептуального обсуждения с бизнесом; громоздка при большом числе атрибутов.

Crow's Foot (IE, «гусиная лапка») — де-факто стандарт логического моделирования (Martin/Finkelstein). Сущность — прямоугольник с атрибутами; связь — линия с символами на каждом конце:

Символ на концеМаксимумМинимум
| (одна черта)одинобязательно (минимум 1)
O (кружок) + | или лапкаодин / многонеобязательно (минимум 0)
< (гусиная лапка)много—

Читайте каждый конец отдельно: слева минимум и максимум для участия этой сущности, справа — для другой. Пример: ||--o{ — со стороны || ровно один и обязательно; со стороны o{ — ноль или много. Не смешивайте в одной фразе «от одного до многих» без указания, какой конец линии вы описываете.

IDEF1X — строгая нотация для сложных логических моделей; явно различает идентифицирующие и неидентифицирующие связи (слабые сущности).

UML (диаграмма классов) — см. UML (диаграмма классов). Класс ≈ сущность, ассоциация с кратностью 0..*, 1..1 — аналог кардинальности ERD. Не заменяет ER при проектировании БД, но привычна в OO-командах.

Min-Max — пара (m, n) на связи: (0, n) — ноль или много, (1, 1) — ровно один. Удобна на концептуальном уровне без запоминания символов Crow's Foot.

3. Как применяется в работе аналитика

3.1 Алгоритм построения (5 шагов)

  1. Определить сущности. Источники: интервью и документы (02.02.01 Интервьюирование и анкетирование, 02.02.03 Наблюдение и анализ документов), user stories и SRS (02.03.03 Спецификация требований (SRS, Use Case, User Story)), описания процессов. Выделяйте существительные предметной области, но проверяйте каждое: не путайте сущность с отчётом, процессом (Управление заказами) или дублем (Клиент vs Пользователь). События (Платёж, Заказ) часто становятся сущностями, если их нужно хранить; если важен только поток действий — это зона Activity или BPMN (03.04.01 BPMN 2.0 - введение и основы). Для каждой сущности решите: сильная, слабая или ассоциативная.
  2. Выявить связи. По глаголам в требованиях; задайте кардинальность и обязательность. Каждой связи — осмысленное имя.
  3. Документировать атрибуты. Черновик словаря данных или 10.01.14 Шаблон глоссария и словаря данных; типы и ограничения — на логическом уровне.
  4. Проверить структурные правила. Связи M:N преобразуйте в ассоциативные сущности; многозначные атрибуты — в отдельные сущности. Пошаговая нормализация (1НФ–3НФ, аномалии) — в 03.03.02 Логическая и физическая модель данных; здесь достаточно правила: M:N на логической ER не оставлять.
  5. Валидация. Обсудите диаграмму с бизнесом и архитектором (02.02.02 Воркшопы, фасилитация и совместные сессии, 02.04.01 Верификация и валидация (V&V)). Бизнес проверяет имена и связи, не нотацию.

3.2 Именование

Договоритесь в команде заранее:

  • Язык модели — язык предметной области (русский) или английский для кода; не смешивайте на одной диаграмме без правила.
  • Единственное vs множественное число — ORDER или ORDERS; главное — единообразие во всех артефактах и 10.01.03 Шаблон спецификации БД сервиса.
  • Связи — глагол в активном залоге со стороны «родителя»: «содержит», «оформляет».

3.3 Практический пример (логический уровень)

Фрагмент интернет-магазина: клиент, его адреса, каталог с категорией, заказ, позиции, оплата и отгрузка. Линии — связи; у конца с «лапкой» много записей, две черты — ровно одна обязательная, кружок — ноль допустим. Диаграмма в DBML (dbdiagram.io), логический слой:

CUSTOMER.customer_id — ADDRESS.customer_idCATEGORY.category_id — PRODUCT.category_idCUSTOMER.customer_id — ORDER.customer_idORDER.order_id — ORDER_ITEM.order_idPRODUCT.product_id — ORDER_ITEM.product_idORDER.order_id — PAYMENT.order_idORDER.order_id — SHIPMENT.order_id
CUSTOMER
  • customer_idintPK
  • emailvarcharUK NN
  • full_namevarcharNN
  • registration_datedateNN
CATEGORY
  • category_idintPK
  • namevarcharUK NN
ADDRESS
  • address_idintPK
  • customer_idintNN
  • cityvarcharNN
  • streetvarcharNN
  • is_defaultbooleanNN
PRODUCT
  • product_idintPK
  • category_idintNN
  • namevarcharNN
  • current_pricedecimalNN
  • stock_quantityintNN
ORDER
  • order_idintPK
  • customer_idintNN
  • order_datedatetimeNN
  • total_amountdecimalNN
  • statusvarcharNN
ORDER_ITEM
  • order_item_idintPK
  • order_idintNN
  • product_idintNN
  • quantityintNN
  • unit_pricedecimalNN
PAYMENT
  • payment_idintPK
  • order_idintNN
  • amountdecimalNN
  • paid_atdatetime
SHIPMENT
  • shipment_idintPK
  • order_idintUK NN
  • carriervarcharNN
  • shipped_atdatetime

Пояснения:

  • email UK — уникальный ключ (§2.5): один email на клиента при суррогатном PK customer_id.
  • CUSTOMER – ORDER и CUSTOMER – ADDRESS: 1:M, ссылка обязательна. У заказа и адреса ровно один клиент (||), у клиента может не быть ни заказов, ни адресов (o{).
  • CATEGORY – PRODUCT: товар без категории не создают. Категория может быть пустой.
  • ORDER – ORDER_ITEM – PRODUCT: M:N разрешена ассоциативной сущностью. Семантически позиция — слабая относительно заказа (идентифицирующая связь в IDEF1X). Crow's Foot не рисует слабость отдельным символом — в строгой IDEF1X это составной PK (order_id, line_no) с FK родителя в ключе; здесь суррогатный order_item_id, а зависимость от заказа зафиксирована в тексте и спецификации. Варианты реализации — 03.03.02 Логическая и физическая модель данных.
  • ORDER – PAYMENT: 1:M. Платёж без заказа не существует; заказ может ещё не быть оплачен, поэтому лапка со стороны платежа — «ноль или много», а не «минимум один».
  • ORDER – SHIPMENT: 1:1. order_id в отгрузке уникален, поэтому у заказа не больше одной отгрузки. Кружок у отгрузки: заказ может ещё не уехать.
  • Обязательность «заказ содержит хотя бы одну позицию» (||--|{) не универсальна: если допустим черновик или пустая корзина, модальность — ||--o{. Зафиксируйте правило в требованиях.
  • total_amount — производный атрибут (сумма quantity × unit_price). Решение «хранить или только вычислять» согласуйте с командой и NFR.
  • unit_price в позиции — снимок цены на момент заказа, не ссылка на текущий current_price.

Тот же магазин, если бизнес разрешает гостевой заказ: customer_id может быть пустым. На линии со стороны клиента появляется кружок — ноль или один, а не «ровно один».

CUSTOMER.customer_id — ORDER.customer_id
CUSTOMER
  • customer_idintPK
  • emailvarcharUK NN
ORDER
  • order_idintPK
  • customer_idint
  • order_datedatetimeNN
  • statusvarcharNN

Жизненный цикл status заказа удобнее описать отдельно — 03.02.04 Диаграмма состояний (State Machine Diagram).

3.4 Связь ER-модели с требованиями

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

Правило в требованияхНа ER-диаграммеГде ещё фиксировать
«Заказ привязан к клиенту»обязательная связь 1:Mмодальность на линии
«Гостевой заказ без регистрации»необязательная связь CUSTOMER – ORDERмодальность на линии
«Один клиент — не более трёх активных заказов»не выражается простой 1:Mтекст требований, [[02.03.01 Классификация требований (БТ, ФТ, НФТ)

Не рисуйте условную кардинальность как «обычный» 1:M — команда потеряет правило. На диаграмме — базовая структура и модальность; условия, лимиты и фильтры по состоянию — в требованиях и спецификации.

Диаграмма должна трассироваться на функциональные требования (02.03.04 Трассировка требований (концепция), 10.01.15 Шаблон матрицы трассировки). Изменение требования («разрешить гостевые заказы») сразу меняет модальность на диаграмме.

3.5 Инструменты

Для повседневной работы достаточно редактора с Crow's Foot и экспортом в документацию: draw.io, Mermaid в Markdown (07.05 Системы контроля версий (Git) для документации), dbdiagram.io для быстрых логических эскизов. Reverse-engineering существующих схем — через DBeaver, DataGrip и аналоги (10.02 Разбор кейса "Миграция legacy-системы").

Критерии выбора (коллаборация, корпоративный стандарт, интеграция с Confluence/Jira) и полный обзор платформ — в 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io). Генерацию DDL и физическую схему относите к 03.03.02 Логическая и физическая модель данных и 07.01 Базы данных и SQL на уровне аналитика.

4. Типовые ошибки и ограничения

ОшибкаПоследствиеРекомендация
Связь M:N без ассоциативной сущностиНекуда положить атрибуты связиДве связи 1:M через промежуточную сущность
Условная кардинальность как простой 1:MПотеря бизнес-правила на handoffБазовая связь на ER; условие — в требованиях и спецификации (§3.4)
Естественный ключ, подверженный изменениюБолезненные миграцииСуррогатный PK + UK на естественный
Неявная модальность«Висячие» записи, споры на приёмкеЯвно помечать обязательность; для Crow's Foot: | = обязательно, O = необязательно
Атрибут вместо сущностиЛишняя сложностьСущность — если есть собственные атрибуты и связи
Безымянные связиНепроверяемый бизнес-смыслИмя-глагол на каждой линии
Одна диаграмма на весь ландшафтНечитаемость, смешение контекстовДекомпозиция по подсистемам / сервисам
Производный атрибут без решения «хранить/считать»Рассинхрон данныхЗафиксировать в спецификации и [[08.02 Нефункциональные требования (НФТ) — классификация и стандарты
Табличная ER 1:1 в ресурсы APIНеудобный контракт, утечка схемы БДER для хранения; API — 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf), 10.01.04 Шаблон спецификации REST API
Нормализация «в голове» без проверкиИзбыточность, аномалииКритерии 1НФ–3НФ — 03.03.02 Логическая и физическая модель данных

ER описывает структуру, а не поток: не путайте с DFD (03.04.02 Диаграмма потоков данных (DFD)). Не подменяйте ER диаграммой классов UML там, где целевая аудитория — DBA и согласование схемы БД; перекрёстная ссылка — 06.01.01 Структурные диаграммы (Class, Object, Package).

Связи с другими разделами базы

Минимальный контур после этой статьи: 03.03.02 Логическая и физическая модель данных → 03.03.03 Словарь данных (описание) → 10.01.03 Шаблон спецификации БД сервиса.

Источники и дополнительные материалы

Книги и стандарты

Статьи и документация