Технология OLAP. OLAP в финансовом управлении Основными характеристиками olap систем является

Концепция технологии OLAP была сформулирована Эдгаром Коддом в 1993 г.

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

Основные требования, предъявляемые к приложениям для многомерного анализа:

- предоставление пользователю результатов анализа за приемлемое время (не более 5 с.);
- многопользовательский доступ к данным;
- многомерное представление данных;
- возможность обращаться к любой информации независимо от места ее хранения и объема.

Инструменты OLAP-систем обеспечивают возможность сортировки и выборки данных по заданным условиям. Могут задаваться различные качественные и количественные условия.

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

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

В рамках OLAP-технологий на основе того, что многомерное представление данных может быть организовано как средствами реляционных СУБД, так многомерных специализированных средств, различают три типа многомерных OLAP-систем:

- многомерный (Multidimensional) OLAP-MOLAP;
- реляционный (Relation) OLAP-ROLAP;
- смешанный или гибридный (Hibrid) OLAP-HOLAP.

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

Достоинствами MOLAP являются:

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

К ограничениям MOLAP относятся:

- сравнительно небольшие размеры баз данных;
- за счет денормализации и предварительной агрегации многомерные массивы используют в 2,5-100 раз больше памяти, чем исходные данные (расход памяти при увеличении числа измерений растет по экспоненциальному закону);
- отсутствуют стандарты на интерфейс и средства манипулирования данными;
- имеются ограничения при загрузке данных.

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

Достоинствами ROLAP-систем являются:

- возможность оперативного анализа непосредственно содержащихся в хранилище данных, т.к. большинство исходных баз данных - реляционного типа;
- при переменной размерности задачи выигрывают RO- LAP, т.к. не требуется физическая реорганизация базы данных;
- ROLAP-системы могут использовать менее мощные клиентские станции и серверы, причем на серверы ложится основная нагрузка по обработке сложных SQL-запросов;
- уровень защиты информации и разграничения прав доступа в реляционных СУБД несравненно выше чем в многомерных.

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

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

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

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

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

Режим выявления закономерностей основан на интеллектуальной обработке данных. Главной задачей здесь является выявление закономерностей в исследуемых процессах, взаимосвязей и взаимовлияния различных факторов, поиск крупных «непривычных» отклонений, прогноз хода различных существенных процессов. Эта область относится к интеллектуальному анализу (Data mining).

Основная разница между фактами и информацией заключается в том, что данные мы получаем и принимаем к сведению, а информацию можем использовать с пользой. Грубо говоря, информация – это проанализированные и систематизированные данные. Благодаря вовремя полученной информации многим фирмам удается выстоять как в условиях финансового кризиса, так и при жесточайшей конкуренции. Мало собирать факты и иметь все нужные данные. Нужно еще уметь их анализировать. Для облегчения труда людей, призванных принимать важные бизнес-решения, были разработаны различные системы поддержки. Именно с этой целью были разработаны различные комплексные системы, позволяющие анализировать большие массивы разнородных данных и превращающие их в информацию, полезную для бизнес-пользователя. Новая область бизнес-аналитики направлен на повышение управления процессами бизнес-систем, путем использования хранилищ данных и технологий.

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

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

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

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

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

FAST (Быстрый) – это означает, что время поиска и выдачи необходимой информации занимает не более пяти секунд. Самые простые запросы обрабатываются за секунду, и лишь немногие сложные запросы имеют время обработки более двадцати секунд. Чтобы достичь такого результата, используются различные методы, от особых форм хранения данных до обширных предварительных вычислений. Таким образом, вы можете за минуту получить отчет, на подготовку которого ранее требовались дни.

ANALYSIS (Аналитический) говорит, что система может произвести любой анализ, как статистический, так и логический, и затем сохраняет его в доступном виде.

SHARED (Разделяемый) означает, что система обеспечивает требуемую конфиденциальность, вплоть до уровня ячейки

MULTIDIMENSIONAL (Многомерный) – является основной характеристикой OLAP. Система должна полностью поддерживать иерархии и множественные иерархии, так как именно таким образом логичнее всего вести анализ и бизнеса, и деятельности организаций.

INFORMATION (Информационная). Нужная информация должна быть доставлена туда, где она необходима.

При работе организации всегда скапливаются данные, связанные со сферой ее деятельности, которые порою хранятся в совершенно разных местах, и свести их воедино и непросто, и долго. Именно для того, чтобы ускорить получение данных для проверки возникающих бизнес-гипотез, и была разработана технология интерактивной аналитической обработки данных или OLAP. Основное назначение таких OLAP – систем – быстро отвечать на произвольные запросы пользователей. Такая необходимость часто возникает при разработке какого-то важного бизнес-проекта, когда разработчику необходимо возникшую рабочую гипотезу. Чаще всего нужная пользователю информация должна быть представлена в виде некоей зависимости – например, как зависит объем продаж от категории товара, от региона продаж, от времени года и так далее. Благодаря OLAP он имеет возможность сразу же получить необходимые данные в нужной компоновке за выбранный период.

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

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

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

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

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

