Создаем OLAP куб. Часть 1

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

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

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

Немного теории.

По сути, Data Warehouse может быть:

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

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

Каким же должен быть Data Warehouse?

Все очень просто – ваш Data Warehouse должен иметь структуру формы звездочки (star model) или снежинки (snowflake model) и состоять из фактов (facts) и измерений (dimensions).

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

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

Определив где у нас факты, а где измерения — очень просто построить модель звезды.

Звезда.

В центре указываем нашу таблицу фактов, а лучами выводим измерения.

А теперь снежинка.

Снежинка — это та же звезда, только измерения могут зависеть от измерений следующего уровня, а те в свою очередь могут включать еще уровни.


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

HabraDW.

Перейдем к собственно разработке нашего Data Warehouse-а.

Наша цель – анализ тенденций голосования на Хабре, нахождение закономерностей и трендов.
Основные тенденции, которые мы хотим определить:

• в какое время года/месяца/недели голосуют лучше/хуже/чаще
• как голосуют по пятницам и понедельникам (например)
• как влияет на результат голосования наличие в посте слов Microsoft, или Карма
• средняя активность пользователей, «пики» голосования
• и т.п.

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

В итоге, имеем следующие таблицы:

• Таблица фактов FactHabravote – определяет кто, когда, за что и как именно проголосовал. Значение Vote в нашем случае будет +- 1, но тип поля позволяет расширить дельту голосами, например, +- 10
• Измерение времени DimTime – определяет нужные для анализа атрибуты времени (значения и названия)
• Измерение пользователей DimUser – определяет пользователей Хабра, пока только никнейм
• Измерение постов DimPost – определяет посты, в нашем случае содержит заголовок и булевые поля, определяющие содержит ли пост слова Microsoft и Карма.

Итоговая схема нашей звезды будет такой.

А здесь исходный SQL скрипт, который создает и наполняет (пока что только случайными данными) наше хранилище.

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