2003 г
Совместное использование учетных систем и технологии OLAP
В наше время без систем управления базами данных не обходится практически ни
одна организация, особенно среди тех, которые традиционно ориентированы на взаимодействие
с клиентами. Банки, страховые компании, авиа- и прочие транспортные компании,
сети супермаркетов, телекоммуникационные и маркетинговые фирмы, организации,
занятые в сфере услуг и другие - все они собирают и хранят в своих базах гигабайты
данных о клиентах, продуктах и сервисах. Ценность подобных сведений несомненна.
Они применяются для различных целей, например для управления материально-техническими
запасами, управления отношениями с клиентами (CRM - customer relationship management),
биллинга (формирования счетов) и т.п.
Такие базы данных называют операционными или транзакционными, поскольку они
характеризуются огромным количеством небольших транзакций, или операций записи-чтения.
Компьютерные системы, осуществляющие учет операций и собственно доступ к базам
транзакций, принято называть системами оперативной обработки транзакций
(OLTP - On-Line Transactional
Processing) или учетными системами.
Учетные системы настраиваются и оптимизируются для выполнения максимального
количества транзакций за короткие промежутки времени. Как правило, большой гибкости
здесь не требуется, и чаще всего используется фиксированный набор надежных и
безопасных методов сбора данных и отчетности. Показателем эффективности является
количество транзакций, выполняемых за секунду. Обычно отдельные операции очень
малы и не связаны друг с другом. Однако каждую запись данных, характеризующую
взаимодействие с клиентом (звонок в службу поддержки, кассовую операцию, заказ
по каталогу, посещение Web-сайта компании и т.п.) можно использовать для получения
качественно новой информации, а именно для создания отчетов и анализа деятельности
фирмы.
Необходимость использования OLAP в учетных системах
Набор аналитических функций в учетных системах обычно весьма ограничен. Схемы,
используемые в OLTP-приложениях, осложняют создание даже простых отчетов, так
как данные чаще всего распределены по множеству таблиц, и для их агрегирования
необходимо выполнять сложные операции объединения. Как правило, попытки создания
комплексных отчетов требуют больших вычислительных мощностей и приводят к потере
производительности.
Кроме того, в учетных системах хранятся постоянно изменяющиеся данные. По мере
сбора транзакций суммарные значения меняются очень быстро, поэтому два анализа,
проведенные с интервалом в несколько минут, могут дать разные результаты. Чаще
всего, анализ выполнятся по окончании отчетного периода, иначе картина может
оказаться искаженной. Кроме того, необходимые для анализа данные могут храниться
в нескольких системах.
Некоторые виды анализа требуют таких структурных изменений, которые недопустимы
в текущей оперативной среде. Например, нужно выяснить, что произойдет, если
у компании появятся новые продукты. На "живой" базе такое исследование
провести нельзя. Следовательно, эффективный анализ редко удается выполнить непосредственно
в учетной системе.
Этим объясняется интерес к объединению и анализу данных учетной системы с помощью
технологии OLAP (On-Line Analytical Processing - оперативная аналитическая обработка).
Этот метод позволяет аналитикам, менеджерам и руководителям "проникнуть
в суть" накопленных данных за счет быстрого и согласованного доступа к
широкому спектру представлений информации. Исходные данные преобразуются таким
образом, чтобы наглядно отразить структуру деятельности предприятия.
При этом конечному пользователю предоставляется ряд аналитических и навигационных
функций:
- расчеты и вычисления по нескольким измерениям, иерархиям и/или членам;
- анализ трендов;
- выборка подмножеств данных для просмотра на экране;
- углубление в данные (drill down), для просмотра информации на более детализированном
уровне;
- переход к детальным данным, лежащим в основе анализа;
- поворот таблицы отображаемых данных.
Сравнение технологий
Как правило, учетные системы работают с реляционными базами данных. Для OLAP-приложений
же разработана специальная многомерная модель, которая позволяет более эффективно
использовать данные, накопленные в оперативных системах. Технология оперативной
аналитической обработки ориентирована на представление данных в виде массивов.
Под массивом понимается последовательность элементов, например продажи продукта
по рынкам/временным периодам, или доход по времени/региону.
В концепции и терминологии OLAP есть много аналогий с реляционной моделью.
В таблице 1 приведено сравнение реляционных терминов и понятий и соответствующих
эквивалентов в OLAP.
Реляционная технология |
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.
Системная характеристика
|
Учетная система (OLTP)
|
OLAP
|
Взаимодействие с пользователем
|
На уровне транзакции
|
На уровне всей базы данных
|
Данные, используемые при обращении пользователя
к системе
|
Отдельные записи
|
Группы записей
|
Время отклика
|
Секунды
|
От нескольких секунд до нескольких минут
|
Использование аппаратных ресурсов
|
Стабильное
|
Динамическое
|
Характер данных
|
Главным образом первичные (самый низкий уровень детализации)
|
В основном производные (сводные значения)
|
Характер доступа к базе данных
|
Предопределенные или статические пути доступа и отношения
данных
|
Неопределенные или динамические пути доступа и отношения
данных
|
Изменчивость данных
|
Высокая (данные обновляются с каждой транзакцией)
|
Низкая (во время запроса данные обновляются редко)
|
Приоритеты
|
Высокая производительность Высокая доступность
|
Гибкость
Автономность пользователя
|
Совместное использование OLAP и учетной системы, в частности прямая настройка
аналитических функций на OLTP-базу, осложняется несколькими факторами:
- OLAP запросы к базам данных чаще всего бывают сложными и требуют много
времени. Прямой доступ к OLTP-базе существенно снижает общую производительность
оперативной системы.
- Разнообразные учетные системы неоднородны по типу используемых синтаксических
соглашений и концептуальных допущений (единицы измерений, онтологии, наименование,
кодирование и т.п.), поэтому их интеграция затруднена.
- Данные в учетных системах часто "зашумленные", неполные и несогласованные.
- Как правило, нет единой модели данных масштаба предприятия. Кроме того,
при проектировании баз учетной системы могут использоваться разные модели
данных (иерархическая, реляционная, объектно-ориентированная, плоские файлы,
"фирменные" модели).
- В оперативных системах отсутствует метод предоставления данных для конкретных
групп пользователей в нужной для них форме.
- Информация за прошлые периоды теряется при обновлении OLTP- базы (при записи
в нее новых, актуальных данных). Это препятствует выполнению анализа временных
тенденций, который так важен для многих сфер бизнеса.
- В OLTP-базе не хранятся данные в агрегированном, денормализованном, виде,
что необходимо для оперативной аналитической обработки. А преобразование данных
в процессе выполнения запросов оказывается слишком трудоемким.
Кроме всех перечисленных выше концептуальных различий, существуют еще и технологические
проблемы, которые необходимо преодолеть для внедрения аналитических возможностей
в учетные системы. Среди них можно назвать следующие сложности: различие в аппаратных
платформах (компьютерах, сетях и периферийных устройствах), использование разного
программного обеспечения (разнообразных операционных систем, СУБД, языков программирования,
протоколов, связующего ПО и т.п.), а также географическое распределение баз
данных по всей организации и вне ее.
Пути интеграции
Процесс интегрирования OLAP-технологии с учетными системами может осуществляться
по-разному. Все подходы имеют свои преимущества и недостатки. Как уже было сказано
выше, прямая настройка аналитических средств (Direct BI) затруднена. Возможно
также создание дублированных баз данных, витрин и Хранилищ данных. Практически
всегда возникает необходимость в преобразовании операционных данных в аналитические.
Для создания многомерного представления, нужно настроить данные так, чтобы они
соответствовали логической многомерной структуре, далекой от структуры учетной
системы. Например, многие измерения, используемые для анализа, могут вообще
не иметь соответствий в учетных системах и извлекаться из других источников.
Хранилище данных
Хранилище данных - методология и технология, позволяющая решить проблемы, возникающие
при интеграции распределенных и гетерогенных баз учетной системы при внедрении
методов OLAP.
Информация в Хранилище является предметно-ориентированной, интегрированной,
она хранится долговременно, а ее управление осуществляется независимо от исходных
операционных баз данных. В отличие от OLTP-баз, где хранятся детальные данные
в виде отдельных записей, в Хранилище содержится сводная и консолидированная
информация (часто из нескольких операционных источников), в том числе и историческая.
Объем данных в Хранилище намного больше, чем в базе учетной системы (в тысячи
раз). Здесь данные организованы в пре-агрегированной форме в виде многомерных
кубов (гиперкубов), удобных для выполнения аналитических операций. Архитектура
Хранилища представлена набором компонентов, среди них: источники данных, репозиторий
метаданных (здесь описывается, какая информация доступна и где), один или несколько
серверов Хранилища или центральный репозиторий (который управляет исходными
базами и поддерживает многомерные представления данных), а также интерфейсные
средства (например, для создания запросов, отчетов и выполнения анализа).
При обновлении все изменения в исходных данных отражаются в Хранилище. За счет
оперативных средств обратной связи Хранилище данных позволяет интегрировать
процесс поддержки принятия решений с учетными системами и внешними источниками
данных.
Совместное использование различных моделей данных
Средства OLAP часто реализуются в виде набора многопользовательских приложений
с Web-поддержкой, дают быстрый доступ к любому элементу базы вне зависимости
от объема и сложности данных. Часто это достигается за счет использования OLAP-сервера
- мощного многопользовательского инструмента для работы с многомерными структурами
данных. Конструкция сервера и структура данных оптимизируются таким образом,
чтобы можно было выполнять нерегламентированные запросы, а также быстрые, гибкие
вычисления и преобразования исходных данных.
С помощью OLAP сервера может быть организовано физическое хранение обработанной
многомерной информации, что позволяет быстро выдавать ответы на запросы пользователя.
Кроме того, предусматривается преобразование данных из реляционных и других
баз в многомерные структуры в режиме реального времени.
Каким образом реляционные и многомерные средства работают совместно? OLAP продукты
вливаются в существующую корпоративную инфраструктуру путем интегрирования с
реляционными системами. Администраторы баз данных либо загружают реляционные
данные в многомерный кэш, либо настраивают кэш для доступа к SQL данным.
В таблице 3 приведены сравнительные характеристики различных моделей управления
данными:
Характеристики
|
Реляционные СУБД OLTP
|
Реляционные СУБД СППР/Хранилища данных
|
Многомерные СУБД OLAP |
Типовая операция |
Обновление |
Отчет |
Анализ |
Уровень аналитических требований |
Низкий |
Средний |
Высокий |
Экраны |
Неизменяемые |
Определяемые пользователем |
Определяемые пользователем |
Объем данных на транзакцию |
Небольшой |
От малого до большого |
Большой |
Уровень данных |
Детальные |
Детальные и суммарные |
В основном суммарные |
Сроки хранения данных |
Только текущие |
Исторические и текущие |
Исторические, текущие и прогнозируемые |
Структурные элементы |
Записи |
Записи |
Массивы |
В архитектуре, одновременно использующей реляционные и многомерные системы,
данные хранятся на OLAP-сервере или OLAP-структуры используются в качестве кэша
для реляционных данных. Можно использовать комбинацию двух этих подходов, минимизируя
объем данных, перемещаемых из реляционной среды в многомерную и обратно.
Обычно в реляционной системе хранятся более детализированные данные, чем в
многомерной. OLAP позволяет пользователю переходить от сводной информации к
более подробной.
Реляционная и многомерная модели математически очень похожи, поэтому отображение
из одной архитектуры в другую выполняется легко. Например, переменные OLAP можно
получить из столбцов реляционной базы. Измерения многомерного куба связаны напрямую
с ключами, идентифицирующими строки реляционной базы.
Модель определят, что видит пользователь, какие вычислительные функции доступны,
как быстро выполняются вычисления, каковы задачи технического персонала.
Обе модели дают возможности анализа, но использование, написание и поддержка
сложного аналитического кода в многомерной модели требует меньшего времени и
усилий, чем в реляционной.