Что такое иерархическая модель организации данных, объясните ее сущность на примере каталога файлов

Обновлено: 21.11.2024

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

В этом суть иерархии, которую мы должны использовать в веб-дизайне.

В файлах есть точка (.), а за ними следует расширение, сообщающее компьютеру, что это за файл, например:

photo.jpg = изображение в формате JPEG
index.html = HTML-страница
мультфильм.jpg = изображение png
style.css = таблица стилей

Папки обычно обозначаются косой чертой (/) и не имеют расширения.

Пути

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

Полный путь включает в себя все необходимое для поиска элемента; это также называется абсолютным URL: части полного пути

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

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

Именование файлов и папок

Чтобы не столкнуться с проблемами, следует помнить о нескольких вещах:

Все буквы нижнего регистра.
Структура файла чувствительна к регистру, поэтому важно соблюдать чистоту. Самый простой способ все запомнить — просто создать все имена файлов и папок, используя строчные буквы.
Пунктуация может вас убить. Сюда входят пробелы!
Серверы должны интерпретировать, что на самом деле означает этот пробел. Большинство помещают [%20] там, где есть пробел, но некоторые вставляют другие символы, и это испортит ваши ссылки. Если в имени должен быть пробел, используйте символ подчеркивания [_] или тире [-], чтобы имена выглядели так: adobe_1.html или adobe-1.html. Следуйте тем же правилам для всех знаков препинания и нечетных символов. Безопаснее всего использовать буквы и цифры, тире и подчеркивание. Примечание. Файлы и определения, начинающиеся с цифры, также могут иметь проблемы, поэтому избегайте и этого.
Короткие имена файлов.
Держите их управляемыми с точки зрения длины.
Названия, которые носят описательный характер.
Выберите имя, чтобы вы могли узнать, что это за страница, просто прочитав название. Это сэкономит вам часы времени, не открывая неправильные файлы. Также сделайте имена родственными. Исключением является то, что главная страница каждого раздела (или главная страница, принадлежащая этой папке) должна называться "index.htm".

Почему это так важно в веб-дизайне?

По сути, HTML — это набор инструкций. Думайте об этом как о рецепте того, как должна быть составлена веб-страница, написанная для программного обеспечения браузера (Chrome, Firefox, Safari и т. д.). Многое из того, что вы видите в Интернете, на самом деле находится в самом рецепте — в файле HTML.

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

Относительная ссылка

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

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

По сути, нужно знать три вещи:

вы связываете вниз в файловой структуре, помещая сначала папку, а затем файл, например, папка/файл.html
вы ссылаетесь на файл в той же папке, просто указывая имя файла: file.html
и вы связываетесь в файловой структуре, используя две точки и тире для обозначения перехода на один уровень вверх: ../

Итак, вот файловая структура веб-сайта о цвете. Я дал каждому имени файла букву, чтобы вы могли видеть, как работает относительное связывание.

Несколько примеров:

Относительная ссылка с главной страницы (а) на темно-красную страницу (г):

Относительная ссылка с синей страницы (f) на малиновую страницу (h):

Относительная ссылка со страницы блюза (f) на страницу цвета морской волны (e):

Относительная ссылка с темно-синей страницы (с) на голубую страницу (g):

Проверьте себя:

Какова относительная ссылка с главной страницы (а) на смешанную блюзовую страницу (i)?
Какова относительная ссылка между кроваво-красной страницей (b) и бирюзово-голубой страницей (e)?
Какой абсолютный URL темно-синей страницы?
Какова относительная ссылка светло-голубой страницы (g) на красную страницу (j)?
Какая ссылка со смешанной синей страницы (i) на страницу цвета морской волны (e)?

Важность страницы по умолчанию (индексной)

Страницы index.html называются страницами по умолчанию. Если вы используете файл в папке, то сервер знает, что нужно показать этот файл, даже если он не указан в адресной строке.

Рекомендуется иметь индексную страницу для каждой папки с содержимым. Я буду отмечать ваши последние сайты на этом!

Корневая папка

