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

Question

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

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

Ответ

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

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

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

Первая нормальная форма (1NF)

Все значения атрибутов атомарны (неделимы).

В таблице нет повторяющихся групп или массивов.

-- Ненормализованная таблица (нарушает 1NF)
CREATE TABLE Orders (
OrderID INT PRIMARY KEY,
CustomerName VARCHAR(100),
Products VARCHAR(255) -- Список товаров через запятую: 'Монитор,Клавиатура,Мышь'
);

-- Приведение к 1NF
CREATE TABLE Orders (
OrderID INT,
CustomerName VARCHAR(100)
);
CREATE TABLE OrderItems (
OrderItemID INT PRIMARY KEY,
OrderID INT,
ProductName VARCHAR(100) -- Один товар на строку
);

Вторая нормальная форма (2NF)
- Таблица должна находиться в 1NF.
- Все неключевые атрибуты должны полностью зависеть от всего первичного ключа (устраняются частичные зависимости). Это критично для таблиц с составными первичными ключами.
- Пример нарушения: В таблице OrderDetails(OrderID, ProductID, ProductName, Quantity) атрибут ProductName зависит только от ProductID, а не от всей пары (OrderID, ProductID).
Третья нормальная форма (3NF)
- Таблица должна находиться в 2NF.
- Нет транзитивных зависимостей: неключевые атрибуты не должны зависеть от других неключевых атрибутов, а только от первичного ключа.
- Пример нарушения: В таблице Employees(EmpID, DeptID, DeptLocation) атрибут DeptLocation зависит от DeptID, который сам не является ключом.

Практический баланс

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

Ответ 18+ 🔞

А, нормализация, говоришь? Ну, это такая классика, как "Муму" Тургенева, только про базы данных. Сейчас объясню, но без соплей.

Представь, что у тебя есть таблица, где ты хранишь заказы. И ты, такой умный, решил запихнуть все товары из заказа в одну ячейку, через запятую. Типа, "Монитор, Клавиатура, Мышь". Ну, и кто ты после этого? Распиздяй, вот кто. Это ж нарушение первой нормальной формы, мать её! Как Герасим немой, только ты ещё и глухой к здравому смыслу. Данные должны быть атомарными, неделимыми! Один товар — одна строка, ебать колотить. Не хочешь потом голову ломать, выковыривая эти "мыши" из строки.

-- Так делать — это пиздец как неправильно. Это как серить на крыше.
CREATE TABLE Orders (
    OrderID INT PRIMARY KEY,
    Products VARCHAR(255) -- 'Монитор,Клавиатура,Мышь' — НЕТ, БЛЯДЬ!
);

-- А вот так — уже красиво и по-человечески. 1NF, всё чинно.
CREATE TABLE OrderItems (
    OrderItemID INT PRIMARY KEY,
    OrderID INT,
    ProductName VARCHAR(100) -- Одна строка — один продукт. Красота.
);

Дальше идёт вторая форма. Тут всё просто: если у тебя ключ составной (из нескольких полей), то все остальные поля должны зависеть от ВСЕГО этого ключа, а не кусочками. Представь, что в заказе (OrderID, ProductID) ты ещё и имя продукта (ProductName) хранишь. А имя-то от чего зависит? Только от ProductID! Это частичная зависимость, ёпта. Выноси это отдельно, в таблицу товаров, не будь жлобом.

Третья нормальная форма — это вообще про то, чтобы не делать транзитивных зависимостей. Это когда у тебя в таблице сотрудников есть отдел (DeptID) и, допустим, адрес этого отдела (DeptLocation). А адрес-то зависит не от сотрудника, а от отдела! Это зависимость через третье лицо, как в дурном анекдоте. Выноси отделы в свою таблицу, и будет тебе счастье. Иначе обновишь адрес в одной строке, а в двадцати других он старый останется — вот тебе и аномалия обновления, пиздец полный.

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

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