Лекция 3. Аномалии хранения данных.

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

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

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

№ зач.	Груп-па	ФИО Студента	Дата рожд.	Шифр Курса	Наименование	Колич. Часов	Оцен-ка	Таб№ преподавателя	ФИО преподавателя
4567	5203	Петров	01.10.80	М	матем.	120	3	10	Сергеев
4567	5203	Петров	01.10.80	Ф	Философия	150	3	45	Афанасьев
4567	5203	Петров	01.10.80	А	англ.	90	4	12	Васильева
4568	5203	Иванов	14.05.79	М	матем.	120	5	10	Сергеев
4568	5203	Иванов	14.05.79	Ф	Философия	150	5	45	Афанасьев
4569	5104	Сидоров	17.08.80	М	матем.	120	4	11	Сазонов
4569	5104	Сидоров	17.08.80	Ф	Философия	150	5	45	Афанасьев
4569	5104	Сидоров	17.08.80	С	Сопромат	100	4	22	Голубев

Рис.6. Отношение «Успеваемость студентов».

Аномалии включения. При попытке включить в базу данных информацию о студенте, который не сдал еще ни одного экзамена, возникает проблема, связанная с тем, что один из компонентов первичного ключа - Шифр Курса не заполнен. Эта ситуация разрешима на уровне приложений, на которые будут накладываться дополнительные требования по обработке пустых значений ключа. Аналогично может быть решена проблема вставки сведений об учебном курсе, по которому еще не поставлено ни одной оценки. Гораздо больше неприятностей разработчику доставит необходимость включения записей с информацией о преподавателях, которые по каким- либо причинам не ведут никакой курс. В случае ввода пустых или нулевых значений ключевых полей возникает ситуация, когда две записи могут иметь одинаковое значение ключа (пустое), что недопустимо. С помощью введения в рассмотрение фиктивных значений ключевых полей эта проблема может быть решена, но при этом требования к приложениям усложняются.

Аномалии удаления. В подобной базе данных рано или поздно возникает необходимость в удалении информации как устаревшей или ненужной. Так, сведения о студенте могут быть удалены по окончании им курса обучения. Представим себе, что существует учебный курс, который читается только непосредственно перед выпуском специалистов. Тогда, удаляя записи со сведениями о выпускнике, мы можем удалить и информацию об этом курсе. Более того – можно потерять и сведения о преподавателе, читающем этот учебный курс. С другой стороны, при попытке удалить сведения о преподавателе, мы неминуемо теряем сведения об оценках студентов. Можно представить себе приложение, которое справится и с этой проблемой, однако сложность его (и затраты на разработку) возрастут настолько, что можно утверждать, что большая часть кода приложения будет посвящена не собственно обработке данных, а «борьбе» со всевозможными аномалиями.

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

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

№ зач.	Груп-па	ФИО Студента	Дата рожд.
4567	5203	Петров	01.10.80
4568	5203	Иванов	14.05.79
4569	5104	Сидоров	17.08.80

Это отношение свободно от каких – либо аномалий. Средством подавления избыточности базы данных является преобразование ее к набору полных декомпозиций. Таким образом, задачу проектирования базы данных можно определить как поиск такой полной декомпозиции исходного универсального отношения, которая при минимальном количестве хранимых отношений (таблиц) обеспечит отсутствие избыточности информации.

Концептуальное проектирование всегда ведется в терминах реляционного представления данных [4]. Вполне понятен такой подход к проектированию в ситуации, когда для реализации проекта предполагается использовать СУБД реляционного типа (в наши дни это 99,999… процентов случаев). Однако, такой подход рекомендован и для иерархического либо сетевого представления данных. Это объясняется тем, что реляционное представление данных опирается на хорошо изученный и развитый аппарат реляционной алгебры, на базе которого были разработаны достаточно формализованные и строгие процедуры проектирования структур данных. Ниже будут рассмотрены два таких алгоритма – т.наз. нормализация и E-R проектирование.