✍️ Нормально делай — нормально будет: пост о нормализации БД

Наверное, как бы качественно и продумана ни была бы БД на старте проекта (на этапе Proof of Concept или MVP), если продукт развивается, если добавляются новые фичи, логика, бизнес-процессы и т.д., то скорее всего рано или поздно все-таки потребуется что-то в имеющейся модели данных перестроить. 👷 Один из способов реорганизации БД называется нормализацией. Собственно, вот и у меня сейчас есть потребность в нормализации некоторых таблиц в БД, что привело к идее поста. 🥺 Кстати, одну таблицу при этом придется денормализовать, так как выделенная в рамках таблицы сущность является излишней с точки зрения бизнес-объекта. 💥 Да, и такое бывает.

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

Причины задумываться о нормализации (из тех, что наблюдаю конкретно я):
➡️Появляются требования к неизменности исторических данных (например, данные о заполненности парковки в разные моменты времени);
➡️Одинаковые данные приходится обновлять в куче полей;
➡️В систему вводятся сложные бизнес-правила, которые трудно реализовать в текущей структуре.

По канону есть три фазы нормализации (вспомню свое ERP-прошлое, поэтому разберу на примере с заказами на поставку):
1️⃣ Первая нормальная форма (1NF)
Цель: Убрать повторяющиеся группы и сделать все значения атомарными.
Действие: Если в заказе может быть несколько товаров, их нужно вынести в отдельную таблицу.

CREATE TABLE orders (order_id INT PRIMARY KEY, customer_name VARCHAR, customer_phone INT, order_date DATE);
CREATE TABLE items (item_id INT PRIMARY KEY, order_id INT NOT NULL, product_name VARCHAR, product_price NUMERIC(10, 2), FOREIGN KEY (order_id) REFERENCES orders(order_id));

2️⃣ Вторая нормальная форма (2NF)
Цель: Устранить зависимость неключевых полей только от части составного ключа.
Проблема: Цена и название товара в items зависят только от product_name, а не от всей пары (order_id, product_name).
Действие: Создаём справочник товаров.

CREATE TABLE products (product_id INT PRIMARY KEY, product_name VARCHAR NOT NULL, price NUMERIC(10, 2));
CREATE TABLE items (item_id INT PRIMARY KEY, order_id INT NOT NULL, product_id INT NOT NULL, price_at_order NUMERIC(10, 2), FOREIGN KEY (order_id) REFERENCES orders(order_id));

3️⃣ Третья нормальная форма (3NF)
Цель: Убрать транзитивные зависимости, когда поле зависит не от первичного ключа, а от другого поля.
Проблема: Телефон клиента в таблице orders зависит от его имени, а не напрямую от order_id.
Действие: Выносим данные о клиенте в отдельную сущность.

CREATE TABLE customers (customer_id INT PRIMARY KEY, name VARCHAR NOT NULL, phone INT);
CREATE TABLE orders (order_id INT PRIMARY KEY, customer_id INT NOT NULL, order_date DATE NOT NULL, FOREIGN KEY (customer_id) REFERENCES customers(customer_id));

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

P.S. Во время подготовки поста ни одно дерево не пострадало я пользовался прикольным SQL-валидатором, чтобы чекать, что у меня не совсем дичь в запросах написана (может, кому тоже пригодится): SQL-Validator.

#SystemAnalysis #БазыДанных #Нормализация #SQL #DataModeling #postgresql #erd #системныйанализ