Нормализация (нормальные формы) в реляционной модели данных.

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

Цели

• Повышение производительности
• Повышение удобства управления данными

Избыточность данных — когда одни и те же данные хранятся в нескольких местах базы данных.

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

Нормальная форма базы данных — набор правил и критериев, которым должна соответствовать база данных.

---

UNF (Ненормальная форма, нулевая нормальная форма)

Перед приведением БД к нормальной форме нужно привести её к табличному виду, чтобы он соответствовал базовым принципам реляционной теории:

• строки в таблицах не должны быть пронумерованы
• порядок столбцов не имеет значения

Пример таблицы в UNF

BlockID	Area	Operator	Holes	Depths	Explosives	Charges
B1	A1	Op1	H1,H2	10,12	ANFO, Emulsion	50,60

Проблемы:

• В ячейках содержится несколько значений
• Данные дублируются

---

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

Правила 1NF:

• Ячейки таблицы хранят атомарные значения — одно не составное значение в каждой ячейке
• Строки таблицы не должны дублироваться
• Столбцы должны содержать данные одного типа

Пример таблицы в 1NF

BlockID	Area	Operator	HoleID	Depth	Explosive	Charge
B1	A1	Op1	H1	10	Березит	50
B1	A1	Op1	H2	12	Амонит	60

---

2NF (Вторая нормальная форма)

Правила 2NF:

• Таблица должна иметь ключ, по которому можно идентифицировать каждую строку
• Все неключевые столбцы должны зависеть от полного ключа (для составного ключа)
• Выделяем отдельные сущности, чтобы убрать дублирование данных и частичные зависимости

Примеры таблиц в 2NF

BlastBlock

BlockID	AreaID	OperatorID
B1	A1	O1

Area

AreaID	AreaName
A1	Pit-1

Operator

OperatorID	OperatorName
O1	Опер главный

BlastHole

HoleID	BlockID	Depth
H1	B1	10
H2	B1	12

Charging

HoleID	ExplosiveID	Charge
H1	E1	50
H2	E2	60

ExpAgent

ExplosiveID	ExplosiveName
E1	Березит
E2	Амонит

---

3NF (Третья нормальная форма)

Правила 3NF:

• Нет транзитивных зависимостей
  (одно поле не зависит от другого неключевого поля)

Примеры в наших таблицах:

• AreaName зависит только от AreaID
• OperatorName зависит только от OperatorID
• ExplosiveName зависит только от ExplosiveID

---

BCNF (Нормальная форма Бойса–Кодда)

Правила BCNF:

• Любой детерминант (столбец или комбинация столбцов, от которых что-то зависит) должен быть кандидатом в ключ

То есть, не должно быть зависимостей, где неключевой столбец определяет другой столбец.