Перейти на PRO

Что такое нормальная форма в теории баз данных?

Тип вопроса: Базы данных Вероятность: 25% Категория: C/C++ Разработчик

Ответ

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

Основные нормальные формы:

  1. Первая нормальная форма (1НФ):

    • Все значения атрибутов атомарны (неделимы).
    • В таблице нет повторяющихся групп или массивов. 
      
-- Ненормализованная таблица (нарушает 1НФ)
CREATE TABLE Orders (
order_id INT PRIMARY KEY,
customer_name VARCHAR(100),
items VARCHAR(500) -- Список товаров через запятую: 'Монитор,Клавиатура,Мышь'
);

    -- 1НФ: Каждый товар в отдельной строке CREATE TABLE OrderItems ( order_id INT, item_name VARCHAR(100), FOREIGN KEY (order_id) REFERENCES Orders(order_id) );

  2. Вторая нормальная форма (2НФ):

    • Таблица должна находиться в 1НФ.
    • Все неключевые атрибуты полностью зависят от всего составного первичного ключа (нет частичных зависимостей).
    • Актуально для таблиц с составными первичными ключами.

  3. Третья нормальная форма (3НФ):

    • Таблица должна находиться в 2НФ.
    • Нет транзитивных зависимостей: неключевые атрибуты не должны зависеть от других неключевых атрибутов, а только от первичного ключа. 
      
-- Нарушает 3НФ: customer_city зависит от customer_id, а не от order_id.
CREATE TABLE Orders (
order_id INT PRIMARY KEY,
customer_id INT,
customer_city VARCHAR(50), -- Транзитивная зависимость!
total_amount DECIMAL
);

    -- 3НФ: Выносим информацию о клиенте в отдельную таблицу. CREATE TABLE Customers ( customer_id INT PRIMARY KEY, city VARCHAR(50) ); CREATE TABLE Orders ( order_id INT PRIMARY KEY, customer_id INT, total_amount DECIMAL, FOREIGN KEY (customer_id) REFERENCES Customers(customer_id) );

  4. Нормальная форма Бойса-Кодда (BCNF):

    • Усиленная 3НФ. Каждая детерминанта (атрибут, от которого функционально зависит другой) должен быть потенциальным ключом.

На практике проектирование часто останавливается на 3НФ или BCNF, так как дальнейшая нормализация (4НФ, 5НФ) решает более специфичные проблемы и может чрезмерно усложнить схему, увеличив количество JOIN-операций.

Ответ 18+ 🔞

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

Зачем это всё, ёпта? Чтобы не было этих ебанутых аномалий. Сидишь ты, такой, обновляешь адрес клиента в одном заказе, а в других десяти он остаётся старый — вот тебе и аномалия обновления, хитрая жопа. Или удалил последний заказ с товаром «Граната Ф-1», и информация о самой гранате из каталога нахуй пропала — аномалия удаления. Нормализация такие фокусы пресекает.

Итак, поехали по формам:

  1. Первая нормальная форма (1НФ): Без этой хуйни — никуда.

    • Правило простое, как три рубля: все значения в ячейках должны быть атомарными, то есть неделимыми. Никаких списков через запятую, массивов и прочей херни.
    • Нарушаем, как последние распиздяи: 
      CREATE TABLE Заказы (
    id_заказа INT PRIMARY KEY,
    имя_клиента VARCHAR(100),
    товары VARCHAR(500) -- Вот тут пиздец: 'Граната,Огнетушитель,Балончик'
);

      Попробуй тут найти, сколько балончиков заказали. Доверия ебать ноль к такой структуре.

    • Делаем по-человечески (1НФ): 
      CREATE TABLE ПозицииЗаказа (
    id_заказа INT,
    название_товара VARCHAR(100),
    FOREIGN KEY (id_заказа) REFERENCES Заказы(id_заказа)
);

      Каждый товар — в своей отдельной строке. Уже легче дышать.

  2. Вторая нормальная форма (2НФ): Для умных таблиц с составными ключами.

    • Сначала должна быть 1НФ, это само собой.
    • Суть: если у тебя ключ составной (из нескольких полей), то все остальные поля должны зависеть от ВСЕГО этого ключа, а не от его кусочка. Убрать частичные зависимости — вот наша цель.
    • Актуально, когда ключ, например, (id_заказа, id_товара). Если в этой же таблице будет поле имя_поставщика, которое зависит только от id_товара, то это нарушение. Выноси поставщика в отдельную таблицу к товарам!

  3. Третья нормальная форма (3НФ): Главный калибр против дурости.

    • Должна быть 2НФ.
    • Золотое правило: неключевые поля зависят ТОЛЬКО от первичного ключа. Никаких транзитивных зависимостей — когда поле А зависит от ключа, а поле Б зависит от поля А.
    • Классический косяк: 
      CREATE TABLE Заказы (
    id_заказа INT PRIMARY KEY,
    id_клиента INT,
    город_клиента VARCHAR(50), -- Вот она, засада! Город зависит не от ключа заказа, а от id_клиента.
    сумма DECIMAL
);

      Один клиент в 100 заказах, и город дублируется овердохуища раз. Поменял он город — и обновляй все 100 записей. Терпения ноль ебать на такое.

    • Делаем красиво (3НФ): 
      CREATE TABLE Клиенты (
    id_клиента INT PRIMARY KEY,
    город VARCHAR(50)
);
CREATE TABLE Заказы (
    id_заказа INT PRIMARY KEY,
    id_клиента INT,
    сумма DECIMAL,
    FOREIGN KEY (id_клиента) REFERENCES Клиенты(id_клиента)
);

      Теперь город живёт в одном-единственном месте. Идиллическая картина.

  4. Нормальная форма Бойса-Кодда (BCNF): Для перфекционистов.

    • Это как 3НФ, но на стероидах. Если очень грубо: любое поле, от которого что-то зависит, само должно быть ключом (или его частью). Ловит более хитрые зависимости, которые 3НФ пропускает.

Итог, чувак: В 99% случаев жизнь прекрасна на уровне 3НФ. Дальше гнаться — это уже для академических споров или очень специфичных случаев. Чрезмерная нормализация — тоже зло: таблиц станет как говна за баней, и чтобы что-то выбрать, придётся делать хуй в пальто из JOIN'ов. Баланс, блядь, везде нужен баланс. Сделал 3НФ — и спи спокойно.

© ХакСобесов, 2026
support@hacksobesov.com