Различные производители имеют разные механизмы представления данных. Процедура гетерогенного представления подразумевает извлечение, трансформирование и загрузку (ETL). Например, в Microsoft SQL Server 2005 Analysis Services проблема консолидации данных реализована с помощью Data Source Views – видов источников данных, описывающих аналитические модели представления.

Бизнес приложения на основе OLAP технологий, примеры продуктов. Наиболее часто встречаются следующие применения OLAP технологий:

Анализ данных.

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

Примеры продуктов: Microsoft Excel Pivot Tables, Microsoft Analysis Services, SAP BW, Oracle Essbase, Oracle OLAP, Cognos PowerPlay, MicroStrategy, Business Objects.

Финансовое планирование-бюджетирование.

Многомерная модель позволяет одновременно вводить данные и легко анализировать их (например, план факт анализ). Поэтому ряд современных продуктов класса CPM (Corporate Performance Management) используют OLAP%модели. Важная задача – многомерный обратный расчёт (backsolve, breakback, writeback), позволяющий рассчитать требуемые изменения детальных ячеек при изменении агрегированного значения. Это инструмент для анализа «что-если» (what-if), т.е. для проигрывания различных вариантов событий при планировании.

Примеры продуктов: Microsoft PerformancePint, Oracle EPB, Oracle OFA, Oracle Hyperion Planning, SAP SEM, Cognos Enterprise Planning, Geac.

Финансовая консолидация.

Консолидация данных согласно международным стандартам учёта, принимая во внимание доли владения, различные валюты и внутренние обороты – актуальная задача в связи с ужесточающимися требованиями проверяющих органов (SOX, Basel II) и выходом компаний на IPO. OLAP технологии позволяют ускорить расчёт консолидированных отчётов и повысить прозрачность всего процесса.

Примеры продуктов: Oracle FCH, Oracle Hyperion FM, Cognos Controller.

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

Список литературы:

1. Erik Thomsen. OLAP Solutions: Building Multidimensional Information Systems Second Edition. Wiley Computer Publishing John Wiley & Sons, Inc., 2002.

2. OLAP council white paper, http://www.olapcouncil.org/research/whtpaply.htm

3. Gerd Stumme and Bernhard Ganter. Formal Concept Analysis _ Mathematical Foundations.

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

Основные характеристики хранилищ данных.

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

Термин OLAP (On-Line Analytical Processing ) служит для описания модели представления данных и соответственно технологии их обработки в хранилищах данных. В OLAP применяется многомерное представление агрегированных данных для обеспечения быстрого доступа к стратегически важной информации в целях углубленного анализа . Приложения OLAP должны обладать следующими основными свойствами:

многомерное представление данных ;
поддержка сложных расчетов;
правильный учет фактора времени.

Преимущества OLAP :

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

OLAP и OLTP. Характеристики и основные отличия

OLAP	OLTP
Хранилище данных должно включать как внутренние корпоративные данные, так и внешние данные	основным источником информации, поступающей в оперативную БД , является деятельность корпорации , а для проведения анализа данных требуется привлечение внешних источников информации (например, статистических отчетов )
Объем аналитических БД как минимум на порядок больше объема оперативных. для проведения достоверных анализа и прогнозирования в хранилище данных нужно иметь информацию о деятельности корпорации и состоянии рынка на протяжении нескольких лет	Для оперативной обработки требуются данные за несколько последних месяцев
Хранилище данных должно содержать единообразно представленную и согласованную информацию, максимально соответствующую содержанию оперативных БД . Необходима компонента для извлечения и "очистки" информации из разных источников. Во многих крупных корпорациях одновременно существуют несколько оперативных ИС с собственными БД (по историческим причинам ).	Оперативные БД могут содержать семантически эквивалентную информацию, представленную в разных форматах, с разным указанием времени ее поступления, иногда даже противоречивую
Набор запросов к аналитической базе данных предсказать невозможно. хранилища данных существуют, чтобы отвечать на нерегламентированные запросы аналитиков. Можно рассчитывать только на то, что запросы будут поступать не слишком часто и затрагивать большие объемы информации. Размеры аналитической БД стимулируют использование запросов с агрегатами (сумма, минимальное, максимальное, среднее значение и т.д.)	Системы обработки данных создаются в расчете на решение конкретных задач. Информация из БД выбирается часто и небольшими порциями. Обычно набор запросов к оперативной БД известен уже при проектировании
При малой изменчивости аналитических БД (только при загрузке данных ) оказываются разумными упорядоченность массивов, более быстрые методы индексации при массовой выборке, хранение заранее агрегированных данных	Системы обработки данных по своей природе являются сильно изменчивыми, что учитывается в используемых СУБД (нормализованная структура БД , строки хранятся неупорядоченно, B- деревья для индексации , транзакционность )
Информация аналитических БД настолько критична для корпорации , что требуются большая грануляция защиты (индивидуальные права доступа к определенным строкам и/или столбцам таблицы)	Для систем обработки данных обычно хватает защиты информации на уровне таблиц

Правила Кодда для OLAP систем

