/ В кубистической манере. Применение OLAP-кубов в практике управления крупных компаний

Вконтакте

Одноклассники

Константин Токмачев , системный архитектор

В кубистической манере.
Применение OLAP-кубов в практике управления крупных компаний

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

О пользе бизнес-аналитики

В контуре управления корпорацией между «сырыми» данными и «рычагами» воздействия на управляемый объект располагаются «показатели работы» – KPI. Они образуют как бы «приборное табло», отражающее состояние различных подсистем управляемого объекта. Оснастить фирму информативными показателями работы и контролировать их расчет и полученные значения – труд бизнес-аналитика. Существенную помощь в организации аналитической работы корпорации способны оказать автоматизированные службы анализа, такие как утилита MS SQL Server Analysis Services (SSAS) и ее главный диспозитив – OLAP-куб.

Прямо здесь нужно сделать еще одно замечание. Скажем, в американской традиции специальность, ориентированная на работу с OLAP-кубами, называется BI (Business Intelligence) . Не должно быть никаких иллюзий, будто бы американское BI соответствует русскому «бизнес-аналитик». Без обид, но нередко наш бизнес-аналитик – это «недобухгалтер» и «недопрограммист», специалист с нечеткими знаниями и с небольшим окладом, реально не обладающий никаким собственным инструментарием и методологией.

Специалист же BI – это, по сути, прикладной математик, высококлассный специалист, ставящий на вооружение фирмы современные математические методы (то, что называлось Operations Researh – методы исследования операций). BI больше соответствует бывшей когда-то в СССР специальности «системный аналитик», выпускавшейся факультетом ВМК МГУ им. М.В. Ломоносова. OLAP-куб и службы анализа могут стать перспективной основой рабочего места русского бизнес-аналитика, возможно, после некоторого повышения его квалификации в сторону американского BI.

В последнее время возникла еще одна вредная тенденция. Благодаря специализации утрачено взаимопонимание между разными категориями работников корпорации. Бухгалтер, менеджер и программист, как «лебедь, рак да щука» в басне И.А. Крылова, тянут корпорацию в разные стороны.

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

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

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

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

Преимущества OLAP-кубов

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

Некоторое представление об OLAP-
кубе может дать «сводная таблица» MS Excel. У этих объектов схожая логика и похожие интерфейсы. Но, как будет видно из статьи, функциональность OLAP несравненно богаче, а производительность несравненно выше, так что «сводная таблица» остается локальным настольным продуктом, тогда как OLAP – продукт корпоративного уровня.

Почему OLAP-куб так хорошо подходит для решения аналитических задач? OLAP-куб устроен так, что все показатели во всех возможных разрезах заранее вычислены (полностью или частично), и пользователю остается только «вытянуть» мышью требуемые показатели (измерения measures) и разрезы (размерности dimensions), а программе – перерисовать таблички.

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

Формулировка аналитики возможна в трех вариантах: это либо поле базы данных (вернее, поле warehouse), либо расчетное поле calculation, определяемое на уровне дизайна куба, либо выражение языка MDX при интерактивной работе с кубом.

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

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

Приведем пример. Допустим, руководитель контролирует дебиторскую задолженность. Пока KPI просроченной дебиторской задолженности «горит зеленым светом», значит, все в норме, никаких управленческих действий не требуется. Если цвет изменился на желтый или красный – что-то не так: разрезаем KPI по отделам продаж и сразу видим подразделения «в красном». Следующий разрез по менеджерам – и продавец, чьи клиенты просрочили платежи, определен. (Далее сумму просрочки можно разрезать по покупателям, по срокам и т.п.) Руководитель корпорации может прямо обратиться к нарушителям на любом уровне. Но вообще-то тот же KPI (на своих уровнях иерархии) видят и начальники отделов, и менеджеры по продажам. Поэтому, чтобы исправить ситуацию, им даже не нужно ждать «вызова на ковер»… Разумеется, сам KPI по смыслу не обязательно должен быть суммой просрочки – он может быть средневзвешенным сроком просрочки или вообще скоростью оборота дебиторской задолженности.

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

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

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

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

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

OLTP + OLAP: контур обратной связи в цепи управления фирмой

Теперь рассмотрим общую идею OLAP-кубов и их точку приложения в управленческой цепи корпорации. Термин OLAP (OnLine Analytical Processing) был введен британским математиком Едгаром Коддом в дополнение к им же ранее введенному термину OLTP (OnLine Transactions Processing). Об этом еще будет сказано, но Е. Кодд, разумеется, предложил не только термины, но и математические теории OLTP и OLAP. Не вдаваясь в детали, в современной интерпретации OLTP – это реляционная база данных, рассмотренная как механизм регистрации, хранения и выборки информации .

Методология решения

Такие ERP-системы (Enterprice Resource Planning), как 1С7, 1С8, MS Dynamics AX, имеют программные интерфейсы, ориентированные на пользователя (ввод и корректировка документов и т.п.), и реляционную базу данных (DB) для хранения и выборки информации, представленную сегодня программными продуктами типа MS SQL Server (SS).

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

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

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

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

В качестве программной реализации OLAP мы будем рассматривать утилиту MS Analysis Services, входящую в состав стандартной поставки MS SQL Server, сокращенно SSAS. Отметим, что по замыслу Е. Кодда OLAP-куб в аналитике должен дать ту же исчерпывающую свободу действий, которую система OLTP и реляционная база данных (SQL Server) дают в хранении и выборке информации.

Материально-техническое обеспечение OLAP

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

Будем считать, что корпорация использует ERP-систему, например, 1С7 или 1С8, в рамках которой в обычном порядке идет регистрация информации. База данных этой ERP-системы располагается на некоем сервере и поддерживается программой MS SQL Server.

Будем считать также, что на другом сервере установлено матобеспечение, включающее MS SQL Server с утилитой MS Analysis Services (SSAS), а также программы MS SQL Server Managment Studio, MS C#, MS Excel и MS Visual Studio. Эти программы в совокупности образуют требуемый контекст: инструментарий и необходимые интерфейсы разработчика OLAP-кубов.

На сервере SSAS установлена свободно распространяемая программа blat, вызываемая (с параметрами) из командной строки и обеспечивающая почтовый сервис.

На рабочих станциях сотрудников, в рамках локальной сети, среди прочего установлены программы MS Excel (версии не менее 2003), а также, возможно, специальный драйвер для обеспечения работы MS Excel с MS Analysis Services (если только соответствующий драйвер уже не включен в MS Excel).

