Блоги

Иерархический справочник: когда данные растут как дерево — 30.06.26 09:00

Представьте дерево. У него есть корень, от него отходят ветки, от больших веток — более мелкие, а затем листья.

Примерно так же устроены иерархические справочники в информационных системах.
И как же можно понять: что есть ветка, а что есть лист в этом иерархическом справочнике?

В канале Аналитика FM я часто разбираю такие ситуации — когда задача вроде решаема, но без нормальной структуры превращается в кашу.

Иерархический справочник: когда данные растут как дерево - 30.06.26 09:00 0

Например:

📁 Транспорт
├── Легковой транспорт
│ ├── Седаны
│ └── Кроссоверы
└── Грузовой транспорт
 ├── Малотоннажный
 └── Тягачи

Или:

📁 Товары
├── Электроника
│ ├── Телефоны
│ └── Ноутбуки
└── Бытовая техника
 ├── Холодильники
 └── Стиральные машины

А как такое дерево хранится в базе данных?

На самом деле всё гораздо проще, чем кажется.

Обычно таблица справочника выглядит примерно так:

| id | name | parent_id |
| — | ———————————— | ————— |
| 1 | Транспорт | NULL |
| 2 | Легковой транспорт | 1 |
| 3 | Грузовой транспорт | 1 |
| 4 | Седаны | 2 |
| 5 | Кроссоверы | 2 |
| 6 | Тягачи | 3 |

Структурно это выглядит так:
1 Транспорт
├── 2 Легковой транспорт
│ ├── 4 Седаны
│ └── 5 Кроссоверы
└── 3 Грузовой транспорт
└── 6 Тягачи

Каждая запись имеет:

  • id — собственный идентификатор;

  • parent_id — идентификатор родительского элемента.

Например:

id = 4
name = Седаны
parent_id = 2

Это означает:

Седаны → Легковой транспорт → Транспорт

Именно благодаря полю parent_id база понимает, что «Седаны» и «Кроссоверы» относятся к одной ветке дерева.

Если подниматься по родителям вверх, то рано или поздно мы придём к общему узлу — корню ветки.

Получается, что вся иерархия строится буквально на одном поле: parent_id

Для чего нужны иерархические справочники?

Они позволяют хранить данные не просто списком, а показывать связи между объектами.

Благодаря этому можно:

✅ группировать данные;
✅ строить отчёты по категориям;
✅ наследовать свойства от родительских узлов;
✅ задавать правила сразу для целой ветки;
✅ быстро находить все дочерние элементы.

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

Где используются?

📌 MDM-системы (Master Data Management);
📌 каталоги товаров интернет-магазинов;
📌 банковские и страховые системы;
📌 ERP и CRM;
📌 классификаторы услуг и продуктов;
📌 организационная структура компании;
📌 государственные классификаторы и справочники.

Преимущества

✔ Гибкость. Можно добавлять новые ветки без изменения структуры данных.

✔ Удобная аналитика. Легко получить данные как по конкретному элементу, так и по всей категории.

✔ Наследование правил. Одно правило может применяться сразу к тысячам объектов.

✔ Масштабируемость. Структура может содержать десятки и сотни уровней вложенности.

Недостатки

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

❌ Производительность. Глубокие иерархии могут существенно замедлять выполнение запросов.

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

❌ Сложность сопровождения. Изменение структуры верхних уровней может затронуть большое количество дочерних элементов.

Как с ними работать?

При работе с иерархическими справочниками чаще всего приходится решать четыре задачи:

🔹 найти всех потомков узла;
🔹 найти всех родителей элемента;
🔹 определить, принадлежит ли элемент определённой ветке;
🔹 определить, к какому верхнему узлу относится конкретный элемент.

В Oracle для этого используются специальные иерархические запросы:

START WITH …
CONNECT BY …

Именно они позволяют «обходить дерево» вверх или вниз по веткам.

В канале Аналитика FM (клик 🙂 ) уже готов пост про конструкцию START WITH и CONNECT BY.

Подписывайся, если интересно разбираться в особенностях работы аналитика.

Иерархический справочник — это не просто список значений. Это способ описать реальные взаимосвязи между объектами и сделать систему более гибкой и управляемой.

А одна маленькая колонка parent_id превращает обычную таблицу в целое дерево данных.

Источник

Теги

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть
Закрыть