Моделирование куба SSAS

Вопрос об архитектуре, состоящий из двух частей:

У меня есть параметры сотрудника, должности и руководителя. Я как бы хотел сохранить их в одном измерении и иметь что-то вроде сайта> супервайзера> должности> сотрудника. Проблема в том, что это должны быть SCD. То есть у них есть исторические ассоциации, связанные с фактами. Таблицы фактов должны обрабатываться каждые пять минут (информационная панель).

1) Должен ли я иметь их в одном измерении с суррогатным ключом (или составным, если на то пошло)? Ключи / суррогатный ключ будут состоять из calendar_id - employee_id.

2) Были ли таблицы фактов содержат ссылку на три разных измерения?

Требование обрабатывать каждые 5 минут (обработка, управляемая MOLAP SSIS ETL). Заставляет меня склоняться к сохранению времени / изменения фактов, чтобы мне было легче обрабатывать измерения вместе с таблицами фактов.


olap-cube business-intelligence ssas
person Wojtek Augustynski    schedule 05.08.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я бы спроектировал его как единое измерение с упомянутой вами иерархией: сайт> руководитель> должность> сотрудник.

Назовем это измерение EmployeeAssignment, потому что его детализация - это не «Сотрудники», а любая комбинация сайта / руководителя / должности, которую сотрудник «принимает» в течение своей карьеры. (Не стесняйтесь придумывать имя получше).

Я не думаю, что вам нужен ключ calendar_id в этом измерении: будет достаточно суррогатного ключа, основанного на DISTINCT SiteID, SupervisorID, JobTitleID, EmployeeID. Добавление ключа calendar_id заставило бы измерение выполнять слишком много работы: помимо нарезки фактических фактов, это заставило бы измерение отвечать на такие вопросы, как

«Где был идентификатор сотрудника 12345 (в сети сайта / руководителя / должности) 1 января 2015 года?» и «Сколько сотрудников контролировал supervisorID 98765 на 1 января 2015 года?»

На эти вопросы, ИМХО, лучше всего отвечать с учетом фактов, а не измерения. Один куб, с которым я работал с адресами с помощью меры EmployeeDay: разрезанный по измерениям «EmployeeAssignment» и «Время», у него просто 1, если в этот день сотрудник выполняет это «задание».

Этот SCD EmployeeAssignment на самом деле довольно медленно меняется, особенно по сравнению с 5-минутным интервалом обновления фактов. Сотрудники не собираются перемещаться или получать повышение каждые 5 минут, поэтому повторная обработка измерения не должна требоваться чаще, чем ежедневно.

Если я что-то неправильно понял, дайте мне знать в комментариях.

person SebTHU    schedule 05.08.2015
comment
Мне это нравится. Компромисс на середине пути, который все еще позволяет мне поддерживать иерархию. Я все еще думаю, что мне нужно проверить, нужно ли обновлять и обрабатывать измерение перед обработкой фактов, но я обрабатываю измерение (через ssis) только в том случае, если было выполнено обновление в employeeAssignment. - person Wojtek Augustynski; 06.08.2015