Для определенности будем считать, что на рабочих станциях сотрудников установлена операционная система Windows XP, а на серверах – Windows Server 2008. Кроме того, пусть в качестве SQL Server используется MS SQL Server 2005, причем на сервере с OLAP-кубом установлены Enterprise Edition (EE) или Developer Edition (DE). В этих редакциях возможно использовать т.н. «полуаддитивные меры», т.е. дополнительные агрегатные функции (статистики), отличные от обычных сумм (например, экстремум или среднее значение).

Дизайн OLAP-куба (OLAP-кубизм)

Скажем несколько слов о дизайне самого OLAP-куба. На языке статистики OLAP-куб – это множество показателей работы, рассчитанных во всех необходимых разрезах, например, показатель отгрузки в разрезах по покупателям, по товарам, по датам и т.п. Из-за прямого перевода с английского в русской литературе по OLAP-кубам показатели называются «мерами», а разрезы – «размерностями». Это математически корректный, но синтаксически и семантически не очень удачный перевод. Русские слова «мера», «измерение», «размерность» почти не отличаются по смыслу и написанию, в то время как английские «measure» и «dimension» отличны и по написанию и по смыслу. Поэтому мы отдаем предпочтение аналогичным по смыслу традиционным русским статистическим терминам «показатель» и «разрез».

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

В этой схеме OLAP и OLTP не имеют общих таблиц, и аналитики OLAP рассчитываются максимально детально на стадии обновления куба (Process), предшествующей стадии использования. Эта схема называется MOLAP (Multidimensional OLAP). Ее минусы – асинхронность с ERP и большие затраты памяти.

Хотя формально OLAP-куб можно построить с использованием в качестве источника данных всех (тысяч) таблиц реляционной базы данных ERP-системы и всех (сотен) их полей в качестве показателей или разрезов, реально этого делать не стоит. Наоборот. Для загрузки в куб правильнее подготовить отдельную базу данных, называемую «витрина» или «хранилище» (warehouse).

Несколько причин заставляют поступить именно так.

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

Можно еще добавить, что ERP-систему и OLAP-куб следует располагать на разных серверах, чтобы разделить нагрузку. Но тогда при наличии общих таблиц для OLAP и OLTP возникает еще и проблема сетевого трафика. Практически неразрешимые -проблемы появляются в этом случае при необходимости консолидации в один OLAP-куб нескольких разнородных ERP-систем (1С7, 1С8, MS Dynamics AX).

Наверное, можно и дальше громоздить технические проблемы. Но самое главное, вспомним, что, в отличие от OLTP, OLAP – не средство регистрации и хранения данных, а средство аналитики. Это означает, что не нужно «на всякий случай» грузить и грузить «грязные» данные из ERP в OLAP. Наоборот, нужно сначала выработать концепцию управления фирмой, хотя бы на уровне системы KPI, и далее сконструировать прикладное хранилище данных (warehouse), расположенное на том же сервере, что и OLAP-куб, и содержащее небольшое рафинированное количество данных из ERP, необходимых для управления.

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

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

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

Архитектура решения

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

На сервере OLAP мы создаем образы (пустые копии) баз данных всех этих ERP-систем. На эти пустые копии мы периодически (еженощно) выполняем частичную репликацию баз данных соответствующих активно работающих ERP.

Далее запускаются SP (stored procedure), которые на том же сервере OLAP без сетевого трафика на основе частичных реплик баз данных ERP-систем создают (или пополняют) хранилище (warehouse) – источник данных OLAP-куба.

Потом запускается стандартная процедура обновления/построения куба по данным warehouse (операция Process в интерфейсе SSAS).

Прокомментируем отдельные моменты технологии. Какую работу выполняют SP?

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

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

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

Конечно, возможно не копировать строки таблиц целиком, но только добавлять новые записи. Однако это создает серьезные неудобства при учете редакций ERP «задним числом», что часто встречается в реально работающих системах. Так что проще, не мудрствуя лукаво, копировать все записи (или обновлять «хвост» начиная с некоторой даты).

Далее, главная задача SP – преобразовать данные ERP-систем к формату warehouse. Если имеется только одна ERP-система, то задача преобразования в основном сводится к выкопировке и, возможно, переформатированию нужных данных. Но если в одном и том же OLAP-кубе необходимо консолидировать несколько ERP-систем разной структуры, то преобразования усложняются.

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

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

Уделим некоторое внимание архитектуре хранилища warehouse. Обычно схему OLAP-куба представляют в виде «звезды», т.е. как таблицу данных, окруженную «лучами» справочников – таблицами значений вторичных ключей. Таблица – это блок «показателей», справочники – это их разрезы. При этом справочник, в свою очередь, может быть произвольным несбалансированным деревом или сбалансированной иерархией, например, многоуровневой классификацией товаров или контрагентов. В OLAP-кубе числовые поля таблицы данных из warehouse автоматически становятся «показателями» (или измерениями measures), а посредством таблиц вторичных ключей могут быть определены разрезы (или размерности dimensions).

Это наглядное «педагогическое» описание. На самом деле архитектура OLAP-куба может быть значительно сложнее.

Во-первых, warehouse может состоять из нескольких «звездочек», возможно, связанных через общие справочники. В этом случае OLAP-куб будет объединением нескольких кубов (нескольких блоков данных).

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

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

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

MS Excel как интерфейс с OLAP

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

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

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

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

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

Еженощный цикл обработки facubi

Теперь опишем ежедневный (еженощный) вычислительный цикл эксплуатации OLAP. Расчет ведется под контролем программы facubi, написанной на C# 2005 и запускаемой посредством Task Scheduler на сервере с warehouse и SSAS. В начале facubi обращается к интернету и считывает текущие курсы валют (используются для представления ряда показателей в валюте). Далее выполняются следующие действия.

Во-первых, facubi запускает SP, выполняющие частичную репликацию баз данных различных ERP-систем (элементов холдинга), доступных в локальной сети. Репликация выполняется, как мы говорили, на заранее подготовленные «подворья» – образы удаленных ERP-систем, расположенные на сервере SSAS.

Во-вторых, посредством SP выполняется отображение из реплик ERP на хранилище warehouse – особую DB, являющуюся источником данных OLAP-куба и расположенную на сервере SSAS. При этом решаются три главные задачи:

• данные ERP подводятся под требуемые форматы куба; речь идет и о таблицах, и о полях таблиц. (Иногда требуемую таблицу нужно «вылепить», скажем, из нескольких листов MS Excel.) Аналогичные данные могут иметь разный формат в разных ERP, например, ключевые поля ID в справочниках 1С7 имеют 36-значный символьный код длиной 8, а поля _idrref в справочниках 1С8 – шестнадцатеричные числа длиной 32;
• по ходу обработки ведется логический контроль данных (в том числе прописывание «умолчаний» default на месте пропущенных данных, где это возможно) и контроль целостности, т.е. проверка наличия первичных и вторичных ключей в соответствующих классификаторах;
• консолидация кодов объектов, имеющих один и тот же смысл в разных ERP. Например, соответствующие элементы справочников разных ERP могут иметь один и тот же смысл, скажем, это один и тот же контрагент. Задача консолидации кодов решается посредством построения таблиц мэппинга, где различные коды одних и тех же объектов приводятся к единству.

В-третьих, facubi запускает стандартную процедуру обновления данных куба Process (из состава процедур утилиты SSAS).

Согласно контрольным спискам программа facubi рассылает почтовые сообщения о ходе выполнения этапов обработки.

Выполнив facubi, Task Scheduler запускает по очереди несколько файлов excel, в которых заранее созданы отчеты на базе показателей OLAP-куба. Как мы говорили, MS Excel имеет специальный программный интерфейс (отдельно загружаемый или встроенный драйвер) для работы с OLAP-кубами (с SSAS). При запуске MS Excel включаются программы на MS VBA (типа макросов), которые обеспечивают обновление данных в отчетах; отчеты при необходимости модифицируются и рассылаются по почте (программа blat) пользователям согласно контрольным спискам.

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

Оценка результатов

Мы говорили выше об асинхронности OLTP и OLAP. В рассматриваемом варианте технологии цикл обновления OLAP-куба выполняется ночью (скажем, запускается в 1 час ночи). Это означает, что в текущем рабочем дне пользователи работают со вчерашними данными. Поскольку OLAP – это не средство регистрации (посмотреть последнюю редакцию документа), а средство управления (понять тенденцию процесса), такое отставание обычно не критично. Впрочем, при необходимости даже в описанном варианте архитектуры куба (MOLAP) обновление возможно проводить несколько раз в сутки.

Время выполнения процедур обновления зависит от особенностей конструкции OLAP-куба (большей или меньшей комплексности, более или менее удачных определений показателей и разрезов) и от объема баз данных внешних OLTP-систем. По опыту процедуры построения warehouse занимают от нескольких минут до двух часов, процедура обновления куба (Process) – от 1 до 20 минут. Речь идет о комплексных OLAP-кубах, объединяющих десятки структур типа «звездочка», о десятках общих «лучей» (справочников-разрезов) для них, о сотнях показателей. Оценивая объемы баз данных внешних ERP-систем по документам отгрузки, мы говорим о сотнях тысяч документов и, соответственно, миллионах товарных строк в год. Историческая глубина обработки, интересующая пользователя, составляла три – пять лет.

Описанная технология эксплуатируется в ряде крупных корпораций: с 2008 года в «Русской рыбной компании» (РРК) и компании «Русское море» (РМ), с 2012 года в компании «Санта-Бремор» (СБ). Часть корпораций является по преимуществу торгово-закупочными фирмами (РРК), другие – производственными (заводы по переработке рыбы и морепродуктов РМ и СБ). Все корпорации являются крупными холдингами, объединяющими по несколько фирм с независимыми и различными системами компьютерного учета – начиная от стандартных ERP-систем типа 1C7 и 1C8 и заканчивая «реликтовыми» учетными системами на базе DBF и Excel. Добавлю, что описанная технология эксплуатации OLAP-кубов (без учета этапа разработки) либо вообще не требует специальных сотрудников, либо входит в круг обязанностей одного штатного бизнес-аналитика. Задача годами крутится в автоматическом режиме, ежедневно снабжая различные категории сотрудников корпораций актуальной отчетностью.

Плюсы и минусы решения

Как показывает опыт, вариант предложенного решения достаточно надежен и прост в эксплуатации. Он легко модифицируется (подключение/отключение новых ERP, создание новых показателей и разрезов, создание и модификация Excel-отчетов и списков их почтовой рассылки) при инвариантности управляющей программы facubi.

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

«Рафинированная» БД warehouse, в которой консолидировано (в ходе построения куба) несколько разнородных ERP-систем, даже без всякого OLAP позволяет решать (на сервере SSAS, методом запросов на языке Transact SQL или методом SP и др.) множество прикладных задач управления. Напомним, структура БД warehouse унифицирована и существенно проще (в плане количества таблиц и числа полей таблиц), чем структуры БД исходных ERP.

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

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

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

Технология OLTP, основанная на теории реляционных БД, была первой идеей Е. Кодда. По сути, концепция OLAP-кубов – это вторая его идея, высказанная им в начале 90-х годов. Даже не будучи математиком, вполне можно ожидать, что вторая идея окажется столь же эффективной, как первая. То есть в плане компьютерной аналитики идеи OLAP скоро захватят мир и вытеснят все другие. Просто потому, что тема аналитики находит в OLAP свое исчерпывающее математическое решение, и это решение «адекватно» (термин Б. Спинозы) практической задаче аналитики. «Адекватно» же означает у Спинозы, что и сам Бог не придумал бы лучше…

1. Ларсон Б. Разработка бизнес-аналитики в Microsoft SQL Server 2005. – СПб.: «Питер», 2008.
2. Codd E. Relational Completeness of Data Base Sublanguages, Data Base Systems, Courant Computer Science Sumposia Series 1972, v. 6, Englwood cliffs, N.Y., Prentice – Hall.

Вконтакте

Кубы данных OLAP (Online Analytical Processing - оперативный анализ данных) позволяют эффективно извлекать и анализировать многомерные данные. В отличие от других типов баз данных, базы данных OLAP разработаны специально для аналитической обработки и быстрого извлечения из них всевозможных наборов данных. На самом деле существует несколько ключевых различий между стандартными реляционными базами данных, такими как Access или SQL Server, и базами данных OLAP.

Рис. 1. Для подключения куба OLAP к книге Excel воспользуйтесь командой Из служб аналитики

Скачать заметку в формате или

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

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

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

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

Подключение к кубу данных OLAP

Чтобы получить доступ к базе данных OLAP, сначала нужно установить подключение к кубу OLAP. Начните с перехода на вкладку ленты Данные . Щелкните на кнопке Из других источников и выберите в раскрывающемся меню команду Из служб аналитики (рис. 1).

При выборе указанной команды мастера подключения к данным (рис. 2). Основная его задача - это помочь вам установить соединение с сервером, который будет использован программой Excel при управлении данными.

1. Сначала нужно предоставить Excel регистрационную информацию. Введите в полях диалогового окна имя сервера, регистрационное имя и пароль доступа к данным, как показано на рис. 2. Щелкните на кнопке Далее . Если вы подключаетесь с помощью учетной записи Windows, то установите переключатель Использовать проверку подлинности Windows .

