Консалтинг и автоматизация в области управления
эффективностью банковского бизнеса

Журнал ВРМ World

Незапланированные запросы к Хранилищу данных на основе генерации View

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

Но, как известно, за все надо платить, "цена" этого достижения - крайне сложная схема первичной организации данных.

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

  1. Средства для построения нерегламентированных запросов, позволяющие оперативно взглянуть на данные через расширенный средний слой, который устанавливается для всех пользователей (Oracle Discoverer, Cognos Impromptu, Business Objects и Brio Query).
  2. Программы анализа и поддержки принятия решения, способные извлекать данные и анализировать их автономно (Microsoft Excel, Lotus и Cognos PowerPlay).
  3. Генераторы отчетов, используемые для создания пользовательских отчетов (Oracle Reports, IQ, Crystal Reports, InfoMaker и SQR).
  4. Системы разработки, позволяющие создавать пользовательские формы запроса (Developer/2000, PowerBuilder, Microsoft Access и Visual Basic).

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

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

Предположим, вы хотите извлечь значимую для вас информацию и настраиваете поле 14 соответствующим образом. Тем не менее, средство запроса представит это поле как "Атрибут 14". Дело в том, что средству запроса "ничего неизвестно" о том, каким образом достигается высокая гибкость Oracle-приложений.

Или, например, чтобы выполнить незапланированный запрос, необходимо уметь соединять таблицы, знать, как задать поиск по проиндексированным полям и т.д. Очевидно, что построение такого сложного запроса потребует значительных временных затрат, причем, если создавать такой запрос будет опытный аналитик. Что же касается рядового пользователя, то решение подобный задачи в лучшем случае будет крайне обременительно, а в большинстве случаев просто невозможно.

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

Во-первых, проблема регистрации пользовательских параметров не решается на уровне клиент-серверных приложений. Обычно, эти средства не читают библиотеку объектов приложения (Application Object Library) и, следовательно, не могут учесть пользовательские настройки.

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

 

Рис. 1. Построение клиент-сервер запросов с помощью существующих средств требует соединения множества таблиц

Разумеется, существуют средства, которые могут работать со многими системами управления базами данных, включая Oracle, Sybase, SQL Server, Informix и пр. В этом случае реальная экономия времени зависит от того, доступна ли "информация, описывающая данные в базе данных" (т. е. метаданные).

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

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

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

Что такое NoetixDW?

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

Во время установки NoetixDW можно настроить каждый из предлагаемых наборов незапланированных запросов (view). Эти запросы (view) относятся к предметным бизнес-областям (Business Subject Area): это "бухгалтерские гибкие счета" (accounting flexfield), списки "Быстрого выбора" ('Quick Pick' list), "Список бухгалтерских счетов компании и их коды" ('Chart-of-Accounts') и т.д. Таким образом, разработчик базы данных может сконфигурировать систему запросов для каждого конечного пользователя.

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

 

Рис. 2. NoetixDW (NoetixView) предлагает удобный и наглядный графический интерфейс

NoetixDW организует и собирает данные, необходимые для создания и наполнения предметных областей хранилища данных. Таким образом, программные продукты Noetix располагаются между приложениями Oracle Financials и самим хранилищем данных, выполняя функцию изолирующего слоя бизнес-метаданных.

Еще одна особенность NoetixDW - возможность защитить клиента (и, следовательно, конечного пользователя) от возможных неприятностей, вызванных изменениями в базовой структуре данных оперативных приложений. Так, в случае внутренних программных модификации, возникающих в результате установки новых версий Oracle Financial, пользователь будет по-прежнему получать корректные данные при выполнении незапланированных запросов. В результате модернизации ERP-приложений Oracle потребует минимум усилий.

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

Помимо этого, NoetixDW поддерживает незапланированные запросы, которые можно применять как к реляционным, так и многомерным хранилищам данных. Запросы могут быть реализованы и для пространственной звезды (Dimensional Star), и для снежинки (Snowflake).

Наконец, NoetixDW является уникальным "подспорьем" для тех, кто только собирается установить хранилище данных. Так, NoetixDW позволяет значительно ускорить и упростить процесс развертывания хранилища данных.

Заключение

Кратко перечислим основные преимущества применения технологии незапланированных запросов:

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