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

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

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

Понятие "данные" исторически формируется в виде любого смыслового элемента какой-либо информации, но в таком представлении оно поначалу лишь констатирует факт, что информация - это комбинация элементов, несущая в себе более сложное содержание, чем каждый элемент в отдельности. Тем не менее, такой факт оказывается весьма значительным, т. к., с одной стороны, позволяет установить системное происхождение феномена информации, а с другой - применить законы систем для выявления общих свойств данных ("КВ" №5), и на этой основе сформулировать само понятие "данные", причем не только как своеобразные ячейки, создаваемые в рамках одной модели, но и как совокупность свойств единообразных элементов для создания источников информации универсального типа ("КВ" №№6, 8).

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

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

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

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

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

Все права на публикацию принадлежат автору