Модель данных микростратегии

Я новичок в МСТ.

Мы работаем над переходом с Essbase на Microstrategy 10.2. Мы ожидаем, что после миграции бизнес-пользователи смогут создавать отчеты поверх куба MSTR и работать с данными так же, как они делали это с помощью Essbase и Excel. Мне нужна помощь в разработке модели данных для данного сценария:

FactTb:

Subcategory Revenue

1   100

2   200

3   300


DimensionTb:

Category    Subcategory

A   1

A   2

B   1

B   2

B   3

C   2

C   3

Пользователь хочет видеть доход по категориям или подкатегориям.

FactTb имеет 3 строки. Предполагая, что размер каждой строки равен 10 байтам, размер FactTb составляет 30 байтов.

Если его соединить с DimensionTb, то будет 7 строк и размер вырастет (примерно) до 70 байт.

Есть ли способ ограничить размер куба?

Отображение категории и подкатегории является статическим, и для него нет необходимости поддерживать таблицу.

Могу ли я создать/определить DimensionTb из куба (сохранить его в отчете, создать производный элемент с помощью подкатегории)?

Мы хотим ограничить размер куба, чтобы сохранить его в памяти и гарантировать, что отчет всегда будет обращаться к кубу по базе данных.


microstrategy
person Swapnil    schedule 20.04.2016    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Куб — это всего лишь результат SQL-запроса, скопированный в память для более быстрого доступа. Поскольку вы не можете себе представить результат разделения запроса на две части, то же самое и для куба.

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

Настройка VLDB может помочь уменьшить размер куба. Если вы посмотрите техническую заметку TN32540: методы интеллектуального заполнения куба в MicroStrategy 9.x, вы увидите различные варианты, по моему опыту, последний параметр (Direct loading of dimensional data and filtered fact data.) очень полезен для ускорения загрузки куба и уменьшения размера, но вы также можете попробовать другие (Normalize Intelligent Cube data in the Database).

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

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

Это безопасный способ, MicroStrategy также предлагает динамический способ сопоставления отчетов с кубами (при выполнении условий), но пользователи могут удивить даже самого тщательного дизайнера.

person mucio    schedule 26.04.2016