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

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

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

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

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

4.1.1. Цели проектирования реляционных бд

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

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

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

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

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

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

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

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

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

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

П-3-Т				П-3-Т				П-3			З-Т
НП	ЗавК	Нтел		НП	ЗавК	Нтел		НП	ЗавК		ЗавК	Нтел
102	Шеломов	2888		102	Шеломов	2888		102	Шеломов		Шеломов	2888
104	Вагнер	2345		104	Вагнер	2345		104	Вагнер		Вагнер	2345
108	Вагнер	2345		108	Вагнер			108	Вагнер
123	Шеломов	2888		123	Шеломов			123	Шеломов

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

• Следует избегать пустых полей

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

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

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

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