На пути к единому формату данных
Компьютерная информация может существовать только при наличии соответствующей программной среды для ее создания, редактирования и воспроизведения. Предметная специализация прикладного ПО обусловила появление огромного ассортимента технологий, предлагаемых потребителю. Однако в совокупности вся эта программная среда только внешне представляется очень многоликой и разнообразной. В действительности все существующие программные средства группируются вокруг совсем небольшого списка основных разновидностей информации, а именно: тексты и таблицы, векторные и точечные изображения, видео и звук.
Если этот список рассматривать с точки зрения технологических возможностей, то наиболее привлекательными они окажутся у таблиц, причем практически по всем основным показателям. К ним относятся: скорость доступа к данным, программная поддержка их целостности (зависимости одних данных от других), упорядоченности (сортировки по отдельным полям), взаимодействия (различные виды связей между отдельными данными), способов обращения (универсальный язык запросов SQL) и др. Более того, все разновидности информации могут упорядочиваться и управляться через таблицы, путем привязки отдельных объектов к соответствующим полям, содержащим необходимые сведения об их принадлежности, содержании, местонахождении и т.д.
Такие широкие возможности таблиц сделали их de facto основным и самым эффективным способом организации данных, обеспечивающим самые высокие показатели производительности компьютерных технологий. Однако следует заметить, что высокая производительность обработки данных в таблицах достигается, в основном, за счет жестко фиксированной длины полей, измеряемой в байтах. Если данные с одинаковой длиной размещаются в одной таблице, то эффективность технологии становится максимальной. Именно поэтому в таблицах зачастую размещают данные особого типа, называемые индексами и позволяющие выполнять поисковые запросы на предельно высоких скоростях. Классическим примером такого рода таблиц является "Таблица размещения файлов" (FAT), позволяющая быстро находить все кластеры, относящиеся к одному файлу, даже если они окажутся разбросанными в мелких фрагментах по всему диску.
Одинаковая длина записей в одноименных полях может без особых проблем обеспечиваться для данных технологического назначения, поскольку это данные, в основном, числового типа и практически всегда можно оценить их предельные значения. Однако длина данных конечного пользователя, как правило, разная, и за высокую производительность приходится расплачиваться нерациональным использованием ресурсов памяти. Например, в табличном списке городов названия Омск и Петропавловск-Камчатский будут занимать одинаковое место на носителе.
Если бы этот недостаток таблиц был единственным, то с ним еще можно было бы как-то смириться, учитывая возможность сохранения данных в упакованном виде. Но более существенным их недостатком является то, что табличный формат данных не может быть универсальным, поскольку пользовательские объекты в подавляющем своем большинстве имеют иерархическую структуру, которая непосредственно в таблицах может отображаться только за счет избыточного дублирования позиций данных. Другой, более рациональный способ отображения сложных объектов - это установление иерархических связей между разными таблицами, управляемых с помощью внешней прикладной программы.
В первом случае универсальность достигается лишь номинально, т.к. при достаточно большом числе данных основное преимущество таблиц превращается в серьезный тормоз, причем не только по отношению к ресурсам памяти, но и с точки зрения возможностей редактирования. Например, чтобы добавить еще одно или несколько полей в таблицу, нужно ввести соответствующие их значения (в т.ч. и повторяющиеся) во все строки таблицы. Во втором случае универсальность невозможна в принципе, т.к. функции прикладной программы ограничиваются конкретным содержанием таблиц.
Невозможность обеспечить универсальную (иерархическую) структуру данных с помощью таблиц имеет очень простое объяснение - в них попросту отсутствуют необходимые для этого ресурсы управления, т.е. отдельная неизбыточная таблица может отображать только один уровень иерархии. Чтобы разместить данные на нескольких уровнях иерархии, пока не придумали ничего лучшего, чем "проектирование баз данных". Придание основательности и внушительного вида этой процедуре путем привлечения математического аппарата из линейной алгебры имеет, скорее, пропагандистское, чем прикладное значение. На деле информационная конструкция под названием "база данных" - это чисто программистское изобретение, предназначенное, главным образом, для того, чтобы не создавать каждый раз специфическую файловую систему под конкретную программу. Что же касается методов уменьшения избыточности данных, то обычная иерархия справляется с этой проблемой намного проще и быстрее, чем самое утонченное "нормирование" таблиц.
Разработчики баз данных, как правило, не задумываются над тем, чтобы иерархию представлять в чистом виде, и устанавливают отдельные связи произвольно. В результате общая картина связей запутывается так, что разобраться в ней не могут даже ее творцы. Но это еще не самое худшее. Отсутствие механизмов жесткой регламентации иерархических связей приводит к тому, что данные, относящиеся к одному запросу, вместо того, чтобы находиться в одном месте, оказываются разбросанными по разным источникам. В этом случае становится просто невозможно обеспечить исчерпывающие и однозначные результаты поиска по конкретному запросу даже в полностью проиндексированных, но экстремально больших по объему источниках, например, таких, как MSDN ("КВ" №№ 43-44/2001).
Технологический инструментарий, именуемый "Системы Управления Базами Данных" (СУБД), явно не соответствует этому громкому названию и в действительности позволяет управлять лишь процессом создания прикладных систем, выполняющих функции управления взаимосвязанными таблицами. Возможности взаимодействия между различными базами данных ограничиваются, в основном, функциями экспорта-импорта, а вот обмен отдельными подсистемами вместе с функциями поддержки их целостности - задача для них практически неразрешимая, не говоря уже об их полной неспособности к развитию и адаптации к изменяющимся условиям.
Технологии, создаваемые на основе баз данных - это результат единичного производства систем, соответствующих уровню развития компьютерной техники 80-х годов прошлого века. При ежегодном объеме производства компьютеров порядка 100 млн. шт. вся эта техника обречена на нерациональное использование, поскольку самые эффективные из существующих сегодня инструментариев (СУБД), ориентированные на самый технологичный (табличный) формат данных, совершенно не в состоянии обеспечить потребности пользователей в новых технологиях даже в том случае, если все они станут программистами. Так все-таки, может, не стоит и дальше упорно следовать по пути создания иерархий из таблиц, а предпочесть более простой и естественный путь - таблица как частный случай иерархии?
Юрий КРАСКОВ,
[email protected]
Комментарии
Страницы
Бред, господа!
Но это хорошо, что уважаемая редакция публикует такую отсебятину. Все же веселее бородатых пошлых приколов, именуемых "компьютерными словестями".
Одной критики мало. Есть пословица: "Трагедия дурака не в глупости, а в недостатке ума".
Чтобы таких статей было меньше, если мы такие умные, давайте напишем толковую статью.
Для автора пожелание - найти экспертов в области, которую он собирается осветить и советоваться с ними. От этого престиж "КВ" только поднимется.
Самые несносные из дураков - это те, которые еще не совсем лишены ума.
Давайте! Или Давайте?
Страницы