5

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

Когда я читаю - в основном, работа Кимбалла, но и другие руководства, - это предложение состоит в том, что в этих случаях мы должны использовать «усохшее измерение». The Kimball Group even specifically mention it in regards to a Month dimension. Но я действительно не нахожу много информации об их реализации за этой статьей, а также краткие рецензии, которые, похоже, перефразируют его части.


Один из моих особых проблем является то, что в данный момент, люди, использующие наши кубики привыкли иметь одно измерение дат для каждого типа даты с год-месяц-день иерархии, и они просто идти только вплоть до месячного уровня, когда это то, что им нужно. Если это приведет к отдельному измерению с иерархией за год, то кажется, что это может быть неприятный беспорядок. Но это намерение?

Последние два абзаца в связанной статье - единственное, что я нашел, чтобы решить, как это должно работать на уровне презентации, и я просто не понимаю, что они пытаются описать. Мне кажется, несколько примеров, чтобы понять, как это должно появиться в кубе. Обычно я просто пробный и ошибочный, но сроки очень плотные. Итак ...

  • Если я это сделаю, каков предполагаемый дисплей в кубе? Будет ли у меня два разных формата даты, с тем, который будет только снижаться до месяца?
  • Если вышесказанное верно, есть ли в этом действительно много смысла, поскольку люди могут в настоящее время радостно запрашивать вещи на ежемесячном уровне без него? Я чувствую, что мне не хватает преимуществ на самом деле. Я вижу, что это более семантически корректно (мы на уровне месяца, поэтому первый день месяца взломан и показывает несвязанные атрибуты), но с пользователями, которые уже привыкли к этому, я не уверен, что это достаточная причина для потратьте больше времени на это только сейчас. Я вижу, что он может работать лучше, учитывая, что это будет меньший размер, но у нас нет проблем с производительностью как есть. Я что-то упускаю?
  • Если я продолжу изменения, любые советы по получению сокращенного измерения, работающего в кубе? Обычно я могу копаться в сети, пока я не сужу что-то до лучших вариантов, но там действительно мало чего, и я бы хотел услышать от кого-то, кто делал это раньше. Не ища ничего огромного, но что-то, написанное немного более технически, чем эта статья или мини-пример, вероятно, оставит меня более ясным, что нужно делать и почему. Статья Kimball особенно смутила меня при обсуждении необходимости присоединения базового измерения к уменьшенному размеру, чтобы увидеть атрибуты.

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

+2

Я пошел учиться Кимбалу и спросил об этом радость. Она в основном сказала, что они считают, что хороший инструмент аналитики имеет функции сквозной обработки в дополнение к деталям. Стек MSBI не обеспечивает эту функциональность изначально SSAS. Таким образом, мини-измерения не будут работать так, как они предполагают. Я склонен не использовать их с SSAS по этой причине, если только он не может обеспечить хорошую удобство использования. Проблема с связыванием вашего факта с существующим измерением даты - это, вероятно, уровень детализации (день), который не применим для факта на уровне месяца. – mmarie

+1

Вы правы, у вас должно быть полное измерение даты, а затем измерение месяца. Вам нужно будет обновить свои имена, чтобы соответствующим образом отразить их содержимое. Альтернативой мини-измерению является охват мер, поэтому они выходят из строя, когда вы тренируетесь на неподходящий уровень. (Это мое предложение, а не Радость.) – mmarie

+0

@mmarie - Спасибо, это отличная информация. Вероятно, объясняет, почему люди избегали использовать их здесь, и почему я изо всех сил пытаюсь найти информацию! То, что вы сказали, кажется очень ценной информацией, даже если есть другие возможные пути вперед - есть ли возможность записать его в качестве ответа? Я мог бы не сразу согласиться, чтобы посмотреть, есть ли у нас какие-то другие мысли, но, безусловно, будем голосовать, поскольку это уже было полезно. –

ответ

4

Это не ответ, и это не ответ на фанкойлы Cognos. Для сравнения я хочу подчеркнуть, как многогранные факты моделируются в других инструментах.

http://www-01.ibm.com/support/knowledgecenter/SSWGNW_8.0.0/com.ibm.swg.im.cognos.ug_best.8.4.0.doc/ug_best_id1339multi-factmulti-grainquery.html%23multi-factmulti-grainquery

http://www.cognoise.com/index.php?topic=17992.0

В первой ссылке:

  • Месячная таблица имеет месяц ключ и присоединился к месяцу в календаре таблице
  • Суточная таблица имеет дневного ключа и присоединяется к той же таблице календаря
  • Что не показывает ссылка, так это то, что вы определяете t он уровней иерархии за кулисами, так что инструмент автоматически знает, не в два раза рассчитывать данные ежемесячно на уровне
  • В результате инструмент автоматически знает, как закатать факты

Я не эксперт, но SSAS похоже, он не поддерживает такую ​​функциональность.

Если это так, то мне кажется, что нет смысла моделировать данные «правильно». Правильно я имею в виду присвоение определенного месяца факту, который определяется только на ежемесячном уровне.

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

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