OLAP-куб. Дополнение третьего измерения

Записаться

1. Завершение измерения «Клиент»

Перед последним измерением «Продукт» (Product) в измерение «Клиент» (Customer) нужно добавить атрибут Дата первой покупки (Date First Purchase). Это первая дата покупки в магазине. Добавляется простым переносом поля. После сохранения переходим к измерению «Продукт» (Product). Источник раскрывается полностью, пока перенесён только ключ.

2. Создание измерения «Продукт»

Переносим атрибуты товара:

• Стандартная стоимость (Standard Cost)
• Уровень страхового запаса (Safety Stock Level)
• Точка повторного заказа (Reorder Point)
• Прайсовая цена (List Price)
• Размер (Size)
• Диапазон размеров (Size Range)
• Вес (Weight)
• Товарная линейка (Product Line)
• Дилерская цена (Dealer Price)
• Класс (Class)
• Стиль (Style)
• Название модели (Model Name)
• Дата начала (Start Date)
• Дата окончания (End Date)
• Статус (Status)

Нужно знать, продаётся товар до сих пор или нет, поэтому важен статус. Даты начала и окончания позволяют проверить, что на момент покупки товар был актуален. Сохраняем список атрибутов. Измерение «Продукт» готово.

3. Промежуточный результат и его отличие от SELECT

На этом этапе создан проект: структура OLAP-куба (OLAP cube), указанные измерения (dimensions), подмножество полей из исходных больших измерений. Может показаться, что задача решается обычным запросом SELECT: выбрать не всё, а часть информации. То есть пока мы лишь сократили объём выборки. Но это не так. Ещё не показана интеллектуальная компонента, которая даёт мгновенный быстрый доступ к мерам (measures) из таблицы фактов (fact table) на основании фильтров или условий по измерениям. Этот механизм ускорения уже реализован в фоне, но не виден явно. OLAP-куб умнее, чем схема «звезда» (star schema) или «снежинка» (snowflake schema). Схема «снежинка» подходит для хранения, но когда важен вопрос быстродействия, OLAP-куб существенно превосходит прямой SELECT-запрос к схеме «звезда» или «снежинка».

4. OLAP-куб, MDX и производительность

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

5. Распараллеливание и иерархии

На кубе далее создаются иерархии (hierarchies). Они позволяют значительно быстрее и эффективнее работать с данными. Поэтому происходящее не сводится к простому набору фильтров: за этим стоит создание сложных структур.

Краткие итоги

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

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

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

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

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