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

Ранние модели данных.

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

Прежде, чем рассматривать особенности организации данных в ранних моделях, выделим некоторые общие черты.

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

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

Наконец, третьей характерной чертой является слаборазвитая (по сравнению с реляционными БД) система ограничений целостности.

Иерархическая модель является первой и появилась вместе с наиболее известной СУБД, ее реализующей – системой IMS (Information Management System) разработки компании IBM. Эта СУБД была выпущена в 1968 году и существует и развивается до сих пор.

Как понятно из названия модели, данные в ней организуются в виде иерархии. Данная организация достаточно типична и часто встречается в реальной жизни, так что воплощение ее в СУБД вполне объяснимо. Основными понятиями данной модели являются база данных, сегмент и поле.

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

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

Сегменты образуют между собой связи типа «родитель-потомок». При этом у сегмента может быть произвольное количество потомков, но только один родитель. Конечно, непосредственно связываются между собой экземпляры сегментов. Экземпляры сегмента-потомка, подчиненные одному сегменту-родителю называются близнецами.

В вершине иерархии стоит сегмент, не имеющий родителя – корневой сегмент. Все сегменты в совокупности образуют древовидную структуру, которая и является базой данных. Схема базы данных – это набор таких деревьев.

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

Рисунок 2.1 Пример иерархической организации данных.

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

· найти указанное дерево (например, Вятский государственный университет);

· перейти от одного дерева к другому;

· перейти от экземпляра одного типа записи к экземпляру другого типа записи внутри дерева (например, перейти от вуза к факультету);

· перейти от одной записи к другой в порядке обхода иерархии;

· вставить новую запись в указанную позицию;

· удалить текущую запись.

В иерархических СУБД поддерживаются ограничения целостности одного типа – между родителем и потомком. Любой экземпляр типа записи потомка должен иметь родителя.

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