Концептуальное, логическое и физическое ERD: глубокий взгляд на моделирование данных

ERD (Entity-Relationship Diagram, диаграмма «сущность‑связь») — это графическая модель данных: она показывает сущности предметной области, их атрибуты и связи между ними. В проектировании баз данных ERD-диаграмму строят на трёх уровнях детализации — концептуальном, логическом и физическом. В статье разберём каждый уровень, типы связей, основные нотации (Чена, Crow’s Foot) и инструменты для моделирования.

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

По данным mysql.com.

Модель «сущность‑связь» предложил Питер Чен в 1976 году, и с тех пор она остаётся стандартным языком проектирования реляционных баз данных. Любая ERD состоит из трёх элементов:

• Сущности (Entities) — классы объектов, о которых система хранит данные: «Студент», «Курс», «Заказ». На диаграмме сущность изображается прямоугольником, а в базе данных превращается в таблицу.
• Атрибуты (Attributes) — свойства сущности: имя, дата рождения, номер зачётки. Особый атрибут — ключ, который однозначно идентифицирует экземпляр сущности.
• Связи (Relationships) — отношения между сущностями: «Студент учится на Курсе», «Преподаватель ведёт Курс».

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

ОНЛАЙН-ПРАКТИКУМ

ЗАПУСК нейросети DEEPSEEK R1 ЛОКАЛЬНО НА СВОЕМ КОМПЬЮТЕРЕ

ЧТО БУДЕТ НА ОБУЧЕНИИ?

• ПОКАЖЕМ, КАК РАЗВЕРНУТЬ МОДЕЛЬ нейросети DEEPSEEK R1 ПРЯМО НА СВОЁМ КОМПЬЮТЕРЕ
• Где и как применять? Потестируем модель после установки на разных задачах
• Как дообучить модель под себя?

Участвовать бесплатно

Типы связей и кардинальность

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

• Один к одному (1:1) — у студента один студенческий билет, у билета один владелец.
• Один ко многим (1:N) — преподаватель ведёт несколько курсов, но у каждого курса один ответственный преподаватель.
• Многие ко многим (M:N) — студент записан на несколько курсов, и на каждом курсе учится много студентов. В реляционной базе такая связь напрямую не реализуется: её разбивают на две связи 1:N через промежуточную таблицу — например, «Запись на курс».

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

Нотации ERD

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

Нотация Чена

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

Crow’s Foot — «воронья лапка» (нотация Мартина)

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

IDEF1X и нотация Баркера

IDEF1X исторически распространена в госпроектах и крупных корпоративных системах — у неё строгие правила для зависимых сущностей. Нотация Баркера знакома тем, кто работал с инструментами Oracle. Если в проекте нет жёстких требований к стандарту, для рабочих моделей обычно берут Crow’s Foot.

Концептуальное ERD

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

Структура

• Сущности (Entities): определение основных объектов данных.
• Связи (Relationships): описание взаимодействия между сущностями.
• Атрибуты (Attributes): ключевые характеристики сущностей — без полного перечня и типов.

Пример

Сущности: Студент, Курс, Преподаватель.

Связи: Студент учится на Курсе, Преподаватель ведёт Курс.

Атрибуты: Имя, Номер студента, Название курса, Должность преподавателя.

Логическое ERD

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

Структура

• Таблицы (Tables): соответствуют сущностям из концептуального ERD.
• Отношения (Relationships): связи между таблицами через внешние ключи.
• Ключи (Keys): первичные (Primary Key) идентифицируют записи, внешние (Foreign Key) реализуют связи.

Пример

Таблицы: Students, Courses, Instructors, Enrollments (промежуточная — для связи M:N студентов и курсов).

Отношения: Students 1:N Enrollments, Courses 1:N Enrollments, Instructors 1:N Courses.

Ключи: student_id, course_id, instructor_id; в Enrollments — пара внешних ключей (student_id, course_id).

Физическое ERD

