Что такое ER-диаграмма

Питер Чен предложил ER-модель в 1976 году в журнале ACM Transactions on Database Systems.

Диаграмма нужна системным аналитикам и разработчикам, которые проектируют базы данных.

Что такое ER-диаграмма и из чего она состоит

ER-диаграмма (или ERD, от англ. Entity-Relationship Diagram) — это схема, которая графически отображает данные проекта в виде сущностей, их атрибутов и связей между ними. Она служит основным инструментом для концептуального проектирования баз данных, помогая разработчикам и аналитикам понять логику предметной области до начала создания самой базы данных.

Любая ER-диаграмма строится из трех основных строительных блоков:

Элемент	Описание
Сущность (Entity)	Это объект или понятие в предметной области, о котором мы хотим хранить информацию Сущности могут быть реальными (клиент, товар) или абстрактными (заказ, проект) Их часто группируют в множества (классы) сущностей
Атрибут (Attribute)	Это свойство или характеристика сущности, которая ее описывает. Например, у сущности «КЛИЕНТ» атрибутами будут: Имя, Телефон, Дата рождения и т.д. Среди атрибутов выделяют ключевые, которые уникально идентифицируют каждый экземпляр сущности
Связь (Relationship)	Это ассоциация или взаимодействие между двумя (или более) сущностями Связь показывает, как сущности связаны друг с другом в бизнес-логике Связи имеют тип кратности (мощности), который описывает, сколько экземпляров одной сущности может быть связано с другой

Три уровня ER-модели: концептуальный, логический, физический

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

Концептуальный уровень

Это верхний уровень абстракции, который отвечает на вопрос «Что мы моделируем»? Он создаётся для обсуждения и согласования структуры данных с бизнес-заказчиками.

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

Что включает:

• Сущности (основные объекты системы). Например, для транспортной компании: «Транспорт», «Груз», «Маршрут», «Накладная».
• Связи между сущностями (без уточнения типа и мощности). Например: «Груз перевозится на Транспорте по Маршруту».

Характеристики:

• Не зависит от конкретной системы управления базами данных (СУБД).
• Отсутствуют детали физического хранения.
• Использует бизнес-термины, понятные заказчикам.
• Итог: диаграмма «сущность-связь» в нотации, понятной заказчикам.

Пример: концептуальная модель ER‑диаграммы для интернет‑магазина может содержать сущности «Клиент», «Товар», «Заказ» и связи между ними.

Логический уровень

Это средний уровень абстракции, который отвечает на вопрос «Что именно и в каком виде мы храним»? Здесь модель становится более детальной и технической.

Цель: детализировать модель данных для разработчиков. Определяются все атрибуты с точными типами данных (STRING, INTEGER, BOOLEAN), указываются первичные и внешние ключи (связи между таблицами).

Характеристики:

• По-прежнему не зависит от конкретной СУБД.
• Появляются первичные ключи и явные ограничения целостности (NOT NULL, UNIQUE).
• Используются нормализованные структуры данных для устранения избыточности.
• Итог: формализованная схема, готовая для проектирования в любой реляционной СУБД.

Пример: для сущности «Клиент» в логической модели добавляют атрибуты: «ФИО», «Email», «Телефон», «Адрес доставки». Связь «Клиент делает Заказ» уточняют как 1:N (один клиент может сделать много заказов).

Физический уровень

Самый нижний уровень абстракции, который отвечает на вопрос «Как именно это будет храниться»? Это уже конкретный проект базы данных с учётом производительности и технологий.

Цель: реализовать логическую модель в виде рабочих объектов конкретной СУБД (например, PostgreSQL, MySQL или Oracle) с учётом требований к скорости работы и объёмам данных.

Характеристики:

• Полная зависимость от выбранной СУБД (её синтаксис и особенности).
• Оптимизация хранения: выбор конкретных типов (INT, VARCHAR(255), DECIMAL(10,2)).
• Создание индексов для ускорения запросов, описание кластеров таблиц и секционирования.
• Указание параметров размещения данных (табличные пространства, файловые группы)
• Итог: SQL-скрипты для создания таблиц, индексов, ограничений с учётом производительности

Пример: в физической модели сущность «Клиент» превращается в таблицу clients со столбцами:

• client_id (INT, PRIMARY KEY);
• full_name (VARCHAR(100), NOT NULL);
• email (VARCHAR(255), UNIQUE);
• phone (VARCHAR(20));
• address (TEXT).

Типы связей между сущностями

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

Типы связей по мощности:

Тип связи	Обозначение	Описание
Один-к-одному (1:1)	1:1	Один экземпляр сущности А связан с одним экземпляром сущности Б Встречается редко, часто указывает на ошибочное разделение одной сущности на две
Один-ко-многим (1:N)	1:N или N:1	Один экземпляр сущности А связан с несколькими экземплярами сущности Б Наиболее распространённый тип связи в реляционных базах данных
Многие-ко-многим (N:M)	N:M или M:N	Несколько экземпляров сущности А связаны с несколькими экземплярами сущности Б При физическом проектировании заменяется двумя связями 1:N через промежуточную (ассоциативную) сущность

Модальность определяет, должен ли экземпляр сущности участвовать в связи:

• Обязательная связь — экземпляр сущности должен быть связан минимум с одним экземпляром другой сущности.
• Необязательная связь — экземпляр сущности может существовать без связи с другой сущностью.

Рекурсивная связь – это связь, в которой сущность связана сама с собой. Например, связь «Сотрудник — Руководитель» внутри одной сущности «Сотрудник».

Символы и нотации ER-диаграмм

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

Нотация Чена

Классическая нотация, предложенная Питером Ченом в 1976 году. ER-модель впервые была опубликована в журнале ACM Transactions on Database Systems.

Элемент	Обозначение
Сущность	Прямоугольник с именем внутри
Атрибут	Овал, соединённый линией с сущностью или связью
Связь	Ромб, соединяющий сущности
Мощность связи	Над линией указывается 1:1, 1:N или N:M
Обязательность	Пунктирная линия — необязательная связь, сплошная — обязательная

Нотация Чена используется преимущественно на концептуальном уровне для согласования с заказчиком.

Нотация Мартина «Воронья лапка»

Нотация Мартина компактнее нотации Чена, потому что атрибуты пишут прямо под сущностью. Она наиболее популярна при логическом моделировании:

Элемент	Обозначение
Сущность	Прямоугольник с именем внутри, атрибуты перечислены под именем
Связь	Линия, соединяющая сущности; на конце ставится символ «вилки» или «вороньей лапки» для обозначения «много»
Мощность	Символ «крест» — «один», «вилка» — «много»
Обязательность	Кружок на конце линии — необязательная связь

Нотация IDEF1X

Стандарт для CASE-средств (ERwin, Design/IDEF):

Элемент	Обозначение
Независимая сущность	Прямоугольник с прямыми углами
Зависимая сущность	Прямоугольник с закруглёнными углами
Идентифицирующая связь	Сплошная линия — первичный ключ родителя мигрирует в первичный ключ потомка
Неидентифицирующая связь	Пунктирная линия — ключ родителя мигрирует в неключевые атрибуты потомка
Мощность	Обозначается буквами: N (0,1+), P (1+), Z (0 или 1)

Где применяют ER-диаграммы

ER‑диаграммы (диаграммы «сущность‑связь») — универсальный инструмент для визуализации структуры данных. Основные сферы применения:

• Проектирование баз данных — основа для создания реляционных БД: определяют таблицы, столбцы и связи между ними. Пример: структура интернет‑магазина: «Клиент», «Товар», «Заказ», «Платёж».
• Системный и бизнес‑анализ — моделирование требований, выявление ключевых сущностей и их взаимосвязей. Пример: система учёта пациентов: «Пациент», «Врач», «Приём», «Медицинская карта».
• Разработка ПО — проектирование бэкенда, понимание структуры данных, синхронизация работы команд. Пример: мобильное банковское приложение: «Пользователь», «Счёт», «Транзакция», «Карта».
• Коммуникация между сторонами — наглядное представление данных для бизнеса и заказчиков без погружения в технические детали. пример: презентация логики стартапа инвесторам.
• Образование — обучение принципам реляционных моделей и нормализации данных. Пример: лабораторная работа: «Книга», «Читатель», «Выдача» для библиотеки.

Когда ER-диаграмма не подходит для задачи

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

В каких случаях ER-диаграмма не подходит для задачи:

• Данные не структурированы по полям, столбцам и строкам. Модель «сущность-связь» жёстко привязана к реляционной структуре. Для неструктурированных данных (документы, графы, временные ряды) она не подходит.
• Нужно описать поведение системы, а не структуру данных. ER-диаграмма статична: она показывает, как данные связаны, но не показывает, как данные изменяются во времени или какие процессы их обрабатывают. Для этого нужны диаграммы потоков данных (DFD), диаграммы деятельности или другие нотации UML.
• Система состоит из 1–2 сущностей без сложных связей. Строить концептуальную ER-модель для двух таблиц с простой связью «один-ко-многим» — избыточно. Можно сразу перейти к логическому проектированию.
• Нужно интегрировать модель с уже работающей базой данных другой архитектуры. ER-диаграмма создаётся «с нуля» под новую базу. Для обратного инжиниринга существующей базы или интеграции с разнородными источниками данных есть специализированные инструменты.
• Команда проектирует NoSQL-хранилище без жёсткой реляционной схемы. Для документных, графовых или key-value баз ER-нотация даст только самое общее представление о сущностях, но не отразит специфику хранения: вложенность, денормализацию, шардирование, индексы. Для NoSQL нужны другие подходы к моделированию.

Таблица сценариев: какой уровень и нотацию выбрать

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

