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

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

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

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

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

Благодаря технологии обработки и анализа данных 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.

Введение

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

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

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

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

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

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

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

Целью курсовой работы является рассмотрение технологии OLAP.

многомерный аналитический обработка данный

Основная часть

1 Основные сведения об OLAP

В основе концепции OLAP лежит принцип многомерного представления данных. В 1993 году термин OLAPввел Эдгар Кодд. Рассмотрев недостатки реляционной модели, он в первую очередь указал на невозможность «объединять, просматривать и анализировать данные с точки зрения множественности измерений, то есть самым понятным для корпоративных аналитиков способом», и определил общие требования к системам OLAP, расширяющим функциональность реляционных СУБД и включающим многомерный анализ как одну из своих характеристик .

В большом числе публикаций аббревиатурой OLAP обозначается не только многомерный взгляд на данные, но и хранение самих данных в многомерной БД. Вообще говоря, это неверно, поскольку сам Кодд отмечает, что "Реляционные БД были, есть и будут наиболее подходящей технологией для хранения корпоративных данных. Необходимость существует не в новой технологии БД, а, скорее, в средствах анализа, дополняющих функции существующих СУБД и достаточно гибких, чтобы предусмотреть и автоматизировать разные виды интеллектуального анализа, присущие OLAP". Такая путаница приводит к противопоставлениям наподобие "OLAP или ROLAP", что не совсем корректно, поскольку ROLAP (реляционный OLAP) на концептуальном уровне поддерживает всю определенную термином OLAP функциональность. Более предпочтительным кажется использование для OLAP на основе многомерных СУБД специального термина MOLAP. По Кодду, многомерное концептуальное представление (multi-dimensional conceptual view) представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям определяется как многомерный анализ. Каждое измерение включает направления консолидации данных, состоящие из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению. Так, измерение.

Исполнитель может определяться направлением консолидации, состоящим из уровней обобщения "предприятие - подразделение - отдел - служащий". Измерение Время может даже включать два направления консолидации - "год - квартал - месяц - день" и "неделя - день", поскольку счет времени по месяцам и по неделям несовместим. В этом случае становится возможным произвольный выбор желаемого уровня детализации информации по каждому из измерений. Операция спуска (drilling down) соответствует движению от высших ступеней консолидации к низшим; напротив, операция подъема (rolling up) означает движение от низших уровней к высшим.

Кодд определил 12 правил, которым должен удовлетворять программный продукт класса OLAP .

1.2 Требования к средствам оперативной аналитической обработки

Многомерное концептуальное представление данных (Multi Dimensional Conceptual View). Концептуальное представление модели данных в продукте OLAP должно быть многомерным по своей природе, то есть позволять аналитикам выполнять интуитивные операции "анализа вдоль и поперек" ("slice and dice"), вращения (rotate) и размещения (pivot) направлений консолидации. Прозрачность (Transparency). Пользователь не должен знать о том, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда берутся.

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

Устойчиваяпроизводительность(Consistent Reporting Performance). С увеличением числа измерений и размеров базы данных аналитики не должны столкнуться с каким бы то ни было уменьшением производительности. Устойчивая производительность необходима для поддержания простоты использования и свободы от усложнений, которые требуются для доведения OLAP до конечного пользователя.

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

Равноправие измерений (Generic Dimensionality). Все измерения данных должны быть равноправны. Дополнительные характеристики могут быть предоставлены отдельным измерениям, но поскольку все они симметричны, данная дополнительная функциональность может быть предоставлена любому измерению. Базовая структура данных, формулы и форматы отчетов не должны опираться на какое-то одно измерение.

Динамическая обработка разреженных матриц (Dynamic Sparse Matrix Handling). Инструмент OLAP должен обеспечивать оптимальную обработку разреженных матриц. Скорость доступа должна сохраняться вне зависимости от расположения ячеек данных и быть постоянной величиной для моделей, имеющих разное число измерений и различную разреженность данных.

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

Неограниченная поддержка кроссмерных операций (Unrestricted Cross-dimensional Operations). Вычисления и манипуляция данными по любому числу измерений не должны запрещать или ограничивать любые отношения между ячейками данных. Преобразования, требующие произвольного определения, должны задаваться на функционально полном формульном языке.

Интуитивное манипулирование данными (Intuitive Data Manipulation). Переориентация направлений консолидации, детализация данных в колонках и строках, агрегация и другие манипуляции, свойственные структуре иерархии направлений консолидации, должны выполняться в максимально удобном, естественном и комфортном пользовательском интерфейсе .

