Построение иерархий для бизнес-областей в Power BI

Question

Я объединяю сообщения из нескольких проектов, которые различаются по степени детализации, но нужно видеть их объединенными. Например, у меня есть некоторые сообщения, которые go для всех внутри Предприятия, в то время как другие - go только для ИТ, а затем некоторые для ИТ-лидера. В настоящее время, если я нажму на ИТ-лидера, он будет отображать сообщения только для этого человека, но на самом деле они также получают сообщения для всего предприятия и для всего ИТ.

Я попытался создать иерархию в моих данных и расширении их для создания дублирующихся строк для одного и того же сообщения (например, одно сообщение, предназначенное для всех ИТ-подразделений, будет связано с двумя строками данных, помеченными как для ИТ, так и для ИТ-лидера), но я сталкиваюсь с проблемами, когда я я вижу, что отображается слишком много данных.

Есть идеи, как это сделать?

Примеры: (Нажмите на КРАСНЫЙ, и все, что идет в СЕРЫЙ, должно отобразиться на приборной панели)

Answer 1

Я могу предложить 3 варианта. У каждого есть свои плюсы и минусы.

Вариант 1: таблица фактов «Расширенный получатель»

Создание таблицы с каждой комбинацией прямых и расширенных получателей.

Расширенная Таблица получателей

Например, люди в «IT-LEADER» должны были получать сообщения, непосредственно связанные с «IT-LEADER», «ITLT» и «IT - все сотрудники», поэтому «IT -» ЛИДЕР "повторяется 3 раза с каждой из этих групп прямых получателей.

Затем вы должны создать отношения, как показано ниже. Обратите внимание, что отношения между прямым получателем и расширенным получателем имеют направление «Оба».

Теперь вы можете фильтровать сообщения на основе расширенного получателя. Для простоты в моем образце данных есть только 4 сообщения. На рисунке ниже показано, что он успешно фильтрует сообщения для различных вариантов среза расширенного получателя.

Плюсы:

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

Минусы:

Используется отношение обоих направлений , которое, как правило, вы бы хотели избежать как можно больше.

Вариант 2: таблица фактов "Получатель связи".

Вы можете выбрать удержание Таблица фактов без связей с сообщениями вместе со всеми расширенными получателями.

Например, сообщение № 1 было привязано к «ИТ - все сотрудники», поэтому получатели сообщений будут иметь 6 строк, соответствующих каждой группе в организации.

Таблица получателей сообщений

Схема будет базовой c звездной схемой с двумя таблицами измерений, одна для уникальных сообщений, в которой может быть столбец для хранения прямых получателей, и один для расширенных получателей.

Плюсы:

Это идеальная схема * звезда !

Минусы:

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

Вариант 3: отношение «многие ко многим»

Этот вариант является лишь вариантом варианта 1. Вы можете используйте отношение «многие ко многим» в направлении кросс-фильтра «Оба», чтобы напрямую соединить таблицу «Связь» и таблицу «Расширенные получатели». В этом случае вам не нужна таблица прямых получателей.

Плюсы и минусы почти такие же, как в варианте 1. Выглядит даже лаконично, но вам нужно проявлять большую осторожность в отношении потенциальной опасности в отношениях «многие ко многим» в обоих направлениях.