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

🏮Сбор и классификация сущностей
Определяется перечень объектов предметной области (сущностей), которые должны быть представлены в модели данных. Эти сущности классифицируются по типу (например, клиенты, товары, заказы)


🏮 Определение отношений между сущностями
Далее устанавливаются связи между выявленными сущностями. Например, один клиент может иметь много заказов, а один заказ может содержать несколько товаров. Связи бывают трёх типов:
- Один-к-одному (1:1)
- Один-ко-многим (1:N)
- Многие-ко-многим (N:M)

🏮 Создание концептуальной модели данных
Концептуальная модель отражает высокоуровневую структуру данных без привязки к конкретной СУБД. Обычно используется нотация ERD (Entity Relationship Diagram). Здесь отражаются сущности, их атрибуты и взаимосвязи.

🏮 Нормализация данных
Нормализация является важным этапом, целью которого является устранение избыточности данных и повышение целостности базы данных. Она заключается в последовательном приведении схемы базы данных к определённым формальным нормам (нормальные формы):

- Первая нормальная форма (1NF): Уничтожение повторяющихся групп.
- Вторая нормальная форма (2NF): Устранение частичной зависимости атрибутов от первичного ключа.
- Третья нормальная форма (3NF): Исключение транзитивной зависимости атрибутов.
- Четвёртая нормальная форма (4NF): Разделение многозначных зависимостей.
- Пятая нормальная форма (5NF): Минимизация аномалий обновления путём разбиения сложных зависимостей.

Этот процесс позволяет минимизировать дублирование данных и повысить производительность запросов.


🏮 Физическое проектирование
На данном этапе разрабатывается физическая структура базы данных, учитывающая особенности выбранной СУБД. Определяются типы полей, индексы, ограничения целостности, триггеры и другие элементы физической структуры.

Примеры решений физического уровня:
- Выбор оптимального типа поля (INT, VARCHAR, DATE и др.)
- Создание уникальных ключей и индексов для ускорения выборок.


🗝 Таким образом мы последовательно приходим к итоговому решению.
Дальше разберем подробно основные шаги.