Цели проектирования реляционных БД

Раздел 4. Проектирования БД

Метод нормальных форм

В жизненном цикле БД одним из наиболее важных этапов является этап проектирования. Главная задача, которая решается в процессе проектирования – это организация данных: интегрирование, структурирование и определение взаимосвязей.

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

На втором этапе разрабатывается концептуальная модель, которая диктует выбор СУБД. Если мы выбрали реляционную модель, то данные представляются в таблице, затем проводится декомпозиция этой таблицы на несколько взаимосвязанных таблиц на основе нормализации отношений, т.е. определяются таблицы, из которых будет состоять БД.

Цели проектирования реляционных БД

Возможность хранения всех необходимых данных в БД

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

Исключение избыточных данных.

Суть в том, что надо различать дублирование данных и избыточное дублирование данных.

Рассмотрим на примере.

П-3
НП (номер преподавателя)	ЗавК (фамилия завкафедрой)
	Шеломов
	Вагнер
	Вагнер
	Шеломов

П-3
НП (номер преподавателя)	ЗавК (фамилия завкафедрой)
	Шеломов
	Вагнер

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

Фамилии повторяются, но это повторение не является избыточным, т.к. удаление повторяющихся фамилий приведет к потере информации о фамилии завкафедры для преподавателей с номером 108 и 123.

Пример отношений с избыточным дублированием данных.

П-3-Т

П-3

З-Т

НП

ЗавК

Нтел

НП

ЗавК

Нтел

НП

ЗавК

Нтел

Шеломов

Вагнер

Шеломов

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

Следует избегать пустых полей
Здесь возникает проблема при удалении информации. Если преподаватель с номером 102 будет удален, то и кортеж <102, Шеломов, 2888 > будет тоже удален, номер телефона Шеломов утерян, т.к. нигде больше не представлен.

Чтобы исключить избыточность телефонных номеров необходимо представить отношение П-3-Т в виде 2-х отношений П-3 и З -Т, потери номера при этом не произойдет.

Сведение числа хранимых в БД отношений к минимальному.

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

Нормализация отношений.

Для некоторых отношений важна проблема удаления и обновления, при которой может произойти потеря информации, поэтому необходимо обнаруживать такие отношения и нормализовать их. Э.Коддом эти проблемы были названы «аномалии обновления отношения».

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

Список аномалий, которые могут встретиться:

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

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

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

· Аномалия обновления проявляется в том, что изменение значения одного данного потребует просмотра всей таблицы и соответствующего изменения других записей. Изменив тел у Вагнера, надо просмотреть всю таб и внести изменения. (исходная таб.)

· Аномалия удаления состоит в том, что при удалении некого данного может пропасть и другая информация не связанная с ним. Удалив номер тел Шеломова, мы потеряем сотрудника 102.

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

На первом этапе проектирования создана однотабличная база данных.

Таблица 1 Отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ

Н_СОТР	ФАМ	Н_ОТД	ТЕЛ	Н_ПРО	ПРОЕКТ	Н_ЗАДАН
1	Иванов		11-22-33	1	Космос
1	Иванов		11-22-33	2	Климат
2	Петров		11-22-33	1	Космос
3	Сидорова		33-22-11	1	Космос
3	Сидорова		33-22-11	2	Климат

Даже одного взгляда на таблицу отношения СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ достаточно, чтобы увидеть, что данные хранятся в ней с большой избыточностью. Во многих строках повторяются фамилии сотрудников, номера телефонов, наименования проектов. Кроме того, в данном отношении хранятся вместе независимые друг от друга данные: данные о сотрудниках, об отделах, о проектах, о работах по проектам. Пока никаких действий с отношением не производится, это не страшно. Но как только состояние предметной области изменяется, то, при попытках соответствующим образом изменить состояние базы данных, возникает большое количество проблем.