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