В 1993 году Кодд опубликовал труд под названием " OLAP для пользователей-аналитиков: каким он должен быть". В нем он изложил основные концепции оперативной аналитической обработки и определил 12 правил, которым должны удовлетворять продукты, предоставляющие возможность выполнения оперативной аналитической обработки.

Концептуальное многомерное представление. OLAP -модель должна быть многомерной в своей основе. Многомерная концептуальная схема или пользовательское представление облегчают моделирование и анализ так же, впрочем, как и вычисления .
Прозрачность. Пользователь способен получить все необходимые данные из OLAP -машины, даже не подозревая, откуда они берутся. Вне зависимости от того, является OLAP -продукт частью средств пользователя или нет, этот факт должен быть незаметен для пользователя. Если OLAP предоставляется клиент -серверными вычислениями, то этот факт также, по возможности, должен быть невидим для пользователя. OLAP должен предоставляться в контексте истинно открытой архитектуры, позволяя пользователю, где бы он ни находился, связываться при помощи аналитического инструмента с сервером. В дополнение к этому прозрачность должна достигаться и при взаимодействии аналитического инструмента с гомогенной и гетерогенной средами БД .
Доступность. OLAP должен предоставлять свою собственную логическую схему для доступа в гетерогенной среде БД и выполнять соответствующие преобразования для предоставления данных пользователю. Более того, необходимо заранее позаботиться о том, где и как, и какие типы физической организации данных действительно будут использоваться. OLAP -система должна выполнять доступ только к действительно требующимся данным, а не применять общий принцип "кухонной воронки", который влечет ненужный ввод.
Постоянная производительность при разработке отчетов . Производительность формирования отчетов не должна существенно падать с ростом количества измерений и размеров базы данных.
Клиент -серверная архитектура. Требуется, чтобы продукт был не только клиент -серверным, но и чтобы серверный компонент был бы достаточно интеллектуальным для того, чтобы различные клиенты могли подключаться с минимумом усилий и программирования.
Общая многомерность. Все измерения должны быть равноправны, каждое измерение должно быть эквивалентно и в структуре, и в операционных возможностях. Правда, допускаются дополнительные операционные возможности для отдельных измерений (видимо, подразумевается время), но такие дополнительные функции должны быть предоставлены любому измерению. Не должно быть так, чтобы базовые структуры данных , вычислительные или отчетные форматы были более свойственны какому-то одному измерению.
Динамическое управление разреженными матрицами . OLAP системы должны автоматически настраивать свою физическую схему в зависимости от типа модели , объемов данных и разреженности базы данных.
Многопользовательская поддержка . OLAP -инструмент должен предоставлять возможности совместного доступа (запроса и дополнения), целостности и безопасности.
Неограниченные перекрестные операции. Все виды операций должны быть дозволены для любых измерений.
Интуитивная манипуляция данными. Манипулирование данными осуществлялось посредством прямых действий над ячейками в режиме просмотра без использования меню и множественных операций.
Гибкие возможности получения отчетов . Измерения должны быть размещены в отчете так, как это нужно пользователю.
Неограниченная

В 1993 году основоположник реляционного подхода к построению баз данных Эдгар Кодд с партнерами (Edgar Codd, математик и стипендиат IBM), опубликовали статью, инициированную компанией "Arbor Software" (сегодня это известнейшая компания "Hyperion Solutions"), озаглавленную "Обеспечение OLAP (оперативной аналитической обработки) для пользователей-аналитиков", в которой сформулированы 12 особенностей технологии OLAP , которые впоследствии были дополнены еще шестью. Эти положения стали основным содержанием новой и очень перспективной технологии.

Основные особенности технологии OLAP (Basic):

многомерное концептуальное представление данных;
интуитивное манипулирование данными;
доступность и детализация данных;
пакетное извлечение данных против интерпретации;
модели анализа OLAP ;
архитектура "клиент-сервер" ( OLAP доступен с рабочего стола);
прозрачность (прозрачный доступ к внешним данным);
многопользовательская поддержка.

Специальные особенности ( Special ):

обработка неформализованных данных;
сохранение результатов OLAP : хранение их отдельно от исходных данных;
исключение отсутствующих значений;
обработка отсутствующих значений.

Особенности представления отчетов ( Report ):

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

Управление измерениями ( Dimension ):

универсальность измерений;
неограниченное число измерений и уровней агрегации ;
неограниченное число операций между размерностями.

Исторически сложилось так, что сегодня термин " OLAP " подразумевает не только многомерный взгляд на данные со стороны конечного пользователя, но и многомерное представление данных в целевой БД. Именно с этим связано появление в качестве самостоятельных терминов "Реляционный OLAP" ( ROLAP ) и "Многомерный OLAP" ( MOLAP ).

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

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

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

Рис. 6.14.

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

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

Рис. 6.15.

У управляющего компанией, например, может зародиться гипотеза о том, что разброс роста активов в различных филиалах компании зависит от соотношения в них специалистов с техническим и экономическим образованием. Чтобы проверить эту гипотезу, менеджер может запросить из хранилища и отобразить на графике интересующее его соотношение для тех филиалов, у которых за текущий квартал рост активов снизился по сравнению с прошлым годом более чем на 10%, и для тех, у которых повысился более чем на 25%. Он должен иметь возможность использовать простой выбор из предлагаемого меню. Если полученные результаты ощутимо распадутся на две соответствующие группы, то это должно стать стимулом для дальнейшей проверки выдвинутой гипотезы.

