Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


Критерий полной декомпозиции с исключением дублирования



Необходимыми и достаточными условиями полной декомпозиции исходной реляционной таблицы с исключением дублирования значений полей являются:

· представление БД в 1НФ;

· выполнение теоремы Хита;

· формировании проекций без какого-либо общего ключа-кандидата.

 

Пример.

В рассмотренной выше БД

Поставщики (№КИ, Фирма, Телефон)

декомпозиция по принятому на рис. 6.4 варианту была полной и дублирование было полностью устранено, так как:

· исходно БД представлена в 1НФ,

· принятые структуры полей удовлетворяли теореме Хита,

· в проекциях не содержалось какого-либо общего ключа - кандидата.

В случае же применения другого варианта декомпозиции на две проекции:

R21 = proj №КИ, Телефон(Поставщики)

и

R22 = proj №КИ, Фирма(По-ставщики)

не ликвидировано дублирование. Причиной этого явилось то, что каждая из проекций содержит ключ-кандидат NКИ, т.е. декомпозиция не удовлетворяет необходимым и достаточным условиям критерия.

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

Отношение в 1НФ в ряде случаев может приводить к аномалиям из-за наличия сцепленных ключей. Для их исключения необходимо привести отношение ко второй нормальной форме.

Схема отношения R находится во второй нормальной форме (2НФ), если она находится в 1НФ и каждый ее непервичный атрибут, функционально полностью зависит от соответствующего ключа-кандидата.

Функционально полной зависимостью называется зависимость атрибута одновременно от всех полей ключа.

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

Пример.

Отношение

Поставщики (№КИ, Фирма, Телефон),

имеет простой ключ №КИ и, следовательно, находится в 2НФ. Действительно, его непервичные атрибуты: Фирма, Телефон функционально полностью зависят от первичного ключа №КИ.

Если в отношении имеются сцепленные ключи, то это отношение, являясь отношением в 1НФ, может и не быть отношением в 2НФ.

Рассмотрим отношение

(6.3)          Поставки(№Поставщика, №Изделия,

а1                      а2

ИмяПоставщика, ИнфОПост-ке, Цена)

       а3                      а4                       а5

где а1,..., а5 - символьные имена атрибутов (см. Рис. 0.10).

В этом отношении:

· поставщики имеют изделия с уникальными номерами;

· одному и тому же поставщику в различных регионах могут быть присвоены различные номера;

· имеется один составной ключ а12, так как он в целом и отдельные его компоненты определяют все остальные неключевые атрибуты записи. Это иллюстрирует Рис. 0.10, а, где приведены функциональные зависимости для отношения Поставки.

· На Рис. 0.10, б приведена реализация отношения Поставки. Из Рис. 0.10, а видно, что атрибуты а3 и а4, не относящиеся к первичным, функционально зависят только от атрибута а2, который является лишь подмножеством составного ключа а12. Это означает, что в отношении нет полной функциональной зависимости всех непервичных атрибутов от сцепленного ключа в целом. Следовательно, отношение не находится в 2НФ.

Нарушение условий 2НФ приводит к ряду затруднений при манипулировании данными в БД:

· невозможен ввод информации о поставщике, пока он не реализует поставки какого-либо изделия, т.к. при этом невозможно задать значение всего сцепленного ключа а12;

· в случае временного прекращения каким-либо поставщиком поставок изделий, т.е. при отсутствии значения поля а2 запись с этим поставщиком из-за отсутствия ключа удаляется, и, следовательно, теряются все сведения о нем, что нежелательно;

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

 

 

   

 

а1 а2 а3 а4 а5
   

 

1 10 А5 C1 12
а1 *

 

1 15 А1 С4 22
а2 * 1 25 А4 С2 52
а3   1 19 А3 С3 30
а4   2 31 А2 С5 55
а5   2 10 А5 С1 13
    2 25 А4 C2 59
  а) 3 25 А4 С2 55
   

 

4 10 А5 С1 14
    4 31 А2 С5 59
   

 

5 19 А3 С3 35

 

5 15 А1 С4 24

 

  5 10 А5 C1 14

 

 

б)

                 

Рис. 0.10

