Сначала повторим общеизвестное определение OLAP. OLAP (On Line Analytical Processing) - процесс оперативного анализа - это класс программного обеспечения, предоставляющий пользователю возможность мгновенно, в режиме реального времени получать ответы на произвольные аналитические запросы.
Так сложилось, что не любые программы, которые быстро выполняют произвольные запросы, расчеты и выдают пользователю данные в понятном ему виде принято считать OLAP-средством. К классу OLAP относят только те программы, которые в качестве внешнего интерфейса предоставляют пользователю многомерную управляемую таблицу. Эта таблица позволяет пользователю менять местами колонки и строки, закрывать и раскрывать - описательные колонки, задавать условия фильтрации и при этом она автоматически вычисляет промежуточные в группах данных и окончательные итоги по - цифровым колонкам. Неотъемлемой частью OLAP-анализа является графическое отображение данных.
Программы, реализующие эту методику, делятся на следующие категории:
Любое конечное решение содержит OLAP-компоненту, которая является интерфейсом пользователя. Эти компоненты похожи друг на друга. Их визуальная часть состоит из элементов управления и элементов отображения данных. Как правило, это таблица, в полях которой содержаться данные, а колонки и строки являются элементами управления.
Подавляющее большинство поставщиков OLAP, а их в мире насчитывается около 140, не продают свои компоненты. Нам известно только три компоненты, которые можно купить для собственной разработки. Это Decision Cube компании Inprise в составе компиляторов Delphi и C++ Builder, Pivot Table корпорации Microsoft в составе MS Office, и Dynamic Cube компании Data Dynamic, специализирующейся на разработке OLAP-компонент.
Decision Cube компании Inprise поставляется как VCL-компонента. По нашей классификации относится к ROLAP-компонентам, то есть содержит в своем составе OLAP-машину и предназначен только для работы с реляционными СУБД или локальными таблицами. Он отличается весьма скромными возможностями. Например, в нем нельзя открыть один элемент измерения, или установить фильтр по нескольким измерениям, отобразить несколько фактов одновременно. Производительность компоненты невысока. Пределом является около 4000 записей при 5 измерениях. Компонента отображает в таблице одновременно только один факт. Неприятной особенностью является наличие в исходных текстах нескольких ошибок, в результате чего только высококвалифицированные программисты после исправления этих ошибок могут использовать компоненту в своих разработках. К достоинствам можно отнести простоту применения и освоения компоненты. При правильном использовании и небольших объемах данных продукты на базе этой компоненты могут оказаться полезными и приемлемыми по быстродействию.
Pivot Table корпорации Microsoft поставляется в двух вариантах: как составная часть MS Excel и как Web-компонента. Web-компонента (ActiveX) может быть использована как в браузере, так и собственном Windows-приложении. Pivot Table является одновременно и MOLAP- и ROLAP-компонентой. По протоколу OLE DB for OLAP он может взаимодействовать с многомерной СУБД MS OLAP Server, или другими 70-ю многомерными СУБД, разработчики которых поддержали этот протокол. По протоколу OLE DB Pivot Table может получать данные от реляционной СУБД и выполнять вычисления кубов в памяти. И конечно данные могут быть получены из заданной области таблицы MS Excel. В этом случае его производительность не отличается от производительности Decision Cube. Компонента отображает в таблице одновременно только один факт. Однако инструментарий компоненты шире, чем у Decision Cube - реализована произвольная фильтрация и раскрытие одного элемента измерения. Основным назначением компоненты является создание интерфейсов к OLAP-серверу в рамках концепции Business Intelligent корпорации Microsoft.
Dynamic Cube компании Data Dynamic является классической ROLAP-компонентой. Он поставляется как VCL для программистов Delphi и C++ Builder и как COM для приверженцев компонентной модели. OLAP- машина компоненты весьма мощна. Она с легкостью обрабатывает десятки и чуть медленнее даже сотни тысяч записей. Есть множественная фильтрация, открытие элемента одного измерения, некоторые дополнительные функции. Компонента позволяет отображать в таблице одновременно несколько фактов. Однако эта компонента довольно дорога, особенно впечатляет ее стоимость для профессиональных разработчиков.
Все три описанные выше компоненты по сравнению с готовыми продуктами многих поставщиков имеют весьма скупую функциональность, ограничивающуюся классическими функциями OLAP: drill down, move, rotate и пр. В то же время в некоторых готовых продуктах часто встречается инструментальная панель, наполненная кнопками дополнительных удобных функций. Таких как, и даже кнопками, выполняющими популярные аналитические задачи, например классический маркетинговый анализ 20/80.
Еще недавно поставщики OLAP-серверов продавали свои продукты по таким ценам, что их покупатели должны были быть богаты как арабские шейхи. Так, приобретение Oracle Express обошлось бы в $100 000 за рабочие места двух аналитиков и двух администраторов. Но, даже после выхода на рынок компании Microsoft, которая обрушила цены, предоставив OLAP-сервер бесплатно в составе MS SQL Server, создание Хранилищ данных или витрин данных остается серьезным мероприятием, требующим привлечения профессионального разработчика, администрирования в процессе эксплуатации и других расходов.
Поэтому на рынке появился особый класс продуктов - DOLAP (Desktop OLAP) - настольный OLAP. Это программа, которая устанавливается на каждый персональный компьютер. Она не требует сервера, имеет "нулевое администрирование". Программа позволяет пользователю настроиться на существующие у него базы данных; как правило, при этом создается словарь, скрывающий физическую структуру данных за ее предметным описанием, понятным специалисту. После этого программа выполняет произвольные запросы и результаты их отображает в OLAP-таблице. В этой таблице, в свою очередь, пользователь может манипулировать данными и получать на экране или на бумаге сотни различных отчетов.
По способу получения данных такие программы можно разделить на локальные и корпоративные:
Корпоративные DOLAP, предназначенные для анализа данных SQL-серверов позволяют анализировать уже имеющиеся в корпорации данные, хранящиеся в OLTP-системах. Однако вторым их назначением может быть быстрое и дешевое создание Хранилищ или витрин данных, когда программистам организации требуется лишь создать совокупности таблиц типа "звезда" и процедуры загрузки данных. Наиболее трудоемкая часть работы - разработка интерфейсов с многочисленными вариантами пользовательских запросов, интерфейсов и отчетов становится ненужной. Это буквально за несколько часов реализуется в DOLAP-программе. Освоение же такой программы конечным пользователем требует 30 минут.
DOLAP программы поставляются самими разработчиками баз данных, многомерных и реляционных. Это SAS Corporate Reporter, являющийся почти эталонным по удобству и красоте продуктом, Oracle Discovery, комплекс программ MS Pivot Services и Pivot Table и другие. Эти продукты, за исключением программ Microsoft, стоят недешево. Так SAS Corporate Reporter обойдется в $2000 на одного пользователя.
Большая группа программ поставляется в рамках компании "OLAP в массы", которую проводит корпорация Microsoft. Эти программы предназначены для работы с MS OLAP Services. Как правило, они являются улучшенными вариантами Pivot Table и предназначены для использования в рамках MS Office или Web. Это Matryx, Knosys и т.д.
Благодаря простоте, дешевизне и огромной эффективности этот класс продуктов приобрел огромную популярность на Западе. Большие корпорации строят свои Хранилища с распределенным доступом на основе таких программ.
Основным продуктом компании "Intersoft Lab" является большая информационно-управленческая система "Контур Корпорация", построенная по принципам Хранилища данных. Однако в процессе общения с клиентами компании осознала, что далеко не все готовы на инвестиции и организационные мероприятия, связанные с построением серьезного Хранилища данных. Первым шагом на этом пути для многих банков и предприятий мог бы стать OLAP-анализ данных из имеющихся OLTP-систем и собственных аналитических базах данных.
Для этих целей был создан DOLAP-продукт "Контур Стандарт".
Контур Стандарт 1.0 Первая версия системы относилась к классу локальных DOLAP. Средства программы позволяли организовать прямой доступ к dbf- и paradox-файлам. Кроме того, в состав дистрибутивного пакета входил мигратор данных, который помогал собрать в локальные таблицы данные из имеющихся у организации систем.
Контур Стандарт 2.0 В дальнейшем, для расширения мощности продукта в системе "Контур Стандарт" 2.0 был обеспечен и доступ к произвольным SQL-серверам на уровне таблиц и, что не встречается в зарубежных аналогах, хранимых процедур. Это превратило программу в корпоративную информационно-аналитическую систему. Отдельно был реализован интерфейс к системе "Контур Корпорация".
Одновременно для удобства администрирования программа была разделена на две редакции. Редакция "Developer" позволяет IT-специалисту описать источники данных и выборки. При этом создаются семантические словари, которые скрывают от конечного пользователя физический слой и переводят данные на язык предметной области. Редакция "Run-Time" позволяет анализировать данные и выпускать отчеты. Основным способом манипуляции данными является OLAP-компонента, которая позволяет без программирования и специальных навыков создавать необходимые отчеты. Одновременно были созданы и новые виды удобных аналитических инструментов, которые формально не являются OLAP-таблицами, но являются OLAP-средствами по духу, т.е. реализуют on-line анализ, но в другой форме представления данных.
В первых двух версиях применялась ROLAP-компонента Decision Cube компании Inprise. Однако ее невысокая мощность и функциональная упрощенность сдерживала применение программы в банках и организациях для анализа больших объемов данных. Поэтому было принято решение о ее замене. Маркетинговый анализ и ревизия интеллектуальных и производственных мощностей самой компании привели к решению о создании собственной OLAP-компоненты. В результате разработки компоненты, которую назвали Contour Cube, появилась следующая версия программы - "Контур Стандарт" 3.0, которая позволяет обрабатывать выборки данных до миллиона записей и обладает расширенной аналитической функциональностью.
Компонента Contour Cube компании "Intersoft Lab" является представителем ROLAP-компонент. Она состоит из OLAP-машины, интерфейса доступа к данным, находящимся в SQL-серверах и других источниках, и визуальной части.
Компонента будет реализована в нескольких версиях для различных применений.
Версия VCL для использования в средах Delphi и C++ Builder компании Inprise. В этом случае данные поставляются через стандартный Data Set этих компиляторов. Доступ к источникам обеспечивается как при помощи BDE, так и ADO, поддержанной в последних версиях этих сред.
Версия COM предназначена для разработчиков на Visual Basic, Visual С++ и т.д. Она обеспечивает доступ к данным при помощи ADO. В будущих версиях будет поддержан и доступ к OLAP-серверам через интерфейс OLE DB for OLAP.
Версия ActiveX является Web-компонентой для создания аналитических Интернет-интерфейсов в стиле, предложенном Microsoft.
Версия DHTML состоит из сервера и DHTML-страниц. Она предназначена для создания аналитических Интернет-интерфейсов в среде UNIX, а также для бурно развивающегося рынка мобильных Интернет-устройств.
Основными достоинствами компоненты являются:
Высокие характеристики компоненты достигнуты за счет уникальной математической модели, созданной специалистами компании.
Создание множества версий компоненты стало возможно благодаря ее многослойной архитектуре. Слой OLAP Engine является относительно независимой частью компоненты. Он реализован как кросс-платформенная библиотека, имеющая API для различных слоев визуализации. Этот API обладает функциями загрузки данных, вычисления срезов многомерного куба и выполнения аналитических и сервисных функций. Сам слой OLAP Engine состоит из машины вычислений и абстрактного многомерного Хранилища данных, которое может сохраняться в виде файла для передачи другим пользователям или длительного использования.
Тесты на персональном компьютере с процессором Intel Celeron 400 и оперативной памятью 64 Мб дали следующие результаты. Загрузка 60 000 записей с 6-ю измерениями занимает 5 секунд; дальнейшие манипуляции, такие как полный поворот таблицы, drill down и drill up выполняются за десятые доли секунды.
Это лучшие по порядку величины (sic!) результаты из известных нам OLAP-компонент. Так, Decision Cube и Pivot Table (без использования OLAP Services) требуют десятки секунд для загрузки и поворота таблицы объемом в 4000 записей и 6-ю измерениями. Скорость работы Dynamic Cube ниже, чем у Contour Cube, в среднем на 30% на средних объемах данных и в разы на предельных объемах.
Таким образом, во многих случаях благодаря своей мощности компонента делает необязательным использование OLAP-сервера. Это значительно упрощает процессы внедрения и администрирования корпоративной системы.
В момент работы с данными компонента занимает наименьший объем оперативной памяти по сравнению с одноклассниками. Так при загрузке 40 000 записей Contour Cube потребляет 7 МБ, Decision Cube 15 МБ.
В компоненте объединены функции лучших OLAP-компонент:
Уникальное свойство компоненты - алгоритм агрегации "Остаток счета". В связи с тем, что в основном OLAP-компоненты предназначаются для анализа продаж и других суммирующих видов анализов, они агрегируют по времени и остатки счетов. Это является ошибкой - остаток счета за квартал не является суммой остатков счета за день, а является остатком за последний день квартала. Реализация этого алгоритма позволяет использовать компоненту для анализа балансов и делает ее полезной не только для экономистов и маркетологов, но и для бухгалтеров.
Для того чтобы при использовании компоненты за минимальное время создавались мощные законченные продукты, в нее встроен набор часто встречающихся в реальной работе аналитических функций. Каждая из этих функций реализована как кнопка в инструментальной панели визуальной части компоненты. Вот перечень этих функций:
В связи с невозможностью защиты авторских прав в России на программные продукты, физическая защита которых принципиально не реализуема, компонента как коммерческий продукт будет поставляться только на Западный рынок. Однако российские потребители могут воспользоваться ее достоинствами для развития собственного бизнеса в продуктах "Контур Стандарт" и "Контур Корпорация".
Разобравшись в том, что такое OLAP и каковы его свойства, перейдем к самому, пожалуй, важному вопросу: для кого предназначены программные продукты этого класса?
Как уже отмечалось, информационная инфраструктура компании имеет иерархический характер и включает в себя уровень сбора первичной информации (транзакционный уровень), уровни хранилищ и витрин данных, уровень OLAP, уровень клиентских аналитических приложений. Таким образом, OLAP-системы занимают в информационной инфраструктуре компании вполне определенное место.
Часто возникает вопрос: чем, с точки зрения пользователя-аналитика, OLAP-система отличается от хранилища данных? Можно сказать, что главное, с точки зрения пользователя, отличие OLAP состоит в структурированности информации в соответствии с ее предметной (именно предметной, а не технической) сущностью. Работая с OLAP-приложе- нием, аналитик использует привычные финансово-экономические термины, категории и показатели (виды материалов и готовой продукции, регионы продаж, объем реализации, себестоимость, прибыль и т. п.), а для того чтобы сформировать любой, даже довольно сложный запрос, ему не придется изучать язык SQL. И при этом ответ на запрос будет получен в течение всего нескольких секунд. Кроме того, работая с OLAP-системой, экономист может пользоваться такими привычными для себя инструментами, как электронные таблицы, или специальными средствами построения отчетов.
Если хранилище данных - это в основном объект внимания 1Т-службы, то OLAP - это инструмент «предметных» специалистов-аналитиков. При этом о существовании хранилища аналитики могут и не догадываться. Таким образом, OLAP без преувеличения можно назвать программным средством из арсенала экономиста, ведь именно экономист имеет дело с самыми разными аналитическими задачами: маркетинговым анализом, анализом продаж, анализом бюджетных показателей, анализом финансовой отчетности и многими другими.
О LAP - инструмент универсальный. Но в то же время именно универсальность делает его не вполне подходящим для специфических финансово-экономических задач, требующих применения специальных методик и организационных принципов. Поэтому OLAP-приложения не могут служить полноценной альтернативой специализированным аналитическим приложениям, например системам бюджетирования или консолидации финансовой отчетности. Здесь нет никакого противоречия: программный продукт, реализующий общие принципы экономического анализа, вряд ли может претендовать на решение абсолютно всех частных задач. Но, с другой стороны, именно сочетание OLAP и специализированных систем дает экономисту наибольшие преимущества, так как в этом случае специальные функции, методы и алгоритмы успешно сочетаются с универсальностью аналитической обработки данных.
Именно поэтому OLAP-средства часто используются клиентскими аналитическими приложениями для многомерного хранения данных. Здесь пользователь применяет привычные для него инструменты для реализации определенных управленческих методик, но при этом данные для обработки и анализа хранятся на OLAP-севере. Показательным примером может служить Hyperion Planning - система бюджетирования, планирования и прогнозирования. Обязательным ее элементом является многомерная база данных, которая используется для хранения наиболее динамично изменяющейся информации (при этом метаданные и другая статичная информация хранятся в реляционной базе данных).
Таким образом, грамотно построенная OLAP-система играет в жизни экономиста весьма заметную роль, ведь с ее помощью можно получить доступ к самой свежей информации и оперативно выполнить общие аналитические процедуры. А сложные финансовые функции и необходимые организационные аспекты будут обеспечены специализированными системами, опять же, на основе данных OLAP. Как показывает опыт ведущих компаний (как международных, так и российских), OLAP-технологии экономически выгодны и инвестиции в такие решения окупаются довольно быстро.
Концепция Business Performance Management: начало пути Средства формирования запросов и отчетности
Как уже было отмечено, средства формирования запросов и построения отчетов {Query and Reporting took) обеспечивают функции построения запросов к информационно-аналитическим системам, интеграцию данных из нескольких источников, просмотр данных с возможностью детализации и обобщения, построение и печать полноценных отчетов, в том числе презентационного качества. Некоторые из программных продуктов этого класса могут использоваться конечными пользователями, с минимальной поддержкой ИТ-департамента, другие же требуют определенного программирования и настраиваются техническими специалистами.
Типичными представителями систем этого класса являются программные продукты корпорации Hyperion, объединенные в семейство Hyperion Performance Suite.
Hyperion Performance Suite представляет собой набор средств построения запросов, анализа, формирования отчетов и их регламентированной доставки в рамках всей организации. Эти программные продукты вошли в линейку BI-систем Hyperion после того, как в 2003 году Hyperion приобрел Brio Software - компанию, хорошо известную на рынке систем бизнес-интеллекта благодаря своим эффективным и легким в использовании решениям. До этого на протяжении ряда лет компании Hyperion и Brio тесно сотрудничали как технологические партнеры, поэтому объединение их разработок позволило создать уникальную линейку, в которой решения Hyperion (OLAP-система Hyperion Essbase и аналитические приложения - Hyperion Planning, Hyperion Financial Management и другие) оказались органично дополнены современными средствами запросов и отчетности Brio. В результате Hyperion стал обладателем самой мощной и полнофункциональной линейкой из всех присутствующих на рынке программных продуктов класса Business Intelligence. Сегодня все эти решения, по достоинству оцененные многими зарубежными компаниями, стали доступны российским предприятиям.
Комплект Hyperion Performance Suite включает в себя два программных продукта - Hyperion Intelligence и Hyperion SQR.
Hyperion Intelligence - это современная, удобная в работе система для формирования сложных запросов к различным источникам данных, включая ERP, CRM, банковские и прочие транзакционные системы, а также для представления этих данных в удобном для анализа виде. Эффективно используя данные, хранящиеся в существующих информационных системах , Hyperion Intelligence дает возможность разработчикам, аналитикам и потребителям превратить «сырые» данные в ценную информацию для принятия решений. Аналитические возможности системы позволяют специалистам организации оперативно оценивать возможности и тенденции бизнеса и повысить обоснованность принимаемых управленческих решений, а интуитивно понятный интерфейс пользователя, основанный на Интернет-технологиях, делает информацию доступной любому из уполномоченных пользователей.
Система Hyperion SQR представляет собой эффективное решение для управления большими потоками отчетов - от относительно простых сообщений до критически важных для организации сложных отчетов. Hyperion SQR позволяет разработчикам формировать отчеты презентационного качества и любой сложности, после чего доставлять эти отчеты через конечным пользователям в рамках всей организации. Обрабатывая сложные запросы и формируя на их основе наглядные отчеты, Hyperion SQR превращает массивы данных в бизнес - информацию, что позволяет повысить эффективность работы всей организации. Система ориентирована на работу с регламентированной отчетностью, формируя отчеты в соответствии с заданным графиком и обеспечивая сотрудников, клиентов, поставщиков и деловых партнеров своевременной информацией. Работать с отчетами очень легко: используя привычные веб-браузеры, пользователи могут просматривать отчеты, печатать их или пересылать по электронной почте в различных форматах. Система также дает возможность классификации сообщений, контроля версий и архивирования, а встроенный язык программирования третьего поколения позволяет использовать Hyperion SQR в качестве инструмента построения средств извлечения, трансформации и загрузки данных.
Линейка BI-решений Hyperion, дополненная средствами запросов и отчетности, доставшимися «по наследству» от Brio, представляет интерес как для ИТ-специалистов, так и для конечных пользователей.
С точки зрения конечного пользователя, это - удобный инструмент, позволяющий решить уже упоминавшуюся проблему, с которой так часто сталкиваются менеджеры и предметные специалисты - проблему «единого взгляда на управленческую информацию». Напомним, что эта проблема состоит в том, что очень часто управленческая информация, необходимая для анализа и принятия решений, хранится в разных источниках - учетных системах, ERP-системах, базах данных и т. п. Это крайне затрудняет получение нужной информации и ее представление в удобном для пользователя виде: специалисты вынуждены тратить время на рутинные процедуры сбора данных и их обработки, причем с риском искажения. Управленческая информация, полученная таким путем, часто не соответствует требованиям достоверности и актуальности, что снижает ее ценность. В этом плане BI-решения Hyperion позволяют существенно упростить и ускорить сбор информации, унифицировать ее и представить в удобной и наглядной форме. Такая информация - надежная база для принятия управленческих решений, при этом рутинные процедуры сводятся к минимуму, а время специалистов высвобождается для решения аналитических задач.
С точки зрения ИТ-службы, BI-решения Hyperion выгодно отличаются своей масштабируемостью, легкостью в поддержке, а также наличием встроенных языков, позволяющих наращивать функциональность программного обеспечения.
Информационные системы серьезного предприятия, как правило, содержат приложения, предназначенные для комплексного анализа данных, их динамики, тенденций и т.п. Соответственно, основными потребителями результатов анализа становится топ-менеджмент. Такой анализ, в конечном итоге, призван содействовать принятию решений. А чтобы принять любое управленческое решение необходимо обладать необходимой для этого информацией, обычно количественной. Для этого необходимо эти данные собрать из всех информационных систем предприятия, привести к общему формату и уже потом анализировать. Для этого создают хранилища данных (Data Warehouses).Иногда Хранилище имеет еще одну цель – интеграция всех данных предприятия, для поддержания целостности и актуальности информации в рамках всех информационных систем. Т.о. хранилище накапливает не только аналитическую, а почти всю информацию, и может ее выдавать в виде справочников обратно остальным системам.
Типичное хранилище данных, как правило, отличается от обычной реляционной базы данных. Во-первых, обычные базы данных предназначены для того, чтобы помочь пользователям выполнять повседневную работу, тогда как хранилища данных предназначены для принятия решений. Например, продажа товара и выписка счета производятся с использованием базы данных, предназначенной для обработки транзакций, а анализ динамики продаж за несколько лет, позволяющий спланировать работу с поставщиками, - с помощью хранилища данных.
Во-вторых, обычные базы данных подвержены постоянным изменениям в процессе работы пользователей, а хранилище данных относительно стабильно: данные в нем обычно обновляются согласно расписанию (например, еженедельно, ежедневно или ежечасно - в зависимости от потребностей). В идеале процесс пополнения представляет собой просто добавление новых данных за определенный период времени без изменения прежней информации, уже находящейся в хранилище.
И, в-третьих, обычные базы данных чаще всего являются источником данных, попадающих в хранилище. Кроме того, хранилище может пополняться за счет внешних источников, например статистических отчетов.
Вернемся к анализу.
Здесь стоит указать на отличие работы с СППР от простого набора регламентированных и нерегламентированных отчетов. Анализ в СППР практически всегда интерактивен и итеративен. Т.е. аналитик копается в данных, составляя и корректируя аналитические запросы, и получает отчеты, структура которых заранее может быть неизвестна. Более подробно к этому мы вернемся ниже, когда будем обсуждать язык запросов MDX .
Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing). OLAP - это ключевой компонент организации традиционных хранилищ данных. Концепция OLAP была описана в 1993 году Эдгаром Коддом , известным исследователем баз данных и автором реляционной модели данных. В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information - быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям для многомерного анализа:
Прежде чем говорить о различных реализациях OLAP, давайте подробнее рассмотрим, что же представляют собой кубы с логической точки зрения.
Результатом этого запроса всегда будет столбец чисел и список атрибутов его описывающих (например, страна) – это одномерный набор данных или, говоря математическим языком, – вектор.
Представим себе, что нам надо получить информацию по суммарной стоимости заказов из всех стран и их распределение по компаниям доставщиков – мы получим уже таблицу (матрицу) из чисел, где в заголовках колонок будут перечислены доставщики, в заголовках строк – страны, а в ячейках будет сумма заказов. Это – двумерный массив данных. Такой набор данных называется сводной таблицей (pivot table ) или кросс-таблицей.
Если же нам захочется получить те же данные, но еще в разрезе годов, тогда появится еще одно изменение, т.е. набор данных станет трехмерным (условным тензором 3-го порядка или 3-х мерным «кубом»).
Очевидно, что максимальное количество измерений – это количество всех атрибутов (Дата, Страна, Заказчик и т.д.), описывающих наши агрегируемые данные (сумму заказов, количество товаров и т.п).
Так мы приходим к понятию многомерности и его воплощению – многомерному кубу . Такая таблица будет у нас называться «таблицей фактов ». Измерения или Оси куба (dimensions ) – это атрибуты, координаты которых – выражаются индивидуальными значениями этих атрибутов, присутствующих в таблице фактов. Т.е. например, если информация о заказах велась в системе с 2003 по 2010 год, то эта ось годов будет состоять из 8 соответствующих точек. Если заказы приходят из трех стран, то ось стран будет содержать 3 точки и т.д. Независимо от того, сколько стран заложено в справочнике Стран. Точки на оси называются ее «членами» (Members ).
Сами агрегируемые данные в данном случае буду назваться «мерами» (Measure ). Чтобы избежать путаницы с «измерениями», последние предпочтительней называть «осями». Набор мер образует еще одну ось «Меры» (Measures ). В ней столько членов (точек), сколько мер (агрегируемых столбцов) в таблице фактов.
Члены измерений или осей могут быть объединены одной или несколькими иерархиями (hierarchy ). Что такое иерархия, поясним на примере: города из заказов могут быть объединены в районы, районы в области, области страны, страны в континенты или другие образования. Т.е. налицо иерархическая структура – континент-страна-область-район-город – 5 уровней (Level ). Для района данные агрегируются по всем городам, которые в него входят. Для области по всем районам, которые содержат все города и т.п. Зачем нужно несколько иерархий? Например, по оси с датой заказа мы можем хотеть группировать точки (т.е. дни) по иерархии Год-Месяц-День или по Год-Неделя-День : в обоих случаях по три уровня. Очевидно, что Неделя и Месяц по-разному группируют дни. Бывают также иерархии, количество уровней в которых не детерминировано и зависит от данных. Например, папки на компьютерном диске.
Агрегация данных может происходить с использованием нескольких стандартных функций: сумма, минимум, максимум, среднее, количество.
Мы рассмотрим его подробно потому что это единственный язык, который получил статус стандартного в рамках общего стандарта протокола 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 ‘. - .’
Очевидно, что в отчете будет не единица, а разность соответствующих срезов, т.е. разность суммы заказов в эти два года.
Drill – это детализация отчета с помощью уменьшения степени агрегации данных, совмещенное с фильтрацией по какой-нибудь другой оси (или нескольким осям). Сверление бывает нескольких видов:
Теги:
На самом деле очень удобно пользоваться многомерным КУБом при работе с управленческой отчетностью. При разработке форматов бюджетов можно столкнуться с проблемой многовариантности форм (подробнее об этом можно прочитать в Книге 8 "Технология постановки бюджетирования в компании" и в книге "Постановка и автоматизация управленческого учета").
Это связано с тем, что для эффективного управления компанией требуется все более детализированная управленческая отчетность. То есть в системе используется все больше различных аналитических срезов (в информационных системах аналитики определяются набором справочников).
Естественно, это приводит к тому, что руководители хотят получать отчетность во всех интересующих их аналитических срезах. А это значит, что отчеты нужно как-то заставить «дышать». Иными словами можно сказать, что в данном случае речь идет о том, что по смыслу один и тот же отчет должен предоставлять информацию в различных аналитических разрезах. Поэтому статичные отчеты уже не устраивают многих современных руководителей. Им нужна динамика, которую может дать многомерный КУБ.
Таким образом, OLAP-технология уже сейчас стала обязательным элементом в современных и перспективных информационных системах. Поэтому при выборе программного продукта нужно обращать внимание на то, используется ли в нем OLAP-технология.
Причем нужно уметь отличать настоящие КУБы от имитации. Одной из таких имитаций являются сводные таблицы в MS Excel. Да, этот инструмент похож на КУБ, но на самом деле таковым не является, поскольку это статические, а не динамические таблицы. Кроме того, в них гораздо хуже реализована возможность построения отчетов, использующих элементы из иерархических справочников.
Для подтверждения актуальности использования КУБа при построении управленческой отчетности можно привести простейший пример с бюджетом продаж. В рассматриваемом примере для компании актуальными являются следующие аналитические срезы: продукты, филиалы и каналы сбыта. Если для компании важны эти три аналитики, то бюджет (или отчет) продаж можно выводить в нескольких вариантах.
Следует отметить, что если создавать строки бюджетов на основе трех аналитических срезов (как в рассматриваемом примере), это позволяет создавать достаточно сложные бюджетные модели и составлять детализированные отчеты с использованием КУБа.
Например, бюджет продаж можно составлять с использованием только одной аналитики (справочника). Пример бюджета продаж, построенного на основе одной аналитики "Продукты" представлен на рисунке 1 .
Рис. 1. Пример бюджета продаж, построенного на основе одной аналитики "Продукты" в OLAP-КУБе
Этот же бюджет продаж можно составлять с использованием двух аналитик (справочников). Пример бюджета продаж, построенного на основе двух аналитик "Продукты" и "Филиалы" представлен на рисунке 2 .
Рис. 2. Пример бюджета продаж, построенного на основе двух аналитик "Продукты" и "Филиалы" в OLAP-КУБе программного комплекса "ИНТЕГРАЛ"
.
Если есть необходимость строить более детальные отчеты, то можно тот же бюджет продаж составлять с использованием трех аналитик (справочников). Пример бюджета продаж, построенного на основе трех аналитик "Продукты", "Филиалы" и "Каналы сбыта" представлен на рисунке 3 .
Рис. 3. Пример бюджета продаж, построенного на основе трех аналитик "Продукты", "Филиалы" и "Каналы сбыта" в OLAP-КУБе программного комплекса "ИНТЕГРАЛ"
Нужно напомнить о том, что КУБ, используемый для формирования отчетов, позволяет выводить данные в различной последовательности. На рисунке 3 бюджет продаж сначала "разворачивается" по продуктам, затем по филиалам, а потом по каналам сбыта.
Те же самые данные можно представить в другой последовательности. На рисунке 4 тот же самый бюджет продаж "разворачивается" сначала по продуктам, затем по каналам сбыта, а потом по филиалам.
Рис. 4. Пример бюджета продаж, построенного на основе трех аналитик "Продукты", "Каналы сбыта" и "Филиалы" в OLAP-КУБе программного комплекса "ИНТЕГРАЛ"
На рисунке 5 тот же самый бюджет продаж "разворачивается" сначала по филиалам, затем по продуктам, а потом по каналам сбыта.
Рис. 5. Пример бюджета продаж, построенного на основе трех аналитик "Филиалы", "Продукты" и "Каналы сбыта" в OLAP-КУБепрограммного комплекса "ИНТЕГРАЛ"
На самом деле это не все возможные варианты вывода бюджета продаж.
Кроме того, нужно обратить внимание на то, что КУБ позволяет работать с иерархической структурой справочников. В представленных примерах иерархическими справочниками являются "Продукты" и "Каналы сбыта".
С точки зрения пользователя он в данном примере получает несколько управленческих отчетов (см. Рис. 1-5 ), а с точки зрения настроек в программном продукте – это один отчет. Просто с помощью КУБа его можно просматривать несколькими способами.
Естественно, что на практике возможно очень большое количество вариантов вывода различных управленческих отчетов, если их статьи строятся на одной или нескольких аналитиках. А уж сам набор аналитик зависит от потребности пользователей в детализации. Правда, при этом не следует забывать, что, с одной стороны, чем больше аналитик, тем более детализированные отчеты можно строить. Но, с другой стороны, значит, и финансовая модель бюджетирования будет более сложной. В любом случае при наличии КУБа компания будет иметь возможность просмотра необходимой отчетности в различных вариантах, в соответствии с интересующими аналитическими разрезами.
Необходимо упомянуть еще о нескольких возможностях OLAP-КУБа.
В многомерном иерархическом OLAP-КУБе есть несколько измерений: тип строки, дата, строки, справочник 1, справочник 2 и справочник 3 (см. Рис. 6 ). Естественно, в отчет выводится столько кнопок со справочниками, сколько есть в строке бюджета, содержащей максимальное количество справочников. Если ни в одной строке бюджета нет ни одного справочника, то в отчете не будет ни одной кнопки со справочниками.
Изначально OLAP-КУБ строится по всем измерениям. По умолчанию при первоначальном построении отчета измерения расположены именно в тех областях, как показано на рисунке 6 . То есть такое измерение, как «Дата», располагается в области вертикальных измерений (измерения в области столбцов), измерения «Строки», «Справочник 1», «Справочник 2» и «Справочник 3» – в области горизонтальных измерений (измерения в области строк), а измерение «Тип строки» – в области «нераскрываемых» измерений (измерения в страничной области). Если измерение находится в последней области, то данные в отчете не будут «раскрываться» по этому измерению.
Каждое из этих измерений можно поместить в любую из трех областей. После переноса измерений отчет мгновенно перестраивается в соответствии с новой конфигурацией измерений. Например, можно поменять местами дату и строки со справочниками. Или можно в вертикальную область измерений перенести один из справочников (см. Рис. 7 ). Иными словами, отчет в OLAP-КУБе можно «крутить» и выбирать тот вариант вывода отчета, который является наиболее удобным для пользователя.
Рис. 7. Пример перестройки отчета после изменения конфигурации измерений программного комплекса "ИНТЕГРАЛ"
Конфигурацию измерений можно менять либо в основной форме КУБа, либо в редакторе карты изменений (см. Рис. 8 ). В этом редакторе также можно мышкой перетаскивать измерения из одной области в другую. Помимо этого, можно менять местами измерения в одной области.
Кроме того, в этой же форме можно настраивать некоторые параметры измерений. По каждому измерению можно настраивать расположение итогов, порядок сортировки элементов и названия элементов (см. Рис. 8 ). Также можно задавать, какое название элементов выводить в отчет: сокращенное (Name) или полное (FullName).
Рис. 8. Редактор карты измерений программного комплекса "ИНТЕГРАЛ"
Редактировать параметры измерений можно непосредственно в каждом из них (см. Рис. 9 ). Для этого нужно нажать на пиктограмму, расположенную на кнопке рядом с названием измерения.
Рис. 9. Пример редактирования справочника 1 Продукты и услуги в
С помощью этого редактора можно выбирать элементы, которые нужно показывать в отчете. По умолчанию в отчет выводятся все элементы, но при необходимости часть элементов или папок можно не показывать. Например, если нужно выводить в отчет только одну продуктовую группу, то у всех остальных необходимо убрать галочки в редакторе измерений. После чего в отчете будет только одна продуктовая группа (см. Рис. 10 ).
Также в этом редакторе можно сортировать элементы. Кроме того, элементы можно перегруппировывать различными способами. После такой перегруппировки отчет мгновенно перестраивается.
Рис. 10. Пример вывода в отчете только одной продуктовой группы (папки) в программном комплексе "ИНТЕГРАЛ"
В редакторе измерения можно оперативно создавать свои группы, перетаскивать туда элементы из справочников и т.д. По умолчанию автоматически создается только группа «Прочие», но можно создавать и другие группы. Таким образом, с помощью редактора измерений можно настраивать, какие элементы справочников и в каком порядке нужно выводить в отчет.
|
На самом деле все такие изменения можно было сделать изначально при настройке строк.
Например, с помощью ограничений также можно задавать, какие элементы или группы справочников нужно выводить в отчет, а какие – нет.
Примечание : более подробно тема данной статьи рассматривается на семинарах-практикумах "Бюджетное управление предприятием" и "Постановка и автоматизация управленческого учета" , которые проводит автор данной статьи - Александр Карпов .
Если пользователю практически регулярно нужно выводить в отчет только определенные элементы или папки справочников, то подобные настройки лучше заранее сделать при создании строк отчетов. Если же для пользователя важны различные комбинации элементов справочников в отчетах, тогда при настройке методики никакие ограничения ставить не нужно. Все такие ограничения можно будет оперативно настраивать с помощью редактора измерения.
2003 Intelligent enterprise
За последние годы появилось достаточно публикаций по OLAP (история, описание, технология, готовые решения), но для большинства специалистов, занимающихся учетом, управлением, планированием, этот термин остаётся по-прежнему чем-то непонятным.
Цель этой статьи - познакомить с практическим опытом реализации решения для подготовки отчетности на основе OLAP-технологий в ООО "Мострансгаз" - крупнейшем отечественном предприятии по транспорту газа.
OLAP (On-line Analytical Processing) обычно переводится как аналитическая обработка данных. И это определение вводит в заблуждение потенциальных пользователей технологии. В России бытует твердое убеждение, что эти системы используются исключительно высококвалифицированными специалистами и аналитиками для проведения сложного анализа. На Западе их рассматривают, как системы, упрощающие понимание данных и обмен ими между всеми сотрудниками компании. В правильности именно западного подхода к OLAP, мы убедились на собственном опыте.
Для ИТ-практиков, OLAP - это технология быстрого создания интерактивных отчетов. Как правило, OLAP-отчет может быть разработан практически без программирования, методом drag&drop. Проектирования и программирования требует только этап извлечения и подготовки данных для отчетов из корпоративных систем предприятия. Серия отчетов для определенной предметной области может быть настроена буквально за несколько часов.
Для конечных пользователей, OLAP - это табличный отчет с промежуточными и окончательными итогами. Он выпускается практически мгновенно и можно самостоятельно изменить его форму: расположение колонок и строк, порядок фильтров и сортировки и т.д. Это позволяет взглянуть на одни и те же данные под разным углом зрения. Например, получив перечень по дебиторской задолженности, углубиться в архивные данные и оценить, были ли у должника проблемы с платежами в прошлом квартале, полгода назад, в ушедшем году? Разносторонний анализ позволяет быстро оценить ситуацию и получить максимум информации о проблеме, чтобы наметить пути ее решения.
Каким образом работает OLAP-система? OLAP-клиент получает данные из исходной информационной системы, и организует их в иерархические структуры в памяти компьютера пользователя. Это позволяет выполнять вычисления промежуточных и окончательных итогов (фактов) практически мгновенно. Пользователь получает простой и интуитивно понятный интерфейс отчета. Это таблица, в которой с помощью "мыши" можно менять местами строки и колонки (измерения), перетаскивать их в область фильтров, тем самым, сворачивая данные, устанавливая самые сложные комбинации фильтров. Функциональные возможности системы позволяют за один сеанс работы выпустить десятки разновидностей одного и того же отчета.
С применением OLAP-инструмента, традиционная задача отдела автоматизации - разработка новых отчетов, в которых одни данные показаны в разрезе других, превращается в задачу предоставления пользователю исходных данных. После этого экономист или бухгалтер не тратит время на написание служебных записок с требованием создания новой разновидности отчета и не ждет, пока программисты спроектируют, разработают и протестируют его. Пользователь сам конструирует нужный вид отчета, выбирая из настроенной для него "заготовки" нужные поля, меняя порядок их следования, устанавливая фильтры и др. Созданный отчет может быть проиллюстрирован графиками и диаграммами, распечатан на бумагу или выгружен в Excel.
Итак, OLAP-инструмент дает два основных преимущества пользователю:
Обратимся к определению ERP-системы: ERP-система (Enterprise Resource Planning system) - комплексная интегрированная система, создающая единую среду для автоматизации планирования, учета, контроля и анализа всех основных бизнес-операций предприятия.
Традиционно, создатели ERP-систем наибольшее внимание уделяют функциям, направленным на реализацию бизнес-процессов предприятий, документооборота, учета, планирования и других сфер. Поэтому в первую очередь они оптимизируют ввод новых учетных данных в систему. При этом на второй план уходит возможность использования накопленных данных, развитие встроенной системы отчетности и, что наиболее важно, - преобразование огромных массивов данных в информацию для принятия управленческих решений.
Все без исключения ERP-системы имеют подсистему формирования отчетов. Но созданные с ее помощью отчеты не позволяют менеджменту предприятия оценить финансовые показатели деятельности, выявить наиболее прибыльные продукты и услуги, проанализировать затраты, дебиторскую и кредиторскую задолженности и т.д. Обычно в составе подсистемы отчетности поставляется базовый минимум отчетов по предметным разделам, например, наличие товаров на складах, ведомость износа основных фондов, кассовая книга, ведомость реализации услуг и др. Номенклатура, уровень достаточности и глубина штатных отчетов определяются разработчиками без учета потребностей конкретного конечного пользователя продукта. В результате, штатные отчеты ориентированы на пользователей "нижнего" уровня. Эти отчеты выпускаются из базы данных, на которой работает учетная система. Скорость формирования таких отчетов находится в обратной зависимости от фильтров, группировок и информационного состава.
Создать дополнительные отчеты, в том числе, управленческие, можно с помощью инструментария для разработки отчетов, который поставляется в составе ERP-системы. В некоторых системах это "продвинутый" конструктор с возможностью визуального проектирования, в некоторых - встроенный язык программирования.
В любом случае настройка нового отчета выполняется силами программистов и занимает от нескольких часов до нескольких дней в зависимости от сложности. Даже незначительное изменение структуры отчета вызывает существенные затраты по ресурсам.
Таким образом, есть ряд факторов, которые препятствуют свободному получению информации из учетной системы:
Выходом из этой ситуации может быть платформенное разделение учета и отчетности, при котором учетная система оптимизирована для отражения бизнес-процессов, а отчетная система является надстройкой над данными учетной системы и предназначена для быстрого создания и выпуска разнообразных отчетов.
Рассмотрим возможный вариант реализации разделения учета и отчетности на примере интеграции ERP-системы и OLAP-инструментов. В ООО "Мострансгаз" данная модель была построена на основе:
Предложенная модель могла быть реализована и с использованием других программных продуктов соответствующего функционального содержания. Выбор указанных систем был продиктован наличием закупленных версий, удачным сочетанием их функциональных возможностей и достаточным опытом их эксплуатации.
Система "Галактика" работает на платформе СУБД Btrieve\Pervasive, что при невысоких расходах на сопровождение обеспечивает вполне приемлемую скорость работы пользователей, выполняющих операции ввода данных и выпуска текущих отчетов. Однако отчеты за длительный период, а также отчеты, построенные на нестандартных запросах, выполняются недостаточно быстро. Это побудило ИТ-менеджеров ООО "Мострансгаз" применить современные OLAP-системы Аналитической платформы Контур для выпуска отчетов.
Контур Стандарт - это инструмент для генерации произвольных табличных отчетов и анализа данных различных информационных систем. В этой системе можно настроить прямой доступ к локальным таблицам и реляционным базам данных, сконструировать SQL-запросы и выпускать на них OLAP-отчеты в режиме реального времени. Созданный отчет сохраняется для работы в off-line режиме и передачи удаленным пользователям в виде файлов микрокубов.
Микрокуб - это мобильный контейнер OLAP-отчетов и данных для представления в отчетах. В нем хранятся данные, выгруженные из автоматизированных корпоративных систем, алгоритмы расчета вычисляемых показателей и формы OLAP-отчетов. Данные в микрокубе подготовлены для многомерного анализа и оперативного получения показателей в различных разрезах. При помещении в микрокуб объем исходной информации сжимается в десятки раз, что позволяет передавать их по Интернет-протоколам и пересылать по электронной почте.
Контур Дизайнер Кубов предназначен для проектирования микрокубов и сценариев их генерации.
Контур Генератор кубов используется для массовой генерации микрокубов по готовым сценариям.
Более подробно об OLAP-технологии, ее возможностях и конкретных примерах использования можно прочесть в статье В.Некрасова "Мобильный OLAP", опубликованной в журнале "Открытые системы" №5 (2003г.).
Общая схема решения выглядит следующим образом:
Пользователи ПК "Галактика" работают в штатном режиме, то есть вводят данные и выпускают текущие отчеты для проверки корректности выполненных транзакций.
Параллельно, планировщик задач с заданным периодом в 30 минут запускает перегрузку данных из БД "Галактики" в промежуточный склад данных. Перегрузка происходит в фоновом режиме без отключения пользователей. Промежуточный склад данных является копией базы данных ERP-системы. В данном конкретном случае склад реализован на платформе Firebird, но нет никаких ограничений по другим СУБД. Основная задача создания промежуточного слоя данных - разделение системы учета и системы отчетности.
Данные промежуточного склада используются для создания микрокубов - витрин данных по разным направлениям отчетности (например, "исполнение договоров по капитальному ремонту" или "состав затрат с местами их возникновения"). Создание микрокубов и настройка OLAP-отчетов делегирована аналитикам службы информационных технологий.
Аналитик настройки отчетности в визуальной среде "Контур Дизайнер кубов" проектирует структуры микрокубов, информационный состав и внешний вид OLAP-отчетов. Все настройки сохраняются в виде файлов сценариев.
По готовым сценариям модуль "Контур Генератор кубов" каждые 30 минут генерирует микрокубы из промежуточного склада данных.
Готовые микрокубы содержат в себе метаданные (настройки внешнего вида отчетов, доступных пользователю измерений и фильтров и др.) и данные (выборки из промежуточного склада данных).
При помощи OLAP-клиента "Контур Стандарт" микрокубы доступны аналитикам, экономистам, бухгалтерам и другим потребителям отчетов.
Какие задачи и как помогают решить OLAP-технологии пользователям ERP-системы? Инструменты OLAP извлекают данные из БД ERP-системы и представляют их в интерактивных отчетах для разных специалистов: бухгалтеров, экономистов, руководителей и т.д. Контроль движения материальных ценностей между складами, сравнительный анализ закупочных цен поставщиков, оценка сбыта по регионам, анализ исполнения бюджетов - таков далеко не полный перечень направлений использования OLAP-систем на предприятии. Фактически интеграция ERP и OLAP выводит автоматизацию поддержки управления предприятием на новый качественный уровень.
Рассмотрим несколько примеров использования OLAP в "Мострансгазе".
Любую базовую отчетность ERP-системы можно представить в виде OLAP-таблицы. Это значит, что пользователь сможет сам управлять формой и содержанием отчета с помощью стандартных OLAP-операций: группировки и детализации данных, фильтрации по измерениям и периодам и т.д. После каждой операции OLAP-система выполняет перерасчет промежуточных и окончательных итогов и мгновенно отображает новый отчет.
Это дает сотрудникам разных подразделений свободный доступ к огромным объемам информации для анализа. Например, все стандартные "шахматки по счетам" за год можно поместить в одну единственную OLAP-таблицу. В колонках и строках таблицы будут представлены корреспондирующие счета, в ячейках на пересечении колонок и строк - суммы проводок. С помощью фильтров бухгалтер выбирает счета для представления в отчете, углубляется в интересующий синтетический счет, например 10 "Материалы" (см. рис.), до уровня субсчетов и сразу же получает шахматку по аналитике этого счета.
Классическая задача, которую решают OLAP-системы - генерация основных периодов из даты. Это значит, что на основе фактических значений за каждую дату, система автоматически вычисляет итоговые значения показателей за заданные периоды: неделя, декада, месяц, квартал, год.
Это помогает в решении множества повседневных задач бухгалтерии предприятия. Например, значительно сокращает время на поиск задолженности, по которой приближается срок исковой давности, при создании резерва по сомнительной задолженности и в других случаях анализа дебиторской и кредиторской задолженности. Для этого в один OLAP-отчет выводятся остатки по счету 76 "Расчеты с дебиторами и кредиторами" в разрезе периодов возникновения задолженности, например по годам.
"Мострансгаз" имеет договорные отношения с огромным количеством контрагентов. В OLAP-отчете можно оперативно просмотреть задолженность каждого контрагента и оценить суммы задолженности по разным видам деятельности в разрезе контрагентов. Для этого в отчет добавляются два измерения: "Контрагент" (объекты аналитического учета по счету 76) и "За что" (предметы договоров с контрагентами, по которым образовалась задолженность). Итоги по новым измерениям рассчитываются автоматически (см. рис).
Рис. 3. OLAP-отчет
Для поиска встречной задолженности в OLAP-отчете дебетовые и кредитовые сальдо по счетам 60 "Расчеты с поставщиками", 62 "Расчеты с покупателями и заказчиками" и 76 "Расчеты с дебиторами и кредиторами" представляются в разрезе контрагентов (измерение "Контрагент"), договоров (измерение "За что") и документов оплаты по договору (измерение "Документ").
Сравнивая промежуточные итоги по дебету и кредиту счетов, бухгалтер видит взаимную задолженность с расшифровкой "с кем" ("Контрагент"), "за что" и "по каким документам".
Рис. 4. OLAP-отчет
В OLAP-таблице с помощью фильтров по фактам и измерениям легко подобрать удобную для решения конкретной задачи форму отчета и выделить данные для сравнения. Можно изменить масштаб (1хN) и формат (абсолютное значение/проценты) представления данных. Две последние функции не являются обязательными для всех OLAP-систем, но они исключительно удобны для решения бухгалтерских задач.
Например, в отчете "Сальдо 2003 года по кварталам и датам" (см. рис.) для сопоставления корректности сальдо по кредиторской задолженности на счете 60 "Расчеты с поставщиками" и налога на добавленную стоимость (НДС) на счете 19 "НДС по приобретенным ценностям" устанавливаются два фильтра. Первый фильтр - по измерению "Счет" для отображения в отчете данных только по двум счетам - 19 и 60. Второй фильтр - по фактам, он включает отображение "свернутого" сальдо по счетам. В результате в соседних колонках в отчете отражаются дебетовое и кредитовое сальдо по выбранным счетам в разрезе счетов-фактур (измерение "С/Ф"), договоров и контрагентов.
Чтобы проверить корректность выделения НДС (18/118, до 2004 года 20/120), бухгалтер одной кнопкой переводит сальдо в проценты по строкам таблицы фактов. В результате в соседних колонках по каждому счету-фактуре выводится сумма оплаты и выделенный из нее НДС. Если отношение 20/120 или 18/118 нарушено, то ситуация по бухгалтерскому документу требует дополнительного разбора и анализа.
Рис. 5. OLAP-отчет
Для анализа затрат предприятия в OLAP-отчете представляются проводки по затратным счетам (20 "Основное производство" и 23 "Вспомогательное производство") в разрезе объектов аналитического учета (измерение "Статья затрат") и их группировок (измерение "Вид деятельности"). В результате с помощью фильтров можно получить в одном отчете группировки затратных статей из различных синтетических счетов.
Помимо фильтров, полезная функция OLAP - сортировка измерений по значениям фактов. Она удобна для выявления приоритетных или, наоборот, наименее выгодных позиций: филиалов, контрагентов, видов деятельности, продуктов и т.д. Например, чтобы выявить наиболее затратные статьи заданного периода, можно отсортировать измерение "Статья затрат" по возрастанию.
Управляя составом измерений отчета, можно оценивать затраты предприятия с разных позиций. Например, для анализа затрат в разрезе структурных подразделений предприятия в отчет достаточно добавить измерение "Филиал" (см. рис.).
Рис. 6. OLAP-отчет
OLAP-инструменты "говорят" со своими потребителями на одном языке. Это достигается за счет создания семантического слоя, когда полям из БД ERP-системы присваиваются названия, в терминах предметной области. В результате переименования колонки, строки и цифры в OLAP-таблице приобретают прикладной смысл, понятный конечным пользователям отчетов.
Наглядный пример - отчет по картотеке незавершенного строительства за 2003 год (см. рис.). Он показывает состояние расчетов с подрядчиками (измерение "Контрагент"), из которых можно оценивать ход выполнения работ по объектам строительства (измерение "Стройка"). Уплаченные суммы представлены в разрезе бухгалтерских документов: счетов-фактур (измерение "Счет-фактура") и соответствующих платежных документов и актов сдачи-приемки (измерение "Номер документа"). В таблице фактов представлены остатки по счетам 08 "Вложения во внеоборотные активы" (факт "Выполнен.работ"), 19 "НДС по приобретенным ценностям" (факт "НДС по работам") и 60 "Расчеты с поставщиками" (факт "Оплачено). К примеру, из таблицы видно, что за работы по строительству 14-этажного жилого дому на Можайском шоссе, подрядчику ЖилСтройКомплект был оплачен аванс в размере 41800 рублей по платежному документу А08016. В акте сдачи-приемки работ №34 было зафиксировано, что работы на сумму 41800 рублей, не облагаемые НДС, выполнены. Таким образом, счет-фактура №256 был закрыт.
Автоматический подсчет промежуточных итогов по разным измерениям таблицы позволяет мгновенно получить дополнительную информацию - суммарные затраты по объекту строительства или конкретному поставщику.
Рис. 7. OLAP-отчет
Для "Отчета о прибыли и убытках" бухгалтер готовит различные группировки по счету 99 "Прибыли и убытки". В OLAP-системе их можно получить практически мгновенно.
В одном OLAP-отчете объединенные в группы проводки по счету 99 показывают источники возникновения прибыли (в разрезе измерения "Филиал") и прибыльные бизнес-направления (в разрезе измерения "Вид деятельности"). По каждой группе проводок автоматически рассчитываются итоговые значения для сравнения составляющих прибылей и убытков.
Если дополнительно разложить данные по датам на периоды: по месяцам, кварталам (см. рис) и др., можно с разным масштабом оценить динамику прибыли.
Рис. 8. OLAP-отчет
Накопленный опыт эксплуатации OLAP-системы как надстройки над ERP показал ряд существенных положительных моментов:
Автор надеется, что все изложенное в статье будет полезно IT-службам и прикладным специалистам предприятий, и поможет им преодолеть искусственный барьер перед использованием OLAP-инструментов для подготовки разнообразной отчетности на основе ERP-систем.