Преимущества Calligraph

Проблема
Появление технологии OLAP (On-Line Analytic Processing) явилось естественным ответом на проблемы, возникающие при обработке информации, предназначенной для немедленного реагирования на текущую ситуацию (Executive Information Systems) - неотъемлемой компоненты систем поддержки принятия решений (DSS - Decision Support Systems).
Принимая важные решения, руководители все чаще опираются на оперативную информацию. В большинстве случаев это означает, что им нужен немедленный доступ к самому широкому диапазону данных, источниками которых, как правило, являются "хранилища информации" (или базы данных), наполняемые системами оперативной обработки транзакций (OLTP), разнообразными прикладными программами, плановыми и прогнозными данными и др. информацией, хранящейся во всевозможных форматах.
Традиционный процесс поддержки принятия решений требует обязательного включения между руководителем (потребителем информации) и БД специалиста информационного отдела (программиста). Программист по заданию руководителя строит запрос к оперативной системе, получает электронный отчет, интерпретирует его и доводит до сведения руководителя. Такая схема имеет крайне низкую эффективность и огромное число недостатков. Вот лишь некоторые из них:
· Традиционный процесс занимает многие дни, когда, как правило, необходимо принять решение немедленно.
· После получения отчета, руководителя, зачастую, интересует уже другой вопрос (уточняющий или требующий рассмотрения данных в другом разрезе), и этот медленный цикл повторяется много раз.
· Программист и руководитель мыслят в разных категориях и, как следствие, могут не понимать друг друга. Требуются дополнительные уточняющие итерации, а это снова время, которого всегда не хватает.
· Проблемой является и сложность отчетов для понимания. У руководителя нет времени выбирать интересующие цифры из отчётов, которые ему готовят, тем более, что их может оказаться слишком много (вспомним огромные многостраничные отчеты, которые готовятся "на все случаи жизни" и в которых реально используются несколько страниц или даже цифр, а остальные - на всякий случай).
· Не является секретом и присутствие в цепочке интерпретации "благожелателей", заинтересованных в преднамеренном искажении информации.
Возможности решения проблемы.
Эта задача формализована Эдвардом Коддом (E.F.Codd), 12 правил которого охватывают все прикладные системы многомерного анализа и генерации отчетов (см. "CW-M", 1993, 38). Разные авторы предлагали дополнительные требования, но эти 12 критериев признаны классическим определением OLAP.

Вот эти требования:

Интересное наблюдение: независимые эксперты пытаются оценивать конкретные продукты по степени приближения к идеально полному соответствию всем этим требованиям, а производители, анонсируя свои продукты в качестве OLAP-систем часто "забывают" провести такой анализ.
Обзор российского рынка OLAP-продуктов
Практически в 100% случаев конечный пользователь или заказчик судит о программном продукте по виду и содержанию отчетов, а в процессе эксплуатации - по возможности их изменений и трудоемкости включения новых отчетных форм. В то же время их проектирование представляет собой весьма трудоемкую и, пожалуй, самую нелюбимую процедуру. В связи с этим понятно, насколько важны средства для проектирования отчетов.
Интересным с этой точки зрения представляется исследование наиболее известных на российском рынке продуктов, которые позиционируются их производителями как OLAP-системы с точки зрения классических 12 правил Кодда.
Наиболее популярными (и доступными по цене) сегодня можно признать следующие генераторы отчетов:

· Crystal Report;
· Report Smith;
· Quick Report.

Рассмотрим некоторые особенности каждого из вышеперечисленных генераторов отчетов.
На рис. 1 показан фрагмент отчета, создаваемого генератором Crystal Report, который был включен в состав поставки СУБД Visual dBASE 5.5 фирмы Borland.

Рис.1. Пример формирования шаблона отчета в среде Crystal Report.