В настоящее время быстрое развитие получило направление, называемое динамическим моделированием (Dynamic Simulation ), в полной мере реализующее указанный выше принцип FASMI.

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

Рис. 6.16.

В таблице 6.3 приведены сравнительные характеристики статического и динамического анализа.

Таблица 6.3.

Характеристика	Статический анализ	Динамический анализ
Типы вопросов	Кто? Что? Сколько? Как? Когда? Где?	Почему так? Что было бы, если…? Что будет, если…?
Время отклика	Не регламентируется	Секунды
Типичные операции работы с данными	Регламентированный отчет, диаграмма, таблица, рисунок	Последовательность интерактивных отчетов, диаграмм, экранных форм . Динамическое изменение уровней агрегации и срезов данных
Уровень аналитических требований	Средний	Высокий
Тип экранных форм	В основном, определенный заранее, регламентированный	Определяемый пользователем, есть возможности настройки
Уровень агрегации данных	Детализированные и суммарные	Определяется пользователем
"Возраст" данных	Исторические и текущие	Исторические, текущие и прогнозируемые
Типы запросов	В основном, предсказуемые	Непредсказуемые - от случаю к случаю
Назначение	Регламентированная аналитическая обработка	Многопроходный анализ, моделирование и построение прогнозов

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

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

Ключевые вопросы "Сколько продано?", "На какую сумму продано?" расширяются по мере усложнения бизнеса и накопления исторических данных до некоторого множества факторов, или разрезов: "..в Санкт-Петербурге, в Москве, на Урале, в Сибири…", "..в прошлом квартале, по сравнению с нынешним", "..от поставщика А по сравнению с поставщиком Б…" и т. д.

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

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

Время . Как правило, это несколько периодов: Год, Квартал, Месяц, Декада, Неделя, День. Многие OLAP -инструменты автоматически вычисляют старшие периоды из даты и вычисляют итоги по ним.

Категория товара . Категорий может быть несколько, они отличаются для каждого вида бизнеса: Сорт, Модель, Вид упаковки и пр. Если продается только один товар или ассортимент очень невелик, то категория не нужна.

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

Регион . В зависимости от глобальности бизнеса можно иметь в виду Континент, Группа стран, Страна, Территория, Город, Район, Улица, Часть улицы. Конечно, если есть только одна торговая точка, то это измерение отсутствует.

Продавец . Это измерение тоже зависит от структуры и масштабов бизнеса. Здесь может быть: Филиал, Магазин, Дилер, Менеджер по продажам. В некоторых случаях измерение отсутствует, например, когда продавец не влияет на объемы сбыта, магазин только один и так далее.

Покупатель . В некоторых случаях, например, в розничной торговле , покупатель обезличен и измерение отсутствует, в других случаях информация о покупателе есть, и она важна для продаж. Это измерение может содержать название фирмы-покупателя или множество группировок и характеристик клиентов: Отрасль, Группа предприятий, Владелец и так далее.. Анализ структуры продаж для выявления важнейших составляющих в интересующем разрезе. Для этого удобно использовать, например, диаграмму типа "Пирог" в сложных случаях, когда исследуется сразу 3 измерения - "Столбцы". Например, в магазине "Компьютерная техника" за квартал продажи компьютеров составили $100000, фототехники -$10000, расходных материалов - $4500. Вывод: оборот магазина зависит в большой степени от продажи компьютеров (на самом деле, быть может, расходные материалы необходимы для продажи компьютеров, но это уже анализ внутренних зависимостей).

Анализ динамики ( регрессионный анализ - выявление трендов ). Выявление тенденций, сезонных колебаний. Наглядно динамику отображает график типа "Линия". Например, объемы продаж продуктов компании Intel в течение года падали, а объемы продаж Microsoft росли. Возможно, улучшилось благосостояние среднего покупателя, или изменился имидж магазина, а с ним и состав покупателей. Требуется провести корректировку ассортимента. Другой пример: в течение 3 лет зимой снижается объем продаж видеокамер.

Анализ зависимостей (корреляционный анализ). Сравнение объемов продаж разных товаров во времени для выявления необходимого ассортимента - "корзины". Для этого также удобно использовать график типа "Линия". Например, при удалении из ассортимента принтеров в течение первых двух месяцев обнаружилось падение продаж картриджей с порошком.

ведение

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

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

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

Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing).

OLAP – это ключевой компонент организации хранилищ данных.

Концепция OLAP была описана в 1993 году Эдгаром Коддом, известным исследователем баз данных и автором реляционной модели данных (см. E.F. Codd, S.B. Codd, and C.T.Salley, Providing OLAP (on-line analytical processing) to user-analysts: An IT mandate. Technical report, 1993).

В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information – быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям для многомерного анализа:

· предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа;

· возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде;

· многопользовательский доступ к данным с поддержкой соответствующих механизмов блокировок и средств авторизованного доступа;

· многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это – ключевое требование OLAP);

· возможность обращаться к любой нужной информации независимо от ее объема и места хранения.

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

2. Что такое OLAP

OLAP – аббревиатура от английского On-Line Analytical Processing – это название не конкретного продукта, а целой технологии. По-русски удобнее всего называть OLAP оперативной аналитической обработкой. Хотя в некоторых изданиях аналитическую обработку называют и онлайновой, и интерактивной, однако прилагательное “оперативная” как нельзя более точно отражает смысл технологии OLAP.

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

Рассмотрим, как обычно происходит процесс разработки решений.

Исторически сложилось так, что решения по автоматизации оперативной деятельности наиболее развиты. Речь идет о системах транзакционной обработки данных (OLTP), проще называемых оперативными системами. Эти системы обеспечивают регистрацию некоторых фактов, их непродолжительное хранение и сохранение в архивах. Основу таких систем обеспечивают системы управления реляционными базами данных (РСУБД). Традиционным подходом являются попытки использовать уже построенные оперативные системы для поддержки принятия решений. Обычно пытаются строить развитую систему запросов к оперативной системе и использовать полученные после интерпретации отчеты непосредственно для поддержки решений. Отчеты могут строиться на заказной базе, т.е. руководитель запрашивает отчет, и на регулярной, когда отчеты строятся по достижении некоторых событий или времени. Например, традиционный процесс поддержки принятия решений может выглядеть таким образом: руководитель идет к специалисту информационного отдела и делится с ним своим вопросом. Затем специалист информационного отдела строит запрос к оперативной системе, получает электронный отчет, интерпретирует его и затем доводит его до сведения руководящего персонала. Конечно, такая схема обеспечивает в какой-то мере поддержку принятия решений, но она имеет крайне низкую эффективность и огромное число недостатков. Ничтожное количество данных используется для поддержки критически важных решений. Есть и другие проблемы. Подобный процесс очень медленен, так как длителен сам процесс написания запросов и интерпретации электронного отчета. Он занимает многие дни, в то время, когда руководителю может быть необходимо принять решение прямо сейчас, немедленно. Если учесть, что руководителя после получения отчета может заинтересовать другой вопрос (скажем, уточняющий или требующий рассмотрения данных в другом разрезе), то этот медленный цикл должен повториться, а поскольку процесс анализа данных оперативных систем будет происходить итерационно, то времени тратится ещё больше. Другая проблема – проблема различных областей деятельности специалиста по информационным технологиям и руководителя, которые могут мыслить в разных категориях и, как следствие, – не понимать друг друга. Тогда потребуются дополнительные уточняющие итерации, а это снова время, которого всегда не хватает. Ещё одной важной проблемой является сложность отчетов для понимания. У руководителя нет времени выбирать интересующие цифры из отчёта, тем более что их может оказаться слишком много (вспомним огромные многостраничные отчеты, в которых реально используются несколько страниц, а остальные – на всякий случай). Отметим также, что работа по интерпретации ложится чаще всего на специалистов информационных отделов. То есть грамотный специалист отвлекается на рутинную и малоэффективную работу по рисованию диаграмм и т.п., что, естественно, не может благоприятно сказываться на его квалификации. Кроме того, не является секретом присутствие в цепочке интерпретации благожелателей, заинтересованных в преднамеренном искажении поступающей информации.

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

В действительности проблемы эти не являются следствием низкого качества оперативной системы или ее неудачной постройки. Корни проблем кроются в фундаментальном отличии той оперативной деятельности, которая автоматизируется оперативной системой, и деятельностью по разработке и принятию решений. Отличие это состоит в том, что данные оперативных систем являются просто записями о некоторых имевших место событиях, фактах, но никак не информацией в общем смысле этого слова. Информация – то, что снижает неопределенность в какой-либо области. И очень неплохо, если бы информация снижала неопределенность в области подготовки решений. По поводу непригодности для этой цели оперативных систем, построенных на РСУБД, в свое время высказался небезызвестный E.F. Codd, человек, стоявший в 70-е годы у истоков технологий систем управления реляционными БД: “Хотя системы управления реляционными БД доступны для пользователей, они никогда не считались средством, дающим мощные функции по синтезу, анализу и консолидации (функций, называемых многомерным анализом данных)”. Речь идет именно о синтезе информации, о том, чтобы превращать данные оперативных систем в информацию и даже в качественные оценки. OLAP позволяет выполнять такое превращение.

