Организация Баз Данных 6 страница

Отношение 8

Номер двигателя

Наименование параметра

Действующая величина параметра

(Связь 7,8)

Отношение 9

Номер изделия

Наименование дефекта

Шифр счета по дефекту

Рис. 11. Результат отображения исходной модели на отношения реляционной модели

Полученную модель необходимо проверить на полноту представления информации.

1.3.2. Анализ полноты представления информации

С точки зрения полноты представления информации анализируется результат отображения (рис. 11) в сравнении с исходной схемой (рис. 2 и рис. 1).

Анализу подлежат:

- полнота представления связей;

- полнота представления характеристик объектов и процессов.

1.4. Нормализация отношений

Этот метод был разработан Коддом. Введены новые понятия:

Домен – набор значений элементов данных одного типа, т.е. один столбец таблицы.

Простой атрибут – атрибут, значения которого атомарны, т.е. неделимы.

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

Составной ключ – это ключ, который содержит несколько атрибутов.

Ключ должен обладать двумя свойствами:

1) однозначная идентификация записей: записи должны однозначно определяться значением ключа;

2) отсутствие избыточности: никакой атрибут нельзя удалить из ключа, не нарушая при этом свойства однозначной идентификации.

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

Коддом выделены 3 нормальных формы отношений.

Следует отметить, что процесс нормализации не имеет отношения к физическому размещению данных. Речь идет только о пользовательском и глобальном логическом представлении данных.

1.4.1. П е р в а я н о р м а л ь н а я ф о р м а

Отношение называется нормализованным или приведенным к первой нормальной форме (1НФ), если все его атрибуты – простые.

Пример 1.

Ненормализованное отношение R1:

Табельный номер	ФИО	Оклад	Комната	Телефон	Дети
Имя	возраст
	Иванов Л.А.				Саша Женя Вася
	Темкин М.Т.				Вова
	Кошкин В.К.				Женя Вова

1НФ:

Табельный номер родителя	Имя ребенка	Возраст ребенка	ФИО	Оклад	Комната	Телефон
	Саша		Иванов Л.А.
	Женя		Иванов Л.А.
	Вася		Иванов Л.А.
	Вова		Темкин М.Т.
	Женя		Кошкин В.К.
	Вова		Кошкин В.К.

Ненормализованное отношение легко сделать нормализованным. Такое представление может привести к изменению ключа.

1.4.2. В т о р а я н о р м а л ь н а я ф о р м а

Ф у н к ц и о н а л ь н а я з а в и с и м о с т ь

Задавая отношения над элементами данных, разработчик должен интересоваться тем, какие из атрибутов объекта являются зависимыми. Термин функциональная зависимость означает следующее: атрибут В отношения R функционально зависит от атрибута А того же отношения, если в каждый момент времени каждому значению атрибута А соответствует не более чем одно значение атрибута В, связанного с А в отношении R.

Утверждения что В функционально зависит от А, означает то же самое, что А определяет В, т.е. если в какой-то момент времени известно значение А, то можно получить и значение В.

Рассмотрим функциональные зависимости примера А:

1) Таб. Номер функционально зависит от ФИО, и одновременно ФИО функционально зависит от таб. номера:

Табельный номер < - > ФИО

Действительно, каждому сотруднику ставится в соответствие только один таб. номер, а конкретный таб. номер в определенный момент времени соответствует только одному сотруднику.

2) номер комнаты функционально зависит от ФИО, если сотрудник имеет рабочее место в одной комнате:

ФИО < - > номер комнаты

3) если в каждой комнате установлен один телефон, то номер телефона функционально зависит от номера комнаты:

номер комнаты < - > номер телефона

Пример 2.

Номер * служащего

Имя * Служащего

Зарплата

Номер Проекта

Дата окончания

* - отмечены основные атрибуты (элементы возможных ключей)

Функциональные зависимости этого отношения:

1) номер служащего < - > имя служащего;

2) зарплата - > имя служащего

или

