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

Среди множества целей, стоящих перед проектированием, следующие представляются наиболее важными:

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

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

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

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

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

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

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

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

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

С – Н С - Н

Слж#	Начк		Слж#	Начк
	Иванов		Иванов
	Петров		Петров
	Петров		-
	Иванов		-

а) б)

Рис.3. Дублирование данных, не являющихся избыточными

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

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

С-Н-Т С-Н-Т

Слж#	Начк	Нтел		Слж#	Начк	Нтел
	Иванов			Иванов
	Петров			Петров
	Петров			Петров	-
	Иванов			Иванов	-

а) б)

С – Н Н - Т

Слж#	Начк		Начк	Нтел
	Иванов	Иванов
	Петров	Петров
	Петров
	Иванов

в)

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

На рис.4,б приведен пример того, как будет выглядеть отношение С-Н-Т в случае замещения дублированных телефонных номеров "нулями".

Данный метод устранения избыточности неудовлетворен по двум причинам. Во-первых, пустых полей в БД следует избегать, так как необходимы дополнительные усилия при программировании, направленные на определение реальных значений "нулей". В рассматриваемом случае чтение третьего кортежа <195, Петров> отношения не позволяет узнать телефонный номер Петрова. Пользователь должен уметь находить в отношении другой кортеж, для которого значение атрибута Начк является Петров, а значение атрибута Нтел не является нулевым. Во-вторых, что более важно, отношение, представленное на рис.4,б, имеет структуру, чреватую возникновением серьезных проблем при удалении информации. Если служащий с номером Слж#=125 увольняется с предприятия и кортеж <125, Иванов, 3051> будет удален из отношения произойдет утеря телефонного номера Иванова, поскольку нигде более в отношении он не представлен.

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

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

Как следует из рис.4,в, служащий с номером 125 теперь может быть удален из отношения С-Н без потери номера телефона бывшего начальника этого служащего, хранимого в отношении Н-Т.

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

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

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

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

Цели 3 и 4 противоречат друг другу, поэтому здесь требуется взаимный компромисс. Это будет частью завершающего этапа проектирования.

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

Рассматриваемый метод проектирования называют декомпозиционным методом.

Универсальное отношение

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

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

Имена и условия, связанные с атрибутами, хранение которых предполагается, определим следующим образом:

Сном: Номер студента. Целое значение, уникальное для каждого студента института.

Сфам: Фамилия студента. Каждый студент имеет только одну фамилию, но возможно, что одну фамилию носят несколько студентов.

Кном: Номер комнаты в общежитии. В одной комнате может проживать более одного студента.

Тном: Номер телефона студента. Каждая комната общежития имеет один телефон и им пользуются все студенты, проживающие в этой комнате.

Дисц: Название дисциплины. В БД будут храниться данные о дисциплинах, по которым проведена итоговая аттестация студента.

Семестр: Институтский семестр. Представляет собой семестр, в котором данная дисциплина была завершена студентом.

Возможно, что студент изучал одну и ту же дисциплину в различных семестрах.

Оценка: Оценка за дисциплину. Оценка, полученная студентом за определенную дисциплину в данном семестре.

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

УСПЕВАЕМОСТЬ

Сном	Сфам	Кном	Тном	Дисц.	Сем.	Оценка
	Серов			ВМ
				ТМ
				Физика
	Перов			ВМ
				Химия
				ВТ
	Иванов			ТМ
	Поляков			ВМ

 

Рис.5. Данные для размещения в БД

Для иллюстрации того, почему таблица на рис.5 не является отношением, выделим одну "строку" из таблицы (рис.6).

	Серов			ВМ
	ТМ
Физика

Рис.6. Одна "строка" таблицы, приведенной на рис.5.

На этом рисунке значения четырех полей Сном, Сфам, Кном и Тном - атомарные (атомарным называется неделимое значение, а не множество, или кортеж, значений из некоторых доменов), в то время как значения в полях Дисциплина, Семестр и Оценка - множественные.

Данная "строка" очевидным образом отличается по форме от кортежей. Отличие в том, что не все поля строки содержат атрибуты, значения которых атомарные. Для придания данным, приведенным на рис.5, формы отношения необходимо реконструировать их таким образом, чтобы каждый элемент кортежа имел атомарное значение. Обычно это удается сделать с помощью простого процесса вставки (результат для данного случая показан на рис.7). В результате этого процесса добавляется большой объем избыточных данных – исключение избыточности достигается на следующих этапах проектирования.

 

УСПЕВАЕМОСТЬ

Сном	Сфам	Кном	Тном	Дисц.	Сем.	Оценка
	Серов			ВМ
	Серов			ТМ
	Серов			Физика
	Перов			ВМ
	Перов			Химия
	Перов			ВТ
	Иванов			ТМ
	Поляков			ВМ

Рис.7. Данные из таблицы, приведенной на рис.5, помещенные в корректное отношение.

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

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