4.15. Резюме. Нормальные формы.

Нормализация – разбиение таблицы на несколько, обладающих лучшими свойствами обновления, включения, удаления. Нормализация – процесс последовательной замены таблицы ее полными декомпозициями пока все они не будут находиться в 5НФ. На практике цель – НФБК.

1НФ  ни одна из ее строк ни в одном столбце не содержит > 1 значения; ключевые поля IS NOT NULL.

2НФ  1НФ; все ее не ключевые поля (не входящие в PK) функционально полно зависят от PK.

5НФ  В каждой полной декомпозиции таблицы все проекции содержат возможный ключ. Таблица, не имеющая ни одной полной декомпозиции тоже в 5НФ.

4НФ – частный случай 5НФ когда полная декомпозиция есть соединение ровно 2 проекций.

Важно, чтобы единственными функциональными зависимостями в любой таблице были PK -> F. Никаких других ФЗ! Цель нормализации – чтобы не было никаких других ФЗ.

“Таблица содержит свойства ключей, свойства всех ключей, ничего кроме свойств ключей”

Случаи в которых требуется нормализация:

1. T = <K1, K2, F> PK(K1,K2) K2->F

Надо T1 <K1,K2> PK(K1,K2)

T2 <K2,F> PK(K2)

2. T = <K, F1, F2> PK(K) F1->F2

Надо T1 <K, F1> PK(K)

T2 <F1, F2> PK(F1)

Пример: переход от рис.2 к рис.5

Рис.2:

PK: Товар, ДатаПрод, Поставщик, Город, ДатаП

Свойства: НДС, Расход, Страна, Вес (кг), Цена

Выявление полей, функционально зависимых от части составного ключа:

Исходное состояние	Результирующее состояние	Рис на котором представлен результат, случай.
Товар –> НДС.	Товары (Товар, НДС)	Рис.3 I случай.
Товар, ДатаПрод -> Расход	Расход (Товар, ДатаПрод, Расход)	Рис.3Q I случай.
Товар, поставщик, ДатаП -> Вес, Цена	Поставки (Товар, Поставщик, ДатаП, Вес, Цена)	Рис.3 I случай.
Поставщик, Город -> Страна	Поставщики (Поставщик, Город, Страна)	Рис.3 I случай.
Город -> Страна	Города (Город, Страна)	Рис.5 I случай.
Поставщик – Город	Поставщики (Поставщик, Город)	Рис.5 II случай.

5. Инфологическое моделирование.

Инфологическое моделирование предназначено для понимания того, что содержится в базе данных, всеми участниками проекта по созданию приложения, в основе которого лежит база данных. Иными словами, инфологическая модель призвана отражать реальный мир в множество понятных человеку концепций, независимых от особенностей реализации системы в конкретной СУБД. Для такого моделирования принято использовать совокупность диаграмм, предложенных Ченом, называемых “модель сущность-связь”. Другое название использует английскую аббревиатуру: ER-диаграмма (Entity-Relation). Впоследствии инфологическая модель должна быть отображена в даталогическую (или, иными словами, в физическую) модель, понятную конкретной СУБД. Существуют и способы автоматического перевода модели “сущность-связь” в физическую модель (реляционную базу данных). Для этой цели служит целый класс программных продуктов, называемый CASE (Computer Aided Software Engineering).