зарплата - > номер служащего;

3) номер проекта - > имя служащего

или

номер проекта - > имя служащего

или

номер проекта - > номер служащего

4) дата окончания - > имя служащего

или

дата окончания - > номер служащего

или

дата окончания - > номер проекта

Атрибут НОМЕР-СЛУЖАЩЕГО не является функционально зависимым от атрибута ЗАРПЛАТА, т.к. несколько служащих могут иметь одинаковую зарплату. Аналогично НОМЕР СЛУЖАЩЕГО не является функционально зависимым от атрибута НОМЕР ПРОЕКТА; атрибут ДАТА ОКОНЧАНИЯ наоборот обладает такой зависимостью. Никакие другие атрибуты не являются зависимыми от атрибута НОМЕР ПРОЕКТА. Эти функциональные зависимости более ясно можно представить с помощью диаграммы:

НОМЕР СЛУЖАЩЕГО *

ИМЯ СЛУЖАЩЕГО *

ЗАРПЛАТА

НОМЕР ПРОЕКТА

ДАТА ОКОНЧАНИЯ

Если В функционально зависит от А, то из вершины А проводится стрелка в вершину В.

Пример 3:

Атрибут может функционально зависеть не от какого-то одного атрибута, а от целой группы атрибутов. Рассмотрим, например, следующее отношение, содержащее информацию о расходе рабочего времени программистов:

Деятельность программиста

Номер * программиста

Номер * программы

Имя * программиста

Имя * программы

Количество рабочих часов

Атрибут КОЛИЧЕСТВО РАБОЧИХ ЧАСОВ функционально зависит от составного ключа (НОМЕР ПРОГРАММИСТА, НОМЕР ПРОГРАМЫ) или от одного из следующих возможных ключей: (НОМЕР ПРОГРАММИСТА, ИМЯ ПРОГРАММЫ), (ИМЯ ПРОГРАММИСТА, НОМЕР ПРОГРАММЫ) или (ИМЯ ПРОГРАММИСТА, ИМЯ ПРОГРАММЫ). Предполагается, что среди программистов нет однофамильцев и что две программы не могут иметь одинаковых имен. Функциональные зависимости этого отношения:

НОМЕР ПРОГРАММИСТА *

НОМЕР ПРОГРАММЫ *

ИМЯ ПРОГРАММИСТА *

ИМЯ ПРОГРАММЫ *

КОЛИЧЕСТВО РАБОЧИХ ЧАСОВ

Нетрудно убедится, что в нормализованном отношении все не ключевые атрибуты функционально зависят от ключа отношения.

Полная функциональная зависимость

Атрибут (или набор атрибутов) В из отношения R называется полностью зависимым от другого набора атрибутов А отношения R, если В функционально зависит от всего множества А, но не зависит от ни от какого подмножества А.

И, другими словами: неключевой атрибут функционально полно зависит от составного ключа, если он функционально зависит от ключа, но не находится в функциональной зависимости ни от какой отдельной части составного ключа.

Рассмотрим пример 1 отношение R2.

Атрибуты ФИО, ОКЛАД, КОМНАТА, ТЕЛЕФОН не находятся в полной функциональной зависимости от ключа отношения, поскольку они функционально зависят от части ключа – ТАБЕЛЬНОГО НОМЕРА. Имеет место дублирование информации, поскольку у сотрудника может быть много детей и для каждого из них будут храниться сведения об окладе родителя, в какой комнате он работает и телефоне.

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

Рассмотрим пример 3.

Атрибут КОЛИЧЕСТВО РАБОЧИХ ЧАСОВ является полностью зависимым от составного ключа (НОМЕР ПРОГРАММИСТА, НОМЕР ПРОГРАММЫ), т.к. он задает количество рабочего времени, затраченного данным программистом на конкретную программу. При этом ни один из атрибутов НОМЕР ПРОГРАММИСТА или НОМЕР ПРОГРАММЫ в отдельности не определяет значение атрибута КОЛИЧЕСТВО РАБОЧИХ ЧАСОВ (единственного в данном случае атрибута, который полностью зависит от составного ключа). Атрибут ИМЯ ПРОГРАММИСТА полностью зависит от одного атрибута НОМЕР ПРОГРАММИСТА; атрибут ИМЯ ПРОГРАММЫ полностью зависит от атрибута НОМЕР ПРОГРАММЫ.

