Кубы
Куб - это параллельное сегментирование списка ID (чаще всего - стратегического сегмента) запросами, обеспечиваемыми рядом иерархий измерений. После создания куба вы можете просматривать отчеты в виде перекрестных таблиц сегментов, которые позволяют раскрыть два измерения куба в любой данный момент времени.
Прежде чем вы сможете создать куб, вы должны выполнить следующие предварительные задачи:
*
Создать стратегический сегмент
*
Создать измерения на основе стратегического сегмента
*
К кубам применимы следующие рекомендации:
*
Метрики кубов можно задать как и любое выражение Campaign со следующими ограничениями:
*
Вы можете задать неограниченное число дополнительных числовых (NUMERIC) метрик, и Campaign вычислит их минимум, максимум, сумму и среднее. Выбранные метрики могут быть производными полями или хранимыми производными полями.
*
Функция агрегации для числа ячеек (минимум, максимум, среднее, % итога и т.п.) вычисляется автоматически.
*
Функция агрегации для значения атрибута (например, avg(age)) автоматически вычисляет минимум, максимум, сумму и среднее.
*
Выражения, содержащие несколько значений атрибутов (например, (attribute1 + attribute2)), поддерживаются в производных полях.
*
Процесс Куб поддерживает производные поля и хранимые производные поля.
*
Выражения Groupby (например, (groupby_where (ID, balance, avg, balance, (trxn_date > reference_date)))) поддерживаются в производных полях.
*
Выражения, содержащие пользовательские переменные (заданные в той же поточной диаграмме, что и процесс Куб, и открытые для Distributed Marketing), поддерживаются в производных полях и хранимых производных полях. (Более подробную информацию о Distributed Marketing смотрите в публикации Distributed Marketing: Руководство пользователя.)
*
Выражения, которые используют чистый SQL, поддерживаются в производном поле, для которого используется пользовательский макрос на основе чистого SQL.
*
Выражения, которые используют пользовательский макрос, поддерживаются в производном поле.
*
Хотя кубы содержат до трех измерений, метрики можно показать только для двух измерений одновременно. Не показанное третье измерение все равно вычисляется и сохраняется на сервере, но оно не используется в визуальном выборе/отчетах для данного конкретного отчета.
*
Кубы можно строить на основе ячеек, а также сегментов (которые, например, можно создавать на уровне транзакций). Однако, если куб построен на основе ячейки, этот куб будет доступен только в данной поточной диаграмме. Поэтому разумным шагом с вашей стороны будет строить кубы на основе стратегических сегментов.
*
Если таблицы не нормализованы, а вы зададите измерения с взаимосвязью много-много с уровнем аудитории, можно получит неожиданные результаты. Алгоритм куба, используемый компонентом Campaign, основан на нормализованных таблицах. Прежде чем вы выберете и построите куб, нормализуйте данные, произведя их объединение (до уровня покупателей через сеанс подготовки данных, например).
*
Если вы строите куб на основе ненормализованных измерений, число сумм может оказаться неправильным в отчетах в виде перекрестных таблиц из-за того, что Campaign обрабатывает ID измерений. Если вам нужно использовать ненормализованные измерения, стройте кубы только с двумя измерениями и используйте транзакции в качестве метрики низшего уровня для ненормализованных измерений, а не ID покупателей, так как сумма транзакций будет правильной.
*
При создании измерения куба нужно присвоить измерению имя, задать уровень аудитории и таблицу, соответствующую измерению. Потом при работе в поточной диаграмме сеанса или кампании вы отобразите измерение так же, как если бы вы отображали таблицу базы данных.
*
Кубы следует строить, когда пользователи к ним не обращаются, как правило, по окончании рабочего дня и по выходным.
Copyright IBM Corporation 2015. All Rights Reserved.