Разработка системы olap отчетности розничных сетей. OLAP - это просто! Как строят хранилище

Синие стрелки - пути, которыми информация попадает в систему, зеленными – как информация в дальнейшем используется.

1. Информация о заказах заносится в систему 1с – dbf версия.
2. Загрузка данных «автообмен». Вообще – то это лишний шаг. Данные можно получать напрямую из dbf базы. Но программисты 1с решили что стандартный (для 1с) механизм выгрузки данных, принесет меньше вреда.
3. Раз в сутки изменения за прошедший день выгружаются в специально подготовленную базу MsSql – хранилище. Выгружается не вся информация, а только то, что нужно для кубов.

   В принципе необязательно строить «хранилище». Данные для куба можно получать напрямую из базы 1с (MsSQL или dbf). Но в моем случае из 1с данные прошлых периодов периодически удаляются и очищаются справочники. Кроме того перед загрузкой в хранилище данные немного «чистятся».

4. Происходит пересчет куба – данные попадают в куб.

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

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

Любой пользователь может получить информацию разными путями:

1. Построить отчет самостоятельно на web-странице или в excel

   Сначала использовался только excel, но возникало много проблем с тем, что екселевские файлы «разбредались», нужно было получить одну «точку входа» для выбора информации.
   Поэтому был создан локальный сайт, на котором опубликованы страницы с PivotTable. Сотрудник, который хочет получить пару цифр «здесь и сейчас» заходит на этот сайт и строит отчет в нужной ему форме. Если человеку нужно использовать этот отчет в дальнейшем – он может написать заявку, чтобы его отчет опубликовали в SSRS или сам сохраняет его в excel.

2. Посмотреть стандартный отчет, опубликованный в SQL Server Reporting Services (SSRS)
3. Получить локальный куб – и вне офиса «вращать» данные с помощью excel
4. Подписаться на рассылку и получать стандартные отчеты из SSRS на e-mail
5. Отдел маркетинга кроме того использует программу CubeSlice. В ней можно создавать локальные кубы самостоятельно и гораздо удобнее, чем в excel

Локальные кубы

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

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

Основные параметры системы

Конфигурация сервера:

процессор: 2xAMD Opteron 280
память: 4Gb
дисковые массивы:
операционная система: RAID 1 (зеркало) 2xSCSI 15k
данные: RAID 0+1 4xSCSI 10k

Согласитесь, такую машинку сложно назвать «мощным» сервером

Объем данных:

хранилище 10Гб, данные с 2002 года
агрегация 30%
Размер многомерной базы 350М
кол-во членов «больших измерений»: товары 25 тыс., адреса – 20 тыс.
кол-во документов в день - 400. среднее кол-во строк в документе - 30

Что в итоге получила компания:

Плюсы

• Для руководства предприятия

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

• Для менеджера

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

• Для поставщиков

  Возможность интерактивной работы с информацией

• С точки зрения it-специалиста

  Уменьшение рутинной работы. Большую часть отчетов пользователь получает самостоятельно.

Минусы:

• Стоимость внедрения. Необходимо дополнительное оборудование и программное обеспечение.
• Нехватка подготовленных специалистов. Расходы на обучение сотрудников it-отдела.

Разобравшись в том, что такое OLAP и каковы его свойства, перейдем к самому, пожалуй, важному вопросу: для кого предназначены программ­ные продукты этого класса?

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

Часто возникает вопрос: чем, с точки зрения пользователя-аналитика, OLAP-система отличается от хранилища данных? Можно сказать, что главное, с точки зрения пользователя, отличие OLAP состоит в струк­турированности информации в соответствии с ее предметной (именно предметной, а не технической) сущностью. Работая с OLAP-приложе- нием, аналитик использует привычные финансово-экономические тер­мины, категории и показатели (виды материалов и готовой продукции, регионы продаж, объем реализации, себестоимость, прибыль и т. п.), а для того чтобы сформировать любой, даже довольно сложный запрос, ему не придется изучать язык SQL. И при этом ответ на запрос будет получен в течение всего нескольких секунд. Кроме того, работая с OLAP-системой, экономист может пользоваться такими привычными для себя инструментами, как электронные таблицы, или специальными средствами построения отчетов.

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

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

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

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

