Лекция 4 Цели проектирования баз данных

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

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

Проектирование баз данных выполняется с целью:

1. Обеспечения возможности хранения в базе данных всех необходимых данных.

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

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

4. Нормализация отношения для упрощения проблем, связанных с модификацией данных.

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

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

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

Рассмотрим подробнее проблемы, связанные с использованием единственного отношения, и причины, по которым проектировщики стремятся привести отношения, составляющие БД, к НФБК.