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

Журнал ВРМ World

Совместное использование учетных систем и технологии OLAP

В наше время без систем управления базами данных не обходится практически ни одна организация, особенно среди тех, которые традиционно ориентированы на взаимодействие с клиентами. Банки, страховые компании, авиа- и прочие транспортные компании, сети супермаркетов, телекоммуникационные и маркетинговые фирмы, организации, занятые в сфере услуг и другие - все они собирают и хранят в своих базах гигабайты данных о клиентах, продуктах и сервисах. Ценность подобных сведений несомненна. Они применяются для различных целей, например для управления материально-техническими запасами, управления отношениями с клиентами (CRM - customer relationship management), биллинга (формирования счетов) и т.п.

Такие базы данных называют операционными или транзакционными, поскольку они характеризуются огромным количеством небольших транзакций, или операций записи-чтения. Компьютерные системы, осуществляющие учет операций и собственно доступ к базам транзакций, принято называть системами оперативной обработки транзакций (OLTP - On-Line Transactional Processing) или учетными системами.

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

Необходимость использования OLAP в учетных системах

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

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

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

Этим объясняется интерес к объединению и анализу данных учетной системы с помощью технологии OLAP (On-Line Analytical Processing - оперативная аналитическая обработка). Этот метод позволяет аналитикам, менеджерам и руководителям "проникнуть в суть" накопленных данных за счет быстрого и согласованного доступа к широкому спектру представлений информации. Исходные данные преобразуются таким образом, чтобы наглядно отразить структуру деятельности предприятия.

При этом конечному пользователю предоставляется ряд аналитических и навигационных функций:

  • расчеты и вычисления по нескольким измерениям, иерархиям и/или членам;
  • анализ трендов;
  • выборка подмножеств данных для просмотра на экране;
  • углубление в данные (drill down), для просмотра информации на более детализированном уровне;
  • переход к детальным данным, лежащим в основе анализа;
  • поворот таблицы отображаемых данных.

Сравнение технологий

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

В концепции и терминологии OLAP есть много аналогий с реляционной моделью. В таблице 1 приведено сравнение реляционных терминов и понятий и соответствующих эквивалентов в OLAP.

Таблица 1.
Реляционная технология OLAP Технология
База данных
База данных
Таблица Куб
Представление (Выборка) Формула
Первичный ключ Измерения
Внешний ключ, не являющийся частью первичного ключа Отношение
Столбец, не являющийся частью первичного или внешнего ключа Переменная
Строка Экземпляр нескольких переменных
Декларативная целостность ссылочных данных
Косвенно задается при определении измерений
Процедурная целостность ссылочных данных (триггеры) Отсутствует
Индексы Отсутствует
Системный каталог Метаданные
Оператор JOIN Отсутствует (косвенно задается общими измерениями)
Оператор WHERE Команда LIMIT
Оператор GROUP BY Команда GROUP
Оператор ORDER BY Команда SORT
Директива GRANT PERMIT
Хранимые процедуры, сценарии, хранимый SQL Программы и пользовательские функции
Null-столбцы Null-значения
Null-строки - не могут быть в таблице или в результирующем множестве Null-значения всегда в явном виде
Управление потоковым языком (PL/SQL, Transact-SQL и др.) Язык хранимых процедур
Агрегирование (SUM, AVG, COUNT, MIN, MAX) Функции и формулы
Операторы вычисления (+, -, /, *) и два-три десятка математических, строковых и временных функций Формулы (+, -, /, *, **) более 100 математических, финансовых, статистических, прогнозирующих, моделирующих, строковых и временных функций
Оператор SELECT REPORT
Оператор INSERT MAINTAIN ADD
Оператор DELETE MAINTAIN DELETE
Оператор UPDATE SET
Оператор COMMIT UPDATE

 

Необходимо отметить, что различия этих технологий существенны. В таблице 2 приведено сравнение системных характеристик OLTP и OLAP.

Таблица 2.
Системная характеристика
Учетная система (OLTP)
OLAP
Взаимодействие с пользователем
На уровне транзакции
На уровне всей базы данных
Данные, используемые при обращении пользователя к системе
Отдельные записи
Группы записей
Время отклика
Секунды
От нескольких секунд до нескольких минут
Использование аппаратных ресурсов
Стабильное
Динамическое
Характер данных
Главным образом первичные (самый низкий уровень детализации)
В основном производные (сводные значения)
Характер доступа к базе данных
Предопределенные или статические пути доступа и отношения данных
Неопределенные или динамические пути доступа и отношения данных
Изменчивость данных
Высокая (данные обновляются с каждой транзакцией)
Низкая (во время запроса данные обновляются редко)
Приоритеты
Высокая производительность Высокая доступность
Гибкость
Автономность пользователя