Концепция Business Performance Management: начало пути Средства формирования запросов и отчетности

Как уже было отмечено, средства формирования запросов и постро­ения отчетов {Query and Reporting took) обеспечивают функции пост­роения запросов к информационно-аналитическим системам, интегра­цию данных из нескольких источников, просмотр данных с возможностью детализации и обобщения, построение и печать полно­ценных отчетов, в том числе презентационного качества. Некоторые из программных продуктов этого класса могут использоваться конечными пользователями, с минимальной поддержкой ИТ-департамента, другие же требуют определенного программирования и настраиваются техни­ческими специалистами.

Типичными представителями систем этого класса являются програм­мные продукты корпорации Hyperion, объединенные в семейство Hyperion Performance Suite.

Hyperion Performance Suite представляет собой набор средств построения запросов, анализа, формирования отчетов и их регламентированной до­ставки в рамках всей организации. Эти программные продукты вошли в линейку BI-систем Hyperion после того, как в 2003 году Hyperion при­обрел Brio Software - компанию, хорошо известную на рынке систем бизнес-интеллекта благодаря своим эффективным и легким в использо­вании решениям. До этого на протяжении ряда лет компании Hyperion и Brio тесно сотрудничали как технологические партнеры, поэтому объ­единение их разработок позволило создать уникальную линейку, в кото­рой решения Hyperion (OLAP-система Hyperion Essbase и аналитические приложения - Hyperion Planning, Hyperion Financial Management и дру­гие) оказались органично дополнены современными средствами запросов и отчетности Brio. В результате Hyperion стал обладателем самой мощной и полнофункциональной линейкой из всех присутствующих на рынке программных продуктов класса Business Intelligence. Сегодня все эти решения, по достоинству оцененные многими зарубежными компаниями, стали доступны российским предприятиям.

Комплект Hyperion Performance Suite включает в себя два программных продукта - Hyperion Intelligence и Hyperion SQR.

Hyperion Intelligence - это современная, удобная в работе система для формирования сложных запросов к различным источникам данных, включая ERP, CRM, банковские и прочие транзакционные системы, а также для представления этих данных в удобном для анализа виде. Эф­фективно используя данные, хранящиеся в существующих информаци­онных системах , Hyperion Intelligence дает возможность разработчикам, аналитикам и потребителям превратить «сырые» данные в ценную информацию для принятия решений. Аналитические возмож­ности системы позволяют специалистам организации оперативно оцени­вать возможности и тенденции бизнеса и повысить обоснованность принимаемых управленческих решений, а интуитивно понятный интер­фейс пользователя, основанный на Интернет-технологиях, делает инфор­мацию доступной любому из уполномоченных пользователей.

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

Линейка BI-решений Hyperion, дополненная средствами запросов и отчетности, доставшимися «по наследству» от Brio, представляет инте­рес как для ИТ-специалистов, так и для конечных пользователей.

С точки зрения конечного пользователя, это - удобный инструмент, позволяющий решить уже упоминавшуюся проблему, с которой так часто сталкиваются менеджеры и предметные специалисты - проблему «единого взгляда на управленческую информацию». Напомним, что эта проблема состоит в том, что очень часто управленческая информация, необходимая для анализа и принятия решений, хранится в разных ис­точниках - учетных системах, ERP-системах, базах данных и т. п. Это крайне затрудняет получение нужной информации и ее представление в удобном для пользователя виде: специалисты вынуждены тратить время на рутинные процедуры сбора данных и их обработки, причем с риском искажения. Управленческая информация, полученная таким путем, часто не соответствует требованиям достоверности и актуаль­ности, что снижает ее ценность. В этом плане BI-решения Hyperion позволяют существенно упростить и ускорить сбор информации, уни­фицировать ее и представить в удобной и наглядной форме. Такая информация - надежная база для принятия управленческих решений, при этом рутинные процедуры сводятся к минимуму, а время специа­листов высвобождается для решения аналитических задач.

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

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

Каталог OLAP-решений и проектов смотрите в разделе OLAP на TAdviser.

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

