Среди множества целей, стоящих перед проектированием, следующие представляются наиболее важными:
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 противоречат друг другу, поэтому здесь требуется взаимный компромисс. Это будет частью завершающего этапа проектирования.
