Ответ
Нормализация — это процесс структурирования реляционной базы данных для уменьшения избыточности данных и улучшения их целостности. Основная цель — разбить большие таблицы на более мелкие и четко определенные, установив между ними связи.
Ключевые цели:
- Устранение избыточности данных: Каждый фрагмент данных хранится только в одном месте, что экономит пространство и упрощает обновление.
- Предотвращение аномалий данных: Исключаются проблемы при вставке, обновлении и удалении данных. Например, при изменении адреса клиента не нужно обновлять его в каждой записи о заказе.
- Обеспечение логической целостности: Данные организованы в логические группы (сущности), что делает схему БД более понятной и простой в обслуживании.
Пример (до и после 1НФ и 2НФ):
До нормализации (одна таблица):
-- Избыточность: имя и адрес клиента повторяются для каждого заказа
-- Аномалия обновления: для смены адреса клиента нужно обновить несколько строк
CREATE TABLE Orders (
order_id INT PRIMARY KEY,
customer_name VARCHAR(100),
customer_address VARCHAR(255),
product_name VARCHAR(100),
quantity INT
);После нормализации:
CREATE TABLE Customers (
customer_id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(100),
address VARCHAR(255)
);
CREATE TABLE Products (
product_id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(100)
);
CREATE TABLE Orders (
order_id INT PRIMARY KEY AUTO_INCREMENT,
customer_id INT,
product_id INT,
quantity INT,
FOREIGN KEY (customer_id) REFERENCES Customers(customer_id),
FOREIGN KEY (product_id) REFERENCES Products(product_id)
);Чаще всего на практике базы данных приводят к третьей нормальной форме (3НФ), так как она обеспечивает хороший баланс между устранением избыточности и сложностью запросов. В некоторых случаях для повышения производительности чтения намеренно применяют денормализацию.
Ответ 18+ 🔞
А, нормализация, ёпта! Ну это когда ты смотришь на свою базу данных, а там один сплошной пиздец и бардак, как в комнате подростка. И ты такой: "Так, блядь, нельзя, сейчас всё по полочкам разложу, а то волосы дыбом встают!"
Зачем это, спрашивается, надо?
- Чтобы не повторяться, как попугай ебучий. Зачем десять раз писать адрес клиента, если можно один раз записать и потом на него тыкать пальцем? Место экономишь и головную боль.
- Чтобы не вышло хуёвой ситуации при обновлении. Представь: клиент сменил адрес. А у тебя он в старых заказах старый, в новых — новый. И кто поймёт, где он живёт на самом деле? Пиздец, а не логика. Нормализация такие фокусы исключает.
- Чтобы всё было логично и по уму. Каждая сущность — в своей таблице. Клиенты — отдельно, товары — отдельно, заказы — отдельно. Красота, а не схема. Сразу видно, кто где и за что отвечает.
Смотри, как было и как стало:
До нормализации (пиздец и срачок):
-- Смотри, какая хуйня: имя и адрес клиента кочуют из заказа в заказ!
-- Захотел клиент переехать — иди, мудак, двадцать строк обновляй вручную.
CREATE TABLE Orders (
order_id INT PRIMARY KEY,
customer_name VARCHAR(100),
customer_address VARCHAR(255),
product_name VARCHAR(100),
quantity INT
);После нормализации (красота и порядок, ёбана):
CREATE TABLE Customers (
customer_id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(100),
address VARCHAR(255)
);
CREATE TABLE Products (
product_id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(100)
);
CREATE TABLE Orders (
order_id INT PRIMARY KEY AUTO_INCREMENT,
customer_id INT,
product_id INT,
quantity INT,
FOREIGN KEY (customer_id) REFERENCES Customers(customer_id),
FOREIGN KEY (product_id) REFERENCES Products(product_id)
);Вот видишь разницу? Теперь адрес клиента живёт в одном-единственном месте. Изменил его раз — и он везде актуальный. Волшебство, блядь!
Обычно гонят базу до третьей нормальной формы (3НФ) — это такой золотой стандарт, когда уже и не стыдно, и работать можно. Но бывает, для скорости чтения (особенно в каких-нибудь отчётах, которые ебут мозг) специально денормализуют — то есть сознательно вносят немного того самого бардака обратно, чтобы запросы летали быстрее. Это как разбросать носки по комнате, чтобы быстрее собраться на работу. Вроде и некрасиво, но иногда овердохуища как эффективно.