ТЕХНОЛОГИЯ qWORD.
ПОЛНОСТЬЮ ОТКРЫТАЯ СИСТЕМА УПРАВЛЕНИЯ ДАННЫМИ

А.Н.Долженков, В.М.Лачинов, А.О.Поляков

Предлагаемое описание qWord технологии и, если смотреть более широко, вообще новой технологии создания СУБД, СУБЗ, “хранилищ знания” и тому подобного, носит здесь в значительной мере обобщающий, методологический характер. Более детальное описание просто скрыло бы крайне важные как теоретические, так и чисто практические аспекты в множестве частных подробностей. Но в этом и нет нужды. qWord весьма тщательно документирован и содержит все уровни документации внутри себя, что также является одним из важных аспектов его технологии.

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

Второй из вопросов самого высокого проблемного уровня – что и как происходит с семантикой проблемного подмножества естественного языка в адекватно устроенной информационной системе (смысл понятия “адекватно устроенной” мы рассмотрим ниже).

Вообще количество и затронутых и разрешенных проблем и вопросов оказалось таково, что их практически невозможно вместить в одну публикацию. Отметим только, что в раннем, рабочем варианте статья имела название “Самоструктурирующиеся СУБД”. Сейчас, когда реализовались и программный продукт, и технология, и теория стало ясно – “Само…” это следующая ступень, управление непосредственно от подмножества естественного языка. Но о том, как это сделать мы поговорим в следующих публикациях, после изложения здесь необходимого предварительного материала.

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

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

Здесь мы будем рассматривать подмножество КС – информационные системы, подразумевая под этим, там где это не вызовет разночтений, всю совокупность таковых от традиционных СУБД до “систем знания” и т.п.

Сделаем первое утверждение.

Минимальной адекватной задаче создания информационной системы структурой является совокупность взаимосвязанных динамических объектов: проблемная среда (ПС) – информационная система (ИС) – основная объектная триада (ООТ).

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

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

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

Фактически мы сделанным утверждением ничего не “открываем” и не “изобретаем” – просто честно констатируем реальную ситуацию.

Сделаем второе утверждение.

Адекватное раскрытие объекта как “наружу”, так и “внутрь” в реальности достигается только в динамическом процессе взаимодействия объектов и процессов, составляющих ООТ. Иначе говоря, объект, моделирующий ИС или ее часть, является адекватным представлением ПО, если по умолчанию имеет свойство динамической раскрываемости. Успех любой ИС заключается в том, насколько эффективно это удалось реализовать.

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

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

Известная идеология Get Up (GU) и Check Up (CHU) интерфейсов обслуживает только два типа процессов, а именно:

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

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

Весьма полезно рассмотреть как получилось, что самый важный тип процессов, ради которого собственно все и делается просто не заметили. Все проектируемые СУБД существуют по единой “схеме жизни”.

Во-первых, конструируется модель ПО.

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

Далее, в эксплуатации при приходе события, вызывающего реструктуризацию, срабатывает схема:

• блокируется часть глобальной среды (или вся среда);
• проводится перенастройка модели данных;
• в соответствии с перестроенной МД производится перезагрузка блокированной части глобальной среды с перевычислением элементов (связей, но иногда и не только их);
• предыдущий пункт выполняется до тех пор, пока не исчерпаны возможности МД, либо возможности перевычисления элементов, либо, наконец, эта процедура не стала слишком дорогой, после чего “жизненный цикл” СУБД завершается и надо проектировать новую СУБД.

Заметим теперь, что то же самое мы наблюдаем на аппаратном уровне при обработке прерывания от сбоев шины памяти (или блока). Если аппаратура снабжена средствами резервирования и некоторым механизмом типа “межблочного кеша”, то она будет сопротивляться сбоям, обходясь частичными горячими перезагрузками, до тех пор, пока не будут исчерпаны возможности резервирования.

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

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

Итак, структура СУБД “раскрывается зеркально относительно ПО”, также как из ПО выделяется логическая модель (или модели), в СУБД возникает собственно структура БД и структура управления в виде динамически раскрываемого объекта.

