Иерархическая модель базы данных — это модель данных , в которой данные организованы в древовидную структуру. Данные хранятся в виде записей , которые связаны друг с другом посредством ссылок . Запись — это набор полей, каждое из которых содержит только одно значение. Тип записи определяет, какие поля содержит запись.
Иерархическая модель базы данных предписывает, чтобы каждая дочерняя запись имела только одну родительскую запись, тогда как каждая родительская запись может иметь одну или несколько дочерних записей. Чтобы извлечь данные из иерархической базы данных, необходимо обойти все дерево, начиная с корневого узла. Эта модель признана первой моделью базы данных, созданной IBM в 1960-х годах. [ необходима цитата ]
Когда появилась реляционная модель базы данных , одним из критических замечаний к иерархическим моделям баз данных была их тесная зависимость от реализации, специфичной для приложения. Это ограничение, наряду с простотой использования реляционной модели, способствовало популярности реляционных баз данных, несмотря на их изначально более низкую производительность по сравнению с существующими сетевыми и иерархическими моделями. [1]
Иерархическая структура была разработана IBM в 1960-х годах и использовалась в ранних мэйнфреймовых СУБД . Связи записей образуют древовидную модель. Эта структура проста, но негибка, поскольку связь ограничивается отношением «один ко многим». IBM Information Management System (IMS) и RDM Mobile являются примерами иерархической системы баз данных с несколькими иерархиями по одним и тем же данным.
Иерархическая модель данных потеряла популярность, поскольку реляционная модель Кодда стала фактическим стандартом, используемым практически всеми основными системами управления базами данных. Реализация иерархической модели на основе реляционной базы данных впервые обсуждалась в опубликованной форме в 1992 году [2] (см. также модель вложенных наборов ). Схемы иерархической организации данных вновь появились с появлением XML в конце 1990-х годов [3] (см. также база данных XML ). Иерархическая структура в настоящее время используется в основном для хранения географической информации и файловых систем. [ необходима цитата ]
В настоящее время иерархические базы данных по-прежнему широко используются, особенно в приложениях, требующих очень высокой производительности и доступности, таких как банковское дело, здравоохранение и телекоммуникации. Одной из наиболее широко используемых коммерческих иерархических баз данных является IMS. [4] Другим примером использования иерархических баз данных является реестр Windows в операционных системах Microsoft Windows . [5]
Организация может хранить информацию о сотрудниках в таблице , содержащей атрибуты/столбцы, такие как номер сотрудника, имя, фамилия и номер отдела. Организация предоставляет каждому сотруднику компьютерное оборудование по мере необходимости, но компьютерное оборудование может использоваться только тем сотрудником, которому оно назначено. Организация может хранить информацию о компьютерном оборудовании в отдельной таблице, которая включает серийный номер каждой детали, тип и сотрудника, который ее использует. Таблицы могут выглядеть следующим образом:
В этой модели employeeтаблица данных представляет собой «родительскую» часть иерархии, в то время как computerтаблица представляет собой «дочернюю» часть иерархии. В отличие от древовидных структур, обычно встречающихся в алгоритмах компьютерного программного обеспечения, в этой модели дети указывают на родителей. Как показано, каждый сотрудник может владеть несколькими единицами компьютерного оборудования, но каждая отдельная единица компьютерного оборудования может иметь только одного владельца-сотрудника.
Рассмотрим следующую структуру:
В этом случае "дочерний" элемент имеет тот же тип, что и "родительский". Иерархия, в которой EmpNo 10 является начальником 20, а 30 и 40 каждый подчиняется 20, представлена столбцом "ReportsTo". В терминах реляционной базы данных столбец ReportsTo является внешним ключом, ссылающимся на столбец EmpNo. Если бы тип данных "дочернего" элемента был другим, он был бы в другой таблице, но все равно был бы внешний ключ, ссылающийся на столбец EmpNo таблицы employees.
Эта простая модель широко известна как модель списка смежности и была введена доктором Эдгаром Ф. Коддом после того, как появились первоначальные критические замечания о том, что реляционная модель не может моделировать иерархические данные. [ необходима цитата ] Однако эта модель является лишь частным случаем общего списка смежности для графа.