2. Выберите в раскрывающемся списке базу данных, с которой будете работать (рис. 3). В текущем примере используется база данных Analysis Services Tutorial. После выбора этой базы данных в расположенном ниже списке предлагается импортировать все доступные в ней кубы OLAP. Выберите необходимый куб данных и щелкните на кнопке Далее .

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

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

Рис. 4. Измените описательную информацию о соединении

4. Щелкните на кнопке Готово , чтобы завершить создание подключения. На экране появится диалоговое окно Импорт данных (рис. 5). Установите переключатель Отчет сводной таблицы и щелкните на кнопке ОК, чтобы начать создание сводной таблицы.

Структура куба OLAP

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

Как видите, основные компоненты куба OLAP – это размерности, иерархии, уровни, члены и меры:

• Размерности . Основная характеристика анализируемых элементов данных. К наиболее общим примерам размерностей относятся Products (Товары), Customer (Покупатель) и Employee (Сотрудник). На рис. 6 показана структура размерности Products.
• Иерархии . Заранее определенная агрегация уровней в указанной размерности. Иерархия позволяет создавать сводные данные и анализировать их на различных уровнях структуры, не вникая во взаимосвязи, существующие между этими уровнями. В примере, показанном на рис. 6, размерность Products имеет три уровня, которые агрегированы в единую иерархию Product Categories (Категории товаров).
• Уровни . Уровни представляют собой категории, которые агрегируются в общую иерархию. Считайте уровни полями данных, которые можно запрашивать и анализировать отдельно друг от друга. На рис. 6 представлены всего три уровня: Category (Категория), SubCategory (Подкатегория) и Product Name (Название товара).
• Члены . Отдельный элемент данных в пределах размерности. Доступ к членам обычно реализуется через OLАР-структуру размерностей, иерархий и уровней. В примере на рис. 6 члены заданы для уровня Product Name. Другие уровни имеют свои члены, которые в структуре не показаны.
• ­Меры - это реальные данные в кубах OLAP. Меры сохраняются в собственных размерностях, которые называются размерностями мер. С помощью произвольной комбинации размерностей, иерархий, уровней и членов можно запрашивать меры. Подобная процедура называется «нарезкой» мер.

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

В списке полей сводной таблицы OLAP меры выводятся первыми и обозначаются значком суммирования (сигма). Это единственные элементы данных, которые могут находиться в области ЗНАЧЕНИЯ. После них в списке указываются размерности, обозначенные значком с изображением таблицы. В нашем примере используется размерность Customer. В эту размерность вложен ряд иерархий. После развертывания иерархии можно ознакомиться с отдельными уровнями данных. Для просмотра структуры данных куба OLAP достаточно перемещаться по списку полей сводной таблицы.

Ограничения, накладываемые на сводные таблицы OLAP

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

• нельзя поместить в область ЗНАЧЕНИЯ сводной таблицы поля, отличные от мер;
• невозможно изменить функцию, применяемую для подведения итогов;
• нельзя создать вычисляемое поле или вычисляемый элемент;
• любые изменения в именах полей отменяются сразу же после удаления этого поля из сводной таблицы;
• не допускается изменение параметров поля страницы;
• недоступна команда Показать страницы ;
• отключен параметр Показывать подписи элементов при отсутствии полей в области значений;
• отключен параметр Промежуточные суммы по отобранным фильтром элементам страницы;
• недоступен параметр Фоновый запрос ;
• после двойного щелчка в поле ЗНАЧЕНИЯ возвращаются только первые 1000 записей из кеша сводной таблицы;
• недоступен флажок Оптимизировать память .

Создание автономных кубов данных

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

Если все же нужно анализировать OLAP-данные при отсутствии подключения к сети, создайте автономный куб данных. Это отдельный файл, который представляет собой кеш сводной таблицы. В этом файле хранятся OLAP-данные, просматриваемые после отключения от локальной сети. Чтобы создать автономный куб данных, сначала создайте сводную таблицу OLAP. Поместите курсор в сводную таблицу и щелкните на кнопке Средства OLAP контекстной вкладки Анализ, входящей в набор контекстных вкладок Работа со сводными таблицами . Выберите команду Автономный режим OLAP (рис. 8).

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

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

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

Укажите расположение и имя куба данных (рис. 12). Файлы кубов данных имеют расширение.cub.

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

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

Применение функций куба данных в сводных таблицах

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

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

Поместите курсор в любом месте сводной таблицы, щелкните на кнопке Средства OLAP контекстной вкладки ленты Анализ и выберите команду Преобразовать в формулы (рис. 14).

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

Спустя несколько секунд вместо сводной таблицы отобразятся формулы, которые выполняются в кубах данных и обеспечивают вывод в окне Excel необходимой информации. Обратите внимание на то, что при этом удаляются ранее примененные стили (рис. 16).

Рис. 16. Взгляните на строку формул: в ячейках содержатся формулы куба данных

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

Добавление вычислений в сводные таблицы OLAP

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

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

Знакомство с MDX. При использовании сводной таблицы вместе с кубом OLAP вы отсылаете базе данных запросы MDX (Multidimensional Expressions - многомерные выражения). MDX - это язык запросов, применяемый для получения данных из многомерных источников (например, из кубов OLAP). В случае изменения или обновления сводной таблицы OLAP соответствующие запросы MDX передаются базе данных OLAP. Результаты выполнения запроса возвращаются обратно в Excel и отображаются в области сводной таблицы. Таким образом обеспечивается возможность работы с данными OLAP без локальной копии кеша сводных таблиц.

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

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

Анализ Работа со сводными таблицами . В раскрывающемся меню Средства OLAP выберите пункт (рис. 18).

Рис. 18. Выберите пункт меню Вычисляемая мера многомерного выражения

На экране появится диалоговое окно Создание вычисляемой меры (рис. 19).

Выполните следующие действия:

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

3. В поле Многомерное выражение (MDX) введите код, задающий новую меру. Чтобы ускорить процесс ввода, воспользуйтесь находящимся слева списком для выбора существующих мер, которые будут использованы в вычислениях. Дважды щелкните на нужной мере, чтобы добавить ее в поле Многомерное выражение. Для вычисления средней цены продажи единицы товара используется следующее многомерное выражение:

4. Кликните ОК.

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

После завершения создания новой вычисляемой меры перейдите в список Поля сводной таблицы и выберите ее (рис. 20).

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

Создание вычисляемых элементов многомерных выражений. Вычисляемый элемент многомерного выражения представляет собой OLAP-версию обычного вычисляемого элемента. Идея заключается в создании нового элемента данных, основанного на некоторых математических операциях, выполняемых по отношению к существующим элементам OLAP. В примере, показанном на рис. 22, используется сводная таблица OLAP, включающая сведения о продажах за 2005–2008 годы (с поквартальной разбивкой). Предположим, нужно выполнить агрегирование данных, относящихся к первому и второму кварталам, создав новый элемент First Half of Year (Первая половина года). Также объединим данные, относящиеся к третьему и четвертому кварталам, сформировав новый элемент Second Half of Year (Вторая половина года).

Рис. 22. Мы собираемся добавить новые вычисляемые элементы многомерных выражений, First Half of Year и Second Half of Year

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

На экране появится диалоговое окно (рис. 24).

Рис. 24. Окно Создание вычисляемого элемента

Выполните следующие действия:

1. Присвойте вычисляемой мере имя.

2. Выберите родительскую иерархию, для которой создаются новые вычисляемые элементы. Настройке Родительский элемент присвойте значение Все . Благодаря этой настройке Excel получает доступ ко всем элементам родительской иерархии при вычислении выражения.

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

..&& +

.. && +

.. && + …

4. Щелкните ОК. Excel отобразит только что созданный вычисляемый элемент многомерного выражения в сводной таблице. Как показано на рис. 25, новый вычисляемый элемент отображается вместе с другими вычисляемыми элементами сводной таблицы.

На рис. 26 иллюстрируется аналогичный процесс, применяемый для создания вычисляемого элемента Second Half of Year.

Обратите внимание: Excel даже не пытается удалить исходные элементы многомерного выражения (рис. 27). В сводной таблице по-прежнему отображаются записи, соответствующие 2005–2008 годам с поквартальной разбивкой. В рассматриваемом случае это не страшно, но в большинстве сценариев следует скрывать «лишние» элементы во избежание появления конфликтов.

Рис. 27. Excel отображает созданный вычисляемый элемент многомерного выражения наравне с исходными элементами. Но все же лучше удалять исходные элементы во избежание конфликтов

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

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

Управление вычислениями OLAP. В Excel поддерживается интерфейс, позволяющий управлять вычисляемыми мерами и элементами многомерных выражений в сводных таблицах OLAP. Поместите курсор в любом месте сводной таблицы и выберите контекстную вкладку Анализ из набора контекстных вкладок Работа со сводными таблицами . В раскрывающемся меню Средства OLAP выберите пункт Управление вычислениями . В окне Управления вычислениями доступны три кнопки (рис. 28):

• Создать. Создание новой вычисляемой меры или вычисляемого элемента многомерного выражения.
• Изменить. Изменение выбранного вычисления.
• Удалить. Удаление выделенного вычисления.

Рис. 28. Диалоговое окне Управление вычислениями

Выполнение анализа «что, если» по данным OLAP. В Excel 2013 можно выполнять анализ «что, если» для данных, находящихся в сводных таблицах OLAP. Благодаря этой новой возможности можно изменять значения в сводной таблице и повторно вычислять меры и элементы на основании внесенных изменений. Можно также распространить изменения обратно на куб OLAP. Чтобы воспользоваться возможностями анализа «что, если», создайте сводную таблицу OLAP и выберите контекстную вкладку Анализ Работа со сводными таблицами . В раскрывающемся меню Средства OLAP выберите команду Анализ «что, если» –> Включить анализ «что, если» (рис. 29).

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

Рис. 30. Выберите пункт Учесть изменение при расчете сводной таблицы , чтобы внести изменения в сводную таблицу

По умолчанию правки, внесенные в сводную таблицу в режиме анализа «что, если», являются локальными. Если же вы хотите распространить изменения на сервер OLAP, выберите команду для публикации изменений. Выберите контекстную вкладку Анализ , находящуюся в наборе контекстных вкладок Работа со сводными таблицами . В раскрывающемся меню Средства OLAP выберите пункты Анализ «что, если» – > Опубликовать изменения (рис. 31). В результате выполнения этой команды включится «обратная запись» на сервере OLAP, что означает возможность распространения изменений на исходный куб OLAP. (Чтобы распространять изменения на сервер OLAP, нужно обладать соответствующими разрешениями на доступ к серверу. Обратитесь к администратору баз данных, который поможет вам получить разрешения на доступ в режиме записи к базе данных OLAP.)

Заметка написана на основе книги Джелен, Александер. . Глава 9.

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

Что такое хранилище данных?

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

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

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

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

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

Как строят хранилище?

ETL – базовое понятие: Три этапа:

• Извлечение – извлечение данных из внешних источников в понятном формате;
• Преобразование – преобразование структуры исходных данных в структуры, удобные для построения аналитической системы;

Добавим еще один этап – очистка данных (Cleaning ) – процесс отсеивания несущественных или исправления ошибочных данных на основании статистических или экспертных методов. Чтобы не формировать потом отчеты типа «Продажи за 20011 год».

Вернемся к анализу.

Что такое анализ и для чего он нужен?

Анализ – исследование данных с целью принятия решений. Аналитические системы так и называют - системы поддержки принятия решений (СППР ).

Здесь стоит указать на отличие работы с СППР от простого набора регламентированных и нерегламентированных отчетов. Анализ в СППР практически всегда интерактивен и итеративен. Т.е. аналитик копается в данных, составляя и корректируя аналитические запросы, и получает отчеты, структура которых заранее может быть неизвестна. Более подробно к этому мы вернемся ниже, когда будем обсуждать язык запросов MDX .

OLAP

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

Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing). OLAP - это ключевой компонент организации традиционных хранилищ данных. Концепция OLAP была описана в 1993 году Эдгаром Коддом , известным исследователем баз данных и автором реляционной модели данных. В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information - быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям для многомерного анализа:

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

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

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

Многомерные понятия

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

Куб

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

• Дата Заказа
• Страна
• Город
• Название заказчика
• Компания-доставщик
• Название товара
• Количество товара
• Сумма заказа

Какие агрегатные данные мы можем получить на основе этого представления? Обычно это ответы на вопросы типа:

• Какова суммарная стоимость заказов, сделанных клиентами из определенной страны?
• Какова суммарная стоимость заказов, сделанных клиентами из определенной страны и доставленных определенной компанией?
• Какова суммарная стоимость заказов, сделанных клиентами из определенной страны в заданном году и доставленных определенной компанией?

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

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

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

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

Очевидно, что максимальное количество измерений – это количество всех атрибутов (Дата, Страна, Заказчик и т.д.), описывающих наши агрегируемые данные (сумму заказов, количество товаров и т.п).

