CC BY
36
СПИСОК Л
1. Скворцов, Н.А. Вопросы согласования неоднородных онтологических моделей и онтологических контекстов [Текст] / Н.А. Скворцов // Симп. Онтологическое моделирование. -М.: ИПИ РАН, 2008.
2. Сухарь, Р.С. Методы отображения онтологий. Обзор [Текст] / Р.С. Сухарь, А.П. Карпенко // Наука и образование: электронное научно-техническое издание. -2009. -№ 1. -C. 4
3. Haase, P. A Framework for Handling Inconsistency in Changing Ontologies [Текст] / P. Haase, Frank van Harmelen [et al.] // Lecture Notes in Computer Science. -Germany. -Springer-Verlag, 2005. -P. 353-367
4. Deutsch, N. The constructive and destructive processes [Текст] / N. Deutsch // New Haven - London,
1973. -P. 13-17.
5. Тузовский, А.Ф. Разработка систем управления знаниями на основе единой онтологической базы знаний [Текст] / А.Ф. Тузовский // Изв. Томского политехнического ун-та, 2007. -T. 310. -№ 2. -C. 182-185.
6. Task Force on Metadata. Summary Report [Электронный ресурс] // American Library Association. -1999. -June. -Режим доступа: www.libraries.psu.edu/tas/jca/ ccda/tf-meta3.html
7. Павлов, Д.А. О разрешении проблем противоречивости развивающихся онтологий [Текст] / Д.А. Павлов // Обробка шформацп в складних техшчних системах. -2007. -№ 3. -C. 65-72.
УДК 004.658.6
И.В. Бутенко
ПОСТРОЕНИЕ АНАЛИТИЧЕСКИХ ОТЧЕТОВ В ИНФОРМАЦИОННЫХ СИСТЕМАХ НА ОСНОВЕ МЕТАДАННЫХ
Решение проблемы «информационного взрыва» в современных системах автоматизации производственных процессов требует создания эффективных методов извлечения необходимых данных и программных средств их поддержки.
Развитие информационных систем на этапе операционного учета (OLTP системы) можно определить как накопление данных о состоянии процессов. При этом жизненный цикл подобных систем измеряется уже десятилетиями. В том случае, когда происходит замена соответствующего ПО, необходимые данные обычно конвертируются в новые форматы. Особенность построения информационных систем на настоящий момент заключается в том, что объемы данных не позволяют двигаться по этому пути. Должна обеспечиваться преемственность на основе стандартизации описания данных и, тем самым, возможность обеспечения доступа без указанных преобразований. В связи с этим при создании новых информационных систем разработчики используют аппарат, базирующийся на метаданных (МД). Он предоставляет возможности описания и манипулирования метаданными в рамках либо общей модели CWM (Common Warehouse Metamodel), сформированной группой OMG (Object Management
Group) [7], либо модели конкретной метасистемы (МС).
Таким образом, современные архитектурные решения обеспечивают решение проблемы «информационного взрыва». Однако большое количество информационных систем, которые не были разработаны на базе последовательного системного использования МД, требуют аппарата поддержки и агрегирования в современные информационные пространства предприятий.
Особую потребность в МД испытывают быстро меняющиеся информационные системы. Например, банковские системы, системы бухгалтерского учета, аналитические системы.
Выходом из создавшегося положения является построение МС на основе уже существующих информационных систем. Она должна формировать общее информационное пространство и обеспечивать дальнейшее развитие системы. Это, в свою очередь, требует разработки сопутствующих методов, алгоритмов и программного обеспечения. В [3] предложено решение этих вопросов.
Модели описаний объектов для МС имеют следующий вид.
Модель представления объектов. В рамках информационных систем разработчики оперируют следующим набором сущностей БД, которые и являются объектами МС: таблицы, хранимые процедуры (ХП), колонки таблиц, параметры процедур, типы данных и их описания
О = < п, Г, {О}, Р, С >,
где п - имя объекта (в терминах БД); t - тип объекта (таблица, ХП, колонка, параметр ХП); Р -параметры объекта, необходимые (и, может быть, достаточные) для построения объекта О на базе; С - описания объекта.
Модель описания классификаторов О = {о}— Ою с О . Здесь ю - ограничения, определяемые на множестве всех объектов О и позволяющие однозначно идентифицировать подмножество Ою.
В процессе преобразований может быть получено следующее описание: О = {ю^ юр, юС}.
Модель загрузки данных в метасистему Si —— О 0у е {1,,}, у > 1, где п - количество рассматриваемых объектов в Системе,у - номер описания объекта
Для того, чтобы каждый раз не загружать все множество объектов системы в МС, необходимо обрабатывать только те данные, которые изменились с даты последней загрузки. Поэтому, для загрузки данных в МС рассматривается подмножество 81оаС с 5 , где 8[оаС - объекты, измененные после последней загрузки в МС. Такое ограничение вводится, поскольку в рамках задачи рассматриваются объекты БД. Очевидно, что при первоначальной загрузке 81оаС = Б.
Загрузка метаданных. Для обеспечения универсальности механизма загрузки разработан специализированный формат, который был промежуточным звеном между МС и исходными данными (рис. 1).
При таком подходе можно разделить логику выгрузки данных из внешних источников и логику загрузки данных в МС. Требуется напи-
Рис. 1. Загрузка метаданных
сать только один загрузчик данных в МС F1 и, поскольку он будет получать данные в универсальном формате, его можно использовать при загрузке данных из любой системы. Заметим, что различия в СУБД, на которой построена система-источник, отсутствуют.
Организационные мероприятия. Отметим основные моменты, которые могут упростить построение и дальнейшее использование МС. Их можно назвать организационными мероприятиями, поскольку эти требования должны быть приняты в рамках всей организации, использующей МС.
При подготовке исходной информации для загрузки необходимо максимально полно описать значения С по выбранным типам описаний К. Алгоритм работы с МС в рамках такого подхода следующий:
описание значений С для всех объектов системы;
загрузка данных в МС; первичная классификация данных; доопределение объектов, если это необходимо в самой МС.
Рекомендуется максимально полно использовать механизм пользовательских типов, встроенный в стандартные поставки большинства промышленных СУБД. Для этого в исходной системе нужно выделить основные, часто используемые домены, и для каждого из них завести свой пользовательский тип. Выделение доменов может производиться в рамках самой МС. То есть после первоначальной загрузки данных начинается выделение и классификация основных типов, которые в дальнейшем переносятся в сами объекты БД.
Методика построения метасистемы
На основе всего сказанного выше детализируем методику построения метасистемы в виде последовательности отдельных этапов.
1. Выбор средств реализации МС. Для реализации МС необходимо выбрать следующие программные средства: СУБД, средства загрузки данных, средства реализации клиентского приложения. При выборе СУБД стоит, в первую очередь, отталкиваться от того, с какой СУБД проще и дешевле работать конкретным разработчикам МС. Связано это с тем, что все модели и алгоритмы могут быть реализованы на любой СУБД. Таким образом, никаких функциональных ограничений при реализации МС нет.
2. Реализация структуры БД МС. В качестве структуры БД можно воспользоваться результатом [3]. Практический опыт показывает, что эта структура достаточна для реализации МС в различных предметных областях и для различных конечных целей (построение аналитических отчетов, использование в качестве справочника по системе). При этом в предложенных моделях, на основе которых построена структура БД, допускается расширение базового набора параметров объектов. Таким образом, и структура БД будет несколько видоизменена. На практике расширение свойств объектов в рамках предложенных моделей влечет за собой увеличение количества параметров у объекта МС. А это, в свою очередь, реализуется добавлением необходимого количества столбцов в таблицу описания.
Поскольку операция расширения описания объекта МС - явление крайне редкое (за время реализации МС автором от начальной предложенной структуры до конечной, реализованной в нескольких коммерческих заказах, описание объекта увеличилось на два параметра), то можно пренебречь накладными расходами на перестроение структуры данных.
3. Загрузка метаданных. В качестве средства загрузки метаданных рекомендуется использовать алгоритм, описанный в [3]. Этот алгоритм может быть недостаточен лишь в ситуации, когда требуется загрузка данных в МС из источников вида: структурированные документы, изображения, специальные программы и т. п. В таком случае будет требоваться реализация своего собственного загрузчика. При этом новый загрузчик должен обладать следующими свойствами:
для уменьшения объемов загрузки данных будут обновляться данные только по объектам, измененным после последней загрузки;
для уменьшения числа затрагиваемых при загрузке параметров будут обновляться только реально обновленные данные.
Сам по себе загрузчик состоит из двух частей: модуля чтения метаданных из внешнего источника и модуля загрузки данных в МС. При этом, в качестве второго модуля всегда может быть выбран реализованный в работе загрузчик. Модуль чтения метаданных полностью привязан к источнику данных: его формату, способу хранения данных и т. д. Таким образом, только эта часть реализации загрузчика «ложится на плечи» разработчика МС.
4. Построение дерева классификатора. При
построении дерева классификаторов на этапе первоначальной загрузки рекомендуется выделить в описании Р такие свойства, по которым можно было бы разграничить объекты по области применения, области действия, типу объекта.
При первоначальном наполнении системы данными, когда еще мало описательной информации, строить классификаторы по С не всегда корректно из-за того, что многие объекты выпадут из рассмотрения. В то же время, классификация объектов по свойствам Р гарантирует участие в выборке всех объектов.
5. Организационные мероприятия. Для полноценного использования метасистемы и для минимизации затрат на ее поддержку рекомендуется использовать алгоритмы, состоящие из следующих шагов.
Подготовка исходной информации для загрузки. В рамках данной методики предлагается два варианта подготовки информации для загрузки.
Первый заключается в необходимости максимально полно описать значения C для выбранных типов описаний K. Алгоритм работы с МС для такого подхода следующий:
описание значений С для всех объектов системы;
загрузка данных в МС; первичная классификация данных; доописание объектов, если это необходимо в самой МС.
Второй вариант отличается от первого тем, что значения С предварительно не будут заполняться в самих объектах. Загрузка данных МС и первичная классификация будут осуществляться только по значениям вектора Р, который всегда заполнен. После загрузки данных необходимо будет вручную максимально полно описать значения С для как можно большего количества типов описаний ^ Только после этого можно будет проводить классификацию объектов по их описаниям. Таким образом, такой подход требует следующей последовательности шагов: загрузка данных в МС;
классификация данных только по значениям вектора Р;
полное описание объектов системы в МС; классификация объектов МС по сформированным описаниям;
выгрузка заполненных обновленных данных для того, чтобы в дальнейшем не перезаписать и
не потерять только что введенную информацию.
В данном случае выбор подхода ложится на пользователя. Как показал опыт, на деле получается комбинация двух вариантов, поскольку обычно в текстах скриптов встречаются комментарии, которые в нашем случае и являются исходным описанием объекта. Они автоматически загружаются в МС. А те данные, которых не хватает, и те, по которым не было соответствующего комментария, дополнительно вводятся вручную.
Введение пользовательских типов. Рекомендуется максимально полно использовать механизм пользовательских типов, встроенный в стандартные поставки большинства промышленных СУБД. Для этого в исходной системе нужно выделить основные часто используемые домены и для каждого такого домена завести свой пользовательский тип. Выделение доменов может производиться в рамках самой МС. То есть после первоначальной загрузки данных начинается выделение и классификация основных типов, которые в дальнейшем переносятся в сами объекты БД.
Оценка эффективности методики на реальных задачах
В качестве примера применения МС рассмотрим задачу построения OLAP-кубов на основе существующих данных в оперативной БД. Стандартным вариантом решения такой задачи может быть построение необходимого куба данных специалистом, хорошо разбирающимся в структуре БД ИС. На практике таким человеком обычно выступает разработчик этой системы. Если система была куплена в виде коробочного готового решения, то пользователи системы становятся заложниками ситуации: построить нужный им отчет может только фирма-разработчик.
Задачей данной работы было создание такой системы, которая позволит именно специалисту в предметной области, а не в области баз данных, выполнять те или иные настроечные работы.
Покажем, как именно с помощью предлагаемой метасистемы могут быть решены задачи подобного вида.
Рассмотрим задачу анализа работы уборочной техники. В оперативную БД MS SQL Server 2005 каждую минуту поступают данные от каждой единицы уборочной техники (УТ) с информацией о ее параметрах: местоположение, скорость, состояние датчиков (по ним определяется, какие именно работы выполняются), дата
посылки и т. д. Всего в посылке содержится 19 параметров. Все эти данные заносятся в оперативную БД. По требованию заказчика в данной системе предполагалась работа 2 500 единиц УТ одновременно. При этом, независимо от того, стоит УТ в гараже или убирает улицы, частота отправки сообщений одинакова - один раз в минуту.
Таким образом, получаем, что в данной системе каждый день появляется 2 500 х 60 х 24 = = 3 6000 00 записей. Через месяц данных станет больше 100 млн.
Кроме задач сохранения оперативных данных, система должна обеспечивать возможность пользователю получать отчеты в различных срезах за различные периоды, иначе смысл системы теряется сам по себе. Отметим, что БД работает с большим количеством данных, исчисляемых сотнями миллионов только в одной таблице. Реляционная БД может с таким объемом просто не справиться.
Типичным средством решения задачи анализа данных в больших БД является построение OLAP-кубов [6]. Поскольку исходные объекты системы лежат в MS SQL Server 2005, то в качестве средства построения OLAP выбран продукт, также входящий в MS SQL Server - Analyzes Services (рис. 2).
Рассмотрим более подробно задачу построения OLAP-куба:
1) формализация требований технологом в терминах предметной области;
2) постановка задачи разработчику в терминах объектов БД;
3) настройка разработчиком объектов для расчета куба в Analyzes Services в терминах объектов БД;
4) расчет OLAP-куба в среде Analyzes Services;
5) работа технолога с OLAP-кубом.
Отметим, что нами рассмотрен случай, когда в качестве «конечного заказчика» выступает технолог. На практике заказчиком может быть руководитель, бухгалтер, сторонняя организация и т. д. В любом случае, задача построения отчета дополнится постановкой задачи технологу, которая может состоять из многих шагов, в зависимости от принятой технологии работы в организации. При этом работа непосредственно по настройке куба сведется к описанным шагам.
Обратим внимание, что пункты можно разбить следующим образом:
постановка - 1, 2;
Рис. 2. Формирование OLAP-куба через метасистему
настройка и расчет - 3, 4;
использование - 5.
Постановка в данном случае выполняется два раза: сначала - на языке пользователя, затем - на языке объектов БД. Теперь попробуем решить ту же задачу в рамках системы, которая использует в своем составе МС.
В МС содержатся описания всех объектов исходной БД. Таким образом, представляется логичным именно в рамках МС настраивать объекты, участвующие в расчете куба: таблицы фактов и измерений. Поскольку в МС данные ведутся в терминах предметной области, то это действие должен выполнять технолог.
Следующий этап - обеспечение окончательной настройки по выделенным в МС объектам и расчет куба в самом Analyzes Services. Такие средства предоставляет сам Analyzes Services, поскольку он обеспечивает настройку кубов по сформированным в других средах проектам в виде XML. При этом, в данный XML можно передать кроме ссылок на сами объекты БД еще и мета-описания этих объектов [1, 2, 4]. Таким образом, даже в среде разработки Analyzes Services окончательную настройку может выполнять технолог в терминах предметной области.
Теперь опишем план, при условии, что в рамках данной системы построена МС, содержащая описания объектов БД.
1. Формализация требований технологом в терминах предметной области.
2. Настройка технологом объектов для расчета куба в Analyzes Services в терминах объектов
БД.
3. Расчет OLAP-куба в среде Analyzes Services.
4. Работа технолога с OLAP-кубом.
Как видим, пункт общения с разработчиком пропал, теперь задача полностью решается технологом за счет повышения уровня языка с объектов БД на термины предметной области.
В данном примере была использована реализация пользовательского интерфейса МС с помощью технологии WPF. Она представляет собой новую технологию создания интерфейсов. Имеет в своем составе высокоуровневый объектно-ориентированный функциональный слой, позволяющий создавать 2D- и 3D-интерфейсы. В ней для отрисовки объектов используется не GDI+, как в Windows Forms, а DirectX. Также она поддерживает привязку данных, темы и нестандартные для WinForms элементы. Производительность WPF выше, чем у GDI+, за счет использования аппаратного ускорения [5, 8].
Помимо реализации отображения и редактирования данных МС, интерфейсу необходимо добавить функциональность загрузки МД в проект Analysis Services. Эта функциональность является ключевой для данного проекта. Для загрузки метаданных будем формировать каркас AS (Analysis Services) проекта путем программного создания соответствующих XML файлов. Пользователь отмечает, какие объекты и свойства он хочет загрузить из МС в AS проект. После этого программа проходит по всему дереву классификаторов, выбирает отмеченные для загрузки объекты и свойства и на их основе формирует соответствующие XML файлы для создания OLAP-куба. Формирование XML файлов
Шаблоны файлов AS-проекта
Тип файла Шаблон
Файл определения проекта служб Analysis Services (DWPROJ) DWPROJ.tpl
Пользовательские настройки проекта служб Analysis Services (DWPROJ.USER) DWPROJ.USER.tpl
Файл источника данных (DS) DS.tpl
Файл представления источника данных (DSV) DSV.tpl
Файл куба (CUBE) CUBE.tpl
Файл секций (PARTITIONS) PARTITIONS .tpl
Файл измерения (DIM) DIMESION.tpl
Файл базы данных (DATABASE) DATABASE.tpl
происходит на основе заранее созданных шаблонов (табл.), к которым только добавляются нужные узлы.
При формировании проекта OLAP-куба из XML файлов основной интерес представляют файлы DSV, CUBE и DIM. В файле DSV описаны представления источника данных. Эти представления являются списком таблиц, используемых в
проекте. Описания таблиц и их свойств даются в понятиях метасистемы.
После необходимой доработки полученного каркаса в среде Analysis Services, для формирования из него пригодного к процессингу куба и заполнения этого куба соответствующими данными из исходной системы можно получить обычный OLAP-куб (рис. 3).
Рис. 3. Окончательная схема куба
Рис. 4. Предлагаемый вариант аналитической подсистемы
Готовый куб затем можно просмотреть в любом средстве просмотра кубов, например в Excel.
В качестве второго примера была выбрана задача построения аналитической подсистемы для коммерческого банка (рис. 4). Заказчиком подобной системы выступал Северо-Западный Банк Сбербанка РФ. Аналитическая подсистема строилась на базе системы «Управление кассовой работы и управление инкассации» (УКР/УИ). Последняя построена на ядре «СКАУТ 5.0», позволяющем строить учетные системы любой сложности. Эта система предназначена для автоматизации расчетно-кассовых операций, деятельности службы инкассации и других служб коммерческого банка. В ней реализованы системы контроля движения и учета ценностей, обработка заявок, АРМ различных работников, разграничение прав пользователей и др.
В данной системе исходные данные (результаты различных транзакций, справочники и т. п.) хранятся на двух различных базах разных кассовых центров банка (КЦ 1 и КЦ 2). Часть данных
реплицируется. Требуемые для аналитики данные по расписанию выгружаются в хранилище данных (ХД).
При реализации данной задачи МС была использована как промежуточная область между операционными данными (КЦ 1 и КЦ 2) и аналитическими (ХД и OLAP).
В результате, с помощью предлагаемой МС были реализованы двенадцать аналитических отчетов для банка. При этом всю настройку логики работы отчетов осуществляли технологи банка без участия программистов.
Таким образом, предложенная методика построения метасистемы и инструментальные средства поддержки выполнения ее этапов позволяют не только строить информационные системы, наследующие БД с уже определенными структурами данных, но и создавать проблемно-ориентированные оболочки уже существующих систем для обеспечения работы пользователя в его профессионально-смысловой среде.
СПИСОК ЛИТЕРАТУРЫ
1. Бутенко, И.В. Реализация механизма загрузки метаданных в Microsoft Analysis Services [Текст] / И.В. Бутенко, Д.Ф. Дробинцев, В.Э. Ковалевский // Технологии Microsoft в теории и практике программирования. -СПб.: Изд-во Политехн. ун-та, 2010. -С. 97-98.
2. Бутенко, И.В. Использование многомерных структур для обработки больших объемов аналитических данных [Текст] / И.В. Бутенко, В.Э. Ковалевский // Технологии Microsoft в теории и практике программирования. -СПб.: Изд-во Политехн. ун-та, 2010. -С. 96-97.
3. Бутенко, И.В. Методика построения репози-тория метаданных для существующей информационной системы [Текст] / И.В. Бутенко, С.М. Устинов// Научно-технические ведомости СПбГПУ -2010. -№ 4 (103). -С. 92-99.
4. Бутенко, И.В. Разработка моделей и методов по-
строения и автоматизированного наполнения системы метаданных[Текст] / И.В. Бутенко, С.М. Устинов // Сб. науч. тр. -СПб.: Изд-во Политехн. ун-та, 2009. -С. 3-10.
5. Мак-Дональд, Мэтью. WPF: Windows Presentation Foundation в .NET 3.5 с примерами на C# 2008 [Текст] / М. Мак-Дональд; пер. с англ. -СПб.: Вильямс, 2008.
6. Баргесян, А.А. Технологии анализа данных: Data Mining, Visual Mining, Text Mining, OLAP [Текст] / А.А. Баргесян, М.С. Куприянов, В.В. Степаненко [и др.]. -СПб.: БХВ-Петербург, 2007. -2-е изд. перераб. и доп. -384 с.
7. [Электронный ресурс] / Режим доступа: http:// www.omg.org/
8. Wadhwa, P.S. Customized Metadata Solutions for a Data Warehouse - A Success Story [Текст] / P.S. Wadhwa, P. Kamalapur. -White Paper, 2004.