В основе OLAP лежит идея многомерной модели данных. Человеческое мышление многомерно по определению. Когда человек задает вопросы, он налагает ограничения, тем самым формулируя вопросы во многих измерениях, поэтому процесс анализа в многомерной модели весьма приближен к реальности человеческого мышления. По измерениям в многомерной модели откладывают факторы, влияющие на деятельность предприятия (например: время, продукты, отделения компании, географию и т.п.). Таким образом получают гиперкуб (конечно, название не очень удачно, поскольку под кубом обычно понимают фигуру с равными ребрами, что, в данном случае, далеко не так), который затем наполняется показателями деятельности предприятия (цены, продажи, план, прибыли, убытки и т.п.). Наполнение это может вестись как реальными данными оперативных систем, так и прогнозируемыми на основе исторических данных. Измерения гиперкуба могут носить сложный характер, быть иерархическими, между ними могут быть установлены отношения. В процессе анализа пользователь может менять точку зрения на данные (так называемая операция смены логического взгляда), тем самым просматривая данные в различных разрезах и разрешая конкретные задачи. Над кубами могут выполняться различные операции, включая прогнозирование и условное планирование (анализ типа “что, если”). Причем операции выполняются разом над кубами, т.е. произведение, например, даст в результате произведение-гиперкуб, каждая ячейка которого является произведением ячеек соответствующих гиперкубов-множителей. Естественно, возможно выполнение операций над гиперкубами, имеющими различное число измерений.

3. История создания OLAP-технологии

Идея обработки данных на многомерных массивах не является новой. Фактически она восходит к 1962 году, когда Ken Iverson опубликовал свою книгу “Язык программирования” (“A Programming Language”, APL). Первая практическая реализация APL состоялась в поздних шестидесятых компанией IBM. APL – это очень изящный, математически определённый язык с многомерными переменными и обрабатываемыми операциями. Он подразумевался как оригинальное мощное средство по работе с многомерными преобразованиями по сравнению с другими практическими языками программирования.

Однако идея долгое время не получала массового применения, поскольку не пришло еще время графических интерфейсов, печатающих устройств высокого качества, а отображение греческих символов требовало специальных экранов, клавиатур и печатающих устройств. Позднее английские слова иногда использовали для замены греческих операторов, однако борцы за чистоту APL пресекли попытки популяризации их любимого языка. APL также поглощал машинные ресурсы. В те дни его использование требовало больших затрат. Программы очень медленно выполнялись и, кроме того, сам их запуск обходился очень дорого. Требовалось много памяти, по тем временам просто шокирующие объемы (около 6 МБ).

Однако досада от этих первоначальных ошибок не убила идею. Она использовалась во многих деловых приложениях 70-х, 80-х годов. Многие из этих приложений имели черты современных систем аналитической обработки. Так, IBM разработала операционную систему для APL, названную VSPC, и некоторые люди считали ее идеальной средой для персонального использования, пока электронные таблицы не стали повсеместно распространены.

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

В 80-х годах APL стал доступен на персональных машинах, но не нашел рыночного применения. Альтернативой было программирование многомерных приложений с использованием массивов в других языках. Это было очень тяжелой задачей даже для профессиональных программистов, что вынуждало ждать следующего поколения многомерных программных продуктов.

В 1972 году несколько прикладных многомерных программных продуктов, ранее использовавшихся в учебных целях, нашли коммерческое применение: Express. Он в полностью переписанном виде остаётся и сейчас, однако оригинальные концепции 70-х годов перестали быть актуальными. Сегодня, в 90-х, Express является одной из наиболее популярных OLAP-технологий, и Oracle (r) будет продвигать его и дополнять новыми возможностями.

Больше многомерных продуктов появилось в 80-х годах. В начале десятилетия – продукт с названием Stratagem, позднее называемый Acumate (сегодня владельцем является Kenan Technologies), который еще продвигался до начала 90-х, но сегодня, в отличие от Express, практически не используется.

Comshare System W был многомерным продуктом другого стиля. Представленный в 1981 году, он был первым, где предполагалась большая ориентированность на конечного пользователя и на разработку финансовых приложений. Он привнёс много концепций, которые, правда, не были хорошо адаптированы, такие, как полностью непроцедурные правила, полноэкранный просмотр и редактирование многомерных данных, автоматическое перевычисление и пакетная интеграция с реляционными данными. Однако Comshare System W был достаточно тяжел для аппаратного обеспечения того времени по сравнению с другими продуктами и меньше использовался в будущем, продавался всё меньше, и в продукте не делалось никаких улучшений. Хотя он и сегодня доступен на UNIX, он не является клиент-серверным, что не способствует повышению его предложения на рынке аналитических продуктов. В поздних 80-х Comshare выпустил продукт для DOS, а позднее для Windows. Эти продукты назывались Commander Prism и использовали те же концепции, что и System W.

Другой творческий продукт поздних 80-х назывался Metaphor. Он предназначался для профессиональных маркетологов. Он также предложил много новых концепций, которые только сегодня начинают широко использоваться: клиент-серверные вычисления, использование многомерной модели на реляционных данных, объектно-ориентированная разработка приложений. Однако стандартное аппаратное обеспечение персональных машин тех дней не было способно работать с Metaphor и поставщики вынуждены были разрабатывать собственные стандарты на персональные машины и сети. Постепенно Metaphor стал работать удачно и на серийных персональных машинах, однако продукт был выполнен исключительно для OS/2 и имел свой собственный графический интерфейс пользователя.

