Цели проектирования

НЕОБХОДИМОСТЬ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ

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

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

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

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

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

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

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

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

Сущность этой цели отнюдь не очевидна для начинающего проектировщика БД. Ключ к ее пониманию заключается в уяснении четкого различия между дублидарованием данных и избыточным дублированием банных. Например, обратимся к отношению С-Н, приведенному на рис. 2.1 (а). Отношение имеет два атрибута - Слж# (табельный номер служащего) и Ншчк (начальник). В отношении содержатся данные, указывающие непосредственного начальника каждого служащего предприятия. Фамилии начальников могут неоднократно появляться в отношении. В действительности фамилия начальника появляется один раз для каждого подчиненного ему служащего. Обратите внимание, однако, что хотя " Шевченко " и " Иванов " появляются дважды в экземпляре С—Н, приведенном в на рис 2. На), ни одна из дублируемых фамилий не является избыточной. Причина отсутствия избыточности включается в том, что при удалении одной из фамилий из отношения будет утеряна информация. Например, на рис 2.1(6) показан вид экземпляра отношения С-Н при удалении дублированных фамилий. В этом случае нет возможности узнать фамилии начальников служащих с номерами # 195 и # 200.

С-Н С-Н

Слж#	Начк		Слж#	Начк
	Шевченко			Шевченко
	Иванов			Иванов
	Иванов		Т95	-
	Шевченко			-

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

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

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

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

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

С-Н-Т

С-Н-Т

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

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

а   С-Н  

б   Н-Т

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

Начк	Нтел
Шевченко
Иванов

в

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

фамилиях руководителей, а другое - информацию о телефонных номерах начальников.

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

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

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

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

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

Дата добавления: 2014-10-15