CC BY
59
П.Ф. Тарасенко, М. С. Бухарова
ТЕХНОЛОГИЯ «THE REPORTER» ДЛЯ ПОСТРОЕНИЯ ОТЧЕТОВ ПО БАЗАМ ДАННЫХ
Дается описание принципов, положенных в основу технологии «The Reporter», разработанной авторами для построения отчетов по базам данных. Данная технология основана на использовании объектного языка описания отчетов, существенным элементом которых являются статистические таблицы. При этом во внимание берутся стандарты и традиции предоставления статистической отчетной информации, действующие в практике российских организаций. Описание отчета может быть подготовлено с помощью специальных редакторов. В качестве источника данных может использоваться любая система управления базами данных (СУБД - Excel, Oracle, Access и т.д.), поддерживающая SQL через провайдер ADO. Построенный отчет может представляться в различных форматах (Excel, HTML и др.).
Одной из типичных проблем эффективного использования баз данных (БД) как организационного ресурса является гибкое построение статистических таблиц для мониторинга деятельности организации и принятия управленческих решений. Построение таких таблиц обычно сводится к следующим этапам:
а) принятие решения о составе системы таблиц, формализация их описания в виде макетов и инструкций к ним;
б) построение аналитической базы данных;
в) разработка и выполнение серии запросов для отбора данных;
г) подведение итогов и размещение полученных данных в результирующем документе.
Среди современных информационных технологий существует целый ряд средств, нацеленных на автоматизацию этих этапов, на придание всему процессу характера единой технологической операции с замкнутым циклом, позволяющей добывать нужную информацию из базы данных. К ним относятся прежде всего системы, реализующие технологию OLAP, которые предлагаются разработчиками всех популярных корпоративных систем управления базами данных (СУБД) [1]. Следует упомянуть разработки, нацеленные на использование в небольших офисах. Это система Crystal Reports [2] фирмы Crystal Decisions (в недавнем прошлом носившей название Seagate), компонент Pivot Table фирмы Microsoft и другие продукты этого класса [3].
Однако для практики работы информационных систем многих организаций все-таки характерно использование ограниченного набора встроенных отчетов, которые предназначены для предоставления стандартной информации вышестоящим органам или государственным службам, но не для снабжения информацией процессов принятия решений в самой организации. Можно назвать несколько причин этого положения дел, обусловленных такими свойствами упомянутых выше программных систем, как степень их доступности, локализации, привязки к конкретным СУБД или форматам выходной информации, соответствия российским стандартам и практике предоставления информации [7].
В данной статье описываются принципы работы технологии «The Reporter», которая разрабатывалась для преодоления перечисленных проблем. Приводятся детали языка описания отчетов, интерпретации отчетов и сведения о программной реализации.
Отличительными чертами технологии являются:
а) основанный на стандарте XML язык описания отчетов;
б) настраиваемый интерфейс к различным СУБД - источникам данных и к документам - приемникам отчетов;
в) возможность описывать в отчете трехмерные таблицы и таблицы с вложенными графами;
г) поддержка традиционных наборов селекторов, статистик, функций, выражений, способов сортировки, подавления и форматирования данных;
д) оптимизация кода SQL запроса за счет сокращения дизъюнктивной формы условий отбора, разбиения или объединения серии запросов.
Основные свойства системы
Задача технологии «The Reporter» - производство статистических отчетов, которые пользователь может легко создавать и изменять, не выполняя ру-
тинной работы и даже не имея глубоких знаний в области баз данных и SQL. При использовании этой системы разработчик имеет дело с объектной моделью отчета, что дает ему возможность сосредоточиться на описании свойств каждого объекта в отдельности: правил отбора данных (селектора), подведения итогов (формулы) и форматирования (формата) и др.
Идея объектного языка описания отчетов основана на предположении, что типичная структура отчета не произвольна, а является иерархической и может быть представлена в виде дерева. Так, отчет состоит из разделов, в которых содержатся таблицы. Каждая таблица состоит из строк и столбцов, которые могут иметь свои подграфы и т.д. Это дает возможность создать простой и ясный язык описания отчетов, в котором свойства каждого объекта отчета задаются независимо друг от друга. С другой стороны, наличие структуры отчета позволяет определить естественные правила взаимодействия описаний отдельных объектов. Так, селектор отчета распространяется на его таблицы и т.д. Формула объекта действует на все подчиненные ему объекты, если для какого-то из них не задана своя формула. На этой основе удается создать генератор запросов для получения необходимых данных, а также автоматизировать подведение итогов и заполнение такого отчета.
Другой особенностью системы «The Reporter» является обеспечение независимости отчета от источника и приемника данных (рис. 1). Достигается это за счет того, что в описании отчета перенастройка на другой источник или приемник делается путем указания их имен. Детали способов соединения с конкретной СУБД - источником данных и с документом
- приемником отчета, скрывающиеся за этими именами, вынесены в отдельное описание окружения.
Рис. 1. Диаграмма потоков данных при интерпретации отчета системой «The Reporter»
Такой подход позволяет разделить обязанности участников разработки отчетов. Настройка деталей соединений с источниками и приемниками остается
за квалифицированным специалистом по базам данных, а от разработчика отчета требуется знание предметной области и работа в рамках тех логических представлений данных источника и возможностей приемника, которые обеспечивает пользовательский интерфейс системы «The Reporter».
Другой аспект независимости описания отчета от приемника данных заключается в том, что при разработке отчета необходимо использовать какую-либо модель приемника и в терминах этой модели задавать размещение и форматирование элементов отчета. В качестве такой внутренней модели система «The Reporter» использует трехмерную электронную таблицу. Поскольку все приемники данных существенно отличаются друг от друга по своим характеристикам, то в системе определены преобразования этой внутренней модели в модель каждого из конкретных приемников данных.
Существенным для понимания принципа работы системы и ее возможностей является тот факт, что
все данные для отчета извлекаются из источника с помощью запросов SQL. Это означает, что все необходимые для отчета сведения уже должны содержаться в базе данных в полях одной или нескольких реляционных таблиц, и чтобы их получить, достаточно использовать запросы SQL. Если в каком-то приложении системы «The Reporter» все-таки невозможно получить нужные данные без предварительной процедурной обработки, то можно разработать программы построения аналитических таблиц, которые сохраняют на сервере БД результаты такой обработки. Впоследствии на основе этих таблиц можно строить требуемые отчеты.
Описание отчета: простой пример
В данном разделе приводится пример, служащий основой для дальнейшего изложения.
Предположим, что требуется построить отчет со структурой, приведенной в таблице.
Требуемая структура отчета
Число договоров по формам собственности Общее количество: [data] Данные за [год] год
Вид собственности Ква ртал Итого [год] Сумма крупных
I II III IV
Федеральная [datai [data] [data] [data] [data] [data]
Муниципальная [datai [data] [data] [data] [data] [data]
Частная [data] [data] [data] [data] [data] [data]
Итого [data] [data] [data] [data] [data] [data]
<?xml version=1.0?>
<REPORT formula="count(id)"
title-'Число договоров по формам
собственности"
selector="and( list(year),
range($From.,le,yearJe,$To.))"> <SUBTITLE text=”Общее количество: @Totalnum.”/>
<VALUE name=”Totalnum”/>
<PARM name=”From” text=”1998”/>
<PARM name=”To” text=”2000”/>
<TABLE title-Данные за @Year. год" >
<CORNER title=”Вид собств-ти”>
<VALUE name="Year", formula=”class”/> <COLS>
<BLOCK title="Квартал"> <BLOCK ti-
tle="@Quarter."
selector="list(quarter,(‘I','II','III ','IV'))">
<VALUE
name="Quarter", formula ="class"/>
</BLOCK>
</BLOCK>
<BLOCK title="итого @Year."/> <BLOCK title="Сумма крупных"
formula="/(sum(value),1000)"
selector="comp(value,ge,1000000)"/>
</COLS>
<ROWS>
<BLOCK ttle="@Privacy_name." selector="list(privacy_name)"> suppress="nested">
<VALUE
name="Privacy_name" formula="class"/>
</BLOCK>
<BLOCK title="Итого"/>
</ROWS>
</TABLE>
</REPORT>
Рис. 2. Описание отчета
Логику и структуру затребованного отчета можно описать, используя следующий (рис. 2) текст на языке описания отчетов системы «The Reporter». Описание этого отчета нуждается в дополнительных пояснениях, которые мы даем в следующем разделе. Мы предполагаем, что, знакомясь с этим материалом, читатель будет обращаться к примеру, приведенному в таблице и на рис. 2-4. В описании отчета (рис. 2) используется предположение, что база данных содержит поля с именами 'id', 'year', 'quarter' и 'value' в таблице 'договора', а также поле 'privacy_name' в таблице 'вид_собств'. Таблицы 'договора' и 'вид_собств' связаны через ключевые поля 'privacy_id', имеющиеся в обеих таблицах. Это приводит к двум вариантам кода SQL, представленным на рис. 3 и 4.
SELECT value, year, quarter, privacy_name,
count(id), sum(value) FROM вид_собств, договора
WHERE (privacy_types.privacy_id = bargains.privacy_id)
AND (year >=1998 AND year<= 2000)
GROUP BY value, year, quarter, privacy_name
Рис. 3. Запрос SQL без пользовательских функций
Вторая версия запроса (рис. 4) используется, если сервер базы данных позволяет вызывать процедуры в коде SQL, но не допускает логических выражений в директиве SELECT. В этом случае можно переложить на сервер часть работы, вызывая пользовательскую функцию package.comp, которая сравнивает свои аргументы, возвращая значение 1 в случае успеха или 0 при неудаче.
SELECT package.comp(value,'>=',100000), year, quarter,
privacy_name,
count(id), sum(value)
FROM вид_собств, договора
WHERE (вид_собств.privacy_id = договора.privacy_id)
AND (year >=1998 AND year<= 2000)
GROUP BY package.comp(value,'>=',100000), year,
quarter, privacy_name
Рис. 4. Запрос SQL с пользовательской функцией comp
Структура отчета и его объекты
Как уже было отмечено, интерпретатор отчетов использует иерархическую структуру отчета, чтобы объединить логику селекции данных, подведения итогов и форматирования отдельных объектов. Для исходного описания отчета используется стандарт XML [4]. Каждый тэг в таком описании представляет один из объектов, который может быть поименованным (тэги PARM, COLS, ROWS), озаглавленным (тэги SUBTITLE, CORNER) и/или классифицированным (тэги REPORT, SECTION, TABLE, BLOCK, VALUE).
Имя объекта используется для ссылок на его вычисленное значение или на другие свойства. Параметр (тэг PARM) используется для реализации пре-процессорной подстановки в атрибутах других объектов отчета (пример замены: $parameter_name.), что позволяет создавать параметризованные отчеты.
Озаглавленные объекты имеют заголовок, в который может вставляться значение другого объекта (пример вставки: @object_name.), если оно однозначно определено.
Отчет (тэг REPORT) является набором разделов и таблиц. Раздел (SECTION) - это набор подразделов и таблиц, он используется в основном для описания сложного размещения разнородных таблиц в отчете друг относительно друга. Тэг таблицы (TABLE) предназначен для описания строк, столбцов и угла таблицы. Тэг BLOCK используется для описания вложенных граф-столбцов и граф-строк. Объект «значение», представляемый тэгом VALUE, не появляется в итоговом документе отчета, но на его вычисленное значение можно ссылаться по имени из формул других объектов. К сказанному добавим, что отчет, раздел, таблица и блок являются озаглавленными классифицированными объектами и могут содержать подзаголовки (объекты-надписи с тэгом SUBTITLE) и значения (тэг VALUE).
Классифицированные объекты в итоговом документе могут иметь несколько экземпляров, как, например, на рис. 2 для блоков-строк с селекторами list, которые отвечают за формы собственности, годы, кварталы. Число экземпляров может быть задано перечислением в атрибуте селектора, например selector=”list(field_name,(1,2,3))”, или зависеть от числа различных значений, имеющихся в базе данных для заданного поля или выражения SQL, например selector=”list(field1+field2)”.
При использовании двоичного селектора число экземпляров равно одному. Например, для отбора записей, удовлетворяющих условию field_name<1 , используется атрибут selector=”comp(field_name,lt,1)”.
В силу того, что классифицированные объекты могут быть вложены друг в друга, число экземпляров вложенного объекта, зависящее от базы данных, может быть различным для разных экземпляров охва-
тывающего объекта. Так, в таблице за 1998 г. из примера в предыдущем разделе может быть три строки, а в таблице за 1999 г. - только две, если, скажем, в этом году не было сделок по объектам муниципальной собственности.
Сам селектор может быть сложным (селекторы and и or позволяют записывать булевские выражения), двоичным (селектор comp представляет сравнение с константой, range - интервал между двумя константами, селектор join выбирает перечислимое множество значений, over - определяет пересечение двух интервалов), многозначным (селектор list определяет ряд значений, hist - множество смежных интервалов). Каждый селектор может иметь отрицание, задаваемое восклицательным знаком (например, selector=”!and (comp(field1,lt,1), range(2,le,field2,lt,3)”).
Каждый экземпляр классифицированного объекта имеет значение, которое вычисляется в соответствии с атрибутом formula. Если этот атрибут у объекта опущен, то берется формула объекта, ближайшего сверху по иерархии отчета. В примере на рис. 2 формула отчета используется везде, за исключением значений с именами Year, Quarter, Privacy_name и блока, имеющего заголовок "Сумма крупных". Сама формула может быть выражением, использующим термы (константы, имена классифицированных объектов как ссылки на их значения, статистики SQL), функции и операции (арифметические, логические, тригонометрические, трансцендентные, случайные, информационные и др.). Кроме того, терм class используется в формулах как ссылка на текущее (по отношению к данному экземпляру) значение многозначного селектора list в ближайшем сверху классифицированном объекте. Так, в примере на рис. 2 классифицированный объект с именем Quarter будет иметь значение, равное текущему значению поля quarter, заданного селектором list(quarter,(T,'N7Nr,W')) в верхнем блоке. Терм empty используется для отмены действия формул, заданных в верхних объектах, что позволяет, например, описывать пустые строки или столбцы в таблице, если атрибут formula=”empty” действует для терминального блока.
В связи с тем, что в языке описания отчетов отсутствует объект, описывающий каждую ячейку таблицы отдельно, вычисление значений ячеек требует пояснения. При интерпретации отчета каждая текущая ячейка размещается на пересечении экземпляров двух блоков: один из них - экземпляр терминальной строки, другой - терминального столбца. В момент, когда вычисляется значение ячейки, к ней в конъюнкции применяются селекторы обоих блоков, заданные атрибутами selector. Что касается таких атрибутов, как формула (formula) и формат данных (dataFormat), то они применяются по принципу экранирования. Для всех объектов принцип экранирования означает, что действует атрибут ближайшего сверху объекта, где он задан, а для ячеек атрибут, заданный в строках, подавляет атрибут, заданный в столбцах. Другими словами, такие атрибуты ячейки определяются в предположении, что объекты, содержащие эту ячейку, образуют иерархию в следующем порядке: сначала идут объекты от отчета до таблицы вниз по иерархии, затем цепочка вложенных блоков-столбцов и, наконец, цепочка вложенных блоков-строк. Этот подход позволяет описывать таблицы, имеющие однородные блоки-столбцы,
за исключением некоторых (или даже всех) однородных блоков-строк. Это покрывает все встречающиеся на практике случаи компоновки таблиц, кроме такого крайне редкого и нестандартного варианта, когда в таблице имеется ячейка или группа ячеек, отличающихся по формуле или формату от всех своих соседей.
Еще одно пояснение - по поводу группировки вычисляемых значений. Для объектов VALUE, находящихся в блоках-столбцах, часто бывает необходимо рассчитывать значения не по каждому экземпляру строк, а по целой группе. Например, пусть столбец таблицы должен содержать проценты по отношению к групповому итогу (в терминах теории статистики - относительные показатели структуры). В этом случае, чтобы подвести групповой итог, для такого объекта VALUE может быть использован атрибут groupby, в котором задается список блоков-строк, селекторы которых (и вложенных в них блоков) будут отменены при подсчете итога. В результате внутри этих групп его значение будет одинаковым и равно групповому итогу. Например, тэг <VALUE name=”val” groupby=”row1name;row2name;*”/>, появляющийся в блоке-столбце, означает, что при вычислении значения val не будут приняты во внимание атрибуты блоков-строк с именами row1name и row2name. Причем если значение вычисляется для строк, не охватываемых этими двумя блоками, то будет подсчитан итог по всему столбцу (на это указывает звездочка в списке groupby).
Остается добавить, что при наличии многих экземпляров объектов для интерпретации отчета реализованы обычные в таких случаях способы сортировки (атрибут sort) и подавления (атрибут suppress). Здесь мы не уточняем эти возможности языка описания отчетов, ограничиваясь лишь их упоминанием.
Интерпретация отчета
Интерпретация отчета состоит из нескольких последовательных этапов.
Прежде всего, интерпретатор собирает воедино логику отбора данных и вычисления итогов, формируя один запрос на весь отчет (см., например, запросы на рис. 3 и 4). В таблице этого запроса часть полей являются индикаторами элементов разбиения пространства данных на области. Эти индикаторы служат в качестве признаков, по которым записи из таблицы запроса отбираются для подведения итогов по отдельным значениям и ячейкам таблиц отчета. Таким образом, интерпретатор не создает отдельных запросов для каждой ячейки, а получает от сервера данные, которые затем на стороне клиента подвергаются группировке в различных сочетаниях в соответствии с логикой отчета.
В некоторых случаях, когда отчет содержит разнородные данные, в целях оптимизации общего размера таблиц, получаемых от сервера, для отчета может быть создан не один, а несколько запросов. Разбиение на запросы делается по принципу построения отдельных запросов для некоторых поддеревьев в дереве описания отчета.
При построении запроса основной задачей является моделирование логики селекции данных, которая затем отражается в директивах WHERE и SELECT. Вы-
бранная для исходного описания отчета иерархическая структура его объектов позволяет легко создать дерево селекторов, моделирующее с помощью дизъюнктивной формы (ДФ) логику селекции данных. Далее это исходное дерево селекторов подвергается преобразованиям с целью оптимизации запроса.
Часть информации для запроса берется из описания окружения на этапе, помеченном цифрой 1 на рис. 5. Так, если об источнике данных известно, что он допускает вызов пользовательских функций, но не допускает логических выражений в директиве SELECT (как это имеет место для SQL СУБД Oracle), то будет использован вариант кода SQL, подобный примеру на рис. 5. Кроме того, для директив FROM и WHERE требуется задание «взгляда» (view) на данные источника, выбор которого в отчете осуществляется по имени или по умолчанию из числа заданных взглядов на данные, заданных для текущего источника в описании окружения. При генерации кода SQL учитываются и другие особенности источника данных, такие как формат даты, десятичный разделитель и др.
Рис. 5. Блок-схема процесса интерпретации отчета
Когда в ответ на запрос от сервера получены таблицы, наступает очередь подведения итогов для объектов и ячеек отчета и сохранения этих итогов в соответствующих экземплярах объектов. Для этого интерпретатор создает дерево данных отчета, в котором каждому объекту и ячейке отвечают их экземпляры, хранящие соответствующие значения.
Интерпретация таблиц требует дополнительной информации (метаданных), описывающей поля таблицы запроса с точки зрения логики отчета. На этом этапе требуется также информация о структуре отчета, чтобы подводить итоги, сохранять их, а затем экспортировать в приемник отчета. Интерпретатор отчета создает такую информацию при подготовке запросов, а затем использует ее на этапе подведения итогов (рис. 5).
Использование дерева данных позволяет достичь сразу нескольких целей: избежать повторных вычислений, проводить сортировку и подавление эк-
земпляров объектов отчета на стороне клиента и, самое главное, выделить последнюю стадию -окончательное оформление отчета - в отдельный этап, на котором решаются вопросы экспорта данных в различные внешние форматы. На этом последнем этапе экспорта отчета (рис. 5, 2) вновь используется описание окружения, в котором определяются тип и особенности приемника данных.
Таким образом, процесс интерпретации отчета состоит из нескольких этапов (рис. 5). При этом информация о структуре, селекторах, формулах, форматах отчета используется на нескольких этапах, как для формирования запросов, так и для интерпретации полученных в ответ на эти запросы данных.
Интерпретация таблиц требует дополнительной информации (метаданных), описывающей поля таблицы запроса с точки зрения логики отчета. На этом этапе требуется также информация о структуре отчета, чтобы подводить итоги, сохранять их, а затем экспортировать в приемник отчета. Интерпретатор отчета создает такую информацию при подготовке запросов, а затем использует ее на этапе подведения итогов (рис. 5).
Использование дерева данных позволяет достичь сразу нескольких целей: избежать повторных вычислений, проводить сортировку и подавление экземпляров объектов отчета на стороне клиента и, самое главное, выделить последнюю стадию - окончательное оформление отчета - в отдельный этап, на котором решаются вопросы экспорта данных в различные внешние форматы. На этом последнем этапе экспорта отчета (см. рис. 5, 2), вновь используется описание окружения, в котором определяются тип и особенности приемника данных.
Таким образом, процесс интерпретации отчета состоит из нескольких этапов (рис. 5). При этом информация о структуре, селекторах, формулах, форматах отчета используется на нескольких этапах, как для формирования запросов, так и для интерпретации полученных в ответ на эти запросы данных.
Одна из главных задач интерпретации отчета - оптимизация всего процесса в целом. Цель такой оптимизации могут выражать различные критерии: объем обработки данных (как на сервере, так и на клиенте), объем передачи данных от сервера клиенту и обратно, объем хранящихся данных (на обеих сторонах). Не следует забывать и о затратах времени и памяти на подготовительном этапе построения запросов. Эта многокритериальная задача, как известно, не имеет единственного решения, но выбор того или иного способа обработки данных непосредственно влияет на код запроса SQL. Интерпретатор отчетов системы «The Reporter» использует ряд эвристических приемов для того, чтобы упростить исходное дерево селекторов отчета с целью оптимизации условий в директиве WHERE и набора полей в директиве SELECT. Эти две цели являются независимыми задачами, поэтому рассмотрим каждую из них отдельно.
Оптимизация директивы WHERE
Основная цель оптимизации директивы WHERE заключается в упрощении условий отбора, которые подвергаются проверке на стороне сервера. По-
скольку логика селекторов отчета моделируется интерпретатором отчетов с помощью ДФ, то мы фактически имеем дело с проблемой, известной как задача сокращения ДФ [6].
Следует, однако, отметить, что методы булевой алгебры не во всех случаях приводят к наилучшему результату, поскольку понятия минимальной и сокращенной ДНФ не однозначно связаны с минимальной трудоемкостью проверки логических условий. Поэтому интерпретатор отчетов использует ряд эвристических правил для получения сокращенного описания отбора записей. Весь процесс упрощения ДФ состоит из нескольких этапов.
1. Преобразование исходной ДФ к ДНФ элементарных селекторов. На этом этапе сложные селекторы (гистограмма и перекрытие) выражаются через элементарные, после чего раскрываются скобки и производится сокращение полученной ДФ с использованием обобщенного многозначного поглощения и склеивания.
2. Построение минимального разбиения для каждого подпространства отчета, где селекторы заменяются дизъюнкцией элементов разбиения своего пространства, т. е. покрытие селекторов.
3. Построение ДНФ после покрытия селекторов. Как и на 1-м этапе, производится раскрытие скобок и сокращение полученной ДФ.
4. Приведение подобных в итоговой дизъюнктивной нормальной форме.
В процессе этих преобразований используются следующие ниже операции. Здесь буквы К обозначают конъюнкции, буквами А, В обозначаются простые селекторы, знаки -, & и V означают отрицание, конъюнкцию и дизъюнкцию соответственно, знак 2 соответствует дизъюнкции несовместных селекторов, О - полное пространство.
Раскрытие скобок.
Ко&(К1 V.. .V Кт) = К0&К1 V.. .V Ко&Кт,
^=1,п А1 У|=1,т А = ^=1,п ^=1,т
-(^=1,п & ]=1,т1 А1]) = ^£=1,К & 1=1,п(—А1](к)).
Поглощение селекторов.
А&В=А, если А^В (АзВ)
Склеивание конъюнкций.
А1&К^^Ап&К=А&К, где А^.^Ап=А (селекторы А1,..,Ап сохраняются для группировки).
В частности, К & -А V К & А = К, А1&К^^Ап&К=К, если А^.^Ап=а Обобщенное склеивание конъюнкций. (А1&К^.^Ап&КпЖК1&..&Кп) =
= А1&К^.^Ап&Кш если А^.^Ап=а Поглощение конъюнкций.
К1 & К2 V К2 = К2
(конъюнкция К1 сохраняется для группировки).
В частности, К2 V К2 = К2.
Разбиение пространств и покрытие селекторов.
Строится минимальное разбиение пространства {А1,..,Ап: 21=1,пА1=О}, благодаря которому любой селектор Вк в этом пространстве представляется в виде покрытия Вк = 21еикА1 .
Приведение подобных.
К0&К1 V.. .V Ко&Кт = Ко&(К1 V.. .V Кт),
Kjo&CKj V.. .V Km) V ... VKno&(Ki V.. .V Km) =
= (K,o V...V Kno) & (Kl V...V Km).
Все перечисленные операции выполняются путем замены левой части на правую часть равенства. При этом необходимо отметить следующие обстоятельства.
Порядок применения упомянутых операций несколько отличается от того, который рекомендуется в алгоритмах булевой алгебры для получения сокращенных ДНФ по методам Квайна или Блейка. Тем не менее во всех практических случаях, благодаря тому, что логика исходного отчета не является произвольной, с помощью применяемой последовательности действий получается приемлемый результат. Это утверждение не является теоретическим результатом, поэтому мы говорим лишь о наборе эвристических правил для упрощения директивы WHERE.
Далее каждый элементарный селектор применяется к некоторому скалярному пространству целых, вещественных или строковых значений из базы данных (или пространству функции от этих значений), на котором установлено отношение упорядочения. Произведение всех таких частных пространств образует пространство отчета, которое подлежит разбиению. При этом разбиение всего пространства отчета является произведением разбиений его скалярных подпространств. В результате можно считать, что каждый сложный селектор отчета соответствует некоторому подмножеству элементов многомерного разбиения. В связи с этим любой селектор можно рассматривать как некоторое множество в пространстве отчета. Этот подход отразился на обозначениях при описании операций.
При раскрытии скобок появляются новые копии начальных селекторов, при разбиении и покрытии селекторы распадаются на части, а при склеивании и поглощении несколько селекторов могут слиться в один, а некоторые будут сокращены. Все эти преобразования должны быть проведены так, чтобы сохранить информацию о группировке данных для вычисления значений объектов отчета. Поэтому между селекторами из исходного описания отчета и селекторами преобразуемого дерева поддерживаются связи типа многие-ко-многим, отражающие происхождение вновь появившихся селекторов. Сокращенные селекторы не уничтожаются, а запоминаются в отдельном дереве, т.к. тоже несут группирующую информацию. В дальнейшем оставшиеся и сокращенные селекторы или их конъюнкции могут выступать как группирующие признаки в директиве SELECT, и в этом случае их связи с исходными селекторами выступают как метаданные и привлекаются для расшифровки полученного ответа на запрос.
Методы сравнения селекторов
При проведении упрощений дерева селекторов необходимо строить разбиения и решать вопрос о полноте наборов селекторов. Поиск ситуаций, требующих преобразования, осуществляется на основе перебора, поэтому приходится производить большое количество сравнений селекторов друг с другом. Для ускорения этих операций и упрощения алгоритмов используется двоичная характеристика попарных сравнений селекторов, которая описывает
состав разбиения пространства признаков, порожденного селекторами A и B. Такая характеристика fA,B) имеет четыре двоичных разряда, которые в порядке от младшего (правого, нулевого) к старшему (левому, третьему) показывают наличие в разбиении множеств A\B, AB, B\A, Q\(AUB). Здесь Q -пространство отчета, A и B - его подмножества, отбираемые двумя селекторами. Используя распространенную нотацию, это можно записать следующим образом:
fA,B)&1 = (A\B*0), fA,B)&2 = (AB*0), fA,B)&4 = (B\A*0), fA,B)&8 = (Q\AUB^0).
Далее, если определена двоичная характеристика f=fA,B) для разбиения, порожденного парой множеств A и B, то с помощью побитовых операций можно получить и другие связанные с ней характеристики, например, следующие.
Для перестановки A и B: f (B,A) = fo f) = ffc8)|f&4)>>2|ffc2)|ffc1)<<2.
Для отрицания A:
fTA,B)=f (/)=(/&8)>>3|(/&4)>>1|(/&2)<<1|(/&1)<<3. Для отрицания B: f(A ,-B )=/2 (J)=fo(f\(fo((f)))). Отрицание A и B: /TA^B)^/ (/))=/2(/1 (/)).
При помощи этих соотношений вычисление характеристики разбиения двух селекторов можно провести в два этапа: сначала вычислить ее без учета отрицаний селекторов, а затем воспользоваться одной из приведенных выше формул.
Подход с использованием характеристики пар селекторов существенно сокращает число проверок различных условий. При этом все задачи сравнения сложных селекторов сводятся к вычислению характеристик для элементарных селекторов, не имеющих отрицания. В роли такого элементарного селектора выступает неравенство в одномерном упорядоченном пространстве. Действительно, интервал B может быть представлен в виде пересечения двух неравенств Bj и B2, поэтому для перехода к двоичной характеристике интервалов A и B достаточно использовать соотношение f (A, B1B2)= (f (A, B1) | f (A, B2)) & 10012+
+(f (A, B1) & f (A, B2)) & 01102 , которое выполняется, если только речь не идет об интервале B1B2, вложенном в интервал А. В случае такого вложения имеем f (A, B1B2) = 10112.
Оптимизация директивы SELECT
Все поля запроса, входящие в директиву SELECT, по своему назначению делятся на две группы. К первой группе относятся значения статистик (sum, count, min, max) или полей, которые используются при подведении итогов для формул отчета. Вторая группа полей запроса
- это группирующие признаки, которые позволяют определить, какие записи запроса должны быть отобраны для вычисления формулы того или иного экземпляра объекта отчета. От состава этих группирующих признаков зависят характеристики трудоемкости процесса: распределение работы между сервером и клиентом по определению принадлежности записи из запроса к кон-
кретной группе, а также объем передаваемой от сервера к клиенту таблицы.
В любом случае набор признаков должен позволять отбирать записи из запроса для всех формул отчета. Это означает, что для каждого экземпляра классифицированного объекта в процессе подведения итогов должны быть определены множество группирующих признаков и набор условий, которым они должны удовлетворять, чтобы запись была отобрана для вычисления формулы данного экземпляра. Для конкретной формулы, находящейся в определенном узле дерева отчета, в качестве группирующих признаков выступают селекторы, которые порождены селекторами из вышестоящих узлов дерева отчета. Для ячейки таблицы имеет место особая ситуация: группирующими признаками являются селекторы ее строки и столбца. Таким образом, множество группирующих признаков отчета есть объединение группирующих признаков всех терминальных итогов (VALUE) и блоков (BLOCK). При этом множества группирующих признаков разных формул могут пересекаться.
Значения группирующих признаков должны появляться в таблице запроса, т.е. соответствующие каждому признаку выражения должны появиться в директиве SELECT. Поэтому на сами признаки накладываются некоторые ограничения, связанные с набором допустимых выражений и функций, которые можно использовать в директиве SELECT запроса, обращенного к тому или иному источнику данных. На практике самым существенным ограничением является то, что для некоторых источников невозможно поместить в директиву SELECT результат проверки логического условия даже с помощью вызова пользовательских функций, вычисляющих логическое выражение на стороне сервера.
В соответствии с этими рассуждениями для построения группирующих признаков можно использовать несколько подходов, которые определяются следующими двумя факторами.
1. Группирующие признаки можно строить либо по исходному дереву селекторов отчета, либо по деревьям селекторов, полученным в результате его преобразований в процессе упрощения.
2. В качестве группирующих признаков можно использовать либо результаты проверки логических условий на стороне сервера (двоичные признаки), либо значения выражений SQL, чтобы затем проверять их на стороне клиента (исходные признаки).
Разные варианты этих факторов могут привести как к увеличению, так и к уменьшению количества полей в таблице запроса, поскольку в процессе упрощения дерева селекторов изменяется число группирующих признаков. Число же записей в таблице запроса при этом не зависит от выбора того или иного варианта по первому фактору, а определяется лишь логикой отчета. Для второго фактора вариант с исходными признаками может привести к катастрофическому увеличению числа записей, т.к. резко сокращаются возможности для группировки на стороне сервера.
В связи с этим в системе «The Reporter» реализовано использование как двоичных, так и исходных группирующих признаков. Один из этих вариантов можно
выбрать, настраивая источник данных в описании окружения. Обычно сервер базы данных способен выполнять проверку условий более эффективно, чем клиент. В этом случае следует выбрать двоичные признаки.
По первому фактору в настоящее время интерпретатор отчетов использует для построения группирующих признаков не исходное, а конечное дерево селекторов. Однако на практике встречаются случаи, когда число признаков в исходном описании меньше числа признаков в конечном описании логики отчета. Дело в том, что одним из этапов преобразований дерева селекторов является построение разбиений подпространств. При этом если исходные селекторы отчета пересекаются, то число условий, требующих проверки, становится больше после перехода к разбиениям (так, покрытием двух пересекающихся множеств является набор из трех не пересекающихся). В таких ситуациях может иметь смысл использование для построения группирующих признаков исходного описания селекции данных, однако здесь выбор варианта определяется не столько соотношением производительности сервера и клиента, сколько особенностями логики конкретного отчета.
Учет особенностей источника и приемника данных
Как уже отмечалось, интерпретация отчета построена так, чтобы обеспечить относительную независимость всего процесса от способов общения системы с внешними приложениями или документами. Однако существуют три главных фактора, которые делают процессы получения данных и представления отчета отличающимися для различных источников данных и приемников отчета. Перечислим эти факторы.
Особенности форматирования чисел и текстов в приемнике отчета. Некоторые из приемников (MS Excel, MS Access) имеют свои собственные механизмы и возможности форматирования чисел. Другие (MS Word, HTML) требуют форматирования чисел на стороне клиента. Интерпретатор отчетов использует атрибут format для описания форматирования заголовков объектов и атрибут dataFormat для описания форматов данных, полученных как вычисленные значения экземпляров классифицированных объектов отчета. Интерпретация этих атрибутов зависит от документа-приемника.
Особенности размещения отчета в документе-приемнике. Интерпретатор отчетов использует модель трехмерной электронной таблицы (row/column /sheet) для описания размещения отчета в документе-приемнике. При этом предполагается, что экземпляры каждого классифицированного объекта размещаются в кубе (точнее, в параллелепипеде), размеры которого измеряются в единицах экземпляров. Два из трех измерений этого куба имеют ограниченный размер (по количеству экземпляров). Третье измерение неограниченно, его размер определяется фактическим числом экземпляров, которое может быть заранее неизвестно до заполнения отчета. Ограничения размеров куба и взаимное расположение кубов для различных классифицированных объектов определяют атрибуты cube-Size и cubeAttach. Если фактическая модель докумен-
та-приемника отличается от трехмерной электронной таблицы, то для перевода внутренней трехмерной модели во внешнее представление должны использоваться некоторые правила преобразования. Например, для документов MS Word вместо листов рабочей книги будут использоваться отдельные страницы, а для размещения заголовков вместо указания ячеек таблицы будет употребляться указание абзаца.
Особенности языка описания запросов источника данных. Стандарт SQL для разных СУБД имеет свои особенности, которые приходится учитывать при генерации запросов. Например, СУБД Oracle не позволяет использовать в директиве SELECT логические выражения, зато допускает вызов пользовательских функций. Прямо противоположная ситуация имеет место для драйвера Microsoft Jet, обеспечивающего интерфейс OLE DB к MS Excel и MS Access. Однако проверка логических условий на стороне сервера БД - одно из средств ускорения процесса интерпретации отчета, и она должна быть реализована, если это возможно, для всех источников данных. Еще один пример - это различие используемых форматов дат в разных стандартах SQL. Все это должно быть учтено при автоматиче-
ской генерации запроса к тому или иному источнику и сказывается как на коде 80Ь, так и на содержании метаданных (см. рис. 5).
Перечисленные выше факторы, связанные с особенностями источников и приемников данных, должны быть учтены при описании окружения интерпретатора отчетов, в котором определяются на выбор действующие по умолчанию форматы, способы размещения объектов отчета, перечень источников, необходимые особенности их стандартов 80Ь, перечень взглядов на данные, перечень описаний приемников данных и т.п. Именно наличие этого описания окружения делает отчет в какой-то степени независимым от источника и приемника данных.
Программная реализация
На основе изложенных в данной статье методов генерации отчетов к настоящему времени разработано несколько программных продуктов. В результате сложилось ядро системы, определились способы отображения отчетов для просмотра и редактирования, а также интерфейс пользователя и разработчика отчетов (рис. 6).
Рис. 6. Внешний вид приложения «Мастер отчетов»
К способам отображения, предназначенным для редактирования отчета, относятся:
- текстовый редактор исходного описания отчета;
- редактор дерева объектов отчета;
- инспектор свойств текущего объекта отчета;
- редактор параметров отчета;
- редактор визуального представления текущей таблицы;
- визуальное представление размещения объектов отчета;
- редактор описания окружения.
Способы отображения отчета, предназначенные для контроля процесса интерпретации, позволяют просматривать:
- список сообщений интерпретатора;
- описание пространств отчета;
- связи многие-ко-многим между селекторами;
- код 80Ь запроса;
- таблицу данных, полученную в ответ на запрос;
- дерево данных отчета;
- деревья селекторов (исходное, сокращенное, приведенное).
Все способы отображения работают синхронно. Например, при добавлении столбца таблицы в редакторе дерева объектов отчета можно сразу увидеть, как изменилось визуальное представление этой таблицы. Выделение узла в дереве объектов отчета приводит к выделению этого объекта и в других редакторах.
На основе различных сочетаний способов представления отчета созданы приложения для:
- разработки отчетов (см. рис. 6);
- интерпретации отчетов (рис. 7);
- специализированных приложений (рис. 8);
- демонстрации технологии «The Reporter».
На рис. 6 приведен пример внешнего вида программы «Мастер отчетов», предназначенной для разработки отчетов. Основой интерфейса этого приложе-
На рис. 8 изображено окно специализированного приложения, которое предназначено для решения задачи построения годовой статистической отчетности комитета по земельным ресурсам. Роль пользователя здесь сводится к выбору отчетного периода (года), запуску процесса построения аналитических таблиц, по окончании которого пользователь запускает интерпретатор отчетов. Особенностью этой задачи является то, что имеется стандартный набор форм отчетности, известный в отрасли как формы 22. Иными словами, состав статистических
ния являются редакторы отчета и его объектов. При редактировании, в тех случаях, где это требуется по контексту, предусмотрено извлечение сведений из базы данных о составе таблиц, полей и значений.
На рис. 7 показан пример универсального интерфейса пользователя, который дает доступ только к типизованным параметрам отчета, но не ко всему исходному описанию. Основой интерфейса здесь служит редактор параметров отчета. Если разработчик отчета предусмотрел, например, настройку начала и конца отчетного периода, то пользователь может выбрать эти даты из календаря и запустить процесс интерпретации отчета. Кроме дат, с помощью типизованных параметров можно задавать списки значений полей или выражений 80Ь из базы данных, способы размещения и форматирования объектов, условия отбора и т. д.
таблиц фиксирован, макеты таблиц со своими заголовками граф и строк являются отраслевым стандартом и существует заранее подготовленный шаблон рабочей книги Excel, ячейки таблиц которого требуется заполнить. Система «The Reporter» в данном случае использует этот шаблон как приемник данных и размещает в нем результаты интерпретации заранее подготовленной серии отчетов по базе данных регионального земельного комитета. При этом данные в рабочей книге не форматируются, а используются форматы шаблона Excel.
Рис. 7. Внешний вид универсального интерфейса пользователя, предназначенного для редактирования параметров отчета и запуска процесса его интерпретации
Состояние: Ожидание команды
Окно сообщений О программе Выход
Рис. 8. Внешний вид специализированного приложения для заполнения годовой статистической отчетности комитета по земельным ресурсам
Заключение
Технология «The Reporter» направлена на упрощение процесса разработки отчетов. Она позволяет разделить обязанности администраторов баз дан-
ных, разработчиков и пользователей отчетов. Во многих случаях пользователь способен выступать и как разработчик отчетов. Основой для этого являются объектный язык описания отчета на базе стандарта XML и выделение описания окружения системы интерпретации в отдельную задачу.
Объектный подход и разработанный интерфейс приложений, реализующих эту технологию, позволяют при создании отчета, содержащего даже сложные статистические таблицы, сосредоточиться на свойствах отдельных элементов отчета - таблицы, графы и подграфы, строки и подстроки и т.п. Атрибуты этих объектов - селекторы, форматы, формулы и др. - описываются независимо друг от друга. Этот подход практически устраняет необходимость формулировать описание отчета в терминах запроса SQL к базе данных и приближает разработчика и пользователя к предметному пониманию отчета. Задача же подсистемы интерпретации заключается в том, чтобы, используя сформированную структуру отчета, собрать отдельные описания его объектов воедино, автоматически сгенерировать запрос к базе данных, подвести необходимые итоги по полученным в ответ от сервера таблицам и поместить результат в документ - приемник отчета. При этом создаваемые отчеты относительно независимы от источника и приемника данных. В результате отчет может разрабатываться и отлаживаться на сокращенной копии БД, помещенной, скажем, в MS Access, а эксплуатироваться - на реальной базе данных предприятия, находящейся под управлением, например, СУБД Oracle. Полученные в результате интерпретации отчета данные могут быть помещены в рабочую книгу MS Excel или при необходимости направлены в формат HTML.
ЛИТЕРАТУРА
1. Архипенков С. Аналитические системы на базе Oracle Express OLAP. М.: Диалог-Мифи, 1999.
2. Маклаков С. Введение в Seagate Crystal Reports 8.0. М., 2000.
3. Некрасов В. OLAP: сделано в России // PC Week/RE. 2001. №° 3. С. 21-22.
4. Эдди С. XML: Справочник. СПб.: Питер, 1999.
5. Tarassenko P., Bukharova M. System for Database Reports Generating // KORUS-2001, 5th Russian-Korean Int. Symp. on Sci. and Tech.,
June 26 - July 3, 2001. Tomsk: Proceedings, 2001. Vol. 1. P. 84-88.
6. Яблонский С.В. Введение в дискретную математику. М.: Наука, 1979.
7. Статистика: Курс лекций / Под ред. В.Г. Ионина. М.: ИНФРА-М, 2000.
Статья представлена кафедрой прикладной информатики факультета информатики Томского государственного университета, поступила в научную редакцию номера 3 декабря 2001 г.