Мы подошли к определению второй нормальной формы: отношение R задано во второй нормальной форме, если оно является отношением в первой нормальной форме, и каждый атрибут, не являющийся основным атрибутом в этом отношении, полностью зависит от любого возможного ключа этого отношения R.

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

Рассмотрим пример 1 отношение R2. Это отношение находится в первой нормальной форме, но не находится во второй.

Чтобы отношение привести ко второй нормальной форме, необходимо:

1) построить его проекцию, исключив атрибуты, которые не находятся в полной функциональной зависимости от составного ключа;

2) построить дополнительно одну или несколько проекций на часть составного ключа и атрибуты, функционально зависящие от этой части ключа.

Отношение R2 преобразуем в два отношения R3 и R4, каждое из которых находится во второй нормальной форме.

R3

Табельный номер	Имя ребенка	Возраст
	Саша
	Женя
	Вася
	Вова
	Женя
	Вова

R4

Табельный номер	ФИО	Оклад	комната	Телефон
	Иванов Л.А.
	Темкин М.т.
	Кошкин в.к.

Рассмотрим пример 2. Если все возможные ключи отношения содержат по одному атрибуту, то это отношение задано во второй нормальной форме, т.к. в этом случае все атрибуты, не являющиеся основными, полностью зависят от возможных ключей.

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

Рассмотрим пример 3. Отношение в этом примере задано во второй нормальной форме, потому что атрибут КОЛИЧЕСТВО РАБОЧИХ ЧАСОВ – единственный атрибут, не являющийся основным, полностью зависит от каждого возможного ключа.

Следующее отношение не является отношением во второй нормальной форме:

Источник снабжения

Номер поставщика

Номер партии товара

Имя поставщика

Сведения о поставщике

Цена

У этого отношения только один возможный ключ. ИМЯ ПОСТАВЩИКА не входит в ключ, т.к. одной и той же фирме в разных районах может быть присвоены различные номера поставщика. Таким образом, атрибут НОМЕР ПОСТАВЩИКА не определяется значением атрибута ИМЯ ПОСТАВЩИКА.

Функциональные зависимости:

НОМЕР ПОСТАВЩИКА *

НОМЕР ПАРТИИ ТОВАРА *

ИМЯ ПОСТАВЩИКА

СВЕДЕНИЯ О ПОСТАВЩИКЕ

ЦЕНА

Атрибуты ИМЯ ПОСТАВЩИКА и СВЕДЕНИЯ О ПОСТАВЩИКЕ, не будучи основными, функционально зависят от атрибута НОМЕР ПОСТАВЩИКА, который является подмножеством составного ключа.

Нарушение условий второй нормальной формы приводит к ряду неудобств:

1) графа СВЕДЕНИЯ О ПОСТАВЩИКЕ не может быть заполнена до фактической поставки конкретной партии данным поставщиком, либо необходимо задать какой-нибудь фиктивный номер партии;

2) если поставщик временно задержал поставку некоторой партии, то удаление записи, соответствующей данному значению атрибута НОМЕР ПОСТАВЩИКА, вызовет удаление сведений о нем. Как правило, такие сведения желательно сохранять.

3) если требуется изменить значение атрибута СВЕДЕНИЯ О ПОСТАВЩИКЕ, то придется внести одни и те же изменения сразу в несколько записей, число таких записей может меняться во времени.

Подобные трудности можно устранить, расщепив исходное отношение на два отношения, заданные во второй нормальной форме.

НОМЕР ПОСТАВЩИКА *

ИМЯ ПОСТАВЩИКА