Так мы приходим к понятию многомерности и его воплощению – многомерному кубу . Такая таблица будет у нас называться «таблицей фактов ». Измерения или Оси куба (dimensions ) – это атрибуты, координаты которых – выражаются индивидуальными значениями этих атрибутов, присутствующих в таблице фактов. Т.е. например, если информация о заказах велась в системе с 2003 по 2010 год, то эта ось годов будет состоять из 8 соответствующих точек. Если заказы приходят из трех стран, то ось стран будет содержать 3 точки и т.д. Независимо от того, сколько стран заложено в справочнике Стран. Точки на оси называются ее «членами» (Members ).

Сами агрегируемые данные в данном случае буду назваться «мерами» (Measure ). Чтобы избежать путаницы с «измерениями», последние предпочтительней называть «осями». Набор мер образует еще одну ось «Меры» (Measures ). В ней столько членов (точек), сколько мер (агрегируемых столбцов) в таблице фактов.

Члены измерений или осей могут быть объединены одной или несколькими иерархиями (hierarchy ). Что такое иерархия, поясним на примере: города из заказов могут быть объединены в районы, районы в области, области страны, страны в континенты или другие образования. Т.е. налицо иерархическая структура – континент-страна-область-район-город – 5 уровней (Level ). Для района данные агрегируются по всем городам, которые в него входят. Для области по всем районам, которые содержат все города и т.п. Зачем нужно несколько иерархий? Например, по оси с датой заказа мы можем хотеть группировать точки (т.е. дни) по иерархии Год-Месяц-День или по Год-Неделя-День : в обоих случаях по три уровня. Очевидно, что Неделя и Месяц по-разному группируют дни. Бывают также иерархии, количество уровней в которых не детерминировано и зависит от данных. Например, папки на компьютерном диске.

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

MDX

Перейдем к языку запросов в многомерных данных.
Язык SQL изначально был спроектирован не для программистов, а для аналитиков (и поэтому имеет синтаксис, напоминающий естественный язык). Но он со временем все больше усложнялся и теперь мало кто из аналитиков хорошо умеет им пользоваться, если умеет вообще. Он стал инструментом программистов. Язык запросов MDX, разработанный по слухам нашим бывшим соотечественником Мойшей (или Мошей) Посуманским (Mosha Pasumansky) в дебрях корпорации Майкрософт, тоже изначально должен был ориентирован на аналитиков, но его концепции и синтаксис (который отдаленно напоминает SQL, причем совершенно зря, т.к. это только путает), еще сложнее чем SQL. Тем не менее его основы все же понять несложно.

Мы рассмотрим его подробно потому что это единственный язык, который получил статус стандартного в рамках общего стандарта протокола XMLA , а во вторых потому что существует его open-source реализация в виде проекта Mondrian от компании Pentaho . Другие системы OLAP-анализа (например, Oracle OLAP Option) обычно используют свои расширения синтаксиса языка SQL, впрочем, декларируют поддержку и MDX.

Работа с аналитическими массивами данных подразумевает только их чтение и не подразумевает запись. Т.о. в языке MDX нет предложений для изменения данных, а есть только одно предложение выборки - select.

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

Select ...Children on rows from
Что здесь что?

Select – ключевое слово и в синтаксис входит исключительно для красоты.
– это название оси. Все имена собственные в MDX пишутся в квадратных скобках.
– это название иерархии. В нашем случае – это иерархия Страна-Город
– это название члена оси на первом уровне иерархии (т.е. страны) All – это мета-член, объединяющий все члены оси. Такой мета-член есть в каждой оси. Например в оси годов есть «Все года» и т.п.
Children – это функция члена. У каждого члена есть несколько доступных функций. Таких как Parent. Level, Hierarchy, возвращающие соответственно предка, уровень в иерархии и саму иерархию, к которой относится в данном случае член. Children – возвращает набор членов-потомков данного члена. Т.е. в нашем случае – страны.
on rows – Указывает как расположить эти данные в итоговой таблице. В данном случае – в заголовке строк. Возможные значении здесь: on columns, on pages, on paragraphs и т.п. Возможно так же указание просто по индексам, начиная с 0.
from – это указание куба, из которого производится выборка.

Что если нам не нужны все страны, а нужно только пара конкретных? Для этого можно в запросе указать явно те страны которые нам нужны, а не выбирать все функцией Children.

Select { ..., ... } on rows from
Фигурные скобки в данном случае – обявление набора (Set ). Набор – это список, перечисление членов из одной оси .

Теперь напишем запрос для нашего второго примера – вывод в разрезе доставщика:

Select ...Children on rows .Members on columns from
Здесь добавилось:
– ось;
.Members – функция оси, которая возвращает все члены на ней. Такая же функция есть и у иерархии и у уровня. Т.к. в данной оси иерархия одна, то ее указание можно опустить, т.к. уровень и иерархии тоже один, то можно выводить все члены одним списком.

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

Select ..Children on rows .Members on columns from where (.)
А где же тут фильтрация?

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

Почему член даты в скобках? Круглые скобки – это кортеж (tuple ). Кортеж – это один или несколько координат по различным осям. Например для фильтрации сразу по двум осям в круглых скобках мы перечислим два члена из разных измерений через запятую. Т. е. кортеж определяет «срез» куба (или «фильтрацию», если такая терминология ближе).

Кортеж используется не только для фильтрации. Кортежи могут быть и в заголовках строк/колонок/страниц и т.п.

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

Select crossjoin(...Children, ..Children) on rows .Members on columns from where (.)
Crossjoin – это функция. Она возвращает набор (set) кортежей (да, набор может содержать кортежи!), полученный в результате декартового произведения двух наборов. Т.е. результирующий набор будет содержать все возможные сочетания Стран и Годов. Заголовки строк, таким образом, будут содержать пару значений: Страна-Год .

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

Вопрос: чем отличается фильтрация в where от фильтрации путем указания членов осей в on rows. Ответ: практически ничем. Просто в where указывается срез для тех осей, которые не участвуют в формировании заголовков. Т.е. одна и та же ось не может одновременно присутствовать и в on rows , и в where .

Вычисляемые члены

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

With member . as ‘.CurrentMember / ..’, FORMAT_STRING=‘0.00%’ select ...Children on rows from where .
Вычисление происходит в контексте ячейки, у которой известные все ее атрибуты-координаты. Соответствующие координаты (члены) могут быть получены функцией CurrentMember у каждой из осей куба. Здесь надо понимать, что выражение .CurrentMember / .. ’ не делит один член на другой, а делит соответствующие агрегированный данные срезов куба! Т.е. срез по текущей территории разделится на срез по всем территориям, т.е. суммарное значение всех заказов. FORMAT_STRING – задает формат вывода значений, т.е. %.