Требования к OLAP-системам. FASMI

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

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

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

При этом такая связка должна удовлетворять очевидным требованиям поддержки импорта-экспорта из нескольких источников данных, осуществления процедур очистки и трансформации данных, унификации используемых классификаторов и справочников. Кроме того, к этим требованиям добавляется необходимость учёта различных циклов обновления данных в существующих информационных системах и унификации требуемого уровня детализации данных. Сложность и многогранность этой проблемы привела к появлению концепции хранилищ данных , и, в узком смысле, к выделению отдельного класса утилит конвертации и преобразования данных - ETL (Extract Transform Load) .

Модели хранения активных данных

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

Это, однако, не значит, что все OLAP-системы используют многомерную модель для хранения активных, "рабочих" данных системы. Так как модель хранения активных данных оказывает влияние на все диктуемые FASMI-тестом требования, её важность подчёркивается тем, что именно по этому признаку традиционно выделяют подтипы OLAP - многомерный (MOLAP), реляционный (ROLAP) и гибридный (HOLAP).

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

Хранение активных данных в многомерной БД

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

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

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

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

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

Хранение активных данных в реляционной БД

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

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

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

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

Хранение активных данных в «плоских» файлах

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

Гибридный подход к хранению данных

Большинство производителей OLAP-систем, продвигающих свои комплексные решения, часто включающие помимо собственно OLAP-системы СУБД , инструменты ETL (Extract Transform Load) и отчетности, в настоящее время используют гибридный подход к организации хранения активных данных системы, распределяя их тем или иным образом между РСУБД и специализированным хранилищем, а также между дисковыми структурами и кэшированием в оперативной памяти.

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

OLAP (англ. on-line analytical processing) – совокупность методов динамической обработки многомерных запросов в аналитических базах данных. Такие источники данных обычно имеют довольно большой объем, и в применяемых для их обработки средствах одним из наиболее важных требований является высокая скорость. В реляционных БД информация хранится в отдельных таблицах, которые хорошо нормализованы. Но сложные многотабличные запросы в них выполняются довольно медленно. Значительно лучшие показатели по скорости обработки в OLAP-системах достигаются за счет особенности структуры хранения данных. Вся информация четко организована, и применяются два типа хранилищ данных: измерения (содержат справочники, разделенные по категориям, например, точки продаж, клиенты, сотрудники, услуги и т.д.) и факты (характеризуют взаимодействие элементов различных измерений, например, 3 марта 2010 г. продавец A оказал услугу клиенту Б в магазине В на сумму Г денежных единиц). Для вычисления результатов в аналитическом кубе применяются меры. Меры представляют собой совокупности фактов, агрегированных по соответствующим выбранным измерениям и их элементам. Благодаря этим особенностям на сложные запросы с многомерными данными затрачивается гораздо меньшее время, чем в реляционных источниках.

Одним из основных вендоров OLAP-систем является корпорация Microsoft . Рассмотрим реализацию принципов OLAP на практических примерах создания аналитического куба в приложениях Microsoft SQL Server Business Intelligence Development Studio (BIDS) и Microsoft Office PerformancePoint Server Planning Business Modeler (PPS) и ознакомимся с возможностями визуального представления многомерных данных в виде графиков, диаграмм и таблиц.

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

Сначала определим измерения. С деятельности компании связаны следующие сущности (категории данных):

• Точки продаж
  - Сотрудники
  - Партнеры

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

Рис.1. Таблицы измерений и фактов в аналитической БД. Последовательность создания
После создания многомерного источника данных в BIDS имеется возможность просмотреть его представление (Data Source View). В нашем примере получится схема, представленная на рисунке ниже.

Рис.2. Представление источника данных (Data Source View) в Business Intellingence Development Studio (BIDS)

Как видим, таблица фактов связана с таблицами измерений посредством однозначного соответствия полей-идентификаторов (PartnerID, EmployeeID и т.д.).

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

