Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
теория.docx
Скачиваний:
17
Добавлен:
20.05.2015
Размер:
74.81 Кб
Скачать

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

Рассмотрим следующий пример. Представим себе, что требуется хранить в базе данных информацию о том, в каком общежитии живет студент с указанием адреса общежития. Для этих целей можно ввести следующие атрибуты: КОД_СТУДЕНТА, ОБЩЕЖИТИЕ и АДРЕС. Между указанными атрибутами имеют место функциональные зависимости, представленные на рис.10.11.

Рис. 10.11. Диаграмма функциональных зависимостей между атрибутами СТУДЕНТ_ОБЩЕЖИТИЕ_АДРЕС

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

Для хранения рассматриваемой информации может быть использовано отношение СТУДЕНТ_ОБЩЕЖИТИЕ_АДРЕС, приведенное на рис.10.12.

СТУДЕНТ_ОБЩЕЖИТИЕ_АДРЕС

КОД_СТУДЕНТА

ОБЩЕЖИТИЕ

АДРЕС

С2 С6 С9 С1 С7

№1 №1 №2 №3 №3

ул.Строительная, д.1 ул.Строительная, д.1 ул.Театральная, д.15 ул.Студенческая, д.4 ул.Студенческая, д.4

Рис. 10.12. Отношение СТУДЕНТ_ОБЩЕЖИТИЕ_АДРЕС

Это отношение находятся во второй нормальной форме. Действительно, как это видно из диаграммы на рис.10.11, между его неключевыми атрибутами общежитие и адрес и ключом отношения, которым является атрибут КОД_СТУДЕНТА, имеет место неприводимая функциональная зависимость. Поэтому в данном отношении не может быть аномалий, связанных с наличием приводимой функциональной зависимости у отношений, не находящихся во второй нормальной форме. Тем не менее, при внимательном рассмотрении этого отношения можно увидеть, что структура отношения на рис.10.12 не лишена недостатков.

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

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

Операция DELETE. При удалении информации о проживающих в общежитии студентах можно потерять информацию об адресе общежития. Например, при удалении кортежа для студента с кодом С9 мы теряем информацию об адресе общежития №2.

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

