Условие

Какие основные этапы проектирования базы данных существуют? Что входит в каждый этап?

Решение

Три уровня

Концептуальное → Логическое → Физическое

Этап	Что делается	Артефакт
Концептуальное	Анализ предметной области, выделение сущностей и связей. Без привязки к СУБД	ER-диаграмма
Логическое	Преобразование ER в реляционную схему: таблицы, ключи, атрибуты, нормализация до 3NF/BCNF	Логическая модель (схема таблиц)
Физическое	Реализация в конкретной СУБД: типы данных, индексы, партиционирование, tablespaces	DDL-скрипты

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

Цель: описать предметную область на языке бизнеса. Не думать о СУБД.

ER-модель состоит из:

Сущности (Entity) — объекты бизнеса (Клиент, Заказ, Товар).
Атрибуты — свойства сущностей (имя, дата).
Ключевые атрибуты — уникальные идентификаторы.
Связи (Relationships) — между сущностями: 1:1, 1:M, M:M.

Логическое

ER → реляционная схема:

Каждая сущность → таблица.
Связь M:M → промежуточная таблица.
Атрибут → колонка.
Ключ → PRIMARY KEY.
Нормализация до 3NF (или 2NF, если есть веские причины оставить в 2NF).

-- Логическая модель — ещё без типов конкретной СУБД
clients(id, name, email)
orders(id, client_id → clients.id, total, created_at)

Физическое

Решения для конкретной СУБД:

Типы (BIGINT vs INT vs NUMERIC).
Индексы (B-tree, GIN, hash, BRIN).
Партиционирование (по дате, по hash).
Tablespace, диски.
Кодировка, collation.
DDL-скрипты, миграции.

CREATE TABLE clients (
  id     BIGSERIAL PRIMARY KEY,
  name   TEXT NOT NULL,
  email  TEXT UNIQUE
) WITH (fillfactor = 90);
 
CREATE INDEX idx_clients_email ON clients(email);

Что НЕ входит в физическое проектирование

Определение предметной области (концептуальное).
Построение ER-модели (концептуальное).
Решение, какие сущности существуют (концептуальное).

Зачем разделять этапы

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

Подводные камни

Перескок через этап — без концептуальной модели команды не понимают друг друга.
Чистая теория vs практика — в реальности этапы переплетаются: иногда физические ограничения заставляют переписывать логическую модель.
«ER-диаграмма» в Crow's foot vs Chen — оба валидны, выбирайте один в команде.
Денормализация делается на физическом уровне, осознанно.

Эталонный ответ

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

Этапы проектирования базы данных: концептуальное → логическое → физическое