Для решения аналитических задач, связанных со сложными расчетами, прогнозированием, моделированием сценариев «Что, если…» применяется технология многомерного анализа данных - Технология OLAP. Концепция OLAP впервые была описана в 1993 году Эдгаром Коддом, известным исследователем баз данных и автором реляционной модели данных, в книге “OLAP для пользователей-аналитиков: каким он должен быть”, где он изложил 12 законов аналитической обработки данных, по которым разработчики OLAP-продуктов живут и сейчас:

1. Концептуальное многомерное представление данных.

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

3. Доступность и детализация данных.

4. Постоянная производительность при разработке отчетов (Если число измерений или объем базы данных увеличиваются, пользователь-аналитик не должен чувствовать ухудшение в производительности).

5. Клиент-серверная архитектура (OLAP доступен с рабочего стола).

6. Общая многомерность.

7. Динамическое управление разреженными матрицами.

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

9. Неограниченные перекрестные операции.

10. Интуитивная манипуляция данными.

11. Гибкие возможности получения отчетов.

12. Неограниченная размерность и число уровней агрегации (аналитический инструмент должен предоставлять не менее 15 измерений одновременно, а предпочтительно 20).

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

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

Концепция OLAP появилась именно для разрешения подобных проблем. OLAP (O nL ine A nalytical P rocessing) – это оперативная аналитическая обработка больших объемов данных в режиме реального времени. Цель OLAP-систем – облегчение решения задач анализа больших объемов данных и быстрая обработка сложных запросов к базе данных.

OLAP – это:

не программный продукт

не язык программирования

не технология

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

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

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

Рис. 26 OLAP – куб

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

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

OLAP – куб совсем не обязательно должен быть трехмерным. Он может быть и двухмерным и многомерным - в зависимости от решаемой задачи. Аналитикам может понадобиться более 20 измерений - серьезные OLAP-продукты именно на такое количество и рассчитаны. Более простые настольные приложения поддерживают не более 6 измерений.

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

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

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

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

Рис. 27 П олучение произвольных срезов данных при разрезании OLAP куба.

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

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

По способу хранения данных делятся на три категории MOLAP, ROLAP и HOLAP:

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

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

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

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

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

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

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

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

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

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

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

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

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

Множество статей, посвященных OLAP, можно прочитать на сайте: http://www.olap.ru/basic/oolap.asp

Возможно, для кого-то использование OLAP-технологии (On-line Analytic Processing) при построении отчетности покажется какой-то экзотикой, поэтому применение OLAP-КУБа для них вовсе не является одним из важнейших требований при автоматизации бюджетирования и управленческого учета .

На самом деле очень удобно пользоваться многомерным КУБом при работе с управленческой отчетностью. При разработке форматов бюджетов можно столкнуться с проблемой многовариантности форм (подробнее об этом можно прочитать в Книге 8 "Технология постановки бюджетирования в компании" и в книге "Постановка и автоматизация управленческого учета").

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

Естественно, это приводит к тому, что руководители хотят получать отчетность во всех интересующих их аналитических срезах. А это значит, что отчеты нужно как-то заставить «дышать». Иными словами можно сказать, что в данном случае речь идет о том, что по смыслу один и тот же отчет должен предоставлять информацию в различных аналитических разрезах. Поэтому статичные отчеты уже не устраивают многих современных руководителей. Им нужна динамика, которую может дать многомерный КУБ.

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

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

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

Следует отметить, что если создавать строки бюджетов на основе трех аналитических срезов (как в рассматриваемом примере), это позволяет создавать достаточно сложные бюджетные модели и составлять детализированные отчеты с использованием КУБа.

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

Рис. 1. Пример бюджета продаж, построенного на основе одной аналитики "Продукты" в OLAP-КУБе

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

Рис. 2. Пример бюджета продаж, построенного на основе двух аналитик "Продукты" и "Филиалы" в OLAP-КУБе программного комплекса "ИНТЕГРАЛ"

.

Если есть необходимость строить более детальные отчеты, то можно тот же бюджет продаж составлять с использованием трех аналитик (справочников). Пример бюджета продаж, построенного на основе трех аналитик "Продукты", "Филиалы" и "Каналы сбыта" представлен на рисунке 3 .

Рис. 3. Пример бюджета продаж, построенного на основе трех аналитик "Продукты", "Филиалы" и "Каналы сбыта" в OLAP-КУБе программного комплекса "ИНТЕГРАЛ"

