Л. Партыка, И. И. Попов системы управления базами данных

Рассмотрим ИМД на примере предприятия (рис. 2.2): предприятие состоит из отделов, в которых работают сотрудники. В каждом отделе может работать несколько сотрудников, но сотрудник не может работать более чем в одном отделе.

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

Для автоматизации учета контрактов с заказчиками необходимо создание еще одной иерархической структуры: заказчик — контракты с ним — сотрудники, задействованные в работе над контрактом. Это дерево будет включать записи Заказчик (Наименование заказчика, Адрес), Контракт (Номер, Дата, Сумма), Исполнитель (Фамилия, Должность, Наименование отдела)  (рис. 2.2, б).

Рис. 2.2. Модель данных предприятия

Из этого примера видны недостатки иерархических БД.

Во-первых, частично дублируется информация между записями Сотрудник и Исполнитель (такие записи называют парными), причем в иерархической модели данных не предусмотрена поддержка соответствия между парными записями.

Иерархическая модель реализует отношение между исходной и дочерней записями по схеме 1:N, т. е. одной родительской записи может соответствовать любое число дочерних. Допустим теперь, что исполнитель может принимать участие более чем в одном контракте (т. е. возникает связь типа M:N). В этом случае в базу данных необходимо ввести еще одно групповое отношение, в котором Исполнитель будет являться исходной записью, а Контракт — дочерней (рис. 2.2, в). Таким образом, мы опять вынуждены дублировать информацию.

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

Далее, в связи с поли иерархичностью связей объектов в реальном мире в подобных БД необходимо создавать и поддерживать несколько иерархических отношений, что нарушает основную идею модели данных. Рассматриваемая модель характерна рядом так называемых «парадоксов», наиболее очевидным из которых является «парадокс исключения». Удаление из БД некоторого вышестоящего сегмента приводит к автоматическому удалению и всех зависимых (порожденных сегментов).

Преимущества иерархической модели: