Історично ієрархічна модель з'явилася раніше мережевий. Вона найбільш проста з усіх моделей даних. Найвідомішою ієрархічною системою дозволяє створювати ієрархічні бази даних є система IMS (Information Management System) фірми IBM, яка використовується в свій час для підтримки місячного проекту «Аполлон». Поява ієрархічної моделі пов'язано з тим, що в реальному світі дуже багато зв'язку відповідають ієрархії, коли один об'єкт виступає як батьківський, а з ним може бути пов'язано безліч підлеглих об'єктів.
Основними інформаційними одиницями в ієрархічній моделі є. база даних (БД), сегмент і поле. Поле даних визначається як мінімальна, неподільна одиниця даних, доступна користувачу за допомогою СУБД. Виділяють також тип поля. представляє собою сукупність полів одного типу. Сегмент складається з конкретних екземплярів полів. Тип сегмента - сукупність вхідних у нього типів полів. Ієрархічна модель являє собою неорієнтований граф, у вершинах якого розташовуються сегменти (або типи сегмента). Особливістю такої моделі є те, що кожен сегмент може мати не більше одного предка, довільну кількість нащадків і, по крайней мере, одне поле. Сегмент, який не має нащадків, називають листовим сегментом. Ієрархічне дерево починається з одного сегмента, званого кореневих сегментом. Дуже важливо, що кожен сегмент повинен мати своє унікальне ім'я або ідентифікатор.
На малюнку 1.1 схематично представлена ієрархічна структура. Вузли (сегменти) з'єднані один з одним сполучними дугами. Сегмент A є кореневим сегментом. Сегменти B, E, H, J, I є листовими сегментами. Кожен сегмент, при цьому, може містити будь-яку кількість полів.
Для ієрархічної моделі даних виділяють два мовних засоби:
· Мова опису даних
· Мова модифікації даних
Опис бази даних передбачає опис всіх її сегментів і встановлення зв'язків між ними.
Рис.1.1. ієрархічна структура
Приклад ієрархічної структури. Ієрархічна модель досить зручна для подання предметних областей, так як ієрархічні відносини досить часто зустрічаються між сутностями реального світу. Але ієрархічна модель не підтримує відносини «багато до багатьох», коли безліч об'єктів одного типу пов'язані з безліччю об'єктів іншого типу. Припустимо, що потрібно побудувати модель відносини між безліччю власників житла і безліччю квартир. Якщо основне питання буде полягати у визначенні того, яким житлом володіє той чи інший власник, то природно взяти в якості батьківських вузлів дані про власника. При цьому кожен сегмент - власник буде пов'язаний з N вузлами - квартирами. Таким чином, по власнику ми легко знайдемо всі квартири, які знаходяться в його власності. Однак проблема полягає в тому, що у однієї і тієї ж квартири може бути кілька власників. Тобто одна і та ж квартира може зустрічатися в різних деревах. В результаті рішення таких задач, як отримання списку всіх квартир, або отримання всіх власників конкретної квартири, будуть вже не настільки очевидними. Крім того, складної виглядає навіть операція видалення з бази конкретної квартири, оскільки для цього доведеться переглядати всі дерева. Можна, звичайно, побудувати паралельно дерева, в яких батьківськими сегментами будуть дані про квартирах, а породжуються сегментами - дані про власників, але в результаті ми отримаємо ще надмірність даних, що породить додаткову проблему їх узгодженості.
Основною одиницею обробки в ієрархічній моделі є сегмент. До сегментам можуть застосовуватися такі операції як запам'ятати, модифікувати, видалити, витягти, знайти. Операція пошуку зводиться до однієї з можливих процедур обходу дерева. Ієрархічні СУБД підтримують, зазвичай, правило: ніякої сегмент не може існувати без свого батька (виключаючи кореневої сегмент). Подібні правила, які підтримуються СУБД, називають обмеженнями цілісності.