Данный генератор (конструктор) предназначен для программиста и позволяет строить достаточно сложные шаблоны документов "спискового" типа. Перед построением отчета данные могут быть отсортированы. Отчет может содержать группировки по отсортированным данным. Можно включить в отчет строки с общими итогами и промежуточными итогами по любой группировке.
Среда конструктора позволяет рисовать на поле шаблона линии и вставлять рисунки. Средства "украшения" отчета в Сrystal Report более удобны, чем в Report Smith или Quick Report.
Вставка в шаблон текстовых строк выполняется путем их ввода в поле редактора и последующей буксировки в нужное место. Для вставки полей базы данных выбирают эти поля в списке и буксируют их в нужные места. Впрочем, аналогичным образом эти процедуры выполняются во всех трех генераторах.
Построение шаблона отчета в среде Crystal Report не представляет особой сложности для программиста. Более сложной процедурой является составление запроса к базе данных, с помощью которого осуществляется связь между базой и генератором. Ниже приведен фрагмент запроса типа QBE (Query by Example (запрос по образцу)):
CLOSE DATABASES
LOCAL Npath,Spath,Ndbf,Nmdx
USE SEANS.DBF
Npath = SEANS->BasDir
Spath = SEANS->SprDir
USE
SET EXACT ON
Ndbf = Npath+"\REGIS.DBF"
Nmdx = Npath+"\REGIS.MDX"
SELECT 1
USE (Ndbf) INDEX (Nmdx)
SET ORDER TO TAG TABN
SET FIELDS TO KOD, CEXR, TABN, FIO, NDOK, DATDOK, SUMTR,;
VID, SUMDEB, SUMCRE, SOD, PRIZ, CEXO
Ndbf = Spath+"\SVE.DBF"
Nmdx = Spath+"\SVE.MDX"
SELECT 2
USE (Ndbf) INDEX (Nmdx)
SET ORDER TO TAG TABN
SET FIELDS TO CEXR, TABN, FIO, PRIZ
SELECT 1
SET RELATION TO TABN INTO SVE
SET SKIP TO REGIS
GO TOP
Как видно из приведенного фрагмента, запрос даже для простого документа представляет собой хоть и небольшую, но процедуру, и для ее написания от программиста требуется знание языка СУБД Visual dBASE 5.5. Встроенный построитель QBE-запросов весьма несовершенен и позволяет строить только очень простые запросы "спискового" типа. Сложные, а тем более "аналитические" запросы приходится строить "вручную".
Генератор отчетов Report Smith очень похож на Crystal Report. Здесь мы рассматриваем вариант генератора, который поставлен в комплекте DELPHI 2.0 фирмы Borland. Кстати, следует отметить, что в версиях DELPHI 3.0 и выше Report Smith не поставляется. (Можно установить его самому). Фирменное руководство рекомендует вместо Report Smith использовать Quick Report, из чего можно сделать вывод, что Borland не будет далее развивать Report Smith, а делает ставку на QuickReport.
На рисунке 2 показан фрагмент отчета, создаваемого в среде Report Smith. Cвязь между базой данных и генератором осуществляется с помощью SQL-запроса. Конечно, возможности языка запросов SQL позволяет строить более сложные конструкции, чем QBE-запрос, но, опять же только для документов "спискового" типа. Сложные "аналитические" запросы также приходится строить "вручную".

Рис.2. Разработка отчета в среде Report Smith.