Совместное использование OLAP и учетной системы, в частности прямая настройка аналитических функций на OLTP-базу, осложняется несколькими факторами:

  • OLAP запросы к базам данных чаще всего бывают сложными и требуют много времени. Прямой доступ к OLTP-базе существенно снижает общую производительность оперативной системы.
  • Разнообразные учетные системы неоднородны по типу используемых синтаксических соглашений и концептуальных допущений (единицы измерений, онтологии, наименование, кодирование и т.п.), поэтому их интеграция затруднена.
  • Данные в учетных системах часто "зашумленные", неполные и несогласованные.
  • Как правило, нет единой модели данных масштаба предприятия. Кроме того, при проектировании баз учетной системы могут использоваться разные модели данных (иерархическая, реляционная, объектно-ориентированная, плоские файлы, "фирменные" модели).
  • В оперативных системах отсутствует метод предоставления данных для конкретных групп пользователей в нужной для них форме.
  • Информация за прошлые периоды теряется при обновлении OLTP- базы (при записи в нее новых, актуальных данных). Это препятствует выполнению анализа временных тенденций, который так важен для многих сфер бизнеса.
  • В OLTP-базе не хранятся данные в агрегированном, денормализованном, виде, что необходимо для оперативной аналитической обработки. А преобразование данных в процессе выполнения запросов оказывается слишком трудоемким.

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

Пути интеграции

Процесс интегрирования OLAP-технологии с учетными системами может осуществляться по-разному. Все подходы имеют свои преимущества и недостатки. Как уже было сказано выше, прямая настройка аналитических средств (Direct BI) затруднена. Возможно также создание дублированных баз данных, витрин и Хранилищ данных. Практически всегда возникает необходимость в преобразовании операционных данных в аналитические. Для создания многомерного представления, нужно настроить данные так, чтобы они соответствовали логической многомерной структуре, далекой от структуры учетной системы. Например, многие измерения, используемые для анализа, могут вообще не иметь соответствий в учетных системах и извлекаться из других источников.

Хранилище данных

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

Информация в Хранилище является предметно-ориентированной, интегрированной, она хранится долговременно, а ее управление осуществляется независимо от исходных операционных баз данных. В отличие от OLTP-баз, где хранятся детальные данные в виде отдельных записей, в Хранилище содержится сводная и консолидированная информация (часто из нескольких операционных источников), в том числе и историческая.

Объем данных в Хранилище намного больше, чем в базе учетной системы (в тысячи раз). Здесь данные организованы в пре-агрегированной форме в виде многомерных кубов (гиперкубов), удобных для выполнения аналитических операций. Архитектура Хранилища представлена набором компонентов, среди них: источники данных, репозиторий метаданных (здесь описывается, какая информация доступна и где), один или несколько серверов Хранилища или центральный репозиторий (который управляет исходными базами и поддерживает многомерные представления данных), а также интерфейсные средства (например, для создания запросов, отчетов и выполнения анализа).

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

Совместное использование различных моделей данных

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

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

Каким образом реляционные и многомерные средства работают совместно? OLAP продукты вливаются в существующую корпоративную инфраструктуру путем интегрирования с реляционными системами. Администраторы баз данных либо загружают реляционные данные в многомерный кэш, либо настраивают кэш для доступа к SQL данным.

В таблице 3 приведены сравнительные характеристики различных моделей управления данными:


Таблица 3.
Характеристики
Реляционные СУБД OLTP
Реляционные СУБД СППР/Хранилища данных
Многомерные СУБД OLAP
Типовая операция Обновление Отчет Анализ
Уровень аналитических требований Низкий Средний Высокий
Экраны Неизменяемые Определяемые пользователем Определяемые пользователем
Объем данных на транзакцию Небольшой От малого до большого Большой
Уровень данных Детальные Детальные и суммарные В основном суммарные
Сроки хранения данных Только текущие Исторические и текущие Исторические, текущие и прогнозируемые
Структурные элементы Записи Записи Массивы


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

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

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

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

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