Аномалии БД

 
 

     Универсальные отношения

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

     Пример. Отношение «Сотрудник»

Номер сотрудника	ФИО сотрудника	Должность	Номер отдела	Наименование  отдела	Квалификация  сотрудника
325	Иванов И.И.	Программист	128	Отдел проектирования	C#, VB
567	Сергеева С.С.	Администратор БД	42	Финансовый  отдел	DB2
225	Петров П.П.	Программист	128	Отдел проектирования	Java, VB
976	Николаев Н.Н.	Системный администратор	128	Отдел проектирования	Windows, Lunix

 

     В данном отношении хранятся вместе независимые друг от друга данные - и данные о сотрудниках, и об отделах.

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

     ·     избыточность данных;

     ·     аномалии обновления. 

     Избыточность  данных

     Под избыточностью понимают дублирование данных в разных кортежах (строках) отношения БД.

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

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

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

     Аномалии  обновления 

     Различают три вида аномалий в базе данных:

• аномалии включения;
• аномалии удаления;
• аномалии модификации.

 

     Аномалии  включения

     Аномалии  включения проявляются при вводе новых данных в отношение с избыточностью данных.

     Рассмотрим  аномалию включения на примере отношения  «Сотрудник». Аномалия включения  возникает при попытке создать «отдел внедрения разработок» и ввести ее в отношение при том условии, что в нее еще не переведен ни один сотрудник. Ввод такой информации в подобной ситуации требует присвоения значения NULL всем атрибутам описания сотрудника, в том числе и атрибуту Номер сотрудника, который является первичным ключом данного отношения. Но реализация такой попытки приведет к нарушению целостности, а значит, система ее обязана отклонить. 
 

     Аномалии  удаления

     Принцип аномалии удаления состоит в том, что при удалении некоторых данных  из отношения может произойти  потеря других данных.

     Например, вернемся к анализу отношения  «Сотрудник». Предположим, что все  сотрудники отдела 128 уволились в  один и тот же день. После удаления кортежей этих сотрудников в БД больше не будет ни одной записи, содержащей информацию об отделе 128. Такая ситуация представляет собой аномалию удаления. 

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

     Предположим, например Петров, временно прекратил поставки деталей? Если мы удалим все кортежи, в которых хранится информация о поставках этого поставщика, то мы потеряем данные о самом Петрове как потенциальном поставщике. Выйти из этого положения, оставив в отношении кортеж типа (2, Петров, NULL, NULL, NULL) мы не можем, т.к. атрибут "Номер детали" входит в состав потенциального ключа и не может содержать null-значений. То же самое произойдет, если некоторая деталь временно не поставляется никаким поставщиком. Получается, что мы не можем хранить информацию о том, что есть некий поставщик, если он не поставляет хотя бы одну деталь, и не можем хранить информацию о том, что есть некоторая деталь, если она никем не поставляется. 
 
 
 

     Аномалия  модификации

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

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

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

     Декомпозиция  отношений

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

     Процесс декомпозиции следует всегда начинать со следующих операций:

• с определения (идентификации) всех атрибутов, подлежащих хранению в БД.
• установления между ними функциональных зависимостей.

 

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

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

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

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

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