СВЕДЕНИЯ О ПОСТАВЩИКЕ

НОМЕР ПОСТАВЩИКА *

НОМЕР ПАРТИИ ТОВАРА *

ЦЕНА

Только атрибут ЦЕНА полностью зависит от составного ключа, а все остальные атрибуты выделяются в отдельное отношение, имеющие отдельный ключ – НОМЕР ПОСТАВЩИКА.

В общем случае каждый атрибут должен полностью зависеть от всего ключа; в противном случае его следует выделить в отдельное отношение.

1.4.3. Третья нормальная форма

В ряде случаев и вторая нормальная форма порождает неудобства. Для их устранения используется последний шаг нормализации, преобразующий вторую нормальную форму в третью. На этом шаге ликвидируется так называемая транзитивная зависимость.

Транзитивная зависимость.

Пусть А,В и С – три атрибута или три набора атрибутов отношения R. Если С зависит от В, а В - от А, то С зависит от А. Если при этом обратное соответствие неоднозначно (т.е. А не зависит от В или В не зависит от С), то говорят, что С транзитивно зависит от А.

На диаграмме транзитивную зависимость С от А изображают следующим образом:

А

В

С

Преобразование в третью нормальную форму состоит в расщеплении исходного отношения на два:

А В

В С

Рассмотрим пример 1 отношение R4. В нем можно увидеть пример транзитивной зависимости:

табельный номер –> комната -> телефон.

Хранение в отношении атрибутов, находящихся в транзитивной зависимости от ключа, порождает ряд неудобств. Рассмотрим их на примере атрибута ТЕЛЕФОН в отношении R4.

Номер телефона есть характеристика комнаты, поэтому сведения о телефоне будут многократно дублироваться для всех сотрудников, рабочие места которых расположены в одной комнате. Кроме прочего, изменение номера телефона потребует корректировки большого числа записей.

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

Рассмотрим пример 2. Атрибут ДАТА ОКОНЧАНИЯ зависит от атрибута НОМЕР ПРОЕКТА, который, в свою очередь, зависит от атрибута НОМЕР СЛУЖАЩЕГО. Таким образом, ДАТА ОКОНЧАНИЯ транзитивно зависит от атрибута НОМЕР СЛУЖАЩЕГО.

Отношение имеет следующие недостатки:

1) до момента привлечения конкретного служащего к работе над данным проектом дату окончания некуда было бы записывать. Можно, конечно, записать ее где-нибудь вместе с другой информацией о проектах, но это неоправданно увеличит избыточность информации в базе.

2) Если вдруг все служащие прекратили работу над данным проектом, и проект был бы приостановлен до привлечения новых служащих, в БД были бы уничтожены все записи, содержащие дату окончания проекта. Такая ситуация кажется маловероятной, но для некоторых файлов подобный процесс вполне реален.

3) Изменение даты окончания проекта приводит к необходимости внесения изменений в несколько записей; число таких записей может меняться во времени, как и в случае второй нормальной формы.

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

Пример 1. Отношение R4 в результате преобразований должно быть приведено к двум отношениям R5 и R6.

R5

Табельный номер	ФИО	Оклад	Комната
	Иванов Л.А.
	Темкин М.Т.
	Кошкин В.К.

R6

Комната	телефон

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

Пример 2. Это отношение можно привести к третьей нормальной форме путем расщепления:

НОМЕР СЛУЖАЩЕГО *

ИМЯ СЛУЖАЩЕГО *

ЗАРПЛАТА

НОМЕР ПРОЕКТА

НОМЕР ПРОЕКТА *

ДАТА ОКОНЧАНИЯ

Пара отношений предпочтительнее первоначального отношения, потому что информация об окончании проекта может потребоваться независимо от информации о служащем, а атрибут ДАТА ОКОНЧАНИЯ относится скорее к проекту, чем к служащему.

Пара отношений в третьей нормальной форме не содержит транзитивных и неполных зависимостей.