Затем Metaphor заключил маркетинговый альянс с IBM, которой впоследствии и был поглощён. В середине 1994 года IBM решила интегрировать технологию Metaphor (переименованную в DIS) со своими будущими технологиями и тем самым прекратить финансирование отдельного направления, однако заказчики выразили своё неудовольствие и потребовали продолжить поддержку продукта. Поддержка была продолжена для оставшихся заказчиков, а IBM перевыпустила продукт под новым названием DIS, что, однако, не сделало его популярным. Но творческие, новаторские концепции Metaphor не были забыты и видны сегодня во многих продуктах.

В середине 80-х родился термин EIS (Executive Information System – информационная система руководителя). Первым продуктом, ясно продемонстрировавшим это направление, был Pilot’s Command Center. Это был продукт, который позволял выполнять совместные вычисления, то, что мы называем сегодня клиент-серверными вычислениями. Поскольку мощность персональных компьютеров 80-х годов была ограничена, продукт был очень “сервероцентричен”, однако этот принцип и сегодня очень популярен. Pilot недолго продавал Command Center, но предложил много концепций, которые можно узнать в сегодняшних OLAP-продуктах, включая автоматическую поддержку временных промежутков, многомерные клиент-серверные вычисления и упрощённое управление процессом анализа (мышь, чувствительные экраны и т.п.). Некоторые из этих концепций были повторно применены позднее в Pilot Analysis Server.

В конце 80-х электронные таблицы были доминирующими на рынке инструментов, предоставляющих анализ конечным пользователям. Первая многомерная электронная таблица была представлена продуктом Compete. Он продвигался на рынок как очень дорогой продукт для специалистов, но поставщики не обеспечили возможность захвата рынка этим продуктом, и компания Computer Associates приобрела права на него вместе с другими продуктами, включая Supercalc и 20/20. Основным эффектом от приобретения CA Compete было резкое снижение цены на него и снятие защиты от копирования, что, естественно, способствовало его распространению. Однако он не был удачным. Compete положен в основу Supercalc 5, но многомерный аспект его не продвигается. Старый Compete всё ещё иногда используют в связи с тем, что в свое время в него были вложены немалые средства.

Компания Lotus была следующей, кто попытался войти на рынок многомерных электронных таблиц с продуктом Improv, который запускается на NeXT машине. Это гарантировало, как минимум, что продажи 1-2-3 не снизятся, но когда тот со временем был выпущен под Windows, Excel уже имел большую долю рынка, что не позволило Lotus внести какие-либо изменения в распределение рынка. Lotus, подобно CA с Compete, переместила Improv в нижнюю часть рынка, однако и это не стало условием удачного продвижения на рынке, и новые разработки в этой области не получили продолжения. Оказалось, что пользователи персональных компьютеров предпочли электронные таблицы 1-2-3 и не интересуются новыми многомерными возможностями, если они не полностью совместимы с их старыми таблицами. Так же концепции маленьких, настольных электронных таблиц, предлагаемых как персональные приложения, в действительности не оказались удобными и не прижились в настоящем деловом мире. Microsoft (r) пошла по этому пути, добавив PivotTables (в русской редакции это называется “сводные таблицы”) к Excel. Хотя немногие пользователи Excel получили выгоду от использования этой возможности, это, вероятно, единственный факт широкого использования в мире возможностей многомерного анализа просто потому, что в мире очень много пользователей Excel.

4. OLAP, ROLAP, MOLAP…

Общеизвестно, что когда Кодд опубликовал в 1985 году свои правила построения реляционных СУБД, они вызвали бурную реакцию и впоследствии сильно отразились вообще на индустрии СУБД. Однако мало кто знает, что в 1993 году Кодд опубликовал труд под названием “OLAP для пользователей-аналитиков: каким он должен быть”. В нем он изложил основные концепции оперативной аналитической обработки и определил 12 правил, которым должны удовлетворять продукты, предоставляющие возможность выполнения оперативной аналитической обработки.

Вот эти правила (текст оригинала сохранен по возможности):

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

2. Прозрачность. Вне зависимости от того, является OLAP-продукт частью средств пользователя или нет, этот факт должен быть прозрачен для пользователя. Если OLAP предоставляется клиент-серверными вычислениями, то этот факт также, по возможности, должен быть незаметен для пользователя. OLAP должен предоставляться в контексте истинно открытой архитектуры, позволяя пользователю, где бы он ни находился, связываться при помощи аналитического инструмента с сервером. В дополнение прозрачность должна достигаться и при взаимодействии аналитического инструмента с гомогенной и гетерогенной средами БД.

3. Доступность. Пользователь-аналитик OLAP должен иметь возможность выполнять анализ, базирующийся на общей концептуальной схеме, содержащей данные всего предприятия в реляционной БД, также как и данные из старых наследуемых БД, на общих методах доступа и на общей аналитической модели. Это значит, что OLAP должен предоставлять свою собственную логическую схему для доступа в гетерогенной среде БД и выполнять соответствующие преобразования для предоставления данных пользователю. Более того, необходимо заранее позаботиться о том, где и как, и какие типы физической организации данных действительно будут использоваться. OLAP-система должна выполнять доступ только к действительно требующимся данным, а не применять общий принцип “кухонной воронки”, который влечет ненужный ввод.

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

