Иерархическая и сетевая модели данных

В иерархической модели база данных представляется в виде иерархически упорядоченных структур – деревьев (диаграммы Бахмана).

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

корень

2-й уровень

Пример, описание ННГУ в иерархической модели выглядит так 2 уровень.

Корень дерева Вуз

Уровень 1. Университет вершины

Уровень 2. Финансовый ф-т Мехмат

связи

Уровень 3. Группа 1311

Уровень 4. Иванов И.И.

Рис. 4.3. Иерархическая модель

Ниже перечислены преимущества иерархической модели.

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

· Использование отношений предок/потомок. СУБД позволяет легко представлять отношения подчиненности, например: «А является частью В» или «А владеет В».

· Быстродействие. В СУБД отношения предок/потомок реализованы в виде физических указателей из одной записи на другую, вследствие чего перемещение по базе данных происходило быстро.

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

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

Недостатки иерархических БД:

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

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

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

· Изменение структуры данных требует перестройки всей системы указателей на записи.

Чтобы получить доступ к данным, содержащимся в базе данных, СУБД может:

· найти конкретный объект (Финансовый факультет) по его номеру;

· перейти «вниз» к первому потомку (Группа 13101);

· перейти «вверх» к предку (Университет);

· перейти «в сторону» к другому потомку (Мехмат).

Таким образом, для чтения данных из иерархической базы данных требуется перемещаться по записям, за один раз переходя на одну запись вверх, вниз или в сторону.

Поддерживается только целостность связей между владельцами и членами группового отношения (никакой потомок не может существовать без предка).

Типичным представителем иерархической модели является СУБД Information Management System (IМS) фирмы IBM. Первая версия появилась в 1968 г.

В сетевой модели БД изображается в виде графа произвольной структуры (рис 11.4.).

А В С Д Е Рис. 11.4.

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

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

Каждый экземпляр группового отношения характеризуется следующими признаками:

1. способ упорядочения подчиненныхзаписей:

- произвольный,

- хронологический /очередь/,

- обратный хронологический /стек/,

- сортированный.

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

2. режим включения подчиненныхзаписей:

- автоматический - невозможно занести в БД запись без владельца;

- ручной - позволяет запомнить в БД подчиненную запись и не включать ее немедленно в экземпляр группового отношения. Эта операция позже инициируется пользователем.

3. режим исключения

Принято выделять три класса членства подчиненных записей в групповых отношениях:

1. Фиксированное. Подчиненная запись жестко связана с записью владельцем и ее можно исключить из группового отношения, только удалив. При удалении записи-владельца все подчиненные записи автоматически тоже удаляются.

2. Обязательное. Допускается переключение подчиненной записи на другого владельца, но невозможно ее существование без владельца. Для удаления записи-владельца необходимо, чтобы она не имела подчиненных записей с обязательным членством. Таким отношением связаны записи "СОТРУДНИК" и "ОТДЕЛ". Если отдел расформировывается, все его сотрудники должны быть либо переведены в другие отделы, либо уволены.

3. Необязательное. Можно исключить запись из группового отношения, но сохранить ее в базе данных, не прикрепляя к другому владельцу. При удалении записи-владельца ее подчиненные записи - необязательные члены сохраняются в базе, не участвуя более в групповом отношении такого типа. Примером такого группового отношения может служить "ВЫПОЛНЯEТ" между "СОТРУДНИКИ" и "КОНТРАКТ", поскольку в организации могут существовать работники, чья деятельность не связана с выполнением каких-либо договорных обязательств перед заказчиками.

Как и в иерархической модели обеспечивается только поддержание целостности по ссылкам (владелец отношения - член отношения).

Сетевые базы данных обладали рядом преимуществ:

· Гибкость. Множественные отношения предок/потомок позволяли хранить данные, структура которых была сложнее простой иерархии.

· Стандартизация. Появление стандарта CODASYL обеспечили популярность сетевой модели.

· Быстродействие. Вопреки своей большой сложности, сетевые базы данных достигли быстродействия, сравнимого с быстродействием иерархических баз данных. Множества были представлены указателями на физические записи данных.

Конечно, у сетевых баз данных были недостатки. Как и иерархические базы данных, сетевые базы данных были очень жесткими. Наборы отношений и структуру записей приходилось задавать наперед. Изменение структуры базы данных обычно означало перестройку всей базы данных.

Как иерархическая, так и сетевая база данных были инструментами программистов. Чтобы получить ответ на вопрос типа: «Какой товар наиболее часто заказывает компания Паровые машины?», программисту приходилось писать программу для навигации по базе данных. Реализация пользовательских запросов часто затягивалась на недели и месяцы, и к моменту появления программы информация, которую она предоставляла, часто оказывалась бесполезной.

Типичным представителем является Integrated Database Management System (IDMS) компании Cиllinet Software, Inc.

Практически все существующие СУБД в наше время используют реляционную модель данных.