Этапы нормализации. 1НФ

За время развития технологии проектирования реляционных БД были выделены следующие нормальные формы:

- первая нормальная форма (1NF);

- вторая нормальная форма (2NF);

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

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

- четвертая нормальная форма (4NF);

- пятая нормальная форма, или нормальная форма проекции-соединения (5NF).

Обычно на практике применение находят только первые три нормальные формы.

Отношение в 1 НФ должны отвечать таким требованиям:

? все атрибуты отношения должны быть атомарными, т.е. неделимыми;

? все строки таблицы должны быть одинаковой структуры, т.е. иметь одно и то же количество атрибутов с совпадающими именами;

? имена столбцов должны быть разными, а значения однородными (иметь одинаковый формат);

? порядок строк в таблице несущественный.

Каждое отношение БД содержит как структурную, так и семантическую информацию. Структурная информация задается схемой отношения, а семантическая выражает функциональные связи между атрибутами.

25. Этапы нормализации. 2НФ.

При выполнении условий 2НФ из универсальной таблицы выделяем новые таблицы. Столбец (домен) «Поставщик» выделяем в отдельную таблицу. Таблица, состоящая из одного столбца, существует только теоретически, нет практической необходимости создавать такие таблицы. На практике, кроме наименования

поставщика, нужны и другие сведения о поставщике, например, юридический и физический адрес; телефон; фамилия, имя и отчество директора (главного бухгалтера, менеджеров) и т. д. Первичным ключом для таблицы «Поставщик» можно назначить поле «Поставщик». Аналогичные рассуждения можно выполнить и для остальных столбцов (доменов), содержащих повторяющиеся значения. После того как из универсальной таблицы выделены все необходимые таблицы и определены первичные ключи (простые или сложные) во всех таблицах, имеет смысл в каждую таблицу добавить поле целочисленного типа «№ п. п.» (Номер по порядку) и назначить его первичным ключом, тем самым сократить объем памяти, занимаемый на диске индексами (индексными файлами).
Замену первичных ключей (простых и сложных), созданных по полям символьного типа, на простые первичные ключи целочисленного типа следует производить после выполнения пяти нормальных форм.
В исходной универсальной таблице вместо удаленных столбцов (доменов) добавляем поля целочисленного типа — поля внешних ключей для связи с выделенными таблицами (таблица 1).

В простейшем случае вышеперечисленные домены выделяют в отдельные таблицы, добавив в каждую из таблиц по одному столбцу (домену) — порядковому номеру записи, который и будет первичным ключом. Такой подход имеет право на существование, но не во всех случаях оправдан. Например, имеет ли смысл для домена «Дата поставки» создавать новую таблицу? Нет, не имеет, так как на одну и ту же дату могут быть поставки разных товаров от одного поставщика (в том числе и по разным накладным), так и поставки товаров от разных поставщиков.

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