Управление данными. Громов Ю.Ю - 23 стр.

UptoLike

1
Иванов 1 11-22-33
2
Климат
1
2
Петров 1 11-22-33
1
Космос
2
3
Сидоров 2 33-22-11
1
Космос
3
3
Сидоров 2 33-22-11
2
Климат
2
Аномалии обновления.
Даже одного взгляда на таблицу отношения
СОТРУДНИ-
КИ_ОТДЕЛЫ_ПРОЕКТЫ
достаточно, чтобы увидеть, что данные хранятся в ней с большой избыточ-
ностью. Во многих строках повторяются фамилии сотрудников, номера телефонов, наименования про-
ектов. Кроме того, в данном отношении хранятся вместе независимые друг от друга данные и данные
о сотрудниках, и об отделах, и о проектах, и о работах по проектам. Пока никаких действий с отноше-
нием не производится, это нестрашно. Но как только состояние предметной области изменяется, так
при попытках соответствующим образом изменить состояние базы данных возникает большое количе-
ство проблем.
Исторически эти проблемы получили название
аномалии обновления
. Попытки дать строгое поня-
тие аномалии в базе данных не являются вполне удовлетворительными. В данных работах аномалии оп-
ределены как противоречие между моделью предметной области и физической моделью данных, под-
держиваемых средствами конкретной СУБД. Аномалии возникают в том случае, когда наши знания о
предметной области оказываются по каким-то причинам невыразимыми в схеме БД или входящими в
противоречие с ней. Мы придерживаемся другой точки зрения, заключающейся в том, что аномалий в
смысле определений упомянутых авторов нет, а есть либо неадекватность модели данных предметной
области, либо некоторые дополнительные трудности в реализации ограничений предметной области
средствами СУБД. Более глубокое обсуждение проблемы строгого определения понятия аномалий вы-
ходит за пределы данной работы.
Таким образом, мы будем придерживаться интуитивного понятия аномалии как неадекватности мо-
дели данных предметной области (что говорит на самом деле о том, что логическая модель данных по-
просту неверна!) или как необходимости дополнительных усилий для реализации всех ограничений,
определённых в предметной области (дополнительный программный код в виде триггеров или храни-
мых процедур).
Так как аномалии проявляют себя при выполнении операций, изменяющих состояние базы данных,
то различают следующие виды аномалий:
аномалии вставки (INSERT);
аномалии обновления (UPDATE);
аномалии удаления (DELETE).
В отношении
СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ
можно привести примеры следующих анома-
лий.
Аномалии вставки
(
INSERT
). В отношение
СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ
нельзя вста-
вить данные о сотруднике, который пока не участвует ни в одном проекте. Действительно, если, напри-
мер, во втором отделе появляется новый сотрудник, скажем, Пушников и он пока не участвует ни в од-
ном проекте, то мы должны вставить в отношение кортеж (4, Пушников, 2, 33-22-11, null, null, null). Это
сделать невозможно, так как атрибут
Н_ПРО
(номер проекта) входит в состав потенциального ключа и,
следовательно, не может содержать null-значений.
Точно так же нельзя вставить данные о проекте, над которым пока не работает ни один сотрудник.
Причина аномалии хранение в одном отношении разнородной информации (и о сотрудниках, и
о проектах, и о работах по проекту).
Вывод. Логическая модель данных неадекватна модели предметной области. База данных, осно-
ванная на такой модели, будет работать неправильно.
Аномалии обновления
(
UPDATE
). Фамилии сотрудников, наименования проектов, номера теле-
фонов повторяются во многих кортежах отношения. Поэтому если сотрудник меняет фамилию, или
проект меняет наименование, или меняется номер телефона, то такие изменения необходимо одновре-
менно выполнить во всех местах, где эта фамилия, наименование или номер телефона встречаются,