Проблемы проектирования базы данных

метки: Проектирование, Проблема, Данные, Телефон, Отношение, Информация, Система, Сотрудник

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

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

В задачи проектирования БД входит:

1. Обеспечение хранения в БД всей необходимой информации.
2. Обеспечение получения всей необходимой информации по всем необходимым запросам.
3. Сокращения избыточности и повтора данных.
4. Обеспечения целостности данных, правильности их содержания.
5. Недопустимость содержания в данных противоречий.
6. Исключение потери данных

1. Проблемы проектирования баз данных.

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

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

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

При проектировании структур данных для автоматизированных систем можно выделить три основных подхода.

1. Сбор информации об объектах решаемой задачи в рамках одной таблицы (одного отношения) и последующая декомпозиция ее на несколько взаимосвязанных таблиц на основе процедуры нормализации отношений.
2. Формулирование знаний о системе (определение типов исходных данных и их взаимосвязей) и требований к обработке данных, получение с помощью CASE-системы (системы автоматизации проектирования и разработки баз данных) готовой схемы БД или даже готовой прикладной информационной системы.
3. Структурирование информации для использования в информационной системе в процессе проведения системного анализа на основе совокупности правил и рекомендаций.

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

Курсовая 4. Проектирование информационной системы Драматический ...

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

К ним относятся такие проблемы как: избыточное дублирование данных, аномалии и проблема формирования исходного отношения. Рассмотрим каждую из них подробнее.

1.1 Избыточное дублирование данных.

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

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

Пример избыточного дублирования представляет приведенное на рис. 5 а отношение С_Т_Н, которое, в отличие от отношения С_Т, дополнено атрибутом Н_комн (номер комнаты сотрудника).

Естественно предположить, что все служащие в одной комнате имеют один и тот же телефон.

Сотрудник	Телефон
Иванов	3721
Петров	4328
Сидоров	4328
Егоров	4328

Рис. 1 Не избыточное дублирование

Следовательно, в рассматриваемом отношении С_Т имеется избыточное дублирование данных. Так, в связи с тем, что Сидоров и Егоров находятся в той же комнате, что и Петров, то их номера можно узнать из кортежа со сведениями о Петрове. На рис. 2б приведен пример неудачного отношения С_Т_Н, в котором вместо телефонов Сидорова и Егорова поставлены «прочерки» (неопределенные значения).

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

	С_Т_Н				С_Т_Н
а)	Сотрудник	Телефон	№ комн	Б)	Сотрудник	Телефон	№ комн
	Иванов И.М.	3721	109		Иванов И.М.	3721	109
	Петров М.И.	4328	111		Петров М.И.	4328	111
	Сидоров Н.Г.	4328	111		Сидоров Н.Г.	—	111
	Егоров В.В.	4328	111		Егоров В.В.	—	111

Рис. 2 Избыточное дублирование

Возможный способ выхода из данной ситуации приведен на рис. 3.

Т_Н			С_Н
Телефон	№ комн.		Сотрудник	№ комн.
3721	109		Иванов И.М.	109
4328	111		Петров М.И.	111
			Сидоров Н.Г.	111
			Егоров В.В.	111

Рис. 3 Исключение избыточного дублирования

Здесь показаны два отношения С_Н и Н_Т, полученные путем декомпозиции исходного отношения С_Т_Н. Первое из них содержит информацию о номерах комнат, в которых располагаются сотрудники, а второе — информацию о номерах телефонов в каждой из комнат. Теперь, если Петрова и уволят из учреждения и, как следствие этого, удалят всякую информацию о нем из баз данных учреждения, то это не приведет к утере информации о номере телефона в 111-й комнате.

Процедура декомпозиции отношения С_Т_Н на два отношения С_Н и Н_Т является основной процедурой нормализации отношений.

Избыточное дублирование данных создает проблемы при обработке кортежей отношения, названные Э. Коддом «аномалиями обновления отношения». Он показал, что для некоторых отношений проблемы возникают при попытке удаления, добавления или редактирования их кортежей.

1.2 Аномалии.

Аномалиями будем называть такую ситуацию в таблицах БД, которая приводит к противоречиям в БД либо существенно усложняет обработку данных

Выделяют три основные вида аномалий: аномалии модификации (или редактирования), аномалии удаления и аномалии добавления.

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

Так, например, изменение номера телефона в комнате 111 (рис.2а), что представляет собой один единственный факт, потребует просмотра всей таблицы С_Т_Н и изменения поля № комн согласно текущему содержимому таблицы в записях, относящихся к Петрову, Сидорову и Егорову.

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

В той же таблице С_Т_Н удаление записи о сотруднике Иванове (например, по причине увольнения или ухода на заслуженный отдых) приводит к исчезновению информации о номере телефона, установленного в 109-й комнате.

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

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

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

Проектирование БД начинается с определения всех объектов, сведения о которых будут включены в базу, и определения их атрибутов. Затем атрибуты сводятся в одну таблицу — исходное отношение.

Пример. Формирование исходного отношения.

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

ФИО — фамилия и инициалы преподавателя. Исключаем возможность соления фамилии и инициалов у преподавателей.

Должн — должность, занимаемая преподавателем.

Оклад — оклад преподавателя.

Стаж — преподавательский стаж.

Д_Стаж — надбавка за стаж.

Д_Каф — номер кафедры, на которой числится преподаватель.

Предм — название предмета (дисциплины), читаемого преподавателем.

Группа — номер группы, в которой преподаватель проводит занятия.

ВидЗан — вид занятий, проводимых преподавателем в учебной группе.

Одно из требований к отношениям заключается в том, чтобы все атрибуты отношения имели атомарные (простые) значения. В исходном отношении каждый атрибут кортежа также должен быть простым. Пример исходного отношения ПРЕПОДАВАТЕЛЬ приведен на рис. 4.

Указанное отношение имеет следующую схему ПРЕПОДАВАТЕЛЬ(ФИО, Должн, Оклад, Стаж, Д_Стаж, Каф, Предм, Группа, ВидЗан).

Исходное отношение ПРЕПОДАВАТЕЛЬ содержит избыточное дублирование данных, которое является причиной аномалий редактирования. Различают избыточность явную и неявную.

Явная избыточность заключается в том, что в отношении ПРЕПОДАВАТЕЛЬ строки с данными о преподавателях, проводящих занятия в нескольких группах, повторяются соответствующее число раз. Например, в отношении ПРЕПОДАВАТЕЛЬ все данные по Иванову повторяются дважды. Поэтому, если Иванов И.М. станет старшим преподавателем, то этот факт должен быть отражен в обеих строках. В противном случае будет иметь место противоречие в данных, что является примером аномалии редактирования обусловленной явной избыточностью данных в отношении.

Неявная избыточность в отношении ПРЕПОДАВАТЕЛЬ проявляется в одинаковых окладах у всех преподавателей и в одинаковых добавках к окладу за одинаковый стаж. Поэтому, если при изменении окладов за должность с 500 на 510 это значение изменят у всех преподавателей, кроме, например, Сидорова, то база станет противоречивой. Это пример аномалии редактирования для варианта с неявной избыточностью.