Очевидно, что причиной этих аномалий уже не является наличие приводимой функциональной зависимости неключевых атрибутов от ключа, как это было в примере, рассмотренном в предыдущем разделе. Таких зависимостей в этом отношении нет. Оно находится во второй нормальной форме и его неключевые атрибуты общежитие и адрес зависят от ключа (атрибут КОД_СТУДЕНТА неприводимо.

На этот раз причиной имеющих место аномалий обновления является наличие транзитивной функциональной зависимости атрибута адрес от атрибута Код_студента, показанной на рис.10.13 пунктирной стрелкой.

Рис. 10.13. Транзитивная функциональная зависимость в отношении СТУДЕНТ_ОБЩЕЖИТИЕ_АДРЕС

Решение обозначенной проблемы также состоит в декомпозиции отношения СТУДЕНТ_ОБЩЕЖИТИЕ_АДРЕС на два отношения для исключения транзитивной функциональной зависимости. Результатом такой декомпозиции являются два отношения, представленные вместе с диаграммами их функциональных зависимостей на рис.10.14.

СТУДЕНТ_ОБЩЕЖИТИЕ

КОД_СТУДЕНТА

ОБЩЕЖИТИЕ

С6 С2 С9 С1 С7

№1 №1 №2 №3 №3

ОБЩЕЖИТИЕ_АДРЕС

ОБЩЕЖИТИЕ

АДРЕС

№1 №2 №3

ул.Строительная, д.1 ул.Театральная, д.15 ул.Студенческая, д.4

Рис. 10.14. Декомпозиция отношения СТУДЕНТ_ОБЩЕЖИТИЕ_АДРЕС

Данная декомпозиция является декомпозицией без потерь. Исходное отношение может быть восстановлено путем операции соединения отношений СТУДЕНТ_ОБЩЕЖИТИЕ и ОБЩЕЖИТИЕ_АДРЕС по атрибуту общежитие. Также при декомпозиции не теряется информация о функциональной (транзитивной) зависимости КОД_СТУДЕНТА→АДРЕС, так как она может быть выведена из зависимостей КОД_СТУДЕНТА→ОБЩЕЖИТИЕ и ОБЩЕЖИТИЕ→АДРЕС.

Не трудно видеть, что данная декомпозиция решает проблемы с приведенными примерами аномалий операций обновления. Действительно, информация об адресе нового общежития может быть легко вставлена в отношение ОБЩЕЖИТИЕ_АДРЕС, операция удаления информации о студенте из отношения СТУДЕНТ_ОБЩЕЖИТИЕ не затрагивает информации об адресах общежитий, и, наконец, изменение названия улицы для общежития производится модификацией значения атрибута АДРЕС в соответствующем (единственном) кортеже отношения ОБЩЕЖИТИЕ_АДРЕС.

Декомпозиция отношения СТУДЕНТ_ОБЩЕЖИТИЕ_АДРЕС переводит его в два отношения СТУДЕНТ_ОБЩЕЖИТИЕ и ОБЩЕЖИТИЕ_АДРЕС, находящиеся уже в третьей нормальной форме. Определение этой нормальной формы имеет следующий вид.

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

Приведенные выше отношения студент и УСПЕВАЕМОСТЬ на рис.10.9, СТУДЕНТ_ОБЩЕЖИТИЕ и ОБЩЕЖИТИЕ_АДРЕС на рис.10.14 удовлетворяют этому определению, поэтому все они находятся в третьей нормальной форме.

Говоря о декомпозиции отношения СТУДЕНТ_ОБЩЕЖИТИЕ_АДРЕС на рис.10.12 с целью преобразования его в два отношения, находящиеся в третьей нормальной форме, следует обратить внимание на то, что кроме приведенного на рис.10.14, возможен другой вариант разбиения его на два отношения. Этот вариант представлен на рис.10.15.

СТУДЕНТ_ОБЩЕЖИТИЕ

КОД_СТУДЕНТА

ОБЩЕЖИТИЕ

С6 С2 С9 С1 С7

№1 №1 №2 №3 №3

СТУДЕНТ_АДРЕС

КОД_СТУДЕНТА

АДРЕС

С6 С2 С9 С1 С7

ул.Строительная, д.1 ул.Строительная, д.1 ул.Театральная, д.15 ул.Студенческая, д.4 ул.Студенческая, д.4

Рис.10.15. Другой вариант декомпозиции отношения СТУДЕНТ_ОБЩЕЖИТИЕ_АДРЕС

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

В предыдущем варианте декомпозиция устраняла транзитивную функциональную зависимость, при этом информация не терялась, так как эта зависимость может быть выведена из оставшихся по правилам Армстронга (см. раздел 10.1). В рассматриваемом же варианте вместо транзитивной зависимости была потеряна зависимость ОБЩЕЖИТИЕ→АДРЕС, которая не выводится из остальных. Необходимость поддержания в базе данных такой зависимости делает в этом случае возможные изменения значений атрибутов ОБЩЕЖИТИЕ и АДРЕС, теперь находящихся в разных отношениях, зависимыми друг от друга.

Действительно, при изменении значения атрибута общежитие в каком-либо кортеже отношения студент_общежитие мы должны произвести соответствующие изменения атрибута АДРЕС в отношении СТУДЕНТ_АДРЕС. Следовательно, необходимость поддержания функциональной зависимости ОБЩЕЖИТИЕ→АДРЕС из зависимости между атрибутами одного отношения превратилась в ограничение целостности, накладываемое на два отношения и реализуемое гораздо более сложно.

При первом же варианте декомпозиции, представленном на рис.10.14, функциональная зависимость ОБЩЕЖИТИЕ→АДРЕС, порождающая в отношении СТУДЕНТ_ОБЩЕЖИТИЕ_АДРЕС нежелательную транзитивную зависимость СТУДЕНТ→АДРЕС преобразуется в отношении ОБЩЕЖИТИЕ_АДРЕС в функциональную зависимость атрибута от первичного ключа. Ограничение целостности, задаваемое такой зависимостью, в этом случае привести в действие гораздо проще. Оно автоматически обеспечивается путем наложение ограничений на уникальность первичного ключа.

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

Риссанен (Rissanen) показал следующее.

Проекции R1 и R2 отношения R независимы в рассмотренном выше смысле тогда и только тогда, когда:

  • каждая функциональная зависимость в отношении R должна выводится из функциональных зависимостей в проекциях R1 и R2;

  • общие атрибуты проекций R1 и R2 образуют потенциальный ключ по крайней мере для одного из этих отношений.

Второй вариант декомпозиции отношения СТУДЕНТ_ОБЩЕЖИТИЕ_АДРЕС, представленный на рис.10.15, не удовлетворяет правилу Риссанена, поэтому функциональная зависимость ОБЩЕЖИТИЕ→АДРЕС, имеющая место в отношении СТУДЕНТ_ОБЩЕЖИТИЕ_АДРЕС, не может быть выведена из функциональных зависимостей, имеющихся в отношениях СТУДЕНТ_ОБЩЕЖИТИЕ и СТУДЕНТ_ АДРЕС.

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

NEXT THEME