Структура, реализующая БД, должна удовлетворять следующим требованиям:

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

Подходящей структурой является механизм В*-деревьев. Более того, нами доказано, что этот механизм является “глобально-минимаксным”. Раскрываемость управляющего объекта (структуры, управляющей БД), сводится к следующему.

Структура должна содержать компоненты:

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

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

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

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

Таким образом, реализация концепции открытости и есть тот самый инструмент для обработки процессов CRR типа. Собственно, никакого особого открытия здесь и нет – все по старому рецепту: чтобы расщепить аварийное и глобальное события надо адекватным образом устроить иерархию структур логической среды.

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

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

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

• языка реализации
• логической (операционной) среды и физической реализации (аппаратуры) в которой выполнен язык и продукт.

В каждой такой реализации существенно конечный набор правил можно считать “работающим по умолчанию”.

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

Корректность работы “нижней” части сдвоенной W-грамматики сомнений не вызывает, если реализация выпонена правильно и с логической точки зрения и с позиции программной среды.

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

За дальнейшими подробностями можно обратиться к документации по qWord, выполненной весьма тщательно, так как возможные здесь один – два примера большой ясности не внесут, а места займут достаточно много.

То есть в качестве средства реализации CRR необходимо как и в В*-деревьях взять формальный аппарат W-грамматики. Это будет “специфическая реализация W-грамматики, как отмечает автор – разработчик qWord. Да, конечно, все это представляется достаточно простым, но только тогда, когда все это уже сделано. Остается, конечно, вопрос адекватности реализации, но это уже Искусство Конструкторап – кто знает как без него обойтись в действительно сложных системах – подскажите.

Естественным представляется использовать подход CRR для раскрытия системы и в других направлениях, используя при этом целиком стандартные средства, т.е. механизм “окон” в его стандартизованном в операционной среде виде, идеологию GU – CHU интерфейса и т.д. Хотя это не всегда экономно, но зато обеспечивает открытость продукта в сторону ОС и аппаратуры, что немаловажно, пока существует множество их существенно различных реализаций.

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

• декларативной;
• процедурной;
• метаописанием (метапроцедурой);
• комбинацией вышеперечисленного.

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

Раскрываемость фрейма достигается:

• наружу – путем порождения новых фреймов, в частности “обобщения”, а также порождения “экземпляров фреймов”;
• внутрь – путем использования “обобщенного понятия”, “обобщенного атрибута” и / или раскрытия по атрибутам.

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

Итак, инструментарий qWord позволяет на строить СУБД на концепции открытости, концепции динамически раскрываемого объекта, причем выполнить это на базе единого формализма W-грамматик. Более того, и сама БД и все окружение (управление БД) реализованы в единой программной среде и на базе единого представления В*-моделей.

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

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

Здесь нам важнее рассмотреть общий аспект – полностью меняется подход к созданию ИС.

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

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

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

• обучить пользователя начальному объему инструментария и технологии;
• помочь в выборе стартовых логических моделей и стартового комплекта средств (фреймов и их настройки);
• по мере надобности помогать в оптимальной организации системы (если возникает необходимость).

Характерно, что “сломать” структуру системы никакими действиями пользователя просто невозможно, правда можно добиться очень высокой степени ее неэффективности, да и это будет весьма трудно.

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

Разумеется, без проблем не бывает. Так при реализации, в особенности интерфейсов, очень мешают противоречивые, иногда и взаимоисключающие соглашения разработчиков и программ и аппаратуры, но это проблема вечная. Наряду с привычными проблемами любого “нормального” программного продукта появились и новые, точнее не появились, а превратились, в связи с повышением собственного уровня ИС, из абстрактно-теоретических в самую что ни есть практику. Некоторые из них мы сейчас и рассмотрим.

При реализации ИС на основе Cache-технологии с самого начала появилась проблема – в структурах БД остаются только литеры (литералы) и связи (т.е. “чистый синтаксис”), словарь системы также представляется как набор иероглифов и связей их с логической моделью и БД. Правда, к любому понятию можно применить как операцию обобщения, так и операцию декомпозиции – начиная от самой логической модели ПО и до литерала.

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