Корневая папка — это папка, в которой хранятся все папки и файлы всего вашего веб-сайта. (Например, на сервере публикации ваша корневая папка называется public_html.) Обычно пути создаются таким образом, что домен фактически представляет собой корневую папку.

Итак, абсолютный (полный) URL целевой страницы красного раздела (j) будет таким:

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

Хотите создать собственную схему базы данных? Попробуйте Люсидчарт. Это быстро, просто и совершенно бесплатно.

Типы моделей баз данных

Существует множество моделей данных. Вот некоторые из наиболее распространенных:

Иерархическая модель базы данных
Реляционная модель
Сетевая модель
Объектно-ориентированная модель базы данных
Модель "сущность-связь"
Модель документа
Модель "сущность-атрибут-значение"
Схема со звездочкой
Объектно-реляционная модель, объединяющая две составляющие ее названия.

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

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

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

Давайте подробнее рассмотрим некоторые из наиболее распространенных моделей баз данных.

Реляционная модель

Самая распространенная реляционная модель сортирует данные в таблицы, также известные как отношения, каждая из которых состоит из столбцов и строк. В каждом столбце указан атрибут объекта, о котором идет речь, например, цена, почтовый индекс или дата рождения. Вместе атрибуты в отношении называются доменом. Конкретный атрибут или комбинация атрибутов выбирается в качестве первичного ключа, на который можно ссылаться в других таблицах, когда он называется внешним ключом.

Каждая строка, также называемая кортежем, содержит данные о конкретном экземпляре рассматриваемого объекта, например о конкретном сотруднике.

Модель также учитывает типы отношений между этими таблицами, включая отношения "один к одному", "один ко многим" и "многие ко многим". Вот пример:

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

Реляционные базы данных обычно пишутся на языке структурированных запросов (SQL). Модель была представлена Э. Ф. Коддом в 1970 году.

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

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

Эта модель в основном использовалась в системах управления информацией IBM в 60-х и 70-х годах, но сегодня они редко встречаются из-за определенной операционной неэффективности.

Сетевая модель

Сетевая модель основывается на иерархической модели, допуская отношения "многие ко многим" между связанными записями, что подразумевает несколько родительских записей. На основе математической теории множеств модель строится с наборами связанных записей. Каждый набор состоит из одной записи о владельце или родительской записи и одной или нескольких записей-членов или дочерних записей. Запись может быть элементом или дочерним элементом в нескольких наборах, что позволяет этой модели передавать сложные отношения.

Он был наиболее популярен в 70-х годах после того, как был официально определен Конференцией по языкам систем данных (CODASYL).

Объектно-ориентированная модель базы данных

В этой модели база данных определяется как набор объектов или программных элементов многократного использования со связанными функциями и методами. Существует несколько видов объектно-ориентированных баз данных:

Мультимедийная база данных включает мультимедийные файлы, например изображения, которые нельзя хранить в реляционной базе данных.

Гипертекстовая база данных позволяет любому объекту связываться с любым другим объектом. Это полезно для организации большого количества разрозненных данных, но не идеально для числового анализа.

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

С Lucidchart можно быстро и легко строить диаграммы. Начните бесплатную пробную версию сегодня, чтобы начать творить и сотрудничать.

Объектно-реляционная модель

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

Языки и интерфейсы вызовов включают SQL3, языки поставщиков, ODBC, JDBC и проприетарные интерфейсы вызовов, являющиеся расширениями языков и интерфейсов, используемых реляционной моделью.

Модель "сущность-связь"

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

Здесь люди, места и вещи, о которых хранятся точки данных, называются объектами, каждый из которых имеет определенные атрибуты, которые вместе составляют их домен. Количество элементов или отношения между объектами также сопоставляются.

Распространенной формой ER-диаграммы является схема "звезда", в которой центральная таблица фактов соединяется с многомерными таблицами.

Другие модели баз данных

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

Перевернутая файловая модель

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

Эта модель используется системой управления базами данных ADABAS компании Software AG с 1970 года и поддерживается по сей день.