Гибкий механизм генерации отчетов (Flexible Reporting). Должны поддерживаться различные способы визуализации данных, то есть отчеты должны представляться в любой возможной ориентации.

Неограниченное количество измерений и уровней агрегации (Unlimited Dimensions and Aggregation Levels). Настоятельно рекомендуется допущение в каждом серьезном OLAP инструменте как минимум пятнадцати, а лучше двадцати, измерений в аналитической модели.

2 Компоненты OLAP-систем

2.1 Сервер. Клиент. Интернет

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

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

Сервер. Прикладной частью OLAP-системы является OLAP-сервер. Эта составляющая выполняет всю работу (в зависимости от модели системы), и хранит в себе всю информацию, к которой обеспечивается активный доступ. Архитектурой сервера управляют различные концепции. В частности, основной функциональной характеристикой OLAP-продукта является использование для хранения данных многомерной (ММБД, MDDB) либо реляционной (РДБ, RDB) базы данных. Агрегированные/Предварительно агрегированные данные

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

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

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

Несмотря на то, что сервер - это как бы "хребет" OLAP-решения, клиент не менее важен. Сервер может обеспечить прочный фундамент для облегчения манипуляций с данными, но если клиент сложен или малофункционален, пользователь не сможет воспользоваться всеми преимуществами мощного сервера. Клиент настолько важен, что множество поставщиков сосредотачивают свои усилия исключительно на разработке клиента. Все, что включается в состав этих приложений, представляет собой стандартный взгляд на интерфейс, заранее определенные функции и структуру, а также быстрые решения для более или менее стандартных ситуаций. Например, популярны финансовые пакеты. Заранее созданные финансовые приложения позволят специалистам использовать привычные финансовые инструменты без необходимости проектировать структуру базы данных или общепринятые формы и отчеты. Инструмент запросов/Генератор отчетов. Инструмент запросов или генератор отчетов предлагает простой доступ к OLAP-данным. Они имеют простой в использовании графический интерфейс и позволяют пользователям создавать отчеты перемещением объектов в отчет методом "drag and drop". Тогда как традиционный генератор отчетов предоставляет пользователю возможность быстро выпускать форматированные отчеты, генераторы отчетов, поддерживающие OLAP, формируют актуальные отчеты. Конечный продукт представляет собой отчет, имеющий возможности углубления в данные до уровня подробностей, вращения (пивотинг) отчетов, поддержки иерархий и др.. Add-Ins (дополнения) электронных таблиц.

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

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

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

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

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

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

2.2 OLAP - клиенты

OLAP-клиенты со встроенной OLAP-машиной устанавливаются на ПК пользователей. Они не требуют сервера для вычислений, и им присуще нулевое администрирование. Такие клиенты позволяют пользователю настроиться на существующие у него базы данных; как правило, при этом создается словарь, скрывающий физическую структуру данных за ее предметным описанием, понятным специалисту. После этого OLAP-клиент выполняет произвольные запросы и результаты их отображает в OLAP-таблице. В этой таблице, в свою очередь, пользователь может манипулировать данными и получать на экране или на бумаге сотни различных отчетов. OLAP-клиенты, предназначенные для работы с РСУБД, позволяют анализировать уже имеющиеся в корпорации данные, например хранящиеся в БД OLTP . Однако вторым их назначением может быть быстрое и дешевое создание хранилищ или витрин данных - в этом случае программистам организации нужно лишь создать совокупности таблиц типа "звезда" в реляционных БД и процедуры загрузки данных. Наиболее трудоемкая часть работы - написание интерфейсов с многочисленными вариантами пользовательских запросов и отчетов - реализуется в OLAP-клиенте буквально за несколько часов. Конечному же пользователю для освоения такой программы требуется порядка 30 минут. OLAP-клиенты поставляются самими разработчиками баз данных, как многомерных, так и реляционных. Это SAS Corporate Reporter, являющийся почти эталонным по удобству и красоте продуктом, Oracle Discoverer, комплекс программ MS Pivot Services и Pivot Table и др. Многие программы, предназначенные для работы с MS OLAP Services, поставляются в рамках кампании "OLAP в массы", которую проводит корпорация Microsoft. Как правило, они являются улучшенными вариантами Pivot Table и рассчитаны на использование в MS Office или Web-браузере. Это продукты фирм Matryx, Knosys и т. д., благодаря простоте, дешевизне и эффективности приобретшие огромную популярность на Западе.

