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