Плоская модель

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

Многомерная модель

Это вариант реляционной модели, предназначенный для улучшения аналитической обработки. Хотя реляционная модель оптимизирована для онлайн-обработки транзакций (OLTP), эта модель предназначена для интерактивной аналитической обработки (OLAP).

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

Полуструктурированная модель

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

Контекстная модель

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

Ассоциативная модель

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

Ассоциативная модель структурирует данные в два набора:

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

Другие, менее распространенные модели баз данных включают:

Семантическая модель, включающая информацию о том, как хранимые данные соотносятся с реальным миром.
База данных XML, которая позволяет задавать данные и даже сохранять их в формате XML.
Именованный график
Тройной магазин

Модели баз данных NoSQL

Помимо модели объектной базы данных, в отличие от реляционной модели, появились другие модели, отличные от SQL:

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

Многозначная модель, отличающаяся от реляционной модели тем, что атрибуты могут содержать список данных, а не одну точку данных.

Модель документа, предназначенная для хранения и управления документами или частично структурированными данными, а не атомарными данными.

Базы данных в Интернете

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

Широкое присутствие баз данных позволяет использовать их практически в любой сфере, от покупок в Интернете до микротаргетинга на сегмент избирателей в рамках политической кампании. В различных отраслях промышленности, от воздушного транспорта до автомобилестроения, разработаны собственные стандарты проектирования баз данных.

Полезные ресурсы

Когда вы будете готовы приступить к моделированию своей базы данных, попробуйте Lucidchart. Это идеальный инструмент для быстрого и простого создания эскизов систем баз данных. Вы даже можете импортировать и экспортировать из SQL. Начните бесплатную пробную версию сегодня!

Часто нам нужно хранить огромные объемы —древовидных“ или —иерархических— данных:

Сотни категорий, подкатегорий и под-подкатегорий в одном интернет-магазине
Меню навигации очень сложных файлов Sitemap
Взаимоотношения участников, которые участвуют в кампаниях аффилированного маркетинга

Правильная организация и индексация этих данных позволит легко:

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

Модель смежного списка: метод «родитель-потомок»

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

Родительское дочернее дерево

Отношения родитель-потомок, хранение идентификатора родителя

Плюсы:

Легко вставлять новые данные (индексация не требуется)
Легкое хранение данных (только одно поле — родительский идентификатор — требуется для построения всего филиального дерева)
—уровни дерева— (насколько глубоко вы находитесь) по своей сути очевидны, поскольку для каждого уровня требуется новый запрос.

Минусы:

Пример: "Показать все дочерние записи одного узла"

Для родительского "А" постройте дерево всех членов нижестоящей аффилированной линии:

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

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

Вложенные наборы спешат на помощь!

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

В стандартном древовидном формате это выглядит запутанно и сложно в управлении.

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

Вот пример:

Создавать отчеты легко и просто.
Быстрый выбор нижестоящих наборов

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

Пример: "сколько дочерних элементов ниже узла A"?

Из-за предварительной индексации узлов вам нужно только взять разницу между левым и правым узлами, вычесть 1 и разделить на 2, чтобы получить общее количество дочерних элементов данного узла. Это можно сделать без каких-либо запросов с участием самих детей.

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

Что такое иерархическая модель базы данных

Это модель данных, в которой данные представлены в виде древовидной структуры. В этой модели данные хранятся в виде записей, которые представляют собой набор полей. Записи связаны ссылками, и тип записи указывает, какое поле содержится в записи. Каждое поле может содержать только одно значение.

Hadoop, наука о данных, статистика и др.

У него должен быть только один родительский узел для каждого дочернего узла, но родительские узлы могут иметь более одного дочернего узла. Несколько родителей не допускаются. В этом основное различие между иерархической и сетевой моделью базы данных. Первый узел дерева называется корневым узлом. Когда данные необходимо получить, то просматривается все дерево, начиная с корневого узла. Эта модель представляет отношения "один ко многим".

