Иерархическая база данных — это модель данных, в которой записи организованы в виде дерева со связями родитель-потомок, причем у каждого потомка ровно один родитель. Так проще всего описывать вложенность: разделы и подразделы, папки и файлы, отделы и сотрудники. Ниже разберем, как устроено такое дерево, какие у модели связи и ограничения, где ее реально применяют (от IBM IMS до файловых систем и LDAP), в чем плюсы и минусы и чем она отличается от реляционной, сетевой и графовой моделей.
Содержание
Как устроена иерархическая модель данных
Данные в иерархической модели хранятся как дерево из узлов. Один узел — это запись (в терминах IBM IMS — сегмент), то есть набор именованных полей. Узлы соединены связями по принципу «сверху вниз».
У дерева есть несколько обязательных элементов:
- Корень (root) — единственный верхний узел, у него нет родителя. С него начинается любой обход дерева.
- Родитель (parent) — узел, у которого есть подчиненные записи.
- Потомок (child) — подчиненный узел. У него всегда ровно один родитель.
- Лист (leaf) — узел без потомков, конец ветки.
Ключевое правило: у потомка может быть только один родитель, а у родителя — сколько угодно потомков. Поэтому иерархическая модель хорошо описывает строгую вложенность и плохо — ситуации, где один объект относится сразу к нескольким «владельцам».
Связи 1:N и почему нет «многие ко многим»
Связь в иерархии — это всегда «один ко многим» (1:N): один родитель, много детей. Прямой связи «многие ко многим» (M:N) модель не поддерживает. Например, если один студент ходит на несколько курсов, а на каждом курсе много студентов — это M:N, и в чистое дерево оно не укладывается: студенту пришлось бы иметь двух родителей.
Обойти это можно только дублированием данных либо искусственными ссылками между деревьями. Оба варианта усложняют поддержку — одна из причин, почему на смену иерархической модели пришли сетевая и позже реляционная.
Важное следствие 1:N — целостность связей: потомок не существует без родителя. Если удалить родительский узел, вместе с ним из базы исчезает вся его ветка (каскадное удаление). Это удобно, когда подчиненная запись бессмысленна в отрыве от главной (строки заказа без заказа), но требует внимания: удаление узла у корня стирает большое поддерево.
Примеры иерархических баз данных
Модель кажется архаичной, но деревья родитель-потомок окружают нас каждый день. Вот где иерархия работает на практике:
- IBM IMS (Information Management System) — классическая иерархическая СУБД. Ее создали в 1960-х для программы «Аполлон», и IBM до сих пор поддерживает и развивает IMS — она обрабатывает транзакции в банках, страховых и логистике на мейнфреймах z/OS.
- Файловая система — папки и вложенные папки с файлами. У каждого файла один родительский каталог, у каталога — много вложений. Это дерево в чистом виде.
- Реестр Windows — ветки (HKEY_LOCAL_MACHINE и другие), разделы и параметры выстроены строго иерархически.
- LDAP и Active Directory — службы каталогов хранят пользователей, группы и компьютеры в дереве (Directory Information Tree). Путь до объекта (Distinguished Name) — это и есть маршрут от корня.
- DNS — доменные имена образуют дерево: корневая зона, домены верхнего уровня (
.ru,.com), затемotus.ruи поддомены. - XML и JSON — форматы обмена данными хранят дерево: у элемента один родитель и любое число вложенных.
Как выглядит дерево в XML
Иерархию удобно показать разметкой. Возьмем упрощенную структуру школы: директор -> завуч -> учитель -> класс.
<school>
<director name="Иванова">
<deputy name="Петров">
<teacher name="Сидоров">
<class name="10А"/>
</teacher>
</deputy>
</director>
</school>Вложенность тегов и есть связи родитель-потомок. Корень тут — <school>, лист — <class>. Ни один тег не может лежать сразу в двух родителях — это и отражает правило одного родителя.
То же дерево в реляционной базе
В реляционной СУБД дерево обычно хранят одним из способов — через ссылку на родителя (adjacency list). Пример на SQL (проверяется в SQLite или PostgreSQL):
CREATE TABLE org (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL,
parent_id INTEGER REFERENCES org(id) -- NULL только у корня
);
INSERT INTO org VALUES (1, 'Директор', NULL);
INSERT INTO org VALUES (2, 'Завуч', 1);
INSERT INTO org VALUES (3, 'Учитель', 2);
-- прямые потомки завуча (id = 2)
SELECT name FROM org WHERE parent_id = 2; -- вернет: УчительЗдесь иерархию задает столбец parent_id: он ссылается на id родителя, а у корня равен NULL. Разница с настоящей иерархической СУБД в том, что связь тут логическая (по значению ключа), а дерево собирается запросом. В IMS же дерево — это физическая структура хранения, и обход идет по ней напрямую, без соединения таблиц.
Частая ошибка новичка — удалить родителя и забыть про детей:
DELETE FROM org WHERE id = 2; -- удалили завуча
-- строка 'Учитель' осталась с parent_id = 2, ссылка ведет в никудаРезультат: «висячая» запись-сирота, ссылающаяся на несуществующего родителя. Исправление — объявить каскадное удаление, чтобы ветка чистилась вместе с корнем поддерева:
parent_id INTEGER REFERENCES org(id) ON DELETE CASCADEПлюсы и минусы иерархической модели
Сильные стороны:
- Скорость на «своих» запросах. Обход по заранее известному пути (от корня вниз) очень быстрый — не нужны соединения таблиц. Поэтому IMS десятилетиями держит высоконагруженные транзакции.
- Простая и понятная структура. Дерево наглядно ложится на реальную вложенность: оргструктуру, каталог, меню.
- Встроенная целостность 1:N. Потомок не может «повиснуть» без родителя.
Слабые стороны:
- Нет связей «многие ко многим» напрямую. Их приходится моделировать дублированием или ссылками, что ведет к избыточности.
- Жесткость структуры. Изменить схему дерева задним числом трудно, а запросы «не по дереву» (найти всех по произвольному признаку) неудобны и медленны.
- Дублирование данных. Один и тот же объект в разных ветках хранится копиями, их легко рассинхронизировать.
Вывод по применимости: иерархия уместна там, где данные древовидны по природе и читаются сверху вниз. Если связи между объектами богатые и разнонаправленные, лучше подойдет реляционная или графовая модель.
Сравнение с реляционной, сетевой и графовой моделями
| Модель | Как связаны данные | Поддержка M:N | Типичный пример | Когда уместна |
|---|---|---|---|---|
| Иерархическая | Дерево, потомок = один родитель | Нет (только через обход) | IBM IMS, файловая система, DNS | Строгая вложенность, чтение сверху вниз |
| Сетевая | Граф, у записи несколько родителей | Да, но через жесткие наборы | CODASYL, IDMS | Сложные связи на мейнфреймах (исторически) |
| Реляционная | Таблицы, связи по ключам | Да, через таблицу-связку | PostgreSQL, MySQL, Oracle | Универсальные бизнес-данные, произвольные запросы |
| Графовая | Узлы и ребра как равноправные сущности | Да, естественно | Neo4j, ArangoDB | Соцсети, рекомендации, связи «всех со всеми» |
Сетевая модель — прямое развитие иерархической: она разрешила потомку иметь несколько родителей и покрыла M:N, но осталась сложной в поддержке. Реляционная модель вытеснила обе за счет гибкости и SQL. Графовые базы — ответ на задачи с очень плотными связями, где дерево и таблицы неудобны.
Выводы
- Иерархическая база данных хранит данные деревом: один корень, связи родитель-потомок, у каждого потомка ровно один родитель.
- Основная связь — «один ко многим» (1:N); «многие ко многим» напрямую не поддерживается и требует обходных решений.
- Целостность встроена: удаление родителя каскадно удаляет всю ветку, потомок без родителя не существует.
- Модель быстрая на обходах по дереву, но жесткая и склонна к дублированию данных.
- Иерархия жива и сегодня: IBM IMS, файловые системы, реестр Windows, LDAP/Active Directory, DNS, XML и JSON — все это деревья.
- Для универсальных задач с произвольными связями выбирают реляционную модель, для плотных связей — графовую.
Где применяется / связь с практикой
Понимание разных моделей данных — база для любой работы с СУБД: выбирая хранилище под задачу, инженер сначала решает, какая модель ложится на данные (дерево, таблицы или граф), и лишь потом — конкретную систему. На практике чаще всего работают с реляционными базами и SQL, но знание иерархической и графовой моделей помогает не «натягивать» дерево на таблицы и наоборот.
Освойте тему на практике
Разобраться, как проектировать схемы, писать запросы и выбирать модель под задачу, можно на курсе subd. Чтобы попробовать формат и темы до старта, загляните на бесплатные вебинары — там разбирают реальные задачи по базам данных.
Смежные темы: Основы работы с базами данных, Работа с базами данных, База данных в мобильном приложении на примере Realm.
FAQ
Иерархическая база данных устарела — ее еще где-то используют?
Как отдельный класс СУБД она редка, но модель жива: IBM IMS работает в банках и страховых, а деревья лежат в основе файловых систем, DNS, LDAP и форматов XML/JSON.
Чем иерархическая модель отличается от сетевой?
В иерархической у потомка ровно один родитель (чистое дерево), в сетевой — несколько родителей (граф). Сетевая поэтому умеет «многие ко многим», но сложнее в поддержке.
Можно ли хранить дерево в обычной реляционной базе?
Да. Дерево моделируют столбцом-ссылкой на родителя (parent_id), схемой nested set или рекурсивными запросами (WITH RECURSIVE). Это стандартная практика в PostgreSQL и MySQL.
