Некоторое время назад мне довелось организовывать новую группу разработки, которая должна была заняться развитием OLAP и BI продуктов в дружеской софтверной компании. А так как группа была собрана из свежих выпускников ВУЗов, то мне пришлось написать «краткий курс молодого бойца» для того чтобы максимально доступно дать начальные понятия об OLAP людям, которые ни разу с ним не сталкивались, но уже имели опыт программирования и работы с БД.

Выкладываю теперь это Введение в Общественное Достояние.

В статье несколько смешиваются понятия OLAP, Business Intelligence, и Data Warehouse, но и в жизни часто сложно понять, где проходит граница. А уж в реальных проектах, так и подавно, все они ходят рядом. Поэтому прошу не судить строго.

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

Essbase для DataWarehouse занимает место многомерных витрин, которые позволяют рассчитать комплексные экономические показатели, построить прогноз, предоставить максимально быстро AD-hoc отчетность. Essbase позволяет без задержек обслуживать многие тысячи пользователей, без особых настроек. Вы забудете про планы запросов, и как тюнить быстродействие того или иного отчета.

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

На данный момент ( февраль 2011) текущей версией является 11.1.2, в которой Oracle и Hyperion в очередной раз сделали большой шаг в сторону интеграции и усложнили в разы инфраструктуру приложения. Эта версия подойдет для тех, кто уже знаком с системой и понимает все архитектурные особенности. Процесс ее инсталляции подробно рассмотрен на тематических блогах.

Я же предлагаю для знакомства с OLAP Oracle Essbase движком использовать предыдущую версию 9.3, которая в части OLAP ядра, мало чем отличается от своего старшего брата, так как процесс настраивания дополнительных компонент в 11 версии (которые ставятся в нагрузку) может занять достаточно много времени, и ресурсов.

Соответственно процесс установки можно разделить на три этапа

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

По следам этого поста.

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

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

Итак, продолжаем создавать куб.
Напомню, что в предыдущей статье, мы создавали Data Warehouse для хранения голосов хабра-пользователей за хабра-топики. Для тех, кто хочет начать сразу создавать куб, я выложил скрипт, который создает и наполняет хранилище (на моей машине скрипт занял 10 минут и нагенерил 1866268 хабра-голосов).
Для того, чтобы создать OLAP куб, нам понадобится:

• SQL Server, на котором хранится наш HabraDW (подойдет любой);
• Microsoft SQL Server, с запущенными Analysis Services (2005/2008);
• Business Intelligence Studio, которая входит в пакет клиентских приложений для Microsoft SQL Server-а, и интегрируется с Visual Studio, если она у вас установлена (2005/2008);

Продолжая тематику Многомерные кубы, OLAP и MDX и olap для маленькой компании, традиционно, предлагаю начать с простенького «Hello World» куба, который будет анализировать процессы и тенденции голосований на Хабре.

Итак, давайте попробуем создать свою первую OLAP систему.
Но, прежде чем, потирая руки, запускать Business Intelligence Studio, предлагаю вначале создать хранилище данных хабра-голосов, так называемый Data Warehouse.
Зачем? Причин в этом несколько:

• сама суть Data Warehouse-а хранить «очищенные» данные, готовые для анализа, поэтому даже его изначальная структура может сильно отличаться от структуры нашей хабра-OLTP базы данных
• в HabraDW (так мы его назовем) мы вынесем только ту информацию, которая нам нужна будет для анализа, ничего лишнего
• к Data Warehouse не накладываются требования нормализации. Даже наоборот, денормализировав некоторые данные можно добиться более понятной схемы для построения куба, а также скорости загрузки данных в куб