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

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

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

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

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

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

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

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

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

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

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

С – Н С - Н

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

а) б)

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

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

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

С-Н-Т С-Н-Т

Слж#	Начк	Нтел		Слж#	Начк	Нтел
125	Иванов	3051		125	Иванов	3051
138	Петров	2222		138	Петров	2222
195	Петров	2222		195	Петров	-
200	Иванов	3051		200	Иванов	-

а) б)

С – Н Н - Т

Слж#	Начк		Начк	Нтел
125	Иванов		Иванов	3051
138	Петров		Петров	2222
195	Петров
200	Иванов

в)

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

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

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

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

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

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

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

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

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

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

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