2015-04-01
768
На практике достаточно привести таблицы к НФБК.
Процедура приведения таблиц к этой форме основана на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида K->F, где K – первичный ключ, а F – некоторое другое поле. Это следует из определения первичного ключа таблицы, в соответствии с которым K->F всегда имеет место для всех полей данной таблицы. Цель нормализации состоит именно в том, чтобы избавиться от других функциональных зависимостей, т.е. таких, которые имеют иной вид, чем K->F. Рассмотрим два случая:
1. Таблица имеет составной первичный ключ вида (К1, К2) и включает кроме прочих так же поле F, которое функционально зависит от части первичного ключа, например от К2, но не от полного ключа.
В этом случае рекомендуется сформировать другую таблицу, содержащую К2 и F (первичный ключ в ней – К2) и удалить F из первоначальной таблицы.
Заменить T: (К1, К2, F), первичный ключ (К1, К2), функциональная зависимость К2 -> F
на Т1: (К1, К2), первичный ключ (К1, К2) и Т2: (К2, F) первичный ключ К2.
2. Таблица имеет первичный ключ К; поле F1, которое не является ключом и функционально зависит от К, а так же другое неключевое поле F2, которое функционально зависит от К1.
В этом случае формируется новая таблица, содержащая поля F1 и F2, с первичным ключом F1, а поле F2 удаляется из первоначальной таблицы.
Заменить Т: (К, F1,F2), первичный ключ К, функциональная зависимость F1->F2
на Т1:(К, F1), первичный ключ К и Т2: (F1, F2), первичный ключ F1.
Для любой заданной таблицы, повторяя применение двух рассмотренных правил, почти во всех практических ситуациях можно получить множество таблиц, находящихся в «окончательной» нормальной форме.
Рассмотрим процедуру проектирования для универсального отношения «Питание» (Таблица 1.7).
Шаг 1. Определение первичного ключа таблицы.
Предположим, что каждое блюдо имеет уникальное название, относится к единственному виду и приготавливается по единственному рецепту, т.е. название блюда однозначно определяет его вид и рецепт. Предположим также, что название организации поставщика уникально для того города, в котором он расположен, и названия городов уникальны для каждой из стран, т.е. название поставщика и город однозначно определяют этого поставщика, а город – страну его нахождения. Наконец, предположим, что поставщик может осуществлять в один и тот же день только одну поставку каждого продукта, т.е. название продукта, название организации поставщика, город и дата поставки однозначно определяют вес и цену поставленного продукта. Тогда в качестве первичного ключа отношения "Питание" можно использовать следующий набор атрибутов:
Блюдо, Дата_Р, Продукт, Поставщик, Город, Дата_П.
Шаг 2. Выявление полей, функционально зависящих от части составного ключа.
Поле Вид функционально зависит только от поля Блюдо, т.е.
Блюдо->Вид.
Аналогичным образом можно получить зависимости:
Блюдо->Рецепт
(Блюдо, Дата_Р)->Порции
Продукт->Калорийность
(Блюдо, Продукт)->Вес
Город->Страна
(Поставщик, Город, Дата_П)->Цена
Шаг 3. Формирование новых таблиц.
Полученные функциональные зависимости определяют состав таблиц, которые можно сформировать из данных универсального отношения:
Блюда (Блюдо, Вид)
Рецепты (Блюдо, Рецепт)
Расход (Блюдо, Дата_Р, Порции)
Продукты (Продукт, Калорийность)
Состав (Блюдо, Продукт, Вес (г))
Города (Город, Страна)
Поставки (Поставщик, Город, Дата_П, Вес (кг), Цена).
Шаг 4. Корректировка исходной таблицы.
После выделения из состава универсального отношения указанных выше таблиц, там остались лишь сведения о поставщиках, для хранения которых целесообразно создать таблицу
Поставщики (Поставщик, Город),
т.е. использовать часть исходного первичного ключа, так как остальные его части уже ничего не определяют.
Таким образом, процедура последовательной нормализации позволила получить проект, лучший, чем приведен на Рис. 1.12.
