Гранулярность кубической меры меняется со временем

Наш ИТ-менеджер попросил меня создать среду SSAS, в которой одни и те же данные хранятся с разной степенью детализации в зависимости от того, сколько им лет.

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

Возможно ли это даже внутри одного куба? Мои исследования показывают, что это не так. Глава нашего ИТ-отдела говорит, что в его предыдущей компании они могли делать что-то в этом направлении, но это могло быть неверным истолкованием того, что происходило за кулисами, поскольку он не слишком технический. Это первый куб, который наша компания построила для производства, и никто из нас этого не делал раньше, но мне интересна тема для развития моей молодой карьеры, и я беру на себя инициативу. Я считаю, что если это невозможно внутри одного куба, то поддержка нескольких кубов фактически потребует больше работы для нас, разработчиков, и больше работы для сервера. Не говоря уже о дополнительных сложностях для пользователей.

Итак, возможно ли это внутри одного куба? Если нет, есть ли какие-то преимущества в его реализации с использованием нескольких кубов, или мы должны просто забыть об этом (не тот ответ, с которым я бы хотел вернуться, но это то, что есть)? В настоящее время мы работаем с 2008R2, но скоро обновимся до 2014 года. Есть ли в этом отношении разница между многомерной и табличной моделями?


person user3266693    schedule 07.05.2014    source источник


Ответы (2)


Я думаю, что это возможно - вы рассматривали SSAS Tabular? http://www.daxpatterns.com/handling-different-granularities/

-С уважением, MikeB

person user3613067    schedule 07.05.2014

Вы можете сделать что-нибудь в следующем духе:

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

    week       month   quarter  year
(2012)      (2012)     (2012)   2012
(Q1/2013)   (Q1/2013)  Q1/2013  2013
(Q2/2013)   (Q2/2013)  Q2/2013  2013
(Q3/2013)   (Q3/2013)  Q3/2013  2013
(Q4/2013)   (Q4/2013)  Q4/2013  2013
(Jan 2014)  Jan 2014   Q1/2014  2014
(Feb 2014)  Feb 2014   Q1/2014  2014
(Mar 2014)  Mar 2014   Q1/2014  2014
(Apr 2014)  Apr 2014   Q2/2014  2014
w18/2014    May 2014   Q2/2014  2014
w19/2014    May 2014   Q2/2014  2014
w20/2014    May 2014   Q2/2014  2014

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

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

person FrankPl    schedule 07.05.2014
comment
Думаю, это сработает. По сути, если я вас правильно понимаю, в рамках обновления хранилища данных, лежащего в основе куба, убедитесь, что измерение даты имеет только один день для каждой недели в прошлом месяце, один день для каждого месяца в последнем квартале и один день для каждый квартал за последние три года. Тем временем обновите даты в таблицах, связанных с измерением даты, чтобы все они соответствовали этой конкретной дате (например, первому дню этого периода). - person user3266693; 07.05.2014
comment
Или, может быть, просто обновите другие даты и оставьте само измерение даты в покое. В сочетании с советом Майка Б. это должно привести к красивой презентации. Я как бы оговорился раньше, b / c я хотел бы сохранить фактическую дату, просто агрегировать ее на более высоком уровне, но это будет служить фактической датой, которая все равно будет храниться в другом месте. - person user3266693; 07.05.2014