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

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

Каждый экземпляр дерева называется групповым отношением, корневая запись называется владельцем группового отношения, а все дочерние записи – членами группового отношения.

Говорят, что иерархическая модель реализует отношение «один-ко-многим» (one-to-many) между исходной и дочерней записью, поскольку каждому экземпляру исходной записи соответствует несколько экземпляров дочерних записей. Такое отношение обозначается как 1:М или 1:N.

Например, в каждом подразделении предприятия может работать несколько («много») сотрудников, но каждый сотрудник принадлежит только одному подразделению.

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

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

Кроме отношения «один-ко-многим» (1:M), довольно распространенным на практике является отношение «многие-ко-многим» (M:M, many-to-many). Например, в приведенном примере с подразделениями и их сотрудниками бизнес-правила предприятия могут допускать возможность работы сотрудника и в нескольких подразделениях одновременно. Такого сотрудника придется включить в экземпляры деревьев для всех подразделений, в которых он работает. То же самое можно сказать и об отношении «сотрудники - дети», поскольку возможна ситуация, когда оба родителя ребенка работают на одном предприятии и даже в одном подразделении. Таким образом, возникает дублирование информации.

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

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

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

2. Сетевая модель данных

Сетевая модель данных определяется в тех же терминах, что и иерархическая. Она состоит из множества записей, которые могут быть владельцами или членами групповых отношений. Связь между записью-владельцем и записью-членом также имеет вид 1:М.

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

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

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

Очевидно, в силу указанных выше недостатков, сетевые СУБД практически прекратили свое существование.

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