Давайте рассмотрим один пример: предположим, что у нас есть главный каталог, который содержит другие подкаталоги. Каждый подкаталог содержит больше файлов и каталогов. Каждый каталог или файл может находиться только в одном каталоге, т. е. иметь только одного родителя.

Здесь A — основной каталог, т. е. корневой узел. B1 и B2 являются их дочерними или подкаталогами.B1 и B2 также имеют двух детей C1, C2 и C2, C3 соответственно. Это могут быть каталоги или другие файлы. Это изображает отношения "один ко многим".

Использование иерархической модели базы данных

Применение модели базы данных описано здесь.

Все в одном пакете для разработки программного обеспечения (600+ курсов, 50+ проектов) 600+ онлайн-курсов | 3000+ часов | Поддающиеся проверке сертификаты | Пожизненный доступ
4,6 (3144 оценки)

Иерархическая модель базы данных широко использовалась в эпоху мейнфреймов. Сегодня он используется в основном для хранения файловых систем и географической информации. Он используется в приложениях, где требуется высокая производительность, таких как телекоммуникации и банковское дело. Иерархическая база данных также используется для реестра Windows в операционной системе Microsoft Windows. Это полезно, когда выполняются следующие два условия:

Данные должны располагаться в иерархическом порядке, т. е. должны присутствовать отношения родитель-потомок.
Доступ к данным в иерархическом шаблоне должен осуществляться только по одному пути.

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

Ниже перечислены некоторые преимущества.

Данные могут быть легко извлечены благодаря явным ссылкам между структурами таблиц.
Всегда поддерживается ссылочная целостность, т. е. любые изменения, внесенные в родительскую таблицу, автоматически обновляются в дочерней таблице.
Способствует обмену данными.
Это концептуально просто из-за отношений родитель-потомок.
Применяется безопасность базы данных.
Эффективен при отношениях 1 : N.
Четкая цепочка подчинения или полномочий.
Увеличивает специализацию.
Высокая производительность.
Удалить результаты.

Недостатки

Ниже приведены некоторые недостатки.

Если родительская и дочерняя таблицы не связаны между собой, добавление новой записи в дочернюю таблицу затруднено, поскольку в родительскую таблицу необходимо добавить дополнительную запись.
Сложные отношения не поддерживаются.
Избыточность, приводящая к неточной информации.
Изменение структуры приводит к изменению всех прикладных программ.
M: отношение N не поддерживается.
Нет манипулирования данными или языка определения данных.
Отсутствие стандартов.
Плохая гибкость
Коммуникационные барьеры
Организационная разобщенность.
Жесткая конструкция

Возможности

Некоторые функции указаны ниже:

Отношения "многие ко многим": поддерживаются только отношения "один ко многим". Отношения "многие ко многим" не поддерживаются.
Проблема удаления: если родитель удаляется, дочерний элемент автоматически удаляется.
Иерархия данных. Данные представлены в виде иерархической древовидной структуры.
Отношения родитель-потомок: у каждого дочернего элемента может быть только один родитель, но у родителя может быть более одного дочернего элемента.
Указатель: указатели используются для связывания записей, которые сообщают, какая запись является родительской, а какая дочерней.
Ввод и вывод на диск сведен к минимуму: родительские и дочерние записи размещаются или хранятся близко друг к другу на устройстве хранения, что сводит к минимуму ввод и вывод на жесткий диск.
Быстрая навигация. Поскольку родительский и дочерний элементы хранятся рядом друг с другом, время доступа сокращается, а навигация становится быстрее.
Предопределенные отношения. Все отношения между корневыми, родительскими и дочерними узлами предопределены в схеме базы данных.
Сложность реорганизации: иерархия не позволяет реорганизовать данные.
Избыточность. Отношения "один ко многим" увеличивают избыточность данных, что приводит к получению неточных данных.

Примеры

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

Теперь мы можем представить приведенную выше иерархическую модель в виде реляционных таблиц, как показано ниже:

Стол для учащихся:

Таблица курса:

Таким образом, иерархическая модель может быть представлена в реляционных таблицах и наоборот.

Заключение

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