На самом деле семантика никуда не пропала, просто адекватно реализованный аппарат “сдвоенной W-грамматики аккуратно и последовательно “разрезает” ее на две части – “константную”, которую укладывает в БД в виде литералов и связей и именует после этого иероглифом словаря, и “плывущую”, переменную, которая “остается в распоряжении” ПО и пользователя. Большая часть народов Земли успешно поступает также – пользуется иероглифами, к которым мы должны относить и всю терминологию профессиональных сленгов.

Отсюда два вывода.

Теоретический – семантика суть динамический объект со всеми вытекающими последствиями.

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

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

Однако здесь все и кончилось. Начиная с некоторого и весьма небольшого уровня “полной автоматизированности” и “полной естественности интерфейса” пользовательперестает думать не только о логике данных, но и о логике ПС, т.е. внешней логической модели и о логике своей собственной работы.

Получается, что проще и гораздо эффективнее все же заставить пользователя усвоить необходимый минимум системной грамоты для блага его собственного, а наипаче – его деятельности. Вопрос эффективности лежит во всей основной объектной триаде (ПО – П – ИС), в согласованности ее частей, а не в одном компоненте, например ИС.

Еще более детективным сюжетом разворачивается попытка сделать прикладную систему вместе с qWord “живой”, способной самостоятельно структурировать данные из входных потоков, а затем и самостоятельно выходить на другие предметные области. Тем более, что технология и механизмы qWord и эту задачу потенциально способны “поднять”, а механизм саморазвития – “структурный резонанс” нам известен.

Первые же прикидки дают результат, вполне адекватный размаху постановки:

• основные затраты уйдут на обучение “всему ненужному” – так же как и в случае с человеком;
• система также будет ошибаться, иметь “собственное мнение” и с этим надо что-то делать;
• систему нельзя выключить – для механизмов саморазвития это “смертельно”;
• нельзя лишать надолго минимально необходимого “потока общения”, иначе неизбежна деградация.

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

На самом деле первая реализация qWord появилась более двадцати лет назад, но имела с Cache общих “прапредков” и “общую среду обитания” – идеи, методологии, средства программной реализации и приложения.

Не праздным представляется вопрос, почему qWord реализуется в Cache-технологии, а не в какой-либо другой.

Ответ крайне поучительный с практической точки зрения!

Не потому, что в программной реализации Cache-технологии было НЕЧТО, а потому, что НЕ БЫЛО ничего лишнего. Только один, но тщательно разработанный механизм В*-деревьев и один тип данных – символьная строка, а все до единого ограничения как логические, так и реализационные поставлены явно и однозначно.

Конечно, к этому топору пришлось добавить и искусство и интуицию Конструктора – и варево, наконец, получилось.

Сейчас, когда в основном и теория завершена и опыт накоплен, мы можем утверждать: все что можно в Cache-технологии возможно и в других технологиях, но только если Конструктор Системы сумеет преодолеть все капканы и ловушки, построение которых являются неотъемлемой частью более “богатых языков”. Если у кого-то есть желание преодолевать трудности – преодолевайте. Получится (при успехе такой борьбы) может быть и лучше в каких то аспектах, а в общем – то же самое, но очень и очень даже не дешево.

Понятие основной объединенной триады, динамически раскрываемого объекта и сам ход реализации полностью открытых систем типа qWord однозначно ведут к пониманию – системы этого класса по своей сущности мультиобъектные и мультипроцессные, да еще, вдобавок, и с “плавающими иерархиями”. Значит и строить их надо соответствующими средствами.

“Раскрытие” инструментальной сущности ИС позволяет строить системы, способные “выжить” и успешно функционировать в весьма динамичной проблемной области. Есть смысл распространить этот подход и дальше – в сторону структуры операционных систем. Или еще дальше – в область аппаратных средств, что приведет нас к концепции “вертикальной машины”, весьма похожей на то, что предлагают “нейрокомпьютеры”, но существенно отличающейся тем, что ее реально можно построить доступными средствами, скажем также, как был построен qWord.

Этому будут посвящены следующие публикации.