3 Классификация продуктов OLAP

3.1 Многомерный OLAP

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

1. Самые первые системы оперативной аналитической обработки (например, Essbase компании Arbor Software, Oracle Express Server компании Oracle) относились к классу MOLAP, то есть могли работать только со своими собственными многомерными базами данных. Они основываются на патентованных технологиях для многомерных СУБД и являются наиболее дорогими. Эти системы обеспечивают полный цикл OLAP-обработки. Они либо включают в себя, помимо серверного компонента, собственный интегрированный клиентский интерфейс, либо используют для связи с пользователем внешние программы работы с электронными таблицами. Для обслуживания таких систем требуется специальный штат сотрудников, занимающихся установкой, сопровождением системы, формированием представлений данных для конечных пользователей.

2. Системы оперативной аналитической обработки реляционных данных (ROLAP) позволяют представлять данные, хранимые в реляционной базе, в многомерной форме, обеспечивая преобразование информации в многомерную модель через промежуточный слой метаданных. К этому классу относятся DSS Suite компании MicroStrategy, MetaCube компании Informix, DecisionSuite компании Information Advantage и другие. Программный комплекс ИнфоВизор, разработанный в России, в Ивановском государственном энергетическом университете, также является системой этого класса. ROLAP-системы хорошо приспособлены для работы с крупными хранилищами. Подобно системам MOLAP, они требуют значительных затрат на обслуживание специалистами по информационным технологиям и предусматривают многопользовательский режим работы.

3. Наконец, гибридные системы (Hybrid OLAP, HOLAP) разработаны с целью совмещения достоинств и минимизации недостатков, присущих предыдущим классам. К этому классу относится Media/MR компании Speedware. По утверждению разработчиков, он объединяет аналитическую гибкость и скорость ответа MOLAP с постоянным доступом к реальным данным, свойственным ROLAP.

Помимо перечисленных средств существует еще один класс - инструменты генерации запросов и отчетов для настольных ПК, дополненные функциями OLAP или интегрированные с внешними средствами, выполняющими такие функции. Эти хорошо развитые системы осуществляют выборку данных из исходных источников, преобразуют их и помещают в динамическую многомерную БД, функционирующую на клиентской станции конечного пользователя. Основными представителями этого класса являются BusinessObjects одноименной компании, BrioQuery компании Brio Technology и PowerPlay компании Cognos. Обзор некоторых продуктов OLAP приведен в приложении.

В специализированных СУБД, основанных на многомерном представлении данных, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов:

1) гиперкубов (все хранимые в БД ячейки должны иметь одинаковую мерность, то есть находиться в максимально полном базисе измерений) или

2) поликубов (каждая переменная хранится с собственным набором измерений, и все связанные с этим сложности обработки перекладываются на внутренние механизмы системы).

Использование многомерных БД в системах оперативной аналитической обработки имеет следующие достоинства.

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

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

С другой стороны, имеются существенные ограничения.

1. Многомерные СУБД не позволяют работать с большими базами данных. К тому же за счет денормализации и предварительно выполненной агрегации объем данных в многомерной базе, как правило, соответствует (по оценке Кодда) в 2.5-100 раз меньшему объему исходных детализированных данных.

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

Следовательно, использование многомерных СУБД оправдано только при следующих условиях.

1. Объем исходных данных для анализа не слишком велик (не более нескольких гигабайт), то есть уровень агрегации данных достаточно высок.

2. Набор информационных измерений стабилен (поскольку любое изменение в их структуре почти всегда требует полной перестройки гиперкуба).

3. Время ответа системы на нерегламентированные запросы является наиболее критичным параметром.

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

Непосредственное использование реляционных БД в системах оперативной аналитической обработки имеет следующие достоинства.

1. В большинстве случаев корпоративные хранилища данных реализуются средствами реляционных СУБД, и инструменты ROLAP позволяют производить анализ непосредственно над ними. При этом размер хранилища не является таким критичным параметром, как в случае MOLAP.

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

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

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

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

В сложных задачах с многоуровневыми измерениями имеет смысл обратиться к расширениям схемы звезды - схеме созвездия (fact constellation schema) и схеме снежинки (snowflake schema). В этих случаях отдельные таблицы фактов создаются для возможных сочетаний уровней обобщения различных измерений (Приложение Б). Это позволяет добиться лучшей производительности, но часто приводит к избыточности данных и к значительным усложнениям в структуре базы данных, в которой оказывается огромное количество таблиц фактов.

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