Другой пример вычисляемого члена, но уже по оси годов:

With member . as ‘. - .’
Очевидно, что в отчете будет не единица, а разность соответствующих срезов, т.е. разность суммы заказов в эти два года.

Отображение в ROLAP

Системы OLAP так или иначе базируются на какой-нибудь системе хранения и организации данных. Когда речь идет о РСУБД, то говорят о ROLAP (MOLAP и HOLAP оставим для самостоятельного изучения). ROLAP – OLAP на реляционной БД, т.е. описанная в виде обычных двумерных таблиц. Системы ROLAP преобразуют MDX запросы в SQL. Основная вычислительная проблема для БД – быстрая агрегация. Чтобы быстрее агрегировать, данные в БД как правило сильно денормализованы, т.е. хранятся не очень эффективно с точки зрения занимаемого места на диске и контроля целостности БД. Плюс дополнительно содержат вспомогательные таблицы, хранящие частично агрегированные данные. Поэтому для OLAP обычно создается отдельная схема БД, которая лишь частично повторяет структуру исходных транзакционных БД в части справочников.

Навигация

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

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

• drill-down – фильтрация по одной из исходных осей отчета с выводом детальной информации по потомкам в рамках иерархии выбранного фильтрующего члена. Например, если имеется отчет по распределению заказов в разрезе Стран и Годов, то при щелчке на 2007-м году выведется отчет в разрезе тех же Стран и месяцев 2007 года.
• drill-aside – фильтрация под одной или нескольким выбранным осям и снятие агрегации по одной или нескольким другим осям. Например, если имеется отчет по распределению заказов в разрезе Стран и Годов, то при щелчке на 2007-м году выведется другой отчет в разрезе, например, Стран и Поставщиков с фильтрацией по 2007 году.
• drill-trough – снятие агрегации по всем осям и одновременная фильтрация по ним же – позволяет увидеть исходные данные из таблицы фактов, из которых получено значение в отчете. Т.е. при щелчке по значению ячейки выводится отчет со всеми заказами, которые дали эту сумму. Эдакое мгновенное бурение в самые «недра» куба.

На этом все. Теперь, если вы решили посвятить себя Business Intelligence и OLAP самое время приступать к чтению серьезной литературы.

Теги: Добавить метки

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

Цель лекции

Изучив материал настоящей лекции, вы будете знать:

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

и научитесь:

• строить многомерные диаграммы ;
• проектировать простые многомерные диаграммы .

Введение

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

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

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

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

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

Таким образом, OLAP можно определить как совокупность средств многомерного анализа данных, накопленных в ХД . Теоретически средства OLAP можно применять и непосредственно к оперативным данным или их точным копиям. Однако при этом существует риск подвергнуть анализу данные, которые для этого анализа не пригодны.

OLAP на клиенте и на сервере

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

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

Если исходные данные содержатся в настольной СУБД , вычисление агрегатных данных производится самим OLAP -средством. Если же источник исходных данных - серверная СУБД , многие из клиентских OLAP -средств посылают на сервер SQL -запросы, содержащие оператор GROUP BY , и в результате получают агрегатные данные, вычисленные на сервере.

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

Многие средства разработки содержат библиотеки классов или компонентов, позволяющие создавать приложения, реализующие простейшую OLAP -функциональность (такие, например, как компоненты Decision Cube в Borland Delphi и Borland C++Builder). Помимо этого многие компании предлагают элементы управления ActiveX и другие библиотеки, реализующие подобную функциональность.

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

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

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

Преимущества применения серверных OLAP -средств по сравнению с клиентскими OLAP -средствами сходны с преимуществами применения серверных СУБД по сравнению с настольными: в случае применения серверных средств вычисление и хранение агрегатных данных происходит на сервере, а клиентское приложение получает лишь результаты запросов к ним, что позволяет в общем случае снизить сетевой трафик, время выполнения запросов и требования к ресурсам, потребляемым клиентским приложением. Отметим, что средства анализа и обработка данных масштаба предприятия, как правило, базируются именно на серверных OLAP -средствах, например, таких как Oracle Express Server , Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, продуктах компаний Crystal Decisions, Business Objects, Cognos, SAS Institute. Поскольку все ведущие производители серверных СУБД производят (либо лицензировали у других компаний) те или иные серверные OLAP -средства, выбор их достаточно широк, и почти во всех случаях можно приобрести OLAP - сервер того же производителя, что и у самого сервера баз данных.

Отметим, что многие клиентские OLAP -средства (в частности, Microsoft Excel 2003, Seagate Analysis и др.) позволяют обращаться к серверным OLAP-хранилищам , выступая в этом случае в роли клиентских приложений, выполняющих подобные запросы. Помимо этого имеется немало продуктов, представляющих собой клиентские приложения к OLAP -средствам различных производителей.

Технические аспекты многомерного хранения данных

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

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

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

• MOLAP ( Multidimensional OLAP) - исходные и агрегатные данные хранятся в многомерной базе данных. Хранение данных в многомерных структурах позволяет манипулировать данными как многомерным массивом, благодаря чему скорость вычисления агрегатных значений одинакова для любого из измерений . Однако в этом случае многомерная база данных оказывается избыточной, так как многомерные данные полностью содержат исходные реляционные данные.
• ROLAP (Relational OLAP) - исходные данные остаются в той же реляционной базе данных, где они изначально и находились. Агрегатные же данные помещают в специально созданные для их хранения служебные таблицы в той же базе данных.
• HOLAP ( Hybrid OLAP) - исходные данные остаются в той же реляционной базе данных, где они изначально находились, а агрегатные данные хранятся в многомерной базе данных.

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

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

Основные понятия OLAP

Тест FAMSI

Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing). OLAP - это ключевой компонент организации ХД. Концепция OLAP была описана в 1993 году Эдгаром Коддом, известным исследователем баз данных и автором реляционной модели данных. В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information) - быстрый анализ разделяемой многомерной информации, включающий следующие требования к приложениям для многомерного анализа :

• Fast (Быстрый) - предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа;
• Analysis (Анализ) - возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде;
• Shared (Разделяемый) - многопользовательский доступ к данным с поддержкой соответствующих механизмов блокировок и средств авторизованного доступа;
• Multidimensional (Многомерный) - многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это ключевое требование OLAP);
• Information (Информация) - приложение должно иметь возможность обращаться к любой нужной информации, независимо от ее объема и места хранения.

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

Многомерное представление информации

Кубы

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

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

Рис. 26.1.

"Разрезание" куба

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

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

