Нормальные формы. Процедура нормализации. Пример

Центральная задача проектирования БД ЭИС – это определение количества отношений и их атрибутного состава. При этом атрибуты могут группироваться в отношения различными способами. Рациональные группировки должны учитывать следующие требования: 1)множества отношений должно обеспечивать минимум избыточности представления информации; 2)корректировка отношений не должна приводить к двусмысленности или к потере информации; 3)перестройка набора отношений при добавлении в БД новых атрибутов должна быть минимальна. Удовлетворение этих требований достигается нормализацией отношений БД. Нормализация – пошаговый обратимый процесс декомпозиции исходных отношений на другие более мелкие и простые отношения. Нормальная форма — требование, предъявляемое к структуре таблиц в теории реляционных БД для устранения из базы избыточных функциональных зависимостей между атрибутами (полями таблиц). Известно 5 различных нормальных форм отношений: чем выше номер нормальной формы, тем больше ограничений накладывается на хранимые значения соответствующего отношения. Реляционная БД в целом характеризуется первой нормальной формой (1НФ). Отношение находится в 1НФ тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов. Отношения находятся во второй нормальной форме (2НФ), если оно находится в 1НФ, а каждый неключевой атрибут функционально полно зависит от первичного ключа (составного). Отношение находится в третьей нормальной форме (3НФ), если оно находится во 2НФ, и в нем отсутствуют транзитивные функциональные зависимости неключевых атрибутов от ключа. Транзитивная зависимость – неключевой атрибут функционально зависит от неключевых атрибутов. (напр., если атрибут В зависит от атрибута А, а атрибут С зависит от атрибута В, то атрибут С транзитивно зависит от атрибута А). Отношения находятся в нормальной форме Бойса-Кодда (НФБК), если каждый детерминант является ключом-кандидатом. Два или более атрибута или группы атрибутов, которые могут быть ключом, называются ключами-кандидатами. Тот из ключей-кандидатов, который выбирается в качестве ключа называется первичным ключом. Отношение находится в четвертой нормальной форме (4НФ), если оно находится в НФБК и не содержит нетривиальных многозначных зависимостей. Т.е. все многозначные зависимости являются, по сути, функциональными зависимостями от ключей отношения. Отношение находится в пятой нормальной форме (5 НФ или в проекционно-соединительной нормальной форме) тогда и только тогда, когда каждая нетривиальная зависимость соединения в нём определяется потенциальным ключом (ключами) этого отношения. Говорят, переменная отношения R удовлетворяет зависимости соединения *{А, В,..., Z} тогда и только тогда, когда любое допустимое значение переменной отношения R эквивалентно соединению ее проекций по подмножествам А, B,..., Z множества атрибутов. Есть нормальные формы и более высокого порядка, но на практике нормализация выше пятого уровня практически ничего не дает.

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

Процедура нормализации основывается на том, что единственными функц-ыми завис-тями в любой таблице д.б. зависимости вида K->F, где K – первичный ключ, а F – нек-ое другое поле, т.е. надо избавиться от всех этих "др." функц-ых завис-тей, т.е. таких, к-ые имеют иной вид, чем K->F.

Рассмотрим процедуру нормализации на примере:

Дано отношение «питание»:

Питание (блюдо, вид, рецепт, порции, дата_р, продукт, калорийность, вес (г), поставщик, город, страна, вес (кг), цена, дата_п)

Шаг 1. Определение первичного ключа таблицы. Предположим, что каждое блюдо имеет уникальное название, относится к единственному виду и приготавливается по единственному рецепту, т.е. название блюда однозначно определяет его вид и рецепт. Предположим также, что название орг-ции поставщика уникально для того города, в к-ом он расположен, и названия городов уникальны для каждой из стран, т.е. название поставщика и город однозначно опр-ют этого поставщика, а город – страну его нахождения. Пусть поставщик может осуществлять в один и тот же день только одну поставку каждого продукта, т.е. название продукта, название орг-ции поставщика, город и дата поставки однозначно опр-ют вес и цену поставленного продукта. Тогда в кач-ве первичного ключа отн-ия "Питание" можно использовать след. набор атрибутов: Блюдо, Дата_Р, Продукт, Поставщик, Город, Дата_П.

Шаг 2. Выявление полей, функционально зависящих от части составного ключа. Поле Вид функционально зависит только от поля Блюдо, т.е. Блюдо->Вид. Аналогично можно получить завис-ти: ●Блюдо->Рецепт; ●(Блюдо, Дата_Р)->Порций; ●Продукт->Калорийность; ●(Блюдо, Продукт)->Вес; ●Город->Страна; ●(Поставщик, Город, Дата_П)->Цена;

Шаг 3. Формирование новых таблиц. Полученные функц-ые завис-ти опр-ют состав таблиц, к-ые можно сформировать из дан-х универсального отн-ия: ●Блюда (Блюдо, Вид); ●Рецепты (Блюдо, Рецепт); ●Расход (Блюдо, Дата_Р, Порций); ●Продукты (Продукт, Калорийность); ●Состав (Блюдо, Продукт, Вес (г)); ●Города (Город, Страна); ●Поставки (Поставщик, Город, Дата_П, Вес (кг), Цена).

Шаг 4. Корректировка исходной таблицы. После выделения из состава универсального отношения указанных выше таблиц, там остались лишь сведения о поставщиках, для хранения к-ых целесообразно создать таблицу Поставщики (Поставщик, Город).

●Блюда (бл, блюдо, вид); ●рецепты (блюдо, рецепт); ●расход (блюдо, дата_р, порции); ●продукты (пр, продукт, калорийность), ●состав (бл, пр, вес (г)); ●поставщики (пос, поставщик, город, страна); ●поставки (пос, пр, вес (кг), цена, дата_п)

Для улучшения проекта, нужно опр-ть первичные ключи таблиц и выявить, нет ли в таблицах полей, зависящих лишь от части этих ключей. Такое поле есть только в 1ой таблице. Это поле Страна в таблице Поставщики. Выделяя его вместе с ключом Город в таблицу Страны, получим следующий проект:

●Блюда (бл, блюдо, вид); ●рецепты (бл, рецепт); ●расход (бл, порций, дата_р); ●продукты (пр, продукт, калорийность), ●состав (бл, пр, вес (г)); ●поставщики (пос, поставщик, город); ●поставки (пос, пр, вес (кг), цена, дата_п); ●город (город, страна)

Дата добавления: 2015-05-09