После подключения SQL-запроса в рабочем окне Report Smith появится простейший вариант отчета. Этот отчет Вы можете изменять и усложнять в соответствии со своими потребностями. Также как и в Crystal Report, можно создавать группировки данных, вычислять общие и промежуточные итоги, вставлять рисунки и линии, производить форматирование данных и т.д.
Если создается программа с использованием какого-либо "визуального" средства (Visual dBASE, Visual FoxPro 5.0, DELPHI 2.0), то, как правило, технология применения генератора отчетов Report Smith или Crystal Report для получения нетривиальных отчетов следующая: Создается форма, которая содержит меню со списком отчетов и диалоговые окна для выбора и задания параметров. Параметры отчета - это данные, которые может изменять пользователь. Примеры параметров отчета: диапазон дат, номер склада, номер счета, табельный номер работника и т.п. Далее создается процедура, которая формирует одну или несколько временных таблиц и заполняет их требуемой информацией. Если таблица одна, то можно ее подключить в качестве источника данных к генератору отчетов. Если же таблиц несколько, то требуется составить запрос и подключить его к генератору отчетов.
Рассмотренные выше генераторы отчетов Crystal Report и Report Smith разрабатывались как независимые программные продукты и затем интегрировались в такие пакеты, как Visual dBASE или DELPHI. Следует признать, что степень такой интеграции весьма слабая. По существу, из своей программы Вы можете только изменить текст запроса. Изменить из программы какой-либо элемент шаблона (текст или поле базы) нельзя. Это обстоятельство приводит к необходимости применения достаточно сложной технологии с использованием временных таблиц и делает этот процесс недоступным простому пользователю.
При создании программ на DELPHI более удобным средством создания отчетов является генератор Quick Report. С точки зрения программиста, основным достоинством этого генератора является то, что он органично вписан в среду DELPHI.

Рис.3. Пример формы для выбора отчета и задания параметров.

Рис.4. Пример формирования шаблона отчета средствами Quick Report.

На рисунке 3 можно видеть пример создания простой экранной формы для управления выбором отчета, заданием параметров (номер месяца и года) и запуском процедуры построения отчета с последующим просмотром или прямым выводом на принтер, а на рисунке 4 - пример формирования шаблона формы.
Шаблон отчета строится, практически, по тем же правилам, что и любая экранная форма. Это очень удобно для программистов, работающих на DELPHI и недоступно для пользователей программ. К числу достоинств Quick Report (на мой взгляд - очень спорных с точки зрения эргономики и человеческого восприятия информации) относят возможность создания так называемых "композитных" отчетов. (Создается несколько независимых друг от друга шаблонов отчетов и объединяют их в один отчет, который печатается как одно целое).
Таким образом, можно сделать вывод, что из трех рассмотренных здесь генераторов отчетов наиболее перспективным является Quick Report. Однако Quick Report - инструмент профессионального программиста на DELPHI. С некоторой натяжкой можно сказать, что генераторы Crystal Report и Report Smith доступны для очень продвинутого пользователя, который может составлять некие тривиальные "списковые" отчеты. Но не более того.
Попытка анализа этих и других, более дорогих и менее распространенных в России генераторов отчетов с точки зрения 12 классических правил Кодда для OLAP-продуктов, приведена на рис. 5.
Объем статьи не позволяет столь же детально остановиться на каждом из еще трех приведенных в таблице систем - признанных лидеров продаж на западном рынке. Это такие системы, как Oracle Discoverer & Express, Hyperion Wired for OLAP и SAS.
Самой продвинутой системой из этого перечня представляется SAS. Она работает на всех известных аппаратных и операционных платформах и обеспечивает статистическую обработку и анализ с использованием всех известных методов и алгоритмов регрессионного, дисперсионного, корреляционного, кластерного анализа, временных рядов и пр. С точки зрения анализа физических процессов эта система вне конкуренции с момента ее создания в 1976 году и по настоящее время.
Две другие системы: Oracle Discoverer и Express и Hyperion Wired for OLAP во многом схожи и почти поровну делят львиную долю (около 40%) рынка OLAP. К несомненным их достоинствам следует отнести высокую производительность, масштабируемость, интеграцию с приложениями MS Office и графическими пакетами визуализации данных. Эти несомненные достоинства плавно перетекают в столь же несомненные недостатки. Для обслуживания таких систем требуется специальный штат сотрудников, занимающихся установкой, сопровождением систем, формированием представлений данных для конечных пользователей.
Даже из приведенных выше характеристик можно видеть, что ни один из упомянутых продуктов нельзя в полной мере отнести к OLAP-системам по классическому определению: On-Line Analytic Processing. Одно из основных требований - прямую, без посредников-программистов работу с такими системами конечных пользователей, ни один из упомянутых продуктов не обеспечивает.