С целью устранения перечисленных аномалий необходимо исходное отношение Поставки (см. Рис. 0.10, а) привести к 2НФ. Для этого требуется реализовать его полную декомпозицию на два отношения, каждое из которых должно быть в 2НФ. Результат нормализации приведен на рис.6.12, где а) и б) - схемы полученных отношений в 2НФ, в) и г) - их соответствующие реализации.

В результате полной декомпозиции от сцепленного ключа а1+а2 полностью зависит лишь атрибут а5, что иллюстрирует схема отношения на Рис. 0.11, б, а все остальные атрибуты, зависящие лишь от простого ключа а1, выделились в отдельное отношение, представленное схемой на Рис. 0.11, а.

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

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

 

а1

*

    а1 *

 

а1 а2 а5

а3

 

    а2 *       1 10 12

а4

 

    а5         1 15 22

 

 

а)       б)     1 25 52

 

 

              1 19 30

 

 

2 31 55

 

 

2 10 13
 

 

 

 

2 25 59

а2

а3

а4

 

3 25 55

10

А5

C1

 

4 10 14

15

А1

С4

 

4 31 59

25

А4

С2

 

5 19 35

19

А3

С3

 

5 15 24

31

А2

C5

 

5 10 14
                           

                   в)                                                                г)

Рис. 0.11

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

Отношение в 2НФ в случае наличия в нем транзитивных зависимостей может приводить к различным аномалиям.

Рассмотрим отношение R с тремя типами атрибутов или тремя наборами типов атрибутов, для которых имеет место транзитивная зависимость. Обозначим эти наборы соответственно через С1, С2 и С3.

Тогда свойство транзитивной зависимости можно представить соотношениями

               С1   C2, С2    С3 и С1  С3.

При этом отметим, что обратное соответствие неоднозначно, т.е. С1 не зависит от С2 или С2 не зависит от С3.

Диаграмму транзитивной зависимости для рассматриваемого случая отражает Рис. 0.12, а.

Для ликвидации возможных аномалий из-за транзитивной зависимости необходимо исключить эти зависимости. С этой целью необходимо произвести декомпозицию исходного отношения для его преобразования таким образом из 2НФ в третью нормальную форму (3НФ).

Отношение R задано в третьей нормальной форме (3НФ), когда оно задано в 2НФ и каждый непервичный атрибут из отношения R нетранзитивно зависит от любого из ключей-кандидатов.

 

С1                             C1               C2

С2                             C2              C3

С3                                                         

          a)                            б)

Рис. 0.12

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

Пример.

В отношении

Служащий(№Служащего, ФИО, ЗПлата, №Проекта, ДатаОкончания),

                               а1     а2 а3      а4       а5

 

в котором каждый служащий занят лишь в одном проекте, атрибут а5 зависит от атрибута а4, который, в свою очередь, зависит от первичного атрибута а1. Следовательно, атрибут а5 транзитивно зависит от первичного атрибута а1, являющегося ключом. Эта транзитивная зависимость приводит к следующим аномалиям:

· до момента привлечения хотя бы одного конкретного служащего к выполнению данного проекта нет возможности записывать значения полей №Проекта и ДатаОкончания, хотя эти реквизиты не зависят от конкретного служащего;

· в случае снятия всех служащих с выполнения данного проекта (например, при его передаче в другую бригаду) в БД уничтожается информация в полях №Проекта и ДатаОкончания;

· при изменении значения поля ДатаОкончания проекта необходим поиск всех записей, содержащих эту дату, и их корректировка.

С целью перевода отношения в 3НФ для ликвидации транзитивной зависимости в исходном отношении требуется декомпозиция этого отношения на два новых отношения:

Служащий (№Служащего, ФИО, ЗПлата, №Проекта)

и

Проект (№Проекта, ДатаОкончания).

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

Из изложенного можно сделать вывод, что отношение в ЗНФ является для АБД средством четкого осмысления предметной области. БД в ЗНФ имеет возможности естественного развития и модификации. Структуризация данных в соответствии с ЗНФ дает простое представление о данных для программистов и пользователей, уменьшает вероятность некорректности выполнения операций.

 

а1 * а4 *
а2 * а5  
а3      
а4      

   а)                                             б)

Рис. 0.13

6.6. Экстранормализационные формы


Поделиться:



Последнее изменение этой страницы: 2019-06-08; Просмотров: 166; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.033 с.)
Главная | Случайная страница | Обратная связь