Частично решают эту проблему расширения языка SQL (операторы GROUP BY CUBE", "GROUP BY ROLLUP" и "GROUP BY GROUPING SETS"); кроме того, предлагается механизм поиска компромисса между избыточностью и быстродействием, рекомендуя создавать таблицы фактов не для всех возможных сочетаний измерений, а только для тех, значения ячеек которых не могут быть получены с помощью последующей агрегации более полных таблиц фактов (Приложение В).

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

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

Заключение

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

Это следующие вопросы:

Откуда поступают данные? – Данные, подлежащие анализу, могут находиться в различных местах. Возможно, что база данных OLAP будет получать их из корпоративного Хранилища данных или из OLTP-системы. Если OLAP-продукт уже имеет возможность получить доступ к какому-то источнику данных, процессы категоризации и очистки данных сокращаются.

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

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

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

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

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

Глоссарий

	Понятие	Определение
1	BI-инструменты	Инструменты и технологии, используемые для доступа к информации. Включают OLAP-технологии, data mining и сложный анализ; средства конечного пользователя и инструменты построения нерегламентированных запросов, инструментальные панели для мониторинга хозяйственной деятельности и генераторы корпоративной отчетности.
2	On-line Analitic Processing, OLAP (Оперативная аналитическая обработка)	Технология аналитической обработки информации в режиме реального времени, включающая составление и динамическую публикацию отчетов и документов.
3	Slice and Dice (Продольные и поперечные срезы, дословно - "нарезка на ломтики и кубики")	Термин, использующийся для описания функции сложного анализа данных, обеспечиваемой средствами OLAP. Выборка данных из многомерного куба с заданными значениями и заданным взаимным расположением измерений.
4	Вращение (пивотинг) данных (Data Pivot)	Процесс вращения таблицы с данными, т. е. преобразования столбцов в строки и наоборот.
5	Вычисленный элемент (Calculated member)	Элемент измерения, чья величина определяется величинами других элементов (например, математическими или логическими приложениями). Вычисленный элемент может представлять собой часть OLAP сервера или быть описан пользователем в течение интерактивной сессии. Вычисленный элемент - это любой элемент, который не вводится, а вычисляется.
6	Глобальные бизнес-модели (Global Business Models)	Тип Хранилища данных, обеспечивающий доступ к информации, которая распределена по различным системам предприятия и находится под контролем различных подразделений или отделов с разными базами данных и моделями данных. Такой тип Хранилища данных труден для построения из-за необходимости объединения усилий пользователей различных подразделений для разработки общей модели данных для Хранилища.
7	Добыча данных (Data Mining)	Технические приемы, использующие программные инструменты, предназначенные для такого пользователя, который, как правило, не может заранее сказать, что конкретно он ищет, а может указать лишь определенные образцы и направления поиска.
8	Клиент/Сервер (Client/Server)	Технологический подход, заключающийся в разделении процесса на отдельные функции. Сервер выполняет несколько функций - управление коммуникациями, обеспечение обслуживания базы данных и др. Клиент выполняет индивидуальные пользовательские функции - обеспечение соответствующих интерфейсов, выполнение межэкранной навигации, предоставление функций помощи (help) и др.
9	Многомернаябазаданных, СУMБД(Multi-dimensional Database, MDBS and MDBMS)	Мощная база данных, позволяющая пользователям анализировать большие объемы данных. База данных со специальной организацией хранения - кубами, обеспечивающая высокую скорость работы с данными, хранящимися как совокупность фактов, измерений и заранее вычисленных агрегатов.
10	Углубление в данные (Drill Down)	Метод изучения детальных данных, используемый при анализе суммарного уровня данных. Уровни "углубления" зависят от степени детализации данных в [ранилище.
11	Центральное Хранилище (Central Warehouse)	1. База данных, содержащая данные, собираемые из операционных систем организации. Имеет структуру, удобную для анализа данных. Предназначена для поддержки принятия решений и создания единого информационного пространства корпорации. 2. Способ автоматизации, охватывающий все информационные системы, управляемые из одного места.

1 Голицина О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. – М.: ФОРУМ: ИНФРА-М, 2003. – 352 с.

2 Дейт К. Введение в системы баз данных. – М.: Hаука, 2005 г. – 246 с.

3 Елманова Н.В., Федоров А.А. Введение в OLAP-технологии Microsoft. – М.:Диалог-МИФИ, 2004. – 312 с.

4 Карпова Т.С. Базы данных: модели, разработка, реализация. – СПб.: Питер, 2006. – 304 с.

5 Коровкин С. Д., Левенец И. А., Ратманова И. Д., Старых В. А., Щавелёв Л. В. Решение проблемы комплексного оперативного анализа информации хранилищ данных // СУБД. - 2005. - № 5-6. - 47-51 с.

6 Кречетов Н., Иванов П. Продукты для интеллектуального анализа данных ComputerWeek-Москва. - 2003. - № 14-15. - 32-39 с.

7 Пржиялковский В. В. Сложный анализ данных большого объема: новые перспективы компьютеризации // СУБД. - 2006. - № 4. - 71-83 с.

8 Сахаров А. А. Концепция построения и реализации информационных систем, ориентированных на анализ данных // СУБД. - 2004. - № 4. - 55-70 с.

9 Ульман Дж. Основы систем баз данных. – М.: Финансы и статистика, 2003. – 312 c.

10 Хаббард Дж. Автоматизированное проектирование баз данных. – М.: Мир, 2007. – 294 с.

Коровкин С. Д., Левенец И. А., Ратманова И. Д., Старых В. А., Щавелёв Л. В. Решение проблемы комплексного оперативного анализа информации хранилищ данных // СУБД. - 2005. - № 5-6. - 47-51 с.

Ульман Дж. Основы систем баз данных. – М.: Финансы и статистика, 2003. – 312 c.

Барсегян А.А., Куприянов М.С. Технологии анализа данных: DataMining, VisualMining, TextMining, Olap. – СПб.: BHV-Петербург, 2007. – 532 с.

Елманова Н.В., Федоров А.А. Введение в OLAP-технологии Microsoft. – М.:Диалог-МИФИ, 2004. – 312 с.

Дейт К. Введение в системы баз данных. – М.: Hаука, 2005 г. – 246 с.

Голицина О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. – М.: ФОРУМ: ИНФРА-М, 2003. – 352с.

Сахаров А. А. Концепция построения и реализации информационных систем, ориентированных на анализ данных // СУБД. - 2004. - № 4. - 55-70 с.

Пржиялковский В. В. Сложный анализ данных большого объема: новые перспективы компьютеризации // СУБД. - 2006. - № 4. - 71-83 с.

хранилища данных формируются на основе фиксируемых на протяжении продолжительного периода времени моментальных снимков баз данных оперативной информационной системы и, возможно, различных внешних источников. В хранилищах данных применяются технологии баз данных, 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 -инструмент должен предоставлять возможности совместного доступа (запроса и дополнения), целостности и безопасности.
Неограниченные перекрестные операции. Все виды операций должны быть дозволены для любых измерений.
Интуитивная манипуляция данными. Манипулирование данными осуществлялось посредством прямых действий над ячейками в режиме просмотра без использования меню и множественных операций.
Гибкие возможности получения отчетов . Измерения должны быть размещены в отчете так, как это нужно пользователю.
Неограниченная

4. Классификация OLAP-продуктов.

5. Принципы работы OLAP-клиентов.

7. Сферы применения OLAP-технологий.

8. Пример использования OLAP-технологий для анализа в сфере продаж.

1. Место OLAP в информационной структуре предприятия.

Термин "OLAP" неразрывно связан с термином "хранилище данных" (Data Warehouse ).

Данные в хранилище попадают из оперативных систем (OLTP-систем), которые предназначены для автоматизации бизнес-процессов. Кроме того, хранилище может пополняться за счет внешних источников, например статистических отчетов.

Задача хранилища - предоставить "сырье" для анализа в одном месте и в простой, понятной структуре.

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

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

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

Хотя OLAP и не представляет собой необходимый атрибут хранилища данных, он все чаще и чаще применяется для анализа накопленных в этом хранилище сведений.

Место OLAP в информационной структуре предприятия (рис. 1).

Рисунок 1 . Место OLAP в информационной структуре предприятия

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

Подытоживая, можно определить OLAP как совокупность средств многомерного анализа данных, накопленных в хранилище.

2. Оперативная аналитическая обработка данных.

В основе концепции OLAP лежит принцип многомерного представления данных. В 1993 году E. F. Codd рассмотрел недостатки реляционной модели, в первую очередь, указав на невозможность "объединять, просматривать и анализировать данные с точки зрения множественности измерений, то есть самым понятным для корпоративных аналитиков способом", и определил общие требования к системам OLAP, расширяющим функциональность реляционных СУБД и включающим многомерный анализ как одну из своих характеристик.

По Кодду, многомерное концептуальное представление данных (multi-dimensional conceptual view ) представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных.

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

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

Операция спуска (drilling down ) соответствует движению от высших ступеней консолидации к низшим ; напротив, операция подъема (rolling up ) означает движение от низших уровней к высшим (рис. 2).

Рисунок 2. Измерения и направления консолидации данных

3. Требования к средствам оперативной аналитической обработки.

Многомерный подход возник практически одновременно и параллельно с реляционным . Однако, только начиная с середины девяностых годов, а точнее с
1993 г., интерес к МСУБД начал приобретать всеобщий характер. Именно в этом году появилась новая программная статья одного из основоположников реляционного подхода Э. Кодда , в которой он сформулировал 12 основных требований к средствам реализации OLAP (табл. 1).

Таблица 1.

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

Правила оценки программных продуктов класса OLAP

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

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

Помнить 12 правил Кодда слишком обременительно для большинства людей. Оказались, что можно резюмировать OLAP-определение только пятью ключевыми словами: Быстрый Анализ Разделяемой Многомерной Информации - или, кратко - FASMI (в переводе с английского: F ast A nalysis of S hared M ultidimensional I nformation ).

Это определение впервые было сформулировано в начале 1995 года и с тех пор не нуждалось в пересмотре.

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

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

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

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

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

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

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

Тест FASMI - разумное и понятное определение целей, на достижение которых ориентированы OLAP.

4. Классификация OLAP -продуктов.

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

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

Классификация по способу хранения данных

Многомерные кубы строятся на основе исходных и агрегатных данных. И исходные и агрегатные данные для кубов могут храниться как в реляционных, так и многомерных базах данных. Поэтому в настоящее время применяются три способа хранения данных: MOLAP (Multidimensional OLAP ), ROLAP (Relational OLAP ) и HOLAP (Hybrid OLAP ). Соответственно, OLAP -продукты по способу хранения данных делятся на три аналогичные категории:

1. В случае MOLAP , исходные и агрегатные данные хранятся в многомерной БД или в многомерном локальном кубе.

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

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

Классификация по месту размещения OLAP -машины.

По этому признаку OLAP -продукты делятся на OLAP -серверы и OLAP -клиенты:

· В серверных OLAP -средствах вычисления и хранение агрегатных данных выполняются отдельным процессом - сервером. Клиентское приложение получает только результаты запросов к многомерным кубам, которые хранятся на сервере. Некоторые OLAP -серверы поддерживают хранение данных только в реляционных базах, некоторые - только в многомерных. Многие современные OLAP -серверы поддерживают все три способа хранения данных: MOLAP , ROLAP и HOLAP .

MOLAP.

MOLAP - это Multidimensional On-Line Analytical Processing, то есть Многомерный OLAP. Это означает, что сервер для хранения данных использует многомерную базу данных (МБД). Смысл использования МБД очевиден. Она может эффективно хранить многомерные по своей природе данные, обеспечивая средства быстрого обслуживания запросов к базе данных. Данные передаются от источника данных в многомерную базу данных, а затем база данных подвергается агрегации. Предварительный расчет - это то, что ускоряет OLAP-запросы, поскольку расчет сводных данных уже произведен. Время запроса становится функцией исключительно времени, необходимого для доступа к отдельному фрагменту данных и выполнения расчета. Этот метод поддерживает концепцию, согласно которой работа производится единожды, а результаты затем используются снова и снова. Многомерные базы данных являются относительно новой технологией. Использование МБД имеет те же недостатки, что и большинство новых технологий. А именно - они не так устойчивы, как реляционные базы данных (РБД), и в той же мере не оптимизированы. Другое слабое место МБД заключается в невозможности использовать большинство многомерных баз в процессе агрегации данных, поэтому требуется время для того, чтобы новая информация стала доступна для анализа.

ROLAP.

ROLAP - это Relational On-Line Analytical Processing, то есть Реляционный OLAP. Термин ROLAP обозначает, что OLAP-сервер базируется на реляционной базе данных. Исходные данные вводятся в реляционную базу данных, обычно по схеме "звезда" или схеме "снежинка", что способствует сокращению времени извлечения. Сервер обеспечивает многомерную модель данных с помощью оптимизированных SQL-запросов.

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

Агрегированные/Предварительно агрегированные данные.

· OLAP -клиент устроен по-другому. Построение многомерного куба и OLAP -вычисления выполняются в памяти клиентского компьютера. OLAP -клиенты также делятся на ROLAP и MOLAP . А некоторые могут поддерживать оба варианта доступа к данным.

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

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

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

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

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

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

· Мощные ПК аналитиков – еще один довод в пользу OLAP -клиентов. При применении OLAP -сервера эти мощности не используются.

Среди преимуществ OLAP-клиентов можно также назвать следующее:

· Затраты на внедрение и сопровождение OLAP -клиента существенно ниже, чем затраты на OLAP -сервер.

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

5. Принципы работы OLAP -клиентов.

Рассмотрим процесс создания OLAP-приложения с помощью клиентского инструментального средства (рис. 1).

Рисунок 1. Создание OLAP-приложения с помощью клиентского ROLAP-средства

Принцип работы ROLAP-клиентов – предварительное описание семантического слоя, за которым скрывается физическая структура исходных данных. При этом источниками данных могут быть: локальные таблицы, РСУБД. Список поддерживаемых источников данных определяется конкретным программным продуктом. После этого пользователь может самостоятельно манипулировать понятными ему объектами в терминах предметной области для создания кубов и аналитических интерфейсов.

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

При создании семантического слоя источники данных – таблицы Sales и Deal – описываются понятными конечному пользователю терминами и превращаются в «Продукты» и «Сделки». Поле «ID» из таблицы «Продукты» переименовывается в «Код», а «Name » - в «Товар» и т.д.

Затем создается бизнес-объект «Продажи». Бизнес-объект – это плоская таблица, на основе которой формируется многомерный куб. При создании бизнес-объекта таблицы «Продукты» и «Сделки» объединяются по полю «Код» товара. Поскольку для отображения в отчете не потребуются все поля таблиц – бизнес-объект использует только поля «Товар», «Дата» и «Сумма».

В нашем примере на базе бизнес-объекта «Продажи» создан отчет по продажам товаров по месяцам.

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

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

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

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

6. Выбор архитектуры OLAP-приложения.

При реализации информационно-аналитической системы важно не ошибиться в выборе архитектуры OLAP-приложения. Дословный перевод термина On-Line Analytical Process - «оперативная аналитическая обработка» - часто воспринимается буквально в том смысле, что поступающие в систему данные оперативно анализируются. Это заблуждение - оперативность анализа никак не связана с реальным временем обновления данных в системе. Эта характеристика относится к времени реакции OLAP-системы на запросы пользователя. При этом зачастую анализируемые данные представляют собой снимок информации «на вчерашний день», если, например, данные в хранилищах обновляются раз в сутки.

В этом контексте более точен перевод OLAP как «интерактивная аналитическая обработка». Именно возможность анализа данных в интерактивном режиме отличает OLAP-системы от систем подготовки регламентированных отчетов.

Другой особенностью интерактивной обработки в формулировке родоначальника OLAP Э. Кодда является возможность «объединять, просматривать и анализировать данные с точки зрения множественности измерений, т. е. самым понятным для корпоративных аналитиков способом». У самого Кодда термин OLAP обозначает исключительно конкретный способ представления данных на концептуальном уровне - многомерный. На физическом уровне данные могут храниться в реляционных базах данных, однако на деле OLAP-инструменты, как правило, работают с многомерными базами данных, в которых данные упорядочены в виде гиперкуба (рис. 1).

Рисунок 1. OLAP – куб (гиперкуб, метакуб )

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

Очевидно, что время формирования многомерной базы данных существенно зависит от объема загружаемых в нее данных, поэтому разумно ограничить этот объем. Но как при этом не сузить возможности анализа и не лишить пользователя доступа ко всей интересующей информации? Существует два альтернативных пути: Analyze then query («Сначала проанализируй - затем запроси дополнительную информацию») и Query then analyze («Сначала запроси данные - затем анализируй»).

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

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

К достоинствам второго подхода следует отнести «свежесть» информации, которую пользователь получает в виде многомерного отчета - «микрокуба ». Микрокуб формируется на основе только что запрошенной информации из актуальной реляционной базы данных. Работа с микрокубом осуществляется в интерактивном режиме - получение срезов информации и ее детализация в рамках микрокуба осуществляется моментально. Другим положительным моментом является то, что проектирование структуры и наполнение микрокуба осуществляется пользователем «на лету», без участия администратора баз данных. Однако подход страдает и серьезными недостатками. Пользователь, не видит общей картины и должен заранее определяться с направлением своего исследования. В противном случае запрошенный микрокуб может оказаться слишком мал и не содержать всех интересующих данных, а пользователю придется запрашивать новый микрокуб , затем новый, затем еще и еще. Подход Query then analyze реализует инструментальное средство BusinessObjects одноименной компании и инструментальные средства платформы Контур компании Intersoft Lab .

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

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

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

Наиболее яркими представителями подхода «Analyze then query » являются инструментальные средства PowerPlay и Impromptu компании Cognos .

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

7. Сферы применения OLAP-технологий.

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

Рассмотрим некоторые сферы применения OLAP-технологий, взятые из реальной жизни.

1. Продажи.

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

2. Закупки.

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

3. Цены.

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

4. Маркетинг.

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

5. Склад.

Анализ структуры остатков на складе в разрезе видов товаров, складов, анализ сроков хранения товаров, анализ отгрузки по получателям и многие другие важные для предприятия виды анализа возможны при наличии в организации складского учета.

6. Движение денежных средств.

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

7. Бюджет.

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

8. Бухгалтерские счета.

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

9. Финансовая отчетность.

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

10. Посещаемость сайта.

Лог-файл Интернет-сервера многомерен по природе, а значит подходит для OLAP-анализа. Фактами являются: количество посещений, количество хитов, время проведенное на странице и другая информация, имеющаяся в логе.

11. Объемы производства.

Это еще один пример статистического анализа. Таким образом, можно анализировать объемы выращенного картофеля, выплавленной стали, произведенного товара.

12. Потребление расходных материалов.

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

13. Использование помещений.

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

14. Текучесть кадров на предприятии.

Анализ текучести кадров на предприятии в разрезе филиалов, отделов, профессий, уровня образования, пола, возраста, времени.

15. Пассажирские перевозки.

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

Этим списком не ограничиваются сферы применения OLAP - технологий. Для примера рассмотрим технологию OLAP -анализа в сфере продаж.

8. Пример использования OLAP -технологий для анализа в сфере продаж.

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

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

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

Измерение «Клиенты» отражает структуру продаж по территориально-географическому признаку. В каждом измерении могут существовать свои ие рархии, например, в данном измерении это может быть структура: Страны – Регионы – Города – Клиенты.

Для анализа эффективности деятельности подразделений следует создать свое измерение. Например, можно выделить два уровня иерархии: департаменты и входящие в них отделы, что и должно найти отражение в измерении «Подразделения».

По сути, измерения «Время», «Товары», «Заказчики» достаточно полно определяют пространство предметной области.

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

OLAP – куб для анализа будет иметь вид (рис. 2):

Рисунок 2. OLAP – куб для анализа объема продаж

Вот именно такой трехмерный массив в терминах OLAP и называется кубом. На самом деле, с точки зрения строгой математики кубом такой массив будет далеко не всегда: у настоящего куба количество элементов во всех измерениях должно быть одинаковым, а у кубов OLAP такого ограничения нет. Куб OLAP совсем не обязательно должен быть трехмерным. Он может быть и двух- , и многомерным - в зависимости от решаемой задачи. Серьезные OLAP-продукты рассчитаны на количество измерений порядка 20. Более простые настольные приложения поддерживают где-то 6 измерений.

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

Однако куб сам по себе для анализа не пригоден. Если еще можно адекватно представить или изобразить трехмерный куб, то с шести- или девятнадцатимерным дело обстоит значительно хуже. Поэтому перед употреблением из многомерного куба извлекают обычные двумерные таблицы. Эта операция называется "разрезанием" куба. Аналитик как бы берет и "разрезает" измерения куба по интересующим его меткам. Этим способом аналитик получает двумерный срез куба (отчет) и с ним работает. Структура отчета представлена на рисунке 3.

Рисунок 3. Структура аналитического отчета

Разрежем наш OLAP – куб и получим отчет о продажах за третий квартал, он будет иметь следующий вид (рис.4).

Рисунок 4. Отчет о продажах за третий квартал

Можно разрезать куб вдоль другой оси и получить отчет о продажах группы товаров 2 в течение года (рис. 5).

Рисунок 5. Поквартальный отчет о продажах товара 2

Аналогично можно проанализировать отношения с клиентом 4, разрезав куб по метке Клиенты (рис. 6)

Рисунок 6. Отчет о поставках товаров клиенту 4

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

Аналитические системы OLAP. OLAP системы В olap анализе используются