9.3.1Вопросы реляционного проектирования
Первичная разработка базы данных в терминах реляционной модели включает в себя создание отношений, составляющих базу данных. Хотя эта задача может показаться легкой, неосмотрительного программиста поджидает множество ловушек.
Предположим, что к информации, содержащейся в отношении на рис. 9.3, мы хотим добавить данные об обязанностях каждого сотрудника. Это может быть список должностей, состоящий из таких атрибутов, как название должности (JobTitle) (секретарь, делопроизводитель, управляющий этажа), идентификационный код (Jobld — уникальный для каждой должности), код квалификации (SkillCode) для каждой должности, отдел (Dept), которому она принадлежит, и период, в течение которого сотрудник занимал указанную должность, то есть даты начала (StartDate) и окончания (TermDate) работы. (На место даты окончания работы ставится звездочка, если сотрудник в данный момент занимает эту должность.)
9.3.2Системы баз данных для персональных компьютеров
На персональных компьютерах используется огромное количество приложений, от простых до самых сложных. В элементарных «базах данных», предназначенных, например, для хранения рождественских открыток или рекордов лиги боулинга, вместо базы данных часто используются системы табличных вычислений, так как от этих приложений в основном требуется только хранение, печать и сортировка данных. Однако на рынке продуктов для персональных компьютеров есть и достаточно сложные системы баз данных, одной из которых является Microsoft Access. Это полная реляционная система базы данных, обладающая всеми возможностями, рассмотренными в разделе 9.3, и программами для создания диаграмм и отчетов. Основное отличие с точки зрения пользователя заключается в том, что в Access используется графический интерфейс пользователя, позволяющий выражать запросы в графическом виде, а не в виде текстовых операторов SQL. Кроме того, в новых версиях Access предусмотрены функции работы через Интернет, то есть запись в строке может содержать URL, который позволяет сделать доступными данные на связанном с ним веб-узле непосредственно из базы данных.
Один из подходов к решению этой проблемы — расширить отношение на рис. 9.3, включив эти атрибуты в дополнительные столбцы в таблице, как показано на рис. 9.4. Однако внимательное изучение результата обнаруживает несколько проблем. Прежде всего, это неэффективность, происходящая от избыточности.
В отношении теперь не хранится по одной строке для каждого сотрудника, скорее каждая строка представляет период работы одного сотрудника на какой-то определенной должности. Если сотрудник продвигался по службе внутри компании, последовательно занимая несколько должностей, в новом отношении для него будет заведено несколько строк. Проблема в том, что информацию, содержащуюся в исходном отношении (имя (Name), адрес (Address), идентификационный номер (Emplld) и номер социального обеспечения (SSN) каждого сотрудника), приходится дублировать. Например (см. рис. 9.4), личная информация о сотрудниках Бэйкер и Смит повторяется, так как они занимали несколько должностей. Кроме того, если определенную должность занимали несколько сотрудников, отдел, к которому относится эта должность, и соответствующий код квалификации также повторяются в каждой строке, представляющей назначение на данную должность. (Например, информация об управляющем этажа дублируется, так как эту должность занимали несколько сотрудников.)