В таблице приведены характеристики еще одного генератора документов: CalliGraph v.4.0.
Помимо вполне естественных в настоящее время атрибутов ("Клиент-Серверная" архитектура, работа с любыми БД через стандартный ODBC, привычный пользовательский интерфейс "a'la MS Office", деловая графика, интеграция с MS Office и т.д.), CalliGraph v.4.0. имеет свои особенности и отличия от других генераторов.
По возможностям его можно сравнить только с наиболее близкими к требованиям OLAP генераторами, представленными в системах Oracle, Hyperion и SAS, с ценой в тысячи и десятки тысяч $ USA. Помимо того, что CalliGraph v.4.0. делает практически все, что с большим или меньшим успехом способны делать каждая из перечисленных выше систем, отметим следующее:
1. CalliGraph v.4.0 - единственный из известных мне программных продуктов, который полностью удовлетворяет всем 12-ти классификационным требованиям, предъявляемым к OLAP - продуктам. Смешно и грустно, но все эти характеристики уже имел даже первый вариант системы, разработанный и внедренный более двадцати лет назад, в 1979 году.
2. Следующее принципиальное отличие CalliGraph v.4.0 от других генераторов документов - это то, что он изначально создавался как средство для конечного пользователя, не обремененного даже минимальными знаниями программирования. В диалоге с генератором, пользователь сам конструирует именно тот отчет, который ему требуется и, что немаловажно, который он способен понять "здесь и сейчас".
В CalliGraph. реализована основная идея OLAP - идея многомерной модели данных, которая полностью совместима с моделью человеческого мышления, многомерного по определению, поэтому и процесс анализа в многомерной модели максимально приближен к реальности человеческого мышления. Задавая вопросы, человек налагает ограничения во многих измерениях. По измерениям в многомерной модели откладывают факторы, влияющие на деятельность объекта анализа. Запрос при этом формулируется практически на естественном, родном языке пользователя и в терминах его предметной области, а потому легко понимаем им. Таким образом, получают "гиперкуб" (название не очень удачно, поскольку под кубом обычно понимают трехмерную фигуру с равными ребрами, что, в данном случае, не так), который затем наполняется показателями деятельности по всем своим измерениям (цены, периоды времени, продажи, прибыли и т.п.). Наполнение это может вестись как реальными данными оперативных систем, так и прогнозируемыми. Измерения гиперкуба могут носить сложный характер, быть иерархическими, между ними могут быть установлены отношения. В процессе анализа пользователь может менять точку зрения на данные, тем самым просматривая данные в различных разрезах и разрешая конкретные задачи. Над "кубами" могут выполняться различные операции, включая прогнозирование и условное планирование (анализ типа "что, если").
3. Весьма принципиально то, что ограничений на размеры и сложность генерируемого документа не накладывается и его структура оптимизируется в зависимости не только от содержания запроса, задаваемой и накапливаемой информации об обрабатываемых БД, но и от попавшей в документ информации, требований по точности расчетов, максимальной упаковке данных, подавления (по заданию пользователя) незначащих (нулевых) строк и (или) столбцов, что важно для "разряженных" документов и т.д. Учитываются, естественно, и эргономические факторы восприятия информации пользователем. При этом один и тот же документ может быть представлен любым из ( N + 1 ) факториал теоретически возможных существенных способов представления, где N - количество непосредственно отражаемых в документе реквизитов. (Каждый реквизит, по сути дела, это свое измерение "гиперкуба" со своим набором граничных условий. Количество не отражаемых в документе, но используемых в запросе реквизитов (для предварительной фильтрации информации) в этой формуле даже и не учитывается.)
4. Очень принципиальным отличием CalliGraph v.4.0 от других генераторов документов является то, что документ любой структуры, сложности и организации формируется за один проход по информации, автоматически обеспечивая корректное взаимодействие и расчеты по любым измерениям всех затребованных в документе функций (процентов, средних величин, общих сумм, разностей, разностных процентов, частных и общих итогов, итогов с расшифровкой любой вложенности, и т.п.). При этом не требуется какой-либо предварительной обработки информации (создания каких-либо промежуточных таблиц, сортировок, выборок и т.д., необходимостью чего грешат практически все известные системы). Объективности ради отметим, что специальные виды анализа, такие, например, как используются в системе SAS для обработки физических экспериментов (кластерный, дискриминантный, регрессионный, корреляционный и т.п. виды) в CalliGraph не вводились, хотя каких-либо препятствий к этому нет и точки подключения любых расчетных функций определены.
5. CalliGraph v.4.0 обеспечивает уникальные средства для верификации и анализа информации, определяемые в процессе работы самим пользователем. Для этого в запрос можно включить неограниченное количество альтернативных условий с произвольным количеством ключей и их логических связей, любой степенью вложенности, с использованием реквизитов, их частей и (или) их различных агрегированных сочетаний - полей и частей реквизитов.
6. В CalliGraph v.4.0 включен механизм работы на любом национальном языке, путем подключения соответствующих словарей и таблиц. В настоящее время система обеспечена двумя словарями: русским и английским.
7. Есть все основания полагать возможным введения в систему голосового ввода запросов. Разработанный внутренний язык системы для этого идеально подходит. Планируется, что следующая версия системы будет ориентирована на голосовое управление генерацией документов.
8. Продукт лицензионно чист и зарегистрирован в Реестре программ для ЭВМ в Российской Федерации.
Перечисленных выше характеристик (по сути - интеллектуальных средств извлечения информации) удалось достичь благодаря тому, что была создана оригинальная теория документа, позволившая свести описание информационных потоков и связей к конечному множеству формальных дискретных алгоритмов, реализованных в терминах разработанного для этих целей внутреннего языка системы. В основу этой теории были положены: многомерная модель данных, математико-лингвистические модели обработки информации, использованы элементы и методы операторного исчисления, математической статистики, тензорного анализа, численных методов, теории графов, теории массового обслуживания и других чисто математических и смежных дисциплин. Для этого пришлось:

· систематизировать документы по типам, разбить типы на классы, для каждого класса создать алгоритмы однопроходной автоматической генерации документа в любом из (N+1)! теоретически возможных существенных представлений одного и того же документа, (где N - количество измерений (реквизитов), задействованных в запросе);
· разработать неизбыточный внутренний язык, с необходимыми и достаточными средствами описания формы, содержания и оптимизации документа, а также подключения расчетных функций;
· разработать интуитивно понятный язык общения генератора с непрограммирующим пользователем (использование технологий WYSIWYG, Drag-and-Drop);
· разработать несколько трансляторов - с графического языка пользователя на внутренний язык и обратно, транслятор с внутреннего языка на SQL, динамической настройки на БД и др.;
· обеспечить работу системы через ODBC, что позволило гарантировать независимость генератора CalliGraph v.4.0 от используемых БД, типов OS и сетей;
· минимизировать потоки информации между сервером и клиентскими машинами;
· разработать механизм и систему дополнительно включаемых в документ расчетных функций, допустимых для каждого из 35 известных в настоящее время системе типов реквизитов, определить точки подключения дополнительных расчетных функций, обеспечить их автоматическое корректное взаимодействие независимо от количества и состава на теоретически неограниченных по размерам и сложности документах.

С автором можно связаться по адресу E-mail: losev@calligraph.ru

(Статья для журнала "Hard & Soft".
Автор: Лосев В.З., 1997 г.)