От таблиц к иерархии

На пути к единому формату данных

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

Если этот список рассматривать с точки зрения технологических возможностей, то наиболее привлекательными они окажутся у таблиц, причем практически по всем основным показателям. К ним относятся: скорость доступа к данным, программная поддержка их целостности (зависимости одних данных от других), упорядоченности (сортировки по отдельным полям), взаимодействия (различные виды связей между отдельными данными), способов обращения (универсальный язык запросов SQL) и др. Более того, все разновидности информации могут упорядочиваться и управляться через таблицы, путем привязки отдельных объектов к соответствующим полям, содержащим необходимые сведения об их принадлежности, содержании, местонахождении и т.д.

Такие широкие возможности таблиц сделали их de facto основным и самым эффективным способом организации данных, обеспечивающим самые высокие показатели производительности компьютерных технологий. Однако следует заметить, что высокая производительность обработки данных в таблицах достигается, в основном, за счет жестко фиксированной длины полей, измеряемой в байтах. Если данные с одинаковой длиной размещаются в одной таблице, то эффективность технологии становится максимальной. Именно поэтому в таблицах зачастую размещают данные особого типа, называемые индексами и позволяющие выполнять поисковые запросы на предельно высоких скоростях. Классическим примером такого рода таблиц является "Таблица размещения файлов" (FAT), позволяющая быстро находить все кластеры, относящиеся к одному файлу, даже если они окажутся разбросанными в мелких фрагментах по всему диску.

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

 

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

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

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

Разработчики баз данных, как правило, не задумываются над тем, чтобы иерархию представлять в чистом виде, и устанавливают отдельные связи произвольно. В результате общая картина связей запутывается так, что разобраться в ней не могут даже ее творцы. Но это еще не самое худшее. Отсутствие механизмов жесткой регламентации иерархических связей приводит к тому, что данные, относящиеся к одному запросу, вместо того, чтобы находиться в одном месте, оказываются разбросанными по разным источникам. В этом случае становится просто невозможно обеспечить исчерпывающие и однозначные результаты поиска по конкретному запросу даже в полностью проиндексированных, но экстремально больших по объему источниках, например, таких, как MSDN ("КВ" №№ 43-44/2001).

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

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

Юрий КРАСКОВ,
c_city2000@mail.ru

Версия для печатиВерсия для печати

Номер: 

25 за 2002 год

Рубрика: 

Новые технологии
Заметили ошибку? Выделите ее мышкой и нажмите Ctrl+Enter!
 

Комментарии

Страницы

Аватар пользователя Piligrim
Я так и не понял, что под «универсальностью» понимает автор. Вообще-то, мне, как человеку, уже не один год занимающемуся вот этими самыми базами, статья показалась, мягко выражаясь, не понятной. Более того, у меня сложилось мнение о том, что автор не совсем хорошо представляет, что он хочет и, совсем не очень хорошо представляет, вообще предмет обсуждения. Вобще-то, заводя базу данных (иш как игриво я выразился) человек вовсе не думает о том, что это будет сборище всевозможных и разрозненных данных. Более того, как правило, человек заранее определяет минимальный набор необходимых сведений и выгод от компьютерной обработки этих конкретных сведений. Если же автор когда-нибудь занимался проектированием баз данных исходя из позиций, которые он определил, то думаю, у него нет работающих сисстем. Во всяком случае, я категорически против, что проектирование баз это то, что обрисовал автор. Да и остальные размышления автора отражают его не высокую компетентность в этом вопросе. Что он имеет в виду под таблицами. Вовсе даже не обязательно, что Петропавловск-Камчатский и Сочи будут занимать одинаковое место на диске. Но это уже относится к области типпов данных, о которых автору вообще туго известно. И вообще хранение данных на диске и отображение данных это совершенно разные вещи. Различие же типов данных скорее не прихоть той или иной системы хранения или СУБД (не люблю этот термин). Ну нельзя умножать этот Петропавловск-Камчатский на 8 марта! Уж не знаю почему. Не знаю, на сколько автору известны каноны ООП, но эти каноны как раз и идут сразу со всеми утверждениями автора. Конечно, применительно к базам данных ООП это скорее философия и стиль, чем методология, но даже на этом уровне всё совершенно не так как представил автор. Хотя известны и строго ОО СУБД. А вот СУБД Cache вообще страшно похожа на то, о чём так мечтает автор. Ни каких таблиц! Сплошная иерархия. При этом одинаково хорошо работает как своим родным механизмом ООП, так и в контексте SQL сервера. Что? Тоже не то? Тогда может подойдёт методология функционального программирования применительно к базам данных, достаточно прилично описанная Литвиновым Ю.С. Скорее, автор имеет только первичные и давно устаревшие знания из области релятивистских баз данных. С тех времён, когда и базой–то любую таблицу называли. Короче – всё это навеяно голивудскими боевиками. Там где любой крутой профи в промежутке между мочиловом запросто влазил в «базу данных» и запросто получал любые данные от количества ног у японского спритматока до количества сексуальных касаний до Моники дяди Била в их поездке на местный рынок.

Бред, господа!

Аватар пользователя mike
Ба, растет, растет Красков. Вот уже и что-то из теории баз данных подчитал. И тут решил вставить свои 3 коп. В графоманском порыве (а может, просто не знает, как по другому компом заработать) критикует ... основы. После того, как где-то подчитает их в популярной литературе для "чайников". А сколько есть еще разделов знаний, которые он может критиковать! И все-то ему хреново. Вот только ничего существенного не предлагает. Похож на импотента, пытающегося изнасиловать женщину.

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

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

Одной критики мало. Есть пословица: "Трагедия дурака не в глупости, а в недостатке ума".

Чтобы таких статей было меньше, если мы такие умные, давайте напишем толковую статью.

Для автора пожелание - найти экспертов в области, которую он собирается осветить и советоваться с ними. От этого престиж "КВ" только поднимется.

Аватар пользователя Космополит
Ларош Фуко:

Самые несносные из дураков - это те, которые еще не совсем лишены ума.

Аватар пользователя Piligrim
Николай

Давайте! Или Давайте?

Аватар пользователя mike
Не странно ли, что ляпсусы Краскова еще и обсуждаются? Причем не в 1-ый раз.Ну согласитесь, приятно читать? Это как др$чить!
Аватар пользователя Piligrim
Польза от обсуждения есть всегда. А вдруг кто-нибудь это примет за чистую монету и будет корить себя за тупоумие? Так и до пожизненных комплексов докатится можно. В конце концов, вот определилось, что данная статья не меня одного за святое затронула. Так что - привет всем!
Аватар пользователя программер
такие статьи вредны тем, что их может прочитать твое не сильно продвинутое в программинге начальство и с умным видом потом поучать %)

Страницы