Переводит логическую модель в спецификации конкретной базы данных — PostgreSQL, MySQL, SQL Server. Здесь определяются типы данных, индексы, ограничения целостности и другие технические детали; по физической модели генерируется DDL-скрипт (CREATE TABLE и сопутствующие команды).

Структура

• Типы данных и ограничения: как именно данные будут храниться в выбранной СУБД.
• Индексы (Indexes): ускоряют выборки по частым условиям запросов.
• Триггеры (Triggers): автоматизируют реакцию на изменения данных.

Пример

Типы данных: VARCHAR(100), INT, DATE.

Ограничения: NOT NULL, UNIQUE, FOREIGN KEY с правилом ON DELETE.

Индексы: индекс по фамилии студента, составной индекс в Enrollments.

Триггеры: триггер на обновление оценки студента.

Сравнение трёх уровней ERD

Инструменты для моделирования

• MySQL Workbench — официальный инструмент MySQL для визуального проектирования баз: строит ER-модели, поддерживает forward engineering (генерация базы из модели) и reverse engineering (модель из существующей базы). Доступен на Windows, Linux и macOS.
• Lucidchart — онлайн-редактор диаграмм с готовыми шаблонами ERD и совместной работой; ERD строится в нотации Crow’s Foot.
• draw.io (diagrams.net) — бесплатный редактор с открытым исходным кодом: работает в браузере или как десктоп-приложение, есть набор фигур для ER-диаграмм.
• Microsoft Visio — корпоративный редактор диаграмм из экосистемы Microsoft; поддерживает ERD наряду с другими типами схем и интегрируется с источниками данных.

Если база нужна без программирования, посмотрите обзор no-code-конструктора Wappler — там визуальная схема данных сразу превращается в рабочий бэкенд. А DDL-скрипт по готовой логической модели быстрее написать с ИИ-ассистентом: подборка — в обзоре нейросетей для генерации и анализа кода, а если работаете в терминале — в разборе Claude Code в России.

Процесс создания ERD

• Определите сущности: выпишите объекты, о которых система должна хранить данные.
• Задайте атрибуты и выберите ключи: чем экземпляры сущности отличаются друг от друга.
• Определите связи и кардинальность: кто с кем связан и в каком соотношении (1:1, 1:N, M:N).
• Постройте логическую модель: разбейте связи M:N, добавьте внешние ключи, нормализуйте таблицы.
• Добавьте технические детали: типы данных, ограничения и индексы под конкретную СУБД.
• Проверьте модель на реальных сценариях: пройдите по типовым запросам системы и убедитесь, что данных хватает и они не дублируются.

ERD и UML: в чём различие

• ERD применяется для проектирования баз данных и фокусируется на сущностях, их атрибутах и взаимосвязях.
• UML — семейство диаграмм для моделирования систем в целом: классы, бизнес-процессы, взаимодействия компонентов. Ближайший аналог ERD в UML — диаграмма классов, но она описывает поведение объектов, а не только структуру хранения.

Частые вопросы

Чем ER-модель отличается от ER-диаграммы?

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

Какую нотацию выбрать?

Для обсуждения с бизнесом — нотацию Чена: она нагляднее. Для рабочих логических и физических моделей — Crow’s Foot: компактнее и поддерживается большинством инструментов. Если в проекте задан стандарт (например, IDEF1X) — следуйте ему.

Можно ли пропустить концептуальный уровень?

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

Чем ERD отличается от схемы базы данных?

Схема базы данных — это фактическая структура в СУБД: таблицы, столбцы, ключи. Физическое ERD — её чертёж: по нему схему создают, а по существующей базе инструменты вроде MySQL Workbench умеют восстанавливать диаграмму (reverse engineering).

Заключение

Концептуальное, логическое и физическое ERD — это один и тот же взгляд на данные с тремя степенями увеличения: от списка сущностей для разговора с бизнесом до DDL-скрипта под конкретную СУБД. Начинайте с крупного плана, детализируйте по мере согласования — и структура базы перестанет быть источником сюрпризов на проде.