Ответ
Третья нормальная форма (3NF) — это правило проектирования реляционных баз данных, направленное на устранение транзитивных зависимостей и избыточности данных. Таблица находится в 3NF, если:
- Она находится во второй нормальной форме (2NF) (нет частичных зависимостей неключевых атрибутов от составного ключа).
- Все неключевые атрибуты зависят ТОЛЬКО от первичного ключа, а не друг от друга (нет транзитивных зависимостей).
Пример нарушения 3NF:
В таблице Заказы атрибут ИмяЗаказчика зависит не от первичного ключа ID_Заказа, а от другого неключевого атрибута ID_Клиента.
-- НЕ в 3NF
CREATE TABLE Orders (
OrderID INT PRIMARY KEY,
CustomerID INT,
CustomerName VARCHAR(100), -- Зависит от CustomerID, а не от OrderID!
OrderDate DATE
);
-- Проблема: при смене имени клиента нужно обновлять все его заказы.Исправление (приведение к 3NF): Необходимо вынести транзитивно зависимые атрибуты в отдельную таблицу.
-- Таблица Customers (отдельная сущность)
CREATE TABLE Customers (
CustomerID INT PRIMARY KEY,
CustomerName VARCHAR(100) NOT NULL
);
-- Таблица Orders (ссылается на Customers)
CREATE TABLE Orders (
OrderID INT PRIMARY KEY,
CustomerID INT NOT NULL,
OrderDate DATE NOT NULL,
FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
);Преимущества 3NF:
- Устранение аномалий обновления: Имя клиента хранится в одном месте.
- Сокращение избыточности: Данные не дублируются.
- Упрощение поддержки: Структура становится более логичной и гибкой.
Ответ 18+ 🔞
Ну, вот смотри, нормальные формы — это как правила гигиены для базы данных. Если их не соблюдать, потом в этой каше нихуя не найдешь и обновишь что-то не там, где надо. Третья нормальная форма (3NF) — это когда ты уже не просто убрал мусор из-под кровати, а разложил всё по полочкам с умом.
Если по-простому, то таблица в 3NF, когда:
- Она уже во второй нормальной форме (2NF). То есть, если ключ составной, то все остальные поля зависят от него целиком, а не от какой-то одной его части. Это как если бы в ведомости зарплата зависела не только от отдела, но и от твоей личной должности — логично же.
- Все неключевые поля зависят ТОЛЬКО от первичного ключа, а не друг от друга. Вот это, блядь, самое важное! Убираем эти ебучіе транзитивные зависимости.
Пример, где всё пошло по пизде:
Допустим, есть таблица Заказы. И в неё, как дурак, засунули имя клиента.
-- Это пиздец, а не дизайн (НЕ 3NF)
CREATE TABLE Orders (
OrderID INT PRIMARY KEY, -- Номер заказа, ключ
CustomerID INT, -- Номер клиента
CustomerName VARCHAR(100), -- Имя клиента. Вот она, засада!
OrderDate DATE
);В чём косяк? Поле CustomerName зависит не от первичного ключа OrderID, а от другого поля — CustomerID. Это и есть транзитивная зависимость, ёпта. Представь: у клиента Петрова поменялось имя на Сидорова. И теперь тебе надо бегать и обновлять его имя в каждой его старой записи заказа, а не в одном месте. Один ебучий UPDATE на сотни записей! Мало того, что избыточно, так ещё и аномалии обновления — жуть.
Как привести в божеский вид (к 3NF): Надо просто не быть жлобом и вынести данные о клиенте в отдельную таблицу. Разделяй и властвуй, как говорится.
-- Таблица Клиентов. Всё про клиента — здесь, в одном месте.
CREATE TABLE Customers (
CustomerID INT PRIMARY KEY,
CustomerName VARCHAR(100) NOT NULL
);
-- Таблица Заказов. Только факты о заказе и ссылка на клиента.
CREATE TABLE Orders (
OrderID INT PRIMARY KEY,
CustomerID INT NOT NULL, -- Ссылаемся на клиента
OrderDate DATE NOT NULL,
FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID) -- Связь
);Что мы выиграли, сделав так:
- Нет аномалий обновления: Имя клиента меняешь ОДИН РАЗ в таблице
Customers, и оно автоматом актуально для всех его заказов. Вообще пиздец как удобно. - Данные не дублируются: Не нужно тащить имя клиента в каждую запись заказа. Экономия места, пусть и не всегда овердохуичная, но приятно.
- Структура логичная: Клиенты — отдельно, заказы — отдельно. База не превращается в свалку, где всё перемешано. Поддерживать такую — одно удовольствие, а не ебля с граблями.
Короче, 3NF — это не прихоть, а здравый смысл, облитый бетоном правил. Делаешь так — и живешь спокойно, не боясь, что твоя база данных рассыпется от одного неловкого запроса.