5. Клиент-серверная архитектура. Большинство данных, которые сегодня требуется подвергать оперативной аналитической обработке, содержатся на мэйнфреймах с доступом через ПК. Это означает, следовательно, что OLAP-продукты должны быть способны работать в среде клиент-сервер. С этой точки зрения является необходимым, чтобы серверный компонент аналитического инструмента был существенно “интеллектуальным”, чтобы различные клиенты могли присоединяться к серверу с минимальными затруднениями и интеграционным программированием. “Интеллектуальный” сервер должен быть способен выполнять отображение и консолидацию между несоответствующими логическими и физическими схемами баз данных. Это обеспечит прозрачность и построение общей концептуальной, логической и физической схемы.

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

7. Динамическое управление разреженными матрицами. Физическая схема OLAP-инструмента должна полностью адаптироваться к специфической аналитической модели для оптимального управления разреженными матрицами. Для любой взятой разреженной матрицы существует одна и только одна оптимальная физическая схема. Эта схема предоставляет максимальную эффективность по памяти и операбельность матрицы, если, конечно, весь набор данных не помещается в памяти. Базовые физические данные OLAP-инструмента должны конфигурироваться к любому подмножеству измерений, в любом порядке, для практических операций с большими аналитическими моделями. Физические методы доступа также должны динамически меняться и содержать различные типы механизмов, таких как: непосредственные вычисления, B-деревья и производные, хеширование, возможность комбинировать эти механизмы при необходимости. Разреженность (измеряется в процентном отношении пустых ячеек ко всем возможным) – это одна из характеристик распространения данных. Невозможность регулировать разреженность может сделать эффективность операций недостижимой. Если OLAP-инструмент не может контролировать и регулировать распространение значений анализируемых данных, модель, претендующая на практичность, базирующаяся на многих путях консолидации и измерениях, в действительности может оказаться ненужной и безнадежной.

8. Многопользовательская поддержка. Часто несколько пользователей-аналитиков испытывают потребность работать совместно с одной аналитической моделью или создавать различные модели из единых данных. Следовательно, OLAP-инструмент должен предоставлять возможности совместного доступа (запроса и дополнения), целостности и безопасности.

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

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

11. Гибкие возможности получения отчетов. Анализ и представление данных являются простыми, когда строки, столбцы и ячейки данных, которые будут визуально сравниваться между собой, будут находиться вблизи друг друга или по некоторой логической функции, имеющей место на предприятии. Средства формирования отчетов должны представлять синтезируемые данные или информацию, следующую из модели данных в ее любой возможной ориентации. Это означает, что строки, столбцы или страницы должны показывать одновременно от 0 до N измерений, где N – число измерений всей аналитической модели. В дополнение каждое измерение содержимого, показанное в одной записи, колонке или странице, должно также быть способно показать любое подмножество элементов (значений), содержащихся в измерении, в любом порядке.

12. Неограниченная размерность и число уровней агрегации. Исследование о возможном числе необходимых измерений, требующихся в аналитической модели, показало, что одновременно может использоваться до 19 измерений. Отсюда вытекает настоятельная рекомендация, чтобы аналитический инструмент был способен предоставить хотя бы 15 измерений одновременно и предпочтительно 20. Более того, каждое из общих измерений не должно быть ограничено по числу определяемых пользователем-аналитиком уровней агрегации и путей консолидации.

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

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

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

MOLAP. Собственно многомерная (multidimensional) OLAP. В основе продукта лежит нереляционная структура данных, обеспечивающая многомерное хранение, обработку и представление данных. Соответственно и базы данных называют многомерными. Продукты, относящиеся к этому классу, обычно имеют сервер многомерных баз данных. Данные в процессе анализа выбираются исключительно из многомерной структуры. Подобная структура является высокопроизводительной.

ROLAP. Реляционная (relational) OLAP. Как и подразумевается названием, многомерная структура в таких инструментах реализуется реляционными таблицами. А данные в процессе анализа, соответственно, выбираются из реляционной базы данных аналитическим инструментом.

Недостатки и преимущества каждого подхода, в общем-то, очевидны. Многомерная OLAP обеспечивает лучшую производительность, но структуры нельзя использовать для обработки больших объемов данных, поскольку большая размерность потребует больших аппаратных ресурсов, а вместе с тем разреженность гиперкубов может быть очень высокой и, следовательно, использование аппаратных мощностей не будет оправданным. Наоборот, реляционная OLAP обеспечивает обработку на больших массивах хранимых данных, так как возможно обеспечение более экономичного хранения, но, вместе с тем, значительно проигрывает в скорости работы многомерной. Подобные рассуждения привели к выделению нового класса аналитических инструментов – HOLAP. Это гибридная (hybrid) оперативная аналитическая обработка. Инструменты этого класса позволяют сочетать оба подхода – реляционного и многомерного. Доступ может вестись как к данным многомерных баз, так и к данным реляционных.

Есть еще один достаточно экзотический вид оперативной аналитической обработки – DOLAP. Это “настольный” (desktop) OLAP. Речь идет о такой аналитической обработке, где гиперкубы малы, размерность их небольшая, потребности скромны, и для такой аналитической обработки достаточно персональной машины на рабочем столе.

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

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