Нужно напомнить о том, что КУБ, используемый для формирования отчетов, позволяет выводить данные в различной последовательности. На рисунке 3 бюджет продаж сначала "разворачивается" по продуктам, затем по филиалам, а потом по каналам сбыта.

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

Рис. 4. Пример бюджета продаж, построенного на основе трех аналитик "Продукты", "Каналы сбыта" и "Филиалы" в OLAP-КУБе программного комплекса "ИНТЕГРАЛ"

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

Рис. 5. Пример бюджета продаж, построенного на основе трех аналитик "Филиалы", "Продукты" и "Каналы сбыта" в OLAP-КУБепрограммного комплекса "ИНТЕГРАЛ"

На самом деле это не все возможные варианты вывода бюджета продаж.

Кроме того, нужно обратить внимание на то, что КУБ позволяет работать с иерархической структурой справочников. В представленных примерах иерархическими справочниками являются "Продукты" и "Каналы сбыта".

С точки зрения пользователя он в данном примере получает несколько управленческих отчетов (см. Рис. 1-5 ), а с точки зрения настроек в программном продукте – это один отчет. Просто с помощью КУБа его можно просматривать несколькими способами.

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

Необходимо упомянуть еще о нескольких возможностях OLAP-КУБа.

В многомерном иерархическом OLAP-КУБе есть несколько измерений: тип строки, дата, строки, справочник 1, справочник 2 и справочник 3 (см. Рис. 6 ). Естественно, в отчет выводится столько кнопок со справочниками, сколько есть в строке бюджета, содержащей максимальное количество справочников. Если ни в одной строке бюджета нет ни одного справочника, то в отчете не будет ни одной кнопки со справочниками.

Изначально OLAP-КУБ строится по всем измерениям. По умолчанию при первоначальном построении отчета измерения расположены именно в тех областях, как показано на рисунке 6 . То есть такое измерение, как «Дата», располагается в области вертикальных измерений (измерения в области столбцов), измерения «Строки», «Справочник 1», «Справочник 2» и «Справочник 3» – в области горизонтальных измерений (измерения в области строк), а измерение «Тип строки» – в области «нераскрываемых» измерений (измерения в страничной области). Если измерение находится в последней области, то данные в отчете не будут «раскрываться» по этому измерению.

Каждое из этих измерений можно поместить в любую из трех областей. После переноса измерений отчет мгновенно перестраивается в соответствии с новой конфигурацией измерений. Например, можно поменять местами дату и строки со справочниками. Или можно в вертикальную область измерений перенести один из справочников (см. Рис. 7 ). Иными словами, отчет в OLAP-КУБе можно «крутить» и выбирать тот вариант вывода отчета, который является наиболее удобным для пользователя.

Рис. 7. Пример перестройки отчета после изменения конфигурации измерений программного комплекса "ИНТЕГРАЛ"

Конфигурацию измерений можно менять либо в основной форме КУБа, либо в редакторе карты изменений (см. Рис. 8 ). В этом редакторе также можно мышкой перетаскивать измерения из одной области в другую. Помимо этого, можно менять местами измерения в одной области.

Кроме того, в этой же форме можно настраивать некоторые параметры измерений. По каждому измерению можно настраивать расположение итогов, порядок сортировки элементов и названия элементов (см. Рис. 8 ). Также можно задавать, какое название элементов выводить в отчет: сокращенное (Name) или полное (FullName).

Рис. 8. Редактор карты измерений программного комплекса "ИНТЕГРАЛ"

Редактировать параметры измерений можно непосредственно в каждом из них (см. Рис. 9 ). Для этого нужно нажать на пиктограмму, расположенную на кнопке рядом с названием измерения.

Рис. 9. Пример редактирования справочника 1 Продукты и услуги в

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

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

Рис. 10. Пример вывода в отчете только одной продуктовой группы (папки) в программном комплексе "ИНТЕГРАЛ"

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

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

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

Например, с помощью ограничений также можно задавать, какие элементы или группы справочников нужно выводить в отчет, а какие – нет.

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

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