(levels). Например, метки, представленная на поддерживаются далеко не всеми OLAP-средствами. Например, в Microsoft Analysis Services 2000 поддерживаются оба типа иерархии , а в Microsoft OLAP Services 7.0 - только сбалансированные. Различными в разных OLAP-средствах могут быть и число уровней иерархии , и максимально допустимое число членов одного уровня, и максимально возможное число самих измерений .

Архитектура OLAP-приложений

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

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

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

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

Конкретные OLAP-продукты, как правило, представляют собой либо средство многомерного представления данных (OLAP-клиент - например, Pivot Tables в Excel 2000 фирмы Microsoft или ProClarity фирмы Knosys), либо многомерную серверную СУБД (OLAP-сервер - например, Oracle Express Server или Microsoft OLAP Services).

Слой многомерной обработки обычно бывает встроен в OLAP-клиент и/или в OLAP-сервер, но может быть выделен в чистом виде, как, например, компонент Pivot Table Service фирмы Microsoft.

В предыдущей статье данного цикла (см. № 2’2005) мы рассказали об основных новшествах аналитических служб SQL Server 2005. Сегодня мы подробнее рассмотрим средства создания OLAP-решений, входящие в этот продукт.

Коротко об основах OLAP

режде чем начать разговор о средствах создания OLAP-решений, напомним, что OLAP (On-Line Analytical Processing) — это технология комплексного многомерного анализа данных, концепция которой была описана в 1993 году Э.Ф.Коддом, знаменитым автором реляционной модели данных. В настоящее время поддержка OLAP реализована во многих СУБД и иных инструментах.

OLAP-кубы

Что представляют собой OLAP-данные? В качестве ответа на этот вопрос рассмотрим простейший пример. Предположим, в корпоративной базе данных некоего предприятия имеется набор таблиц, содержащих сведения о продажах товаров или услуг, и на их основе создано представление Invoices с полями Country (страна), City (город), CustomerName (название компании-клиента), Salesperson (менеджер по продажам), OrderDate (дата размещения заказа), CategoryName (категория товара), ProductName (наименование товара), ShipperName (компания-перевозчик), ExtendedPrice (оплата за товар), при этом последнее из перечисленных полей, собственно, и является объектом анализа.

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

SELECT Country, City, CustomerName, Salesperson,

OrderDate, CategoryName, ProductName, ShipperName, ExtendedPrice

FROM Invoices

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

SELECT Country, SUM (ExtendedPrice) FROM Invoices

GROUP BY Country

Результатом этого запроса будет одномерный набор агрегатных данных (в данном случае — сумм):

Country	SUM (ExtendedPrice)
Argentina	7327.3
Austria	110788.4
Belgium	28491.65
Brazil	97407.74
Canada	46190.1
Denmark	28392.32
Finland	15296.35
France	69185.48
	209373.6
	...

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

SELECT Country, ShipperName, SUM (ExtendedPrice) FROM Invoices

GROUP BY COUNTRY, ShipperName

Исходя из результатов этого запроса можно создать таблицу следующего вида:

Такой набор данных называется сводной таблицей (pivot table).

SELECT Country, ShipperName, SalesPerson SUM (ExtendedPrice) FROM Invoices

GROUP BY COUNTRY, ShipperName, Year

На основании результатов этого запроса можно построить трехмерный куб (рис. 1).

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

Иерархии в измерениях

Предположим, нас интересует не только суммарная стоимость заказов, сделанных клиентами в разных странах, но и суммарная стоимость заказов, сделанных клиентами в разных городах одной страны. В этом случае можно воспользоваться тем, что значения, наносимые на оси, имеют различные уровни детализации — это описывается в рамках концепции иерархии изменений. Скажем, на первом уровне иерархии располагаются страны, на втором — города. Отметим, что начиная с SQL Server 2000 аналитические службы поддерживают так называемые несбалансированные иерархии, содержащие, например, такие члены, «дети» которых содержатся не на соседних уровнях иерархии или отсутствуют для некоторых членов изменения. Типичный пример подобной иерархии — учет того факта, что в разных странах могут существовать, либо отсутствовать такие административно-территориальные единицы, как штат или область, размещающиеся в географической иерархии между странами и городами (рис. 2).

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

Создание OLAP-кубов в SQL Server 2005

SQL Server 2005 кубы создаются с помощью SQL Server Business Intelligence Development Studio. Этот инструмент представляет собой специальную версию Visual Studio 2005, предназначенную для решения данного класса задач (а при наличии уже установленной среды разработки список шаблонов проектов пополняется проектами, предназначенными для создания решений на основе SQL Sever и его аналитических служб). В частности, для создания решений на основе аналитических служб предназначен шаблон Analysis Services Project (рис. 3).

Для создания OLAP-куба в первую очередь следует решить, на основе каких данных его формировать. Наиболее часто OLAP-кубы строятся на основе реляционных хранилищ данных со схемами «звезда» или «снежинка» (о них мы рассказывали в предыдущей части статьи). В комплекте поставки SQL имеется пример такого хранилища — база данных AdventureWorksDW, для использования которой в качестве источника следует найти в Solution Explorer папку Data Sources, выбрать пункт контекстного меню New Data Source и последовательно ответить на вопросы соответствующего мастера (рис. 4).

Затем рекомендуется создать Data Source View — представление, на основе которого будет создаваться куб. Для этого необходимо выбрать соответствующий пункт контекстного меню папки Data Source Views и последовательно ответить на вопросы мастера. Результатом указанных действий станет схема данных, с помощью которых будет построено представление источников данных, при этом в полученной схеме вместо исходных можно указать «дружественные» имена таблиц (рис. 5).

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

При создании кубов в настоящее время используются многие особенности новой версии SQL Server, такие, например, как представление источников данных. Описание исходных данных для построения куба, равно как и описание структуры куба, теперь производится с помощью знакомого многим разработчикам инструмента Visual Studio, что является немалым достоинством новой версии этого продукта — изучение разработчиками аналитических решений нового инструментария в этом случае сведено к минимуму.

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

Рис. 8. Добавление вычисляемого атрибута

Кроме того, в кубах SQL Server 2005 можно осуществлять автоматическую группировку или сортировку членов измерения по значению атрибута, определять связи между атрибутами, реализовывать связи «многие ко многим», определять ключевые показатели бизнеса, а также решать многие другие задачи (подробности о том, как выполняются все эти действия, можно найти в разделе SQL Server Analysis Services Tutorial справочной системы данного продукта).

В последующих частях данной публикации мы продолжим знакомство с аналитическими службами SQL Server 2005 и выясним, что нового появилось в области поддержки Data Mining.