Ситуация	Рекомендация	Причина
Нужно согласовать состав данных с заказчиком, который далёк от IT	Концептуальная модель в нотации Чена	Простые символы — прямоугольники, овалы — понятны без подготовки
Нужно детально описать все атрибуты для команды разработки	Логическая модель в нотации Мартина (Crow's Foot)	Атрибуты пишут прямо под сущностью, модель компактнее
Нужно определить, на какой СУБД и в каких таблицах хранить данные	Физическая модель с типами, первичными и внешними ключами	Показывает техническую реализацию для конкретной СУБД
Проект — простая система из 1–2 сущностей	Сразу логическая модель без концептуального уровня	Дополнительная детализация не нужна для небольшой системы
Нужно показать наследование признаков между похожими сущностями	Расширенная ER-модель с подтипами и супертипами	Отображает, какие атрибуты и связи наследуются от родительской сущности

Сравните курсы по системному анализу и базам данных на Сравни, если хотите освоить построение ER-диаграмм на практике.

Как создать простую ER-диаграмму: пошаговая инструкция

Создание ER-диаграммы — это процесс от общего к частному: от определения ключевых понятий предметной области до конкретных атрибутов и связей. Простые системы с 1–2 сущностями можно проектировать без построения концептуальной ER-модели. Ниже — пошаговый план для самостоятельной работы.

Шаг 1. Определите цель и границы моделирования

Ответьте на вопрос: для чего создаётся диаграмма? Это может быть:

• проектирование новой базы данных с нуля;
• добавление новых таблиц в существующую базу;
• документирование текущей структуры;
• согласование данных с заказчиком.

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

Шаг 2. Выявите все сущности

Выпишите все основные объекты (сущности), информацию о которых нужно хранить в системе. Обычно их выражают существительными: «Клиент», «Товар», «Заказ», «Врач», «Пациент».

На этом этапе не стремитесь сразу всё отфильтровать — запишите всё, что приходит в голову, а потом уберите дубликаты.

Шаг 3. Определите атрибуты для каждой сущности

Для каждой сущности перечислите характеристики (свойства). Например, для сущности «Сотрудник»:

• Табельный номер (уникальный идентификатор).
• Фамилия, Имя, Отчество.
• Дата рождения.
• Должность.
• Дата приёма на работу.

Выделите ключевой атрибут (первичный ключ) — тот, который уникально идентифицирует каждый экземпляр сущности (например, Табельный номер). Первичный ключ таблицы не допускает значений NULL или дубликатов.

Шаг 4. Установите связи между сущностями

Определите, как сущности взаимодействуют друг с другом. Для каждой пары сущностей задайте вопросы:

• Связаны ли они?
• Какая связь по типу: 1:1, 1:N или N:M?
• Связь обязательная или необязательная?

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

Пример: «Один Клиент может сделать много Заказов» → связь 1:N от Клиента к Заказу.

Шаг 5. Нарисуйте диаграмму в выбранной нотации

Выберите нотацию под аудиторию и цель:

• Нотация Чена — для согласования с заказчиком (сущности — прямоугольники, атрибуты — овалы, связи — ромбы).
• Нотация «Воронья лапка» (Crow's Foot) — для логического моделирования (атрибуты внутри сущности, компактная запись).
• IDEF1X — для работы в CASE-средствах (ERwin, Design/IDEF).

На этом шаге используйте любой инструмент: бумагу и карандаш, специализированное ПО или даже Word/Excel для простых схем.

Шаг 6. Проверьте модель на избыточность

Готовую ER-модель нужно проверить на нормализацию: отсутствие дублей и лишних сущностей. Убедитесь, что:

• каждая сущность действительно нужна;
• атрибуты привязаны к правильной сущности;
• нет дублирования данных (можно применить принципы нормализации);
• связи корректно отражают бизнес-логику.

Пример проверки: Атрибут «Название отдела» не должен храниться у каждого Сотрудника — лучше создать отдельную сущность «Отдел» и связать её с Сотрудником.

Шаг 7. Перейдите к следующему уровню (если нужно)

Если диаграмма создавалась как концептуальная для заказчика — завершайте. Если нужна логическая или физическая модель:

• Логическая модель: добавьте типы данных для атрибутов, уточните первичные и внешние ключи.
• Физическая модель: выберите конкретную СУБД, определите точные типы, добавьте индексы и ограничения целостности.

Для более углубленного изучения правил составления ER-диаграммы стоит пройти обучение на платных курсах. На Сравни собраны актуальные предложения, которые помогут не только освоить построение диаграммы разными способами но и полностью погрузиться в профессию «Инженер данных».

На какие платные курсы стоит обратить внимание:

Курс «Аналитик данных: расширенный курс» от Нетология

Школа	Нетология
Стоимость	142 100 руб
Цена в рассрочку	4 387 руб/мес
Длительность курса
Программа трудоустройства	Есть
Формат	Запись лекций, Онлайн занятия с преподавателем

Курс «Data Scientist с нуля до Junior» от Skillbox

Школа	Skillbox
Стоимость	69 818 руб
Цена в рассрочку	2 494 руб/мес
Длительность курса
Программа трудоустройства	Есть
Формат	Запись лекций

Курс «Аналитик данных + ИИ» от Эдюсон

Школа	Эдюсон
Стоимость	80 900 руб
Цена в рассрочку	3 370 руб/мес
Длительность курса
Программа трудоустройства	Есть
Формат	Запись лекций

FAQ

Что такое ER-диаграмма?

Это схема, которая показывает, какие данные хранит система и как эти данные связаны друг с другом. На диаграмме вы видите сущности (прямоугольники), их атрибуты (овалы) и связи между ними (ромбы) — так вы быстро понимаете структуру базы данных без чтения сложного кода.

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

Питер Чен предложил ER-модель в 1976 году. Его статья была впервые опубликована в журнале ACM Transactions on Database Systems. С тех пор модель стала стандартом для проектирования реляционных баз данных.

Чем отличаются нотация Чена и нотация Мартина?

В нотации Чена сущности — это прямоугольники, атрибуты — овалы, связи — ромбы; она отлично подходит для обсуждения с заказчиком. Нотация Мартина (Crow's Foot) компактнее: атрибуты пишут прямо внутри сущности, а на конце линий рисуют «воронью лапку» для обозначения связей «многие».

Что будет, если построить ER-диаграмму без проверки на нормализацию?

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

Кому нужна ER-диаграмма, а в каких случаях она не подходит?

ER-диаграммы применяются для проектирования БД, отладки БД, информационных систем, реорганизации бизнес-процессов, образования и исследований. Однако эта модель не подходит для нереляционных и неструктурированных данных — например, для документных NoSQL-хранилищ или графовых баз она даст только общее представление.

Где можно научиться строить ER-диаграммы?

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

Итог

• ER-диаграмма — это графический способ описания структуры данных, состоящий из сущностей, их атрибутов и связей между ними.
• Питер Чен предложил эту модель в 1976 году, и она остаётся стандартом для концептуального и логического проектирования реляционных баз данных.
• Модель широко применяется при разработке информационных систем, отладке БД и реорганизации бизнес-процессов.
• Чтобы освоить этот инструмент с нуля и научиться применять его на практике, изучите профильные курсы по проектированию баз данных на Сравни.