Почему иерархии в КТ малоэффективны?

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

И все же системы, не допускающие иных связей между данными или объектами, кроме иерархических, составляют явное меньшинство, а в основной массе это такие, в которых иерархия, если и поддерживается, то только частично. Самый простой пример - это многолетние и безуспешные попытки разработчиков MS Word обеспечить автоматическую поддержку иерархической нумерации списков. Эта функция работает настолько неэффективно, что зачастую ее лучше не применять, т.к. ручная правка изменений в нумерации тогда станет значительно проще. Другой пример - это гипертекстовые документы (формат HTML). Для взаимодействия между объектами и отдельными данными здесь используются ссылки, которые хорошо работают, когда нужно максимально быстро переместиться с одного места расположения данных в другое. Однако в качестве связей, отражающих структуру объекта, ссылки непригодны, т.к. они могут устанавливаться совершенно произвольно, а в связях это недопустимо, поскольку может привести к нарушению целостности объекта. Если бы ссылки были только иерархическими, то ситуация, когда пользователь, следуя им, плутал бы по замкнутому кругу, была бы просто невозможной. Отсюда становится понятно, почему запросы в интернете, как правило, выполняются по ключевым словам, т.е. значительно менее эффективным способом, чем если бы они выполнялись по иерархическим связям.

В прикладных разработках основное применение иерархии связано со стандартом справочных систем (Microsoft HTML Help System), который для конечного пользователя доступен только в статичной (неизменяемой) форме. Однако у разработчиков в этом смысле руки полностью развязаны, и более эффективное решение напрашивается само собой: в структурах объектов руководствоваться исключительно и только иерархическими связями, а все ссылки выделить в отдельную функцию. Несмотря на то, что понимание необходимости придерживаться строго иерархических связей в объектах еще не стало прописной истиной¹, как тенденция развития новых технологий эта необходимость все же просматривается достаточно отчетливо.

Прежде всего, она явно присутствует в методологии объектно-ориентированного программирования (ООП), которое опирается именно на иерархические связи (по аналогии с родственными) между отдельными разновидностями (классами) объектов. Но технически это реализуется не принудительно, а только в виде рекомендаций, придерживаться которых на практике оказывается довольно затруднительно. В результате верная по сути идея фактически дискредитируется конкретными ее интерпретациями, и поэтому в качестве альтернативы ООП предлагается множество новых разработок, в которых эта же самая идея просто закрепляется. Один из примеров таких разработок - "Функциональное программирование (ФП)".

Ее автор и идеолог Ю. Литвинов предлагает конкретную реализацию системы, которая, по его мнению, должна быть устойчивой к изменениям. Но при этом он сразу сталкивается с проблемой общего определения понятия "объект"². Казалось бы, чего проще, универсальная структура любого объекта - это иерархия? Но в том-то и дело, что тогда это было бы слишком просто. Куда более солидно выглядит "Технология Взаимодействия Объектов (ТВОЛ) как универсальный протокол обмена данными между универсальными объектами". Но сути дела это не меняет - универсальные (т.е. иерархические) объекты должны создаваться и взаимодействовать через принудительную процедуру (ТВОЛ).

Похожая ситуация и в "постреляционной объектно-ориентированной" СУБД Cache, отличительная особенность которой - "единая архитектура данных как единое описание объектов и таблиц, отображаемых непосредственно в многомерные структуры ядра базы данных"³. Это "единое описание" - есть не что иное, как та же самая принудительная процедура установления связей между объектами. Иерархия здесь присутствует явно, однако в описаниях этот термин нигде даже не упоминается. Разработчики как бы стесняются называть вещи своими именами. Но почему?

Ответ может быть следующим. Еще в конце 80-х годов прошлого века новые разработки, "улучшающие" процедуру проектирования БД, сыпались как из рога изобилия. Этот процесс не прекратился и до сих пор, а приведенные примеры - это лишь капля в море. Однако ни одна из подобных разработок (включая и нашумевшие в свое время CASE-технологии) так и не смогла конкурировать с такими старушками, как Access, FoxPro, Paradox, FoxBase, которые по-прежнему сохраняют ведущие позиции на рынке ПО. В лице этих продуктов реляционные СУБД по-прежнему остаются лучшими технологиями для создания прикладных систем с применением наиболее простых, т.е. табличных, форматов данных, обеспеченных к тому же и методологией на уровне общего образования, и разнообразным инструментарием в конкретных продуктах, и стандартами (SQL).

В этих условиях рассчитывать на то, что хотя бы одна из тысяч (!) новых разработок, появившихся как результат очевидных недостатков реляционных БД (но сохраняющих преемственность с ними в части их обеспечения), сможет с ними достойно конкурировать, было бы просто наивно. В то же время давно уже созревшая необходимость технической реализации универсальных, т.е. иерархических, структур, доступных конечному пользователю, упирается в отсутствие соответствующего методологического и инструментального обеспечения. Поскольку любая конкретная иерархия реализуется без всяких проблем теми же СУБД, то проблема видится разработчикам только в процедуре этой реализации. Но ведь эту процедуру нужно выполнять им самим, причем в каждой конкретной технологии, потребность в которых значительно превышает общее количество всех существующих в мире компьютеров. Так стоит ли и дальше так упорно стремиться объять необъятное?

Юрий КРАСКОВ,
[email protected]

1 Как это ни странно, но болезненная реакция программистов на то, что этот очевидный факт был просто констатирован ("КВ" №25/2002), только подтверждает, что действительно разработчики БД руководствуются не соблюдением строго иерархических связей между данными, а самыми что ни есть благими намерениями (см. форум www.kv.by)

2 От монополии ООП к ТВОЛ и ФП - homepages.tversu.ru

3 Отличительные особенности СУБД Cache - www.